Hallo,

da es hier ja auch eine gewisse Menge an Leuten gibt, die sich auch mit Linux auseinandersetzen, möchte ich mal eine Frage loswerden, in der Hoffnung, dass es auch ein paar Leute gibt, die Antworten dazu haben.

Wie sichert man denn am Besten ein LinuxSystem während es läuft? "dd" soll ja so seine Tücken haben im Live-Betrieb. Ich müsste eigentlich nur die 2. Partition (Root Dateisystem) sichern um diese dann entsprechend wieder herstellen zu können.

Danke für Ideen

Ist das System (bei moderneren Linux-Systemen üblich) mit LVM aufgesetzt? Dann könnte ein Snapshot die Lösung sein.

Wenn Du nicht gerade Datenbanken oder Logfiles sichern willst, ist das durchaus eine Option.

Nein, leider nicht. Es handelt sich im speziellen um RaspiOS (Debian), welches auf einer USB SSD läuft. Die Partition ist ca. 80GB groß. Das Ding ist halt, dass das verwendete Gehäuse die ganzen Komponenten ziemlich gut kapselt und ich nicht mehr so ohne Weiteres dran komme.

Es ist quasi mein kleiner lokaler Server. Meinst du, wenn ich vor dem "dd" diverse Dienste (Cron, DB, SMB, etc) beende, wären meine Sorge bei "dd" unbegründet? Ich habe ein "dd" ja schon mal getestet. Es läuft knapp 1,5h mit bzip2-Komprimierung. Das ginge ja zur Not in der Nacht. gzip habe ich noch nicht getestet.

ich wuerde rsync vorschlagen

fuer datenbanken erstellst du dumps (die dann ebenfalls von rsync erfasst werden) mit mysqldump

Wie sieht denn dann die Notfallwiederherstellung aus? Ich boote von einem Behelfssystem, leere die Partition und kopiere/rsynce die Dateien rüber und kann dann wieder davon booten?
Das muss ich ja im Prinzip bei dd fast genauso machen.

Ich habe vorhin mal ein dd mit gzip gemacht. Hier müsste ich die Wiederherstellung auch noch mal testen, denn wir wissen ja: "Du sollst das Backup nicht vor dem Restore loben"

ja im prinzip schon.

achso. ok, fuer bootbare komplette klone ist dd wohl geeigneter.
rsync waere eher was fuer inkrementelle backups.

edit:
hab gerade noch partclone entdeckt. evtl waere das noch was. hab ich allerdings keine erfahrung mit.

Ich denke auch, mit dd fährst Du immer noch am besten.

dd sichert halt wirklich die ganze Plattenstruktur, was vorher bootbar war ist das dann in aller Regel (wenn nichts grausam schiefgeht) auch. Problematisch sind immer Dateien, die zum Zeitpunkt der Sicherung zum Schreiben geöffnet sind, und solche, bei denen ein konsistenter Status über mehrere Dateien erforderlich ist (prominentes Beispiel: Datenbanken). Wenn also die Möglichkeit besteht, dann Datenbanken und andere Software, die ggf. betroffen ist, vor der Sicherung herunterfahren.

cron selbst muß nicht sein (wohl aber wenn irgendwelche Jobs Daten verändern), SMB ja, falls Du Clients hast, die während der Sicherung auf die Platte schreiben, Datenbanken auf jeden Fall. Die sollte man ohnehin mit den geeigneten Mitteln sichern, also z.B. pgdump oder besser pg_basebackup für PostgreSQL.

rsync ist für bootbare Backups vollkommen ungeeignet, aber fein für größere Datenbestände. Eventuell kannst Du auch eine Mischkonstruktion fahren: Einmal im Monat oder Quartal ein bootbares Backup per dd, ansonsten regelmäßige Sicherungen der "beweglichen Daten" mit rsync.

Ein kompletter clone ist es nicht. Ich kann ja noch mal meine Gedanken der Vollständigkeit halber niederschreiben. Bei einem Raspberry Pi (ab jetzt nur noch Pi) haben wir ja nur die SD-Card in definierter Größe.
Bisher war mein Workflow für die Sicherung: Pi runterfahren, SD-Card raus, SD-Card sichern mit dd, SD-Card rein, Booten. Die USB-SSD blieb davon unangetastet.
Zur Wiederherstellung: Pi runterfahren, SD-Card raus, SD-Card zurückschreiben mit dd, SD-Card rein, Booten.

Nun habe ich alles auf einer USD-SSD in einem speziellen Gehäuse und auf der SSD 3 Partitionen (Boot, Root, Daten).
Mein bisheriger Workflow ist hier nicht mehr praktikabel, da ich die Daten-Partition nicht mit sichern möchte. Dafür habe ich Backupscripte. Das Backup möchte ich in der 1. Stufe auf der Daten-Partition vorhalten und in der 2. Stufe auf meinem NAS. Hierfür habe ich bereits Scripte am Laufen. Also vorausgesetzt, dass ich die Partitionstabelle nicht zerlege, würde ich nun von einem "Recoverysystem" booten (das kann dann ja eine SD-Card sein). Die USB-SSD mounten und via dd die 2. Partition, im Notfall auch die 1. Partition mit dd zurückspielen. Das ich Cron während des dd ausschalte, ist darin begründet, dass es durchaus sein kann das eigene Cronjobs starten, welche Dateioperationen ausführen.
Die automatische Sicherung (dauert mit gzip ca. 45min und mit bzip2 ca. 1h15min) habe ich gestern nochmals getestet und als "funktionierend" "freigegeben" Die Wiederherstellung muss ich noch testen. Hier ist nun leider Werkzeug nötig um das den Pi zu kommen.

Das klingt doch erstmal sinnvoll.

Wenn Du bei der Kompression Zeit sparen möchtest: Daß bzip2 deutlich länger braucht als gzip ist der besseren Kompression geschuldet. Aber auch gzip kannst Du, wenn es darauf ankommt, noch Beine machen: Man kann als Parameter noch '-1', '-2', ..., '-9' angeben, wobei eine höhere Zahl mit einer geringeren Kompression und damit höherer Geschwindigkeit korreliert. Für '-1' gibt es auch noch die symbolische Form '--fast', für '-9' umgekehrt '--best'. Da die CPU im RasPi zwar flott, aber nicht soo flott ist, kann das durchaus noch was bringen.

Das Problem bei bzip2 auf dem PI ist, dass bunzip wohl mit Dateien größer 2GB nicht klar kommt und man es selbst aus dem Source kompilieren muss.

Da war was. Es gibt da so eine "lustige" Begrenzung im Linux-Kernel, um die man herumprogrammieren muß, wenn man mehr als 2 GB auf einmal schreiben will.

Aber wie gesagt: Wenn Geschwindigkeit Primat ist, ist bzip2 ohnehin meist die falsche Lösung (meist, weil es Situationen gibt - z.B. beschränkte I/O-Bandbreite) in denen der CPU-Aufwand sich lohnt, um die dann stärker komprimierten Daten schneller wegzubekommen.

Und wenn es darum geht, Inkonsistenzen zu vermeiden, ist schneller auch besser.

Da bedanke ich mich bei euch beiden.
Ich werde meine Strategie entgegen anfänglicher Zweifel auf dd aufbauen.