Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > de.comp.sys.mac.misc > #80664 > unrolled thread

Ein paar Gedanken zu SD-Karten-Sicherungen

Back to article view | Back to de.comp.sys.mac.misc

Contents

  Ein paar Gedanken zu SD-Karten-Sicherungen Başar Alabay <alabay@gmx.net> - 2024-10-03 10:41 +0000
    Re: Ein paar Gedanken zu SD-Karten-Sicherungen Başar Alabay <alabay@gmx.net> - 2024-10-03 11:38 +0000
      Re: Ein paar Gedanken zu SD-Karten-Sicherungen Steffen Bendix <unbeliebte2000-usenetspam@yahoo.de> - 2024-10-03 16:57 +0000
        Re: Ein paar Gedanken zu SD-Karten-Sicherungen Başar Alabay <alabay@gmx.net> - 2024-10-03 20:15 +0000
    Re: Ein paar Gedanken zu SD-Karten-Sicherungen "T." <nospam@godawa.invalid> - 2024-10-04 12:11 +0200
      Re: Ein paar Gedanken zu SD-Karten-Sicherungen Başar Alabay <alabay@gmx.net> - 2024-10-04 11:22 +0000
        Re: Ein paar Gedanken zu SD-Karten-Sicherungen "T." <nospam@godawa.invalid> - 2024-10-04 22:11 +0200
        Re: Ein paar Gedanken zu SD-Karten-Sicherungen "T." <nospam@godawa.invalid> - 2024-10-04 22:11 +0200
        Re: Ein paar Gedanken zu SD-Karten-Sicherungen "T." <nospam@godawa.invalid> - 2024-10-04 22:11 +0200
          Re: Ein paar Gedanken zu SD-Karten-Sicherungen Başar Alabay <alabay@gmx.net> - 2024-10-10 08:46 +0000
            Re: Ein paar Gedanken zu SD-Karten-Sicherungen "T." <nospam@godawa.invalid> - 2024-10-10 11:51 +0200
        Re: Ein paar Gedanken zu SD-Karten-Sicherungen "T." <nospam@godawa.invalid> - 2024-10-04 22:11 +0200
        Re: Ein paar Gedanken zu SD-Karten-Sicherungen "T." <nospam@godawa.invalid> - 2024-10-04 22:11 +0200

#80664 — Ein paar Gedanken zu SD-Karten-Sicherungen

Juten Morjen in die Runde,

nachdem letztens eine SD-Karte aus meinem RPi anscheinend doch etwas
schwächelte, ich neue Karten besorgte (32 GB), dann jedoch, hoppla, das
Image der Vorangängerkarte einen Ticken zu groß war … kam ich ins
Rödeln, löste die Probleme, stieß auf neue Ideen – und würde diese gerne
diskutieren.

Bisher fertige ich wöchentlich oder in kürzeren Abständen Abbilder der
32 GB SD-Karte an, indem ich Folgendes tu:

1. Ich packe die SD-Karte mit einem Kartenleser an den Rechner.
2. Im CLI kommt ein su zum Administrator, danach geht es weiter mit:
3. diskutil list (da sehe ich dann die Nummer).
4. sudo diskutil unmountDisk diskX
5. sudo e2fsck -fvy -C 0 /dev/diskXs2
6. sudo dcfldd if=/dev/rdiskX sizeprobe=if | gzip >
/Volumes/Platte/Ablageort/tempnixtimemachine/Name_JJJMMTT.dd.gz

Und danach habe ich ein Archiv, das etwas über 7 GB groß ist.

Zurückschreiben kann ich das bei Bedarf mit:

7. sudo gzcat
/Volumes/Platte/Ablageort/Name_JJJJMMTT.dd.gz | sudo dd
bs=8m of=/dev/rdiskX (verschoben aus tempnixtimemachine)

Da es nun tatsächlich kürzlich beim Umstieg von einer Samsung auf eine
SanDisk SD-Karte klemmte, fand ich – traraaa! – ApplePiBaker. Das kannte
ich nicht. Dort konnte ich das vorliegende Archiv/Image mit der
Funktion, die Linux-Partition aufs Nötigste einzudampfen, auf die
minimal kleinere SD-Karte spielen. Toll.

Dieses ApplePiBaker kann – ebenfalls mit diesem Shrinken, wenn man will
– auch die SD-Karte in ein Image/Archiv schreiben. Was mir da dann aber
fehlt, ist der obige Schritt 5 mit e2fsck. Was interessant ist, weil
nämlich genau das in diesem Programm als Bestandteil des Bundles mit
drin ist. Vielleicht nutzt es das intern nach z. B. Shrinks.

Da ApplePiBaker nun aber auch 7z als Endprodukt anbot, kam mir die Idee,
ob ich nicht vom gzip in Schritt 6 auf 7z umsteigen könnte. Kann ich,
wie ich festgestellt habe. Via Macports p7zip installieren, und ich habe
7z. Jut.

Dann sieht Schritt 6 so aus:

6a. sudo dcfldd if=/dev/rdiskX bs=32M sizeprobe=if | 7z a -si
/Volumes/Platte/Ablageort/tempnixtimemachine/Name_JJJJMMTT.tar.7z

Das mit tar statt dd habe ich im Netz gelesen. Wäre bereits die erste
Frage … ist tar.7z das gleiche wie dd.7z oder nicht?

So, und da ware das Zurückspielen dann vermutlich (habe ich noch nicht
gemacht, das Ganze braucht ja Zeit):

7a. sudo 7z x -so  
/Volumes/Platte/Ablageort/Name_JJJJMMTT.tar.7z | sudo dd
bs=8m of=/dev/rdiskX (verschoben aus tempnixtimemachine)

Die Frage wäre, ob bs=8m sinnvoll ist oder auch bs=32M sein
könnte/sollte.

ApplePiBakery hat mir jedenfalls samt Shrinkgedöns eine 7z-Datei
ausgeworfen, die 5,7 GB groß ist. Das ging aber fast eineinhalb Stunden.

Meine alte Methode gibt (wie gehabt) eine .dd.gz-Datei aus, die 7,2 GB
groß ist … bei ungefähr einer halben Stunde.

Die "neue" 7z-Methode gibt in weniger als einer halben Stunde (15–20
Minuten?) eine .tar.7z-Datei von 6 GB aus.

Shrinken ist an sich nicht nötig, bis es mal wieder eine SD-Karte gibt,
bei der ein paar Megabyte fehlen, dann kann ApplePiBakery gerne
eindampfen und ausdampfen.

Nun die Frage: Ist es sinnvoll von gzip/gzcat auf 7z umzusteigen? Ist es
okay, bs=32M zu nutzen? Sollte dann das bs=8m verändert werden?

Ich habe, ich weiß nicht mehr, warum, fürs Sichern dcfldd genutzt, fürs
Zurückspielen nur dd. Ich glaube, das hatte was mit der Zeitanzeige zu
tun, die ich bei dcfldd schick finde.

So, mal wieder ein Mac-Thread, der Macianer, Linuxer und Unixoide
gleichermaßen ansprechen könnte ;-)

B. Alabay

[toc] | [next] | [standalone]

#80665

Başar Alabay schrieb am 03.10.2024, 12:41 h:

Ein paar Nachträge zu unten stehendem:

Unterschied dcfldd zu dd: 32M bei ersterem, 32m bei zweiterem. Seltsam,
daß es so kleine Unterschiede gibt.

Punkt 7a. erfolgreich getestet. Allerdings habe ich.tar.7z zu .dd.7z
geändert, um der alten Namenstradition Rechnung zu tragen.

Ich könnte beim Zurückspielen dd auch mit dcfldd ersetzen, dann wäre
auch dieser Murx mit M bei einem entspricht (nur) m beim anderen gelöst.
Die große Frage wäre: Könnte man auch eine Anzeige mit Sizeprobe
bekommen, wenn der Input via Pipe von 7z kommt? dcfldd weiß ja nicht,
was noch kommen wird, es kommt einfach, bis es zu Ende ist … aber ich
weiß, daß es 32 GB sein werden. Kann man das mit BYTES realisieren?

Auf alle Fälle scheint 7z schneller und besser zu komprimieren als gzip.
Das ist schon einmal eine große Erkenntnis für zukünftige
SD-Karten-Abbilder.

B. Alabay 

> Juten Morjen in die Runde,
> 
> nachdem letztens eine SD-Karte aus meinem RPi anscheinend doch etwas
> schwächelte, ich neue Karten besorgte (32 GB), dann jedoch, hoppla, das
> Image der Vorangängerkarte einen Ticken zu groß war … kam ich ins
> Rödeln, löste die Probleme, stieß auf neue Ideen – und würde diese gerne
> diskutieren.
> 
> Bisher fertige ich wöchentlich oder in kürzeren Abständen Abbilder der
> 32 GB SD-Karte an, indem ich Folgendes tu:
> 
> 1. Ich packe die SD-Karte mit einem Kartenleser an den Rechner.
> 2. Im CLI kommt ein su zum Administrator, danach geht es weiter mit:
> 3. diskutil list (da sehe ich dann die Nummer).
> 4. sudo diskutil unmountDisk diskX
> 5. sudo e2fsck -fvy -C 0 /dev/diskXs2
> 6. sudo dcfldd if=/dev/rdiskX sizeprobe=if | gzip >
> /Volumes/Platte/Ablageort/tempnixtimemachine/Name_JJJMMTT.dd.gz
> 
> Und danach habe ich ein Archiv, das etwas über 7 GB groß ist.
> 
> Zurückschreiben kann ich das bei Bedarf mit:
> 
> 7. sudo gzcat
> /Volumes/Platte/Ablageort/Name_JJJJMMTT.dd.gz | sudo dd
> bs=8m of=/dev/rdiskX (verschoben aus tempnixtimemachine)
> 
> Da es nun tatsächlich kürzlich beim Umstieg von einer Samsung auf eine
> SanDisk SD-Karte klemmte, fand ich – traraaa! – ApplePiBaker. Das kannte
> ich nicht. Dort konnte ich das vorliegende Archiv/Image mit der
> Funktion, die Linux-Partition aufs Nötigste einzudampfen, auf die
> minimal kleinere SD-Karte spielen. Toll.
> 
> Dieses ApplePiBaker kann – ebenfalls mit diesem Shrinken, wenn man will
> – auch die SD-Karte in ein Image/Archiv schreiben. Was mir da dann aber
> fehlt, ist der obige Schritt 5 mit e2fsck. Was interessant ist, weil
> nämlich genau das in diesem Programm als Bestandteil des Bundles mit
> drin ist. Vielleicht nutzt es das intern nach z. B. Shrinks.
> 
> Da ApplePiBaker nun aber auch 7z als Endprodukt anbot, kam mir die Idee,
> ob ich nicht vom gzip in Schritt 6 auf 7z umsteigen könnte. Kann ich,
> wie ich festgestellt habe. Via Macports p7zip installieren, und ich habe
> 7z. Jut.
> 
> Dann sieht Schritt 6 so aus:
> 
> 6a. sudo dcfldd if=/dev/rdiskX bs=32M sizeprobe=if | 7z a -si
> /Volumes/Platte/Ablageort/tempnixtimemachine/Name_JJJJMMTT.tar.7z
> 
> Das mit tar statt dd habe ich im Netz gelesen. Wäre bereits die erste
> Frage … ist tar.7z das gleiche wie dd.7z oder nicht?
> 
> So, und da ware das Zurückspielen dann vermutlich (habe ich noch nicht
> gemacht, das Ganze braucht ja Zeit):
> 
> 7a. sudo 7z x -so  
> /Volumes/Platte/Ablageort/Name_JJJJMMTT.tar.7z | sudo dd
> bs=8m of=/dev/rdiskX (verschoben aus tempnixtimemachine)
> 
> Die Frage wäre, ob bs=8m sinnvoll ist oder auch bs=32M sein
> könnte/sollte.
> 
> ApplePiBakery hat mir jedenfalls samt Shrinkgedöns eine 7z-Datei
> ausgeworfen, die 5,7 GB groß ist. Das ging aber fast eineinhalb Stunden.
> 
> Meine alte Methode gibt (wie gehabt) eine .dd.gz-Datei aus, die 7,2 GB
> groß ist … bei ungefähr einer halben Stunde.
> 
> Die "neue" 7z-Methode gibt in weniger als einer halben Stunde (15–20
> Minuten?) eine .tar.7z-Datei von 6 GB aus.
> 
> Shrinken ist an sich nicht nötig, bis es mal wieder eine SD-Karte gibt,
> bei der ein paar Megabyte fehlen, dann kann ApplePiBakery gerne
> eindampfen und ausdampfen.
> 
> Nun die Frage: Ist es sinnvoll von gzip/gzcat auf 7z umzusteigen? Ist es
> okay, bs=32M zu nutzen? Sollte dann das bs=8m verändert werden?
> 
> Ich habe, ich weiß nicht mehr, warum, fürs Sichern dcfldd genutzt, fürs
> Zurückspielen nur dd. Ich glaube, das hatte was mit der Zeitanzeige zu
> tun, die ich bei dcfldd schick finde.
> 
> So, mal wieder ein Mac-Thread, der Macianer, Linuxer und Unixoide
> gleichermaßen ansprechen könnte ;-)
> 
> B. Alabay

[toc] | [prev] | [next] | [standalone]

#80667

Ich benutze ApplePi Baker schon sehr lange und lasse es ausschließlich eine
.img Datei erstellen. Das geht am schnellsten und funktioniert beim
Zurückspielen zuverlässig. Ich habe es in der Vergangenheit auch mal mit einer
Komprimierung versucht. Dauert aber ewig.

Steffen

[toc] | [prev] | [next] | [standalone]

#80674

Steffen Bendix schrieb am 03.10.2024, 18:57 h:

> Ich benutze ApplePi Baker schon sehr lange und lasse es ausschließlich eine
> .img Datei erstellen. Das geht am schnellsten und funktioniert beim
> Zurückspielen zuverlässig. Ich habe es in der Vergangenheit auch mal mit einer
> Komprimierung versucht. Dauert aber ewig.

Ich bin die letzten zehn Jahre grundsätzlich zu Fuß gegangen und werde
das womöglich auch so beibehalten. Das Komprimieren war aber von Anfang
an dabei – halt mit gzip. Ich bin von der 7z-Variante ganz angetan. Ohne
Shrinken ist das reine Komprimieren – on the fly – kein Zeitding. 32 GB
auf 5–7 GB in 25–30 Minuten. Als *.dd.gz oder *.dd.7z.

B. Alabay

[toc] | [prev] | [next] | [standalone]

#80677

Başar Alabay schrieb:
> nachdem letztens eine SD-Karte aus meinem RPi anscheinend doch etwas
> schwächelte, ich neue Karten besorgte (32 GB), dann jedoch, hoppla, das
...
> Bisher fertige ich wöchentlich oder in kürzeren Abständen Abbilder der
> 32 GB SD-Karte an, indem ich Folgendes tu:

ganz spontan würde ich sagen, dass die Erstellung eines SD-Karten-Images 
der Raspi-Installation "etwas" aufwändig ist, in jeder Hinsicht.

Du musst den Raspi ausschalten, SD-Karte rausziehen, in den Rechner 
stecken, Image erstellen und dann wieder zurück in den Raspi und den 
wieder starten. Und das wöchentlich oder sogar noch öfter und das alles 
per Hand.

Ich gehe davon aus, dass Du ein ganz normales Raspi-Image benutzt, eine 
Reihe von Paketen installiert hast und dann noch einiges konfiguriert 
hast, alle Daten landen im home-Verzeichnis.

Der bessere Weg dürfte sein, die ganze Installation und Konfiguration zu 
automatisieren, entweder mit Ansible oder einfach per bash-Script und 
nur die Daten selbst zu sichern, im einfachsten Fall nur das 
home-Verzeichnis, automatisch.

Fällt die SD-Karte aus, ein (aktuelles) Standard-Image auf eine neue 
SD-Karte schreiben, dann die automatisierte Installation durchlaufen 
lassen und abschließend das home zurückspielen. Dann spielt auch die 
Größe der SD-Karte keine Rolle, muss nur groß genug sein um alle Daten 
plus Reserve aufnehmen zu können.


> ApplePiBakery hat mir jedenfalls samt Shrinkgedöns eine 7z-Datei
> ausgeworfen, die 5,7 GB groß ist. Das ging aber fast eineinhalb Stunden.
> 
> Meine alte Methode gibt (wie gehabt) eine .dd.gz-Datei aus, die 7,2 GB
> groß ist … bei ungefähr einer halben Stunde.
> 
> Die "neue" 7z-Methode gibt in weniger als einer halben Stunde (15–20
> Minuten?) eine .tar.7z-Datei von 6 GB aus.

Ich glaube, dass der Unterschied ob gzip oder 7zip nicht wirklich eine 
Rolle spielt, aber klar, je schneller das Backup erledigt ist, desto 
besser. Allerdings würde ich grundsätzlich noch ein Verify anschließen.

-- 

Gruesse,

Thorolf

[toc] | [prev] | [next] | [standalone]

#80679

T. schrieb am 04.10.2024, 12:11 h:

> Başar Alabay schrieb:
>> nachdem letztens eine SD-Karte aus meinem RPi anscheinend doch etwas
>> schwächelte, ich neue Karten besorgte (32 GB), dann jedoch, hoppla, das
> ...
>> Bisher fertige ich wöchentlich oder in kürzeren Abständen Abbilder der
>> 32 GB SD-Karte an, indem ich Folgendes tu:
> 
> ganz spontan würde ich sagen, dass die Erstellung eines SD-Karten-Images 
> der Raspi-Installation "etwas" aufwändig ist, in jeder Hinsicht.
> 
> Du musst den Raspi ausschalten, SD-Karte rausziehen, in den Rechner 
> stecken, Image erstellen und dann wieder zurück in den Raspi und den 
> wieder starten. Und das wöchentlich oder sogar noch öfter und das alles 
> per Hand.

Das stimmt. Allerdings hat das auch etwas Rituelles :-) Samstags,
Kaffee, Großaufwasch von anderen Rechnern und ihren Backups etc.

> Ich gehe davon aus, dass Du ein ganz normales Raspi-Image benutzt, eine 
> Reihe von Paketen installiert hast und dann noch einiges konfiguriert 
> hast, alle Daten landen im home-Verzeichnis.

Das ist ein headless Server. Raspbian, Debian 11. Zusätzlich habe ich
noch ein Repository für ein Monitoring System.

Ich weiß eben nicht, ob alles in /home landet. Da ich in den letzten 10
Jahren soviel getweakt habe, daß ich schon gar nicht mehr weiß, wo was …
ist mir das ein gewisses Risiko. Es wäre schön, wenn alles an einem Ort
wäre, aber ich nehme an, daß rechnerrelevante Dinge auch an anderen
Orten abgelegt sind. Jedenfalls fragten mich vergangene (rollierende)
Systemupdates schon, ob ich die modifizierten Files beibehalten wolle.
 
> Der bessere Weg dürfte sein, die ganze Installation und Konfiguration zu 
> automatisieren, entweder mit Ansible oder einfach per bash-Script und 
> nur die Daten selbst zu sichern, im einfachsten Fall nur das 
> home-Verzeichnis, automatisch.

Ich habe auch noch einen rsync-Weg eingerichtet gehabt, aber sehr lange
nicht mehr genutzt. Eben weil ich dann die »auf Nummer sich«
Einfach-Variante gehen wollte. Wenn etwas schiefläuft, Image
zurückspielen, und jut is.

Der π läuft 24/7, die Rechner, von denen aus ich ihn anspreche aber
nicht.
 
> Fällt die SD-Karte aus, ein (aktuelles) Standard-Image auf eine neue 
> SD-Karte schreiben, dann die automatisierte Installation durchlaufen 
> lassen und abschließend das home zurückspielen. Dann spielt auch die 
> Größe der SD-Karte keine Rolle, muss nur groß genug sein um alle Daten 
> plus Reserve aufnehmen zu können.
> 
>> ApplePiBakery hat mir jedenfalls samt Shrinkgedöns eine 7z-Datei
>> ausgeworfen, die 5,7 GB groß ist. Das ging aber fast eineinhalb Stunden.
>> 
>> Meine alte Methode gibt (wie gehabt) eine .dd.gz-Datei aus, die 7,2 GB
>> groß ist … bei ungefähr einer halben Stunde.
>> 
>> Die "neue" 7z-Methode gibt in weniger als einer halben Stunde (15–20
>> Minuten?) eine .tar.7z-Datei von 6 GB aus.
> 
> Ich glaube, dass der Unterschied ob gzip oder 7zip nicht wirklich eine 
> Rolle spielt, aber klar, je schneller das Backup erledigt ist, desto 
> besser. Allerdings würde ich grundsätzlich noch ein Verify anschließen.

Ah, sehr gute Idee! Wie würdest Du das machen? Mit einem separaten 7z -t
Lauf nach dem Packen, on the fly und/oder mit Hash? Die Frage ist auch,
was genau verifyen – im Falle von 7z scheinen die Archive recht sicher
zu sein.

B. Alabay 

[toc] | [prev] | [next] | [standalone]

#80684

Başar Alabay schrieb:
> Das ist ein headless Server. Raspbian, Debian 11. Zusätzlich habe ich
> noch ein Repository für ein Monitoring System.

die meisten Raspis dürften Headless sein, ebenso wie die meisten Server. 
Macht ja sonst oft auch wenig Sinn, wenn die dauerhaft laufen sollen.

> Ich weiß eben nicht, ob alles in /home landet. Da ich in den letzten 10
> Jahren soviel getweakt habe, daß ich schon gar nicht mehr weiß, wo was …
> ist mir das ein gewisses Risiko. Es wäre schön, wenn alles an einem Ort
> wäre, aber ich nehme an, daß rechnerrelevante Dinge auch an anderen
> Orten abgelegt sind. Jedenfalls fragten mich vergangene (rollierende)
> Systemupdates schon, ob ich die modifizierten Files beibehalten wolle.

Grundsätzlich, wo sich die Daten befinden, sollte man über die 
Konfig-Dateien der einzelnen Dienste herausbekommen und man weiß ja 
hoffentlich was da läuft und wie man es konfiguriert hat.

Wenn ich das oben aber lese, habe ich da so meine Zweifel und würde 
grundsätzlich empfehlen eine neue, anständig dokumentierte Installation 
durchzuführen und das auch gleich in ein Ansible gießen.

Ist erstmal relevanter Mehraufwand, aber auf Dauer ganz sicher die 
weniger aufwändige Lösung wenn's um Backup und Restore geht.

Für's Backup würde ich Restic empfehlen, das braucht als Ziel nur einen 
SSH-Zugang mit Key und kann alles, was man von einem modernen 
Backup-Mechanismus erwartet.

> Der π läuft 24/7, die Rechner, von denen aus ich ihn anspreche aber
> nicht.

Ähhh, Du erstellst ein Image der Installation während der Raspi läuft? 
Wie stellst Du sicher, dass sich die Daten während des Backups nicht 
ändern, z.B. bei Datenbanken wenn geschrieben wird?

> Ah, sehr gute Idee! Wie würdest Du das machen? Mit einem separaten 7z -t
> Lauf nach dem Packen, on the fly und/oder mit Hash? Die Frage ist auch,
> was genau verifyen – im Falle von 7z scheinen die Archive recht sicher
> zu sein.

Naja, nach dem Erstellen des Images nochmal einen Vergleich mit den 
gleichen Parametern zwischen Quelle und Ziel. Das geht natürlich nur, 
wenn sich die Daten in der Zwischenzeit nicht ändern, was bei einem 24/7 
laufenden System eher unmöglich ist.

Was meinst Du mit "Hash"? Von jeder gesicherten Datei einen Hash 
erstellen und mit dem Hash im Backup vergleichen? Kann man sicher auch 
machen, hört sich aber aufwändiger an, als wann man das Backup-Programm 
einfach für's Vergleichen startet, was dann jede gesicherte Datei 
nochmal liest und mit der im Backup vergleicht.

-- 

Gruesse,

Thorolf

[toc] | [prev] | [next] | [standalone]

#80685

Başar Alabay schrieb:
> Das ist ein headless Server. Raspbian, Debian 11. Zusätzlich habe ich
> noch ein Repository für ein Monitoring System.

die meisten Raspis dürften Headless sein, ebenso wie die meisten Server. 
Macht ja sonst oft auch wenig Sinn, wenn die dauerhaft laufen sollen.

> Ich weiß eben nicht, ob alles in /home landet. Da ich in den letzten 10
> Jahren soviel getweakt habe, daß ich schon gar nicht mehr weiß, wo was …
> ist mir das ein gewisses Risiko. Es wäre schön, wenn alles an einem Ort
> wäre, aber ich nehme an, daß rechnerrelevante Dinge auch an anderen
> Orten abgelegt sind. Jedenfalls fragten mich vergangene (rollierende)
> Systemupdates schon, ob ich die modifizierten Files beibehalten wolle.

Grundsätzlich, wo sich die Daten befinden, sollte man über die 
Konfig-Dateien der einzelnen Dienste herausbekommen und man weiß ja 
hoffentlich was da läuft und wie man es konfiguriert hat.

Wenn ich das oben aber lese, habe ich da so meine Zweifel und würde 
grundsätzlich empfehlen eine neue, anständig dokumentierte Installation 
durchzuführen und das auch gleich in ein Ansible gießen.

Ist erstmal relevanter Mehraufwand, aber auf Dauer ganz sicher die 
weniger aufwändige Lösung wenn's um Backup und Restore geht.

Für's Backup würde ich Restic empfehlen, das braucht als Ziel nur einen 
SSH-Zugang mit Key und kann alles, was man von einem modernen 
Backup-Mechanismus erwartet.

> Der π läuft 24/7, die Rechner, von denen aus ich ihn anspreche aber
> nicht.

Ähhh, Du erstellst ein Image der Installation während der Raspi läuft? 
Wie stellst Du sicher, dass sich die Daten während des Backups nicht 
ändern, z.B. bei Datenbanken wenn geschrieben wird?

> Ah, sehr gute Idee! Wie würdest Du das machen? Mit einem separaten 7z -t
> Lauf nach dem Packen, on the fly und/oder mit Hash? Die Frage ist auch,
> was genau verifyen – im Falle von 7z scheinen die Archive recht sicher
> zu sein.

Naja, nach dem Erstellen des Images nochmal einen Vergleich mit den 
gleichen Parametern zwischen Quelle und Ziel. Das geht natürlich nur, 
wenn sich die Daten in der Zwischenzeit nicht ändern, was bei einem 24/7 
laufenden System eher unmöglich ist.

Was meinst Du mit "Hash"? Von jeder gesicherten Datei einen Hash 
erstellen und mit dem Hash im Backup vergleichen? Kann man sicher auch 
machen, hört sich aber aufwändiger an, als wann man das Backup-Programm 
einfach für's Vergleichen startet, was dann jede gesicherte Datei 
nochmal liest und mit der im Backup vergleicht.

-- 

Gruesse,

Thorolf

[toc] | [prev] | [next] | [standalone]

#80686

Başar Alabay schrieb:
> Das ist ein headless Server. Raspbian, Debian 11. Zusätzlich habe ich
> noch ein Repository für ein Monitoring System.

die meisten Raspis dürften Headless sein, ebenso wie die meisten Server. 
Macht ja sonst oft auch wenig Sinn, wenn die dauerhaft laufen sollen.

> Ich weiß eben nicht, ob alles in /home landet. Da ich in den letzten 10
> Jahren soviel getweakt habe, daß ich schon gar nicht mehr weiß, wo was …
> ist mir das ein gewisses Risiko. Es wäre schön, wenn alles an einem Ort
> wäre, aber ich nehme an, daß rechnerrelevante Dinge auch an anderen
> Orten abgelegt sind. Jedenfalls fragten mich vergangene (rollierende)
> Systemupdates schon, ob ich die modifizierten Files beibehalten wolle.

Grundsätzlich, wo sich die Daten befinden, sollte man über die 
Konfig-Dateien der einzelnen Dienste herausbekommen und man weiß ja 
hoffentlich was da läuft und wie man es konfiguriert hat.

Wenn ich das oben aber lese, habe ich da so meine Zweifel und würde 
grundsätzlich empfehlen eine neue, anständig dokumentierte Installation 
durchzuführen und das auch gleich in ein Ansible gießen.

Ist erstmal relevanter Mehraufwand, aber auf Dauer ganz sicher die 
weniger aufwändige Lösung wenn's um Backup und Restore geht.

Für's Backup würde ich Restic empfehlen, das braucht als Ziel nur einen 
SSH-Zugang mit Key und kann alles, was man von einem modernen 
Backup-Mechanismus erwartet.

> Der π läuft 24/7, die Rechner, von denen aus ich ihn anspreche aber
> nicht.

Ähhh, Du erstellst ein Image der Installation während der Raspi läuft? 
Wie stellst Du sicher, dass sich die Daten während des Backups nicht 
ändern, z.B. bei Datenbanken wenn geschrieben wird?

> Ah, sehr gute Idee! Wie würdest Du das machen? Mit einem separaten 7z -t
> Lauf nach dem Packen, on the fly und/oder mit Hash? Die Frage ist auch,
> was genau verifyen – im Falle von 7z scheinen die Archive recht sicher
> zu sein.

Naja, nach dem Erstellen des Images nochmal einen Vergleich mit den 
gleichen Parametern zwischen Quelle und Ziel. Das geht natürlich nur, 
wenn sich die Daten in der Zwischenzeit nicht ändern, was bei einem 24/7 
laufenden System eher unmöglich ist.

Was meinst Du mit "Hash"? Von jeder gesicherten Datei einen Hash 
erstellen und mit dem Hash im Backup vergleichen? Kann man sicher auch 
machen, hört sich aber aufwändiger an, als wann man das Backup-Programm 
einfach für's Vergleichen startet, was dann jede gesicherte Datei 
nochmal liest und mit der im Backup vergleicht.

-- 

Gruesse,

Thorolf

[toc] | [prev] | [next] | [standalone]

#80708

T. schrieb am 04.10.2024, 22:11 h:

> Grundsätzlich, wo sich die Daten befinden, sollte man über die 
> Konfig-Dateien der einzelnen Dienste herausbekommen und man weiß ja 
> hoffentlich was da läuft und wie man es konfiguriert hat.

Nö, ich kann mich doch nicht mehr an alles erinnern, wie ich das vor
acht oder zehn Jahren wo konfiguriert habe. Hauptsache, es läuft.

> Wenn ich das oben aber lese, habe ich da so meine Zweifel und würde 
> grundsätzlich empfehlen eine neue, anständig dokumentierte Installation 
> durchzuführen und das auch gleich in ein Ansible gießen.

Du mußt massiv zu viel Zeit haben :-)
 
> Ist erstmal relevanter Mehraufwand, aber auf Dauer ganz sicher die 
> weniger aufwändige Lösung wenn's um Backup und Restore geht.

Grundsätzlich sicherlich. Aber das ist jetzt einfach nicht umsetzbar.

> Für's Backup würde ich Restic empfehlen, das braucht als Ziel nur einen 
> SSH-Zugang mit Key und kann alles, was man von einem modernen 
> Backup-Mechanismus erwartet.

Das ist alles viel zu kompliziert … ich hatte meine Methode beschrieben.
 
>> Der π läuft 24/7, die Rechner, von denen aus ich ihn anspreche aber
>> nicht.
> 
> Ähhh, Du erstellst ein Image der Installation während der Raspi läuft? 
> Wie stellst Du sicher, dass sich die Daten während des Backups nicht 
> ändern, z.B. bei Datenbanken wenn geschrieben wird?

Wo liest Du denn, daß ich da ein Image erstelle? Das beschriebene
Szenario war ein Ziehen von Daten. Da das auch schon ewig her ist, weiß
ich nicht mal mehr, welcher Daten. Aber tatsächlich war das Thema
Datenbank ein Stolperstein. Ich glaube, ich hatte ein Script, um die
Cloud vorher abzuschalten. Doch genau das ganze Gehampel wurde mir zu
kompliziert, ich fing an, die Kiste herunterzufahren, um ein Abbild zu
ziehen.

>> Ah, sehr gute Idee! Wie würdest Du das machen? Mit einem separaten 7z -t
>> Lauf nach dem Packen, on the fly und/oder mit Hash? Die Frage ist auch,
>> was genau verifyen – im Falle von 7z scheinen die Archive recht sicher
>> zu sein.
> 
> Naja, nach dem Erstellen des Images nochmal einen Vergleich mit den 
> gleichen Parametern zwischen Quelle und Ziel. Das geht natürlich nur, 
> wenn sich die Daten in der Zwischenzeit nicht ändern, was bei einem 24/7 
> laufenden System eher unmöglich ist.

Welchen Befehl genau würdest Du bei 7z nutzen? Und in welcher
Kombination? Das war die Frage.

> Was meinst Du mit "Hash"? Von jeder gesicherten Datei einen Hash 
> erstellen und mit dem Hash im Backup vergleichen? Kann man sicher auch 
> machen, hört sich aber aufwändiger an, als wann man das Backup-Programm 
> einfach für's Vergleichen startet, was dann jede gesicherte Datei 
> nochmal liest und mit der im Backup vergleicht.

7z bietet Hashs an. Übrigens, nebenbei: Retrospect kann sowohl das eine
als auch das andere … und ein Vergleich via Hash geht massiv schneller
als das Vergleichslesen. Hat zwar nichts mit dem Raspi zu tun, sei aber
am Rande angemerkt. Mit RS sichere ich den Mac-Zoo.

B. Alabay 

[toc] | [prev] | [next] | [standalone]

#80709

Başar Alabay schrieb:
> Nö, ich kann mich doch nicht mehr an alles erinnern, wie ich das vor
> acht oder zehn Jahren wo konfiguriert habe. Hauptsache, es läuft.

noch ein Grund alles neu zu machen, jetzt, wo das alte System noch läuft 
und nicht erst dann, wenn es aus irgendwelchen unerfindlichen Gründen 
partout nicht mehr starten will, Du es dringend brauchst, aber den 
Fehler nicht finden kannst.

> Du mußt massiv zu viel Zeit haben :-)

Im Gegenteil.

Wenn man einfach alles was man ausgeführt hat in ein Script kopiert, hat 
man schonmal 'ne Grundlage für eine einfache Doku.

Und darauf aufbauend kann man dann auch ein Ansible erstellen.

> Grundsätzlich sicherlich. Aber das ist jetzt einfach nicht umsetzbar.

Schlecht, wenn man sowas 10 Jahre vor sich her schiebt.

Aber soll ja Leute geben, die meinen, dass man in der Rente dann endlich 
Zeit hat, all das zu erledigen, was man vorher nicht geschafft hat.

>> Für's Backup würde ich Restic empfehlen, das braucht als Ziel nur einen
>> SSH-Zugang mit Key und kann alles, was man von einem modernen
>> Backup-Mechanismus erwartet.
> 
> Das ist alles viel zu kompliziert … ich hatte meine Methode beschrieben.

Ein Backup, welches vollautomatisch, sicher und platzsparend sichert ist 
wohl aufwändiger, als das Erstellen eines Images der gesamten 
Installation. Und man muss sich damit beschäftigen und dokumentieren, 
welche Daten man sichern muss. Ich sehe da nur Vorteile drin!

Im übrigen ist restic auch nicht komplizierter als rsync oder tar.

> Wo liest Du denn, daß ich da ein Image erstelle? Das beschriebene
> Szenario war ein Ziehen von Daten. Da das auch schon ewig her ist, weiß
> ich nicht mal mehr, welcher Daten. Aber tatsächlich war das Thema
> Datenbank ein Stolperstein. Ich glaube, ich hatte ein Script, um die
> Cloud vorher abzuschalten. Doch genau das ganze Gehampel wurde mir zu
> kompliziert, ich fing an, die Kiste herunterzufahren, um ein Abbild zu
> ziehen.

Ein Abbild ist ein Image und Du schreibst, dass der "π läuft 24/7", dann 
muss das Image im laufenden Betrieb gesichert werden.

Wenn Du ihn jedes Mal herunterfährst, wenn Du ein Backup machst ist das 
natürlich sicher aber ziemlich aufwändig.

> Welchen Befehl genau würdest Du bei 7z nutzen? Und in welcher
> Kombination? Das war die Frage.

Keine Ahnung, ich nutze kein 7z, steht aber sicher in der Doku.

> 7z bietet Hashs an. Übrigens, nebenbei: Retrospect kann sowohl das eine
> als auch das andere … und ein Vergleich via Hash geht massiv schneller
> als das Vergleichslesen. Hat zwar nichts mit dem Raspi zu tun, sei aber
> am Rande angemerkt. Mit RS sichere ich den Mac-Zoo.
Da sowohl beim Vergleichen, als auch beim Hash Erstellen immer erst die 
ganze Datei auf beiden Seiten gelesen werden muss, kann ich nicht 
nachvollziehen, weshalb das Errechnen eines Hash-Werts schneller sein 
soll ...

-- 

Gruesse,

Thorolf

[toc] | [prev] | [next] | [standalone]

#80687

Başar Alabay schrieb:
> Das ist ein headless Server. Raspbian, Debian 11. Zusätzlich habe ich
> noch ein Repository für ein Monitoring System.

die meisten Raspis dürften Headless sein, ebenso wie die meisten Server. 
Macht ja sonst oft auch wenig Sinn, wenn die dauerhaft laufen sollen.

> Ich weiß eben nicht, ob alles in /home landet. Da ich in den letzten 10
> Jahren soviel getweakt habe, daß ich schon gar nicht mehr weiß, wo was …
> ist mir das ein gewisses Risiko. Es wäre schön, wenn alles an einem Ort
> wäre, aber ich nehme an, daß rechnerrelevante Dinge auch an anderen
> Orten abgelegt sind. Jedenfalls fragten mich vergangene (rollierende)
> Systemupdates schon, ob ich die modifizierten Files beibehalten wolle.

Grundsätzlich, wo sich die Daten befinden, sollte man über die 
Konfig-Dateien der einzelnen Dienste herausbekommen und man weiß ja 
hoffentlich was da läuft und wie man es konfiguriert hat.

Wenn ich das oben aber lese, habe ich da so meine Zweifel und würde 
grundsätzlich empfehlen eine neue, anständig dokumentierte Installation 
durchzuführen und das auch gleich in ein Ansible gießen.

Ist erstmal relevanter Mehraufwand, aber auf Dauer ganz sicher die 
weniger aufwändige Lösung wenn's um Backup und Restore geht.

Für's Backup würde ich Restic empfehlen, das braucht als Ziel nur einen 
SSH-Zugang mit Key und kann alles, was man von einem modernen 
Backup-Mechanismus erwartet.

> Der π läuft 24/7, die Rechner, von denen aus ich ihn anspreche aber
> nicht.

Ähhh, Du erstellst ein Image der Installation während der Raspi läuft? 
Wie stellst Du sicher, dass sich die Daten während des Backups nicht 
ändern, z.B. bei Datenbanken wenn geschrieben wird?

> Ah, sehr gute Idee! Wie würdest Du das machen? Mit einem separaten 7z -t
> Lauf nach dem Packen, on the fly und/oder mit Hash? Die Frage ist auch,
> was genau verifyen – im Falle von 7z scheinen die Archive recht sicher
> zu sein.

Naja, nach dem Erstellen des Images nochmal einen Vergleich mit den 
gleichen Parametern zwischen Quelle und Ziel. Das geht natürlich nur, 
wenn sich die Daten in der Zwischenzeit nicht ändern, was bei einem 24/7 
laufenden System eher unmöglich ist.

Was meinst Du mit "Hash"? Von jeder gesicherten Datei einen Hash 
erstellen und mit dem Hash im Backup vergleichen? Kann man sicher auch 
machen, hört sich aber aufwändiger an, als wann man das Backup-Programm 
einfach für's Vergleichen startet, was dann jede gesicherte Datei 
nochmal liest und mit der im Backup vergleicht.

-- 

Gruesse,

Thorolf

[toc] | [prev] | [next] | [standalone]

#80688

Başar Alabay schrieb:
> Das ist ein headless Server. Raspbian, Debian 11. Zusätzlich habe ich
> noch ein Repository für ein Monitoring System.

die meisten Raspis dürften Headless sein, ebenso wie die meisten Server. 
Macht ja sonst oft auch wenig Sinn, wenn die dauerhaft laufen sollen.

> Ich weiß eben nicht, ob alles in /home landet. Da ich in den letzten 10
> Jahren soviel getweakt habe, daß ich schon gar nicht mehr weiß, wo was …
> ist mir das ein gewisses Risiko. Es wäre schön, wenn alles an einem Ort
> wäre, aber ich nehme an, daß rechnerrelevante Dinge auch an anderen
> Orten abgelegt sind. Jedenfalls fragten mich vergangene (rollierende)
> Systemupdates schon, ob ich die modifizierten Files beibehalten wolle.

Grundsätzlich, wo sich die Daten befinden, sollte man über die 
Konfig-Dateien der einzelnen Dienste herausbekommen und man weiß ja 
hoffentlich was da läuft und wie man es konfiguriert hat.

Wenn ich das oben aber lese, habe ich da so meine Zweifel und würde 
grundsätzlich empfehlen eine neue, anständig dokumentierte Installation 
durchzuführen und das auch gleich in ein Ansible gießen.

Ist erstmal relevanter Mehraufwand, aber auf Dauer ganz sicher die 
weniger aufwändige Lösung wenn's um Backup und Restore geht.

Für's Backup würde ich Restic empfehlen, das braucht als Ziel nur einen 
SSH-Zugang mit Key und kann alles, was man von einem modernen 
Backup-Mechanismus erwartet.

> Der π läuft 24/7, die Rechner, von denen aus ich ihn anspreche aber
> nicht.

Ähhh, Du erstellst ein Image der Installation während der Raspi läuft? 
Wie stellst Du sicher, dass sich die Daten während des Backups nicht 
ändern, z.B. bei Datenbanken wenn geschrieben wird?

> Ah, sehr gute Idee! Wie würdest Du das machen? Mit einem separaten 7z -t
> Lauf nach dem Packen, on the fly und/oder mit Hash? Die Frage ist auch,
> was genau verifyen – im Falle von 7z scheinen die Archive recht sicher
> zu sein.

Naja, nach dem Erstellen des Images nochmal einen Vergleich mit den 
gleichen Parametern zwischen Quelle und Ziel. Das geht natürlich nur, 
wenn sich die Daten in der Zwischenzeit nicht ändern, was bei einem 24/7 
laufenden System eher unmöglich ist.

Was meinst Du mit "Hash"? Von jeder gesicherten Datei einen Hash 
erstellen und mit dem Hash im Backup vergleichen? Kann man sicher auch 
machen, hört sich aber aufwändiger an, als wann man das Backup-Programm 
einfach für's Vergleichen startet, was dann jede gesicherte Datei 
nochmal liest und mit der im Backup vergleicht.

-- 

Gruesse,

Thorolf

[toc] | [prev] | [standalone]

Back to top | Article view | de.comp.sys.mac.misc

csiph-web