Mein Linux-Home-Backup-Script und eine Frage
Dienstag, 22.7.2025, 07:40 > daMaxMeine Frage nach einem vernünftigen, automatisierbaren Backup wurde ja recht zahlreich beantwortet, also habe ich mich in den letzten Tagen mal daran gemacht, mir eine Lösung zum Sichern meines /home-Verzeichnis zurecht zu schustern. Der folgende Post ist nerdig, ihr seid gewarnt.
Angefangen hatte ich mit grsync, das eine grafische Oberfläche für den Kommandozeilenbefehl rsync darstellt. Beim Herumspielen fiel mir auf, dass in meinem /home sehr viele Dateien rumliegen, die ich gar nicht sichern will, also war mir schnell klar, dass ich eine Ausnahmeliste (exclude list) benötigen werde.
Tja, leider ist Grsync eben nicht so grafisch, wie ich das gerne hätte (so mit einer Baumansicht zum Aktivieren / Deaktivieren von Ordnern), außerdem lässt es sich (meines Wissens nach) nicht automatisieren, also bin ich im Laufe des Wochenendes auf eine reine Scriptlösung umgestiegen.
Alles dreht sich im Endeffekt um diesen Befehl:
rsync -axv --progress -s --exclude-from="$EXCLUDELIST" "$SOURCEDIR" "$TARGETDIR"
Grsync hätte zwar diese Flags verwendet:
rsync -r -t -x -v --progress -s --exclude-from="$EXCLUDELIST" "$SOURCEDIR" "$TARGETDIR"
aber mein Admin meinte, "axv" sei ideal, vor allem, weil meine Flags keine Symlinks mit kopieren würden, was doof sei. -a beinhaltet -rlptgoD und muss wohl perfekt sein.
Ein reines Backup alleine war mir natürlich nicht genug, ich will Logfiles haben. Und zwar rotierende, also so dass nur das allererste (vollständige) Logfile bestehen bleibt sowie sagen wir mal 20 weitere. Zusammen mit Perplexity vibete ich mir also dieses Script zusammen:
Automatisiert habe ich das per systemd mit einem Service:
und einem Timer:
Das funktioniert so weit so gut.
Frage in die Runde: könnte ich ein solches Script auch dazu verwenden, mein System zu sichern? Also einmal komplett / und dabei dann entsprechend Ordner wie /home, /var und so weiter ausnehmen? Aber wie kriege ich das im root-Kontext automatisch zum Laufen?
Da hast du was schönes zusammengebastelt. Du hast nun ein Skript, dass Inhalte von A nach B synchronisiert, so dass danach B gleich A aussieht (ohne den ausgeschlossenen Sachen) und schön rollierende Logfiles. Was ist nun aber, wenn du was aus A löscht, automatisch dein Skript anläuft und du erst in ein paar Tagen merkst, dass genau das Gelöscht doch noch gebraucht wird? Aus B ist es dann schon lange weg, da rsync synchronisiert. Allenfalls hast du in den schönen Logfiles stehen, dass es bis zum Löschtag noch vorhanden war. Ein Backup ist das nicht.
Deine Vorraussetzung war, dass dein Backup eine GUI hat. Deshalb habe ich damals nicht kommentiert. Mach es richtig. Nimm ein deduplizierendes Backup-Programm, z.B. borg backup. Das kann inkrementales Backup, kann easy parametrisiert werden, so dass es jährliche, monatliche und wöchentliche Sicherungen aufhebt (und auch alte löscht) und es verschlüsselt die Backups, so dass man sie sogar extern zu irgendeinem Hoster schieben könnte, wenn man das denn will. Und ja, borg-backup kann auch das komplette System sichern (mit Ausschluss von /dev, /proc usw.).
Um dein "Backup" oder ein anderes Backup im root-Kontext laufen zu lassen, mache es zur System-Unit. Ohne die Angabe von user= oder group= laufen diese automatisch als root. Läuft denn dein jetziger Timer und die Unit unter User-systemd? Wenn nicht, dann läuft sie ja jetzt schon als root.
Das alles spielt natürlich nur eine Rolle, wenn der angekündigte "Umstieg auf ein neues Betriebssystem" heißt, dass du bei einem Linux-artigen bleibst, denn nur dort gibt es borg-backup.
@Jens T.: also wenn ich rsync richtig verstehe, löscht das gar nix, es sei denn, ich gebe den --delete Flag mit, oder habe ich da was falsch verstanden?
So wie ich rsync verstehe, habe ich jetzt ein inkrementelles Backup... für das OS-Backup würde ich den --delete Flag setzen, denn davon hätte ich ja gerne eine 1:1 Kopie.
Ja, das hatte ich so gesagt, das stimmt schon. Und Grsync war schon ein guter Einstieg in die rsync-Welt, ließ sich bloß nicht automatisieren, deshalb jetzt ist es jetzt eben doch ein Script geworden. Agil und so
Da muss ich nochmal nachgucken
Die Freunde von Heise hatten vor Jahren eine rsync-Lösung vorgestellt, die bei jedem Lauf in einen neuen Verzeichnisbaum sichert, aber hardlinks auf den vorhergehenden setzt, so dass nur neue oder geänderte Files tatsächlich gespeichert werden... man rsync.
Deine Lösung klappt bei gelöschten Dateien, nicht aber bei geänderten, denn die werden überschrieben. Also kein Schutz vor dem berüchtigten fat finger.
Die hardlink Lösung hat das Problem, dass das Löschen alter Versionen lange dauert (bei mir).
@Jens T.: Also, rsync kann auch inkementelle backups. Siehe Apple Rechner mit Time Machine. Genau so geht das.
@daMax: rsync kann im Source nicht mehr vorhandene Dateien auf Wunsch löschen oder beibehalten.
Aber Backup ist weniger ein Programm. Man kann sich immer irgend eine Lösung nehmen oder basteln. Backup ist ein Konzept. Genau deshalb willst du das automatisieren.
Und nebenbei: Logfiles sollen im Fehlerfall helfen. Wenn alles okay war, dann braucht man maximal ein timestamp + okay. Bei den systemd logs etwa findet sich Rauschen ohne Ende, während die Fehler dauernd kommen und von niemandem beachtet werden und oft unverständlich sind.
Nachtrag, apropos systemd: man kann Logging auch in den syslog machen. Man könnte "rotieren" der Logfiles sogar mit rsync automatisieren.
Keep it super simple!
Mir kam kürzlich der Gedanke, ob ich dir einen Gastbeitrag für "Dummies" mit konkreter Lösung anbieten sollte. Aber nu hast du ja deinen Script geschrieben und es reicht mit meiner dummen Besserwisserei.
@Andreas: Sorry eine Korrektur: es werden bei inkrementellem Backup mit rsync keine "geänderten" Dateien überschrieben. Ich weiß aber momentan nicht, was geschieht, wenn Dateien verschoben werden. Ich glaube nicht, dass rsync merkt, dass er da nur einen Link anders setzen müsste.
Löschen alter Versionen geht einfach, indem man das (die) richtige Backupverzeichnis(e) sucht (Datum) und löscht. Das ist ja der Zauber von Hardlinks. Im "Explorer" oder mit rm oder sonstwie.
@daMax: Stimmt, ohne --delete wird nichts gelöscht. Allerdings will man irgendwann vielleicht wirklich alte Zöpfe abschneiden. Die verschwinden dann nie aus deinem Backup.
@Joachim: Mit Apple habe ich überhaupt keine Erfahrung und weiß daher nicht, wie Time Maschine funktioniert. Aber wir sind ja hier auch nicht bei Apple
Ganz klar, wie @Joachim schon sagte, Backup ist weniger ein Programm, sondern eher ein Konzept. Was will ich erreichen? Auch alte, bereits gelöschte Inhalte wiederherstellen können, auf alte Versionen geänderter Dateien im Notfall zugreifen können oder reicht eine 1:1 Kopie inkl. bereits gelöschter Sachen? Dazu kommt noch, wo die Backups lagern. Auf dem selben Rechner ist da keine gute Idee. Man kann sich da auch ganz verrückte Sachen einfallen lassen, wie z.B. ~/Documents/ in ein Remote-Repository zu schieben.
Ich jedenfalls bin ein Freund davon, nicht immer eigene Lösungen zu benutzen, sondern auf Bewährtes zu setzen. Und das ist beim Backup eben ein Backup-Programm, und kein Programm, dessen Hauptaufgabe es ist, zwei Verzeichnisse zu synchronisieren.
Genauso überlasse ich meine Logeinträge einem Programm, welches für Logs gedacht ist: dem Syslog, alternativ dem journald. Das täglich über alle Logs bzw. das gesamte journald-Log laufende logcheck schickt mir die Fehmeldungen dann automatisch per Mail.
Wofür sich eigene Lösungen aber hervorragend eignen ist die Diskussion über sie selbst
@Jens T.: ACK. Allerdings habe ich als Softwareentwickler natürlich gut reden, wenn ich, ähnlich wie Max, einfach Programme zu einem Script kombiniere. Es gilt wie immer "always use the right tool". Genau deshalb stimme ich auch bei Syslog und journald zu.
TimeMachine nutzt rsync bzw einen Fork wg. der Lizens. Du steckst die Platte an und es rödelt los (ein use case). Du kannst für's restore timeMachine oder einfach den Mac "Explorer" (finder) verwenden und damit eben auch alten Kram löschen, ohne neue Backups zu gefährden. Kein Schick Schnack, nix zu tun, geht einfach (dank rsync)
TimeMachine ist eine "eigene Lösung" eben nur von Apple
@Jens T. (1) nochmal: Perplexity weiß:
Da ich den Service mangels anderen Wissens systemweit angelegt hatte, würde ein solches Script auch als Systembackup gehen, dann natürlich mit dem --delete Flag.
Wie wäre es den mit Borg Backup?
Das kann auch dedublizierung was sicherlich bei wiederkehrenden Backups helfen wird die Größe des Storage zu verringern.
@Thomas F.: wenn ich das richtig im Kopf habe, erzeugt Borg spezielle Archive, die sich dann auch nur per Borg einsehen und restaurieren lassen, oder? Ich wollte lieber etwas "simples" mit "normalen" Dateikopien und ich glaube, das rsync-Script ist gut genug für meine Zwecke...
@daMax: Auf der Webseite steht:
"Mountable backups with FUSE" und
"Backed by a large and active open source community."
Keine Ahnung, ob das was ist. Doch dein Argument könnte ggF nicht zutreffen?
@Joachim: Danke für den Hinweis! Das war mir bisher gar nicht bewusst oder gab es damals, als ich borg backup bei mir eingerichtet habe, noch nicht.
@Joachim: oh, spannend. Danke.