Backuptools sind komplex und aufwändig. Das ist so und das wird sich auch so schnell nicht ändern. Wer sich auf sein Backup verlassen will, muss einfach Zeit, Aufwand und/oder Geld investieren. Was aber tun, wenn man keine hohe Sicherheit braucht, aber unter Umständen auf alte Stände des Systems / der Konfiguration zugreifen will? Weil vielleicht ein ausgefeiltes Backuptool vorhanden ist, aber ein Restore sehr umständlich wäre und man einen Abkürzung braucht? Geht sie – super! Geht sie nicht, gibt’s immer noch das eigentliche Backup.
Eine Möglichkeit wären vcs Systeme wie Git, aber auch die sind selten trivial in ihrer Bedienung – ausserdem müssen sie normalerweise dazu gebracht werden, einen aktuellen Stand eines Systems / einer Konfiguration zu sichern und das vergisst man leicht bzw. kann man es evtl nicht allen Usern zumuten. Ganz zu schweigen davon, dass man ja auch mal etwas sichern möchte, ohne, dass man dabei „anwesend“ ist. Und nicht zuletzt sind vcs Systeme dafür gedacht, Textdateien wie Quellcode und Config zu sichern und nicht ganze Server.
Eine mögliche Lösung sind Tools wie Rsnapshot. Backup, das leicht zu bedienen ist, aber, oder weil es, auf viele Features verzichtet.
Rsnapshot ist sehr schnell eingerichtet und braucht beinahe keine Ressourcen.
Die Installation funktioniert in aller Regel über den Paketmanager der ausgewählten Distribution und die Konfiguration ist ziemlich selbst erklärend mit einigen Kommentaren in der Beispielkonfig, weshalb ich hier nicht weiter darauf eingehen möchte. Bedarf kann gern in den Kommentaren angemeldet werden, dann reiche ich gern einen Artikel dazu nach.
Kurz zusammengefasst erstellt das Tool eine Kopie des Dateisystems mit rsync und erstellt Kopien dieser Kopie mit Hilfe von Hardlinks. Dadurch benötigen nur die Dateien, die sich seit dem letzten Lauf geändert haben, tatsächlich Platz auf der Festplatte. Ein Restore funktioniert dann einfach via cp oder ähnlichen Bordmitteln. Aber bitte nicht mv, da dies die interne Struktur der Backups durcheinanderbringen kann.
Ein paar mehr Details sind für das weitere Verständnis allerdings noch hilfreich: rsnapshot kennt verschiedene Intervalle, die in der Konfiguration sortiert sind und immer vom Kürzesten zum Längsten genannt werden. Dabei ist es völlig unerheblich, wie die Intervalle benannt werden, wichtig ist, nur dass die Reihung kürzer -> länger immer eingehalten wird. Der Einfachheit halber hat es sich eingebürgert, sie nach Zeitspannen zu bennnen und sie ihrem Namen entsprechend auszuführen, also hourly stündlich, daily, täglich, etc. . Im Sinne einer einfacheren Lesbarkeit werde ich davon ausgehen, dass es genauso umgesetzt wird – ich bitte also um Verständnis, wenn ich „stündliches Backup“ und nicht „am häufigsten ausgeführte Backupkonfiguration“ schreibe. Ausserdem gehe ich davon aus, dass 24 hourly, 7 daily, 4 weekly, 12 monthly und 10 yearly aufgehoben werden sollen. Genauso gut könnte ich 6 hourly, 17 daily und 8 quonko aufheben, aber das wird jetzt schon klar sein.
rsnapshot wird nach der Konfiguration via cron aufgerufen und zwar immer in der Art rsnapshot [intervallname], wobei eben hourly stündlich, daily täglich, etc. ausgeführt wird. Anders ausgedrückt muss für jeden Intervall ein eigener Job eingerichtet werden.
Im internen Ablauf passiert bei jedem Dtündlichen ein rsync, das die zu sichernden Verzeichnisse nach hourly.0 unter dem angegbenen Zielpfad kopiert (hourly entspricht wieder dem frei wählbaren Intervallnamen). Ausserdem wird hourly.23 (wegen dem Beginn bei 0 gibt es natürlich kein hourly.24) gelöscht, hourly.22 via mv in hourly.23 umbenannt, hourly.21 in hourly.22, etc. Das passiert noch vor dem Ausführen des rsync, weshalb bereits davor kein hourly.1 mehr existiert. hourly.0 wird mithilfe von Hardlinks nach hourly.1 kopiert – erst dann findet der zuvor genannte rsync statt.
Bei einem Lauf mit rsnapshot daily wird daily.6 gelöscht, daily.5 in daily.6 umbenannt, etc. . hourly.23 wird in daily.0 umbenannt. Existiert zu diesem Zeitpunkt kein hourly.23, gibt’s auch kein neues daily. Das bedeuet auch, dass erst daily erstellt werden, wenn alle hourly existieren. Das gilt es zu bedenken, wenn man z.B. 96 hourly behalten will. Ausserdem ist somit jedes daily älter als jedes hourly, jedes weekly älter als jedes daily, etc. In der angenommenen Konfiguration könnten wir also alleine durch hourly und daily 8 Tage zurück.
Wirklich hilfreich werden tools wie rsnapshot aber erst, wenn man etwas länger daran herumspielt. Ein Problem ist zum Beispiel, dass bei jedem Lauf alle bereits erstellten Backups umbenannt werden. Sucht man ein bestimmtes Backup, so muss man ausrechnen, wie es aktuell heisst und hoffen, dass alle Sicherungen nur via cron angestossen wurden. Eine mögliche Abhilfe ist, sich einen Ordner anzulegen, in dem man Dateien hinterlegt, die nur für die Dauer eines Backuplaufs existieren und das Backup identifizeren. z.B /root/snap/mysql_coldbackup . Nach der Datei kann man dann den Zielordner durchsuchen (aber bitte nicht mit locate, sondern mit etwas, das den aktuellen Zustand des Filesystems überprüft 🙂 ). Man kann das auch automatisieren, in dem man durch cron unmittelbar vor jedem backup einen timestamp dort hinterlegen lässt. Es ist auch denkbar, gewisse Zustände so zu verewigen. z.B Softwareversionsstände im Laufe einer Migration (geht ebenfalls automatisiert, vor allem da die meisten tools beim Aufruf mit -V ihre aktuelle Versionsnummer ausgeben.) oder noch ausstehende Schritte. So habe ich mir angewohnt, vor grösseren Schritten, erst touch /root/snap/[namedesgroesserenschrittes] ; rsnapshot hourly && rm -f /root/snap/[namedesgroesserenschrittes] auszuführen. So kann ich, wenn was schief geht, leicht auf alte Konfig zugreifen, kann das aber durchaus öfter machen, da diese Backups durch die stündliche Rotation wieder rausfallen. Evtl. geht eines davon auf die Reise durch die weiteren Intervalle, aber das stört mich nicht weiter.
Dabei muss man natürlich bedenken, wie lange man die Backups aufheben möchte. Da rsnapshot die einzelnen Intervalle unabhängig voneinander rotiert, passiert es leicht, dass ein Zustand, der nur in einer einzigen Sicherung vorhanden ist, bei der stündlichen Rotation rausfällt. Möchte man, dass gewisse Dateien länger im Backup bleiben, gibt es leider keine Garantie dafür. Wenn alles glatt geht, sollte das Aufheben aber funktionieren, wenn man die Datei einen Intervall des Backupzyklus lang verfügbar macht, für das man es aufhält. Ist eine Datei also eine Woche lang auf dem Filesystem zu finden, hat man gute Chancen, sie in allen hourly, allen daily und mindestens einem weekly zu finden, bis die Rotation sie aus dem letzten weekly wirft. In unserem Beispiel also 5 Wochen und 1 Tag lang. Gefährdet wird diese Logik vor allem, wenn man ausgiebig Gebrauch von den oben erwähnten „händischen Backups“ macht. Damit erhöht sich die Zeit, die ein Status bestehen muss, um ins daily überzugehen natürlich entsprechend.
Die yearly backups scheinen in den meisten Fällen überzogen, aber das ist aus meiner Sicht der beste Weg, einen Zustand dauerhaft zu bewahren. Dazu ein Beispiel aus der Praxis. Bevor ich eine grössere Migration beginne, in deren Rahmen ich rsnapshot einführe, lege ich die Konfiguration an und lasse, dem obigen Beispiel folgend, 24+7+4+12+10 mal folgenden Befehl laufen: rsnapshot hourly ; rsnapshot daily ; rsnapshot weekly ; rsnapshot monthly ; rsnapshot yearly. Das dauert nicht sehr lange und braucht nur minimal mehr Platz als eine einzige Kopie des zu sichernden Filesystems. Ab da beginne ich die normalen cron Läufe mit hourly stündlich, daily täglich… . So kann ich davon ausgehen, dass für die ganze Dauer der Migration und auch jedes spätere Mal, wenn ich zu diesem Kunden komme, die ursprüngliche Ausgangssituation im letzten yearly noch vorhanden ist.
Noch ein paar Worte der Warnung. Als Ziel wird rsnapshot ein Verzeichnis angegeben. Wenn dort ein anderes Filesystem, z.B. von einer USB Festplatte, gemountet ist und man diese entfernt, legt rsnapshot einfach in dieses Verzeichnis neue Backups an, womit man sich ganz schnell Festplatten anfüllen kann. Dieses Verhalten ist allerdings konfigurierbar. Falls das reguläre Backuptool das rsnapshot Zielverzeichnis inkludiert und nicht mit Hardlinks umgehen kann, wird man bald einen Backupadmin mit einer roten Kletzn (österr. für „Kopf“) im Büro stehen haben, weil man bei der obigen Konfig 24+7+4+12+10+1 mal den gesamten Platz des zu sichernden Filesystems wegkopiert. Das selbe gilt bei Netzwerkshares, etc. auf die man hinschreibt, sofern die nicht mit Hardlinks umgehen können. Aus dem gleichen Grund kann man auch nicht einfach via ssh oder ähnliches auf einen entfernten Server sichern. Um das hinzubekommen, muss man via rsync auf den Zielhost sichern und dort dann rsnapshot laufen lassen. Wer auf andere Hosts sichern, selbst auf dem selben Host die Backupkonfiguration verwalten und Backups auch noch verschlüsseln will, sollte sich evtl. duplicity und die vielen kleinen Tools, die einem das Leben damit deutlich einfacher machen, wie duply oder deja-dup ansehen. Eine Stolperfalle, in die man immer wieder gerne tappt, ist das Konfigfile, das Optionsname und Wert immer mit Tabulator getrennt verlangt und bei Zeilen, die Leerzeilen statt Tabs enthalten, Fehler wirft. Daher bietet es sich immer an, einen rsnapshot hourly Lauf nach Konfigänderungen zu machen.
Nicht zuletzt sollte man immer daran denken, Restores nur mit Kopien zu machen, da man Daten tatsächlich aus den Backups rausnehmen kann und so unter Umständen alle Kopien vernichtet. Umgekehrt muss man Backupsets, die man aus der Rotation entfernt (Pfade, die nicht mehr gesichert werden oder wenn man z.B. von 48 hourly auf 24 hourly umstellt) selbst löschen. Das nimmt einem rsnapshot nicht ab.
Danke für den Artikel. Ich nutze rsnapshot schon länger, aber ich muss mir scheinbar nochmals ein Paar gedanken über die Backupintervalle machen.
s/Dtündlichen/Stüdlichen/
Schon mal „dirvish“ (http://www.dirvish.org/) angeschaut? Das macht auch rsync-Backups mit Hardlinks (üblicherweise von anderen Rechnern), benennt die aber mit ISO-Datum und löscht dann später die Sets raus, die man nicht mehr braucht. Also ohne was zu „mv“en.
Und im Cron-Script kann man auch noch gleich das Ziel-Filesystem mounten oder prüfen, ob es gemountet ist.
Haben wir seit langem im Einsatz für einen Haufen Rechner und läuft prima.