ist eines das man braucht, aber nicht angelegt hat.
Die Erfahrung hatte ich vor einigen Jahren einmal gemacht. Gefolgt wurde sie vielen Erfahrungen in den letzten Jahren und Jahrzehnten, dass es viele Formen der „teuren“ Backups gibt. Dazu gibt (besser gab und wird bald wieder geben) es hier einige Erfahrungsberichte, welche ich auf hoffentlich bald wieder online setzen und hier verlinken kann.
Die neue Erfahrung nun zeigt, dass man auch „zu viel“ Backup haben kann. Eine Erfahrung, die einen wirklich einmal dazu bringt, sich noch einmal neu umzuschauen (daher das Beitragsbild), denn sie kam in meiner bisherigen Existenz so nicht vor. Dazu gibt es eine kurze Vorgeschichte.
Ich habe in den letzten Jahren Systeme zu schätzen gelernt, die einfach sind. Der Grundsatz, den ich seit dem bei Systemeinrichtungen verfolge, ist in der Regel:
As
Simple
As
Possible
Oft ergänzt um den Grundsatz:
As
Complex
As
Needed
Dem Grundsatz folgt vor allen Dingen mein Backupkonzept. Das vor allen Dingen 3 Grundsätze hat:
1.Niemals soll eine Datei nur auf einem Rechner liegen, erst recht nicht für längere Zeit. Das ist erst einmal noch keine wirklich Sicherung, sondern eher eine Datenverteilung. Sie erfolgt bei mir via privat betriebener Nextcloud (https://www.nestcloud.de).
2.Niemals nur ein Backup
Externe Festplatten können ausfallen, USB-Sticks ebenso, und besonders ärgerlich ist es, wenn der Computer von dem aus man die Daten sichert zusammen mit der einzigen Festplatte ausfällt, auf die man die Daten sichert. Die Chancen dafür stehen gering, vor einigen Jahren habe ich sie jedoch in Kooperation mit einer plötzlichen Spannungsspitze genutzt. Einige Jahre später hatte ich noch einmal das Vergnügen, da haben sich 2 externe USB Platten während des Zurückspielen des Backups überhitzt.
3.Niemals nur eine Version einer Datei
Wir sind alle Menschen, und Menschen machen Fehler. Wie schnell ist ein Abschnitt, den man später doch wieder sucht, aus einer Datei herausgelöscht, oder eine Datei mit irgendetwas überschrieben, weil man beim Speichern nicht aufgepasst hat. Solche Fehler fängt bei mir die Nextcloud mit ihrem Versionslauf einerseits auf, andererseits hoffe ich sie aber auch durch das Backupsystem aufzufangen.
Was ist, wenn ich grad eben eine Datei gelöscht habe, die noch nicht im regelmäßigen Backup war, und es irgendwie geschafft hat an Versionsverlauf und Papierkorb der Nextcloud vorbeizukommen. Das Gejammer ist schnell groß und die verlorene Arbeitszeit ist auch Lebenszeit, die man nie wieder bekommt.
Achja, und löschen kann man überflüssige Versionen später, z.B. wenn die Arbeit abgegeben und bewertet oder das Projekt abgeschlossen ist und archiviert wird, immer noch.
Backup mit Konzept(anpassung)
Daher basierte und basiert mein Backupkonzept auf rsync. Es ist praktisch, es ist erprobt, es kann Backups mit vielen Optionen auf vielen Medien erstellen.
Aktuell erfolgt die Sicherung meiner Daten in 3 Stufen. Im folgenden werde ich primär auf Stufe 2 eingehen, da diese Stufe sich hier als kritisch erwies.
1.Stufe Verteilung – möglichst alle Daten, welche keine dienstliche Relevanz haben, liegen in meiner privaten Cloud (alles andere auf einer verschlüsselten externen Festplatte – mit 2 verschlüsselten externen Backupfestplatten, welche sich in der Regel maximal kurze Zeit am gleichen Standort aufhalten)
2.Stufe Sicherung – das ist die Sicherung der Nextcloud auf einem lokalen Server hier via Skript. Die neue Fassung sieht wie folgt aus.
#!/bin/bash
#
/usr/bin/rsync -avzrb --backup-dir=/home/nestcloud-live-backup/archive --update --delete --progress benutzername@nestcloud.de:/var/customers/webs/cloudnext/ /home/nestcloud-live-backup/live/
/sbin/shutdown -h 3
kurz zu den Parametern des Skript
-a archiviert, d.h. u.A. der Zeitstempel aller Dateien bleibt erhalten
-v Ausgabe ausführlich was geschieht
-r (recursive), es werden alle Dateien und Unterverzeichnisse/Subordner heruntergelade
–update –delete Dateien die an der Quelle, d.h. in der Cloud, geändert, verschoben oder gelöscht werden, werden auch im Backup geändert,
in Kombination mit
–backup-dir=/home/nestcloud-live-backup/archive
Kopien aller Dateien, die aus dem Backup entfernt werden, werden im Verzeichnis /home/nestcloud-live-backup/archive. Es ist dabei egal, ob die Datei geändert wurde, gelöscht oder verschoben.
Besonders letzteres wurde mir in meinem Backupskript zu Verhängnis. Hier fehlte in der alten Fassung der Parameter –delete noch.
Randgeschichte
Als ich nun vor einigen Monaten anfing meine Daten zu sortieren und dort viele Duplikate zu löschen, um die alle Dateien in eine sinnvolle(re) Struktur zu verschieben, erzeugt ich damit wahre Massen an Duplikaten und verschiedenen Versionsständen in verschiedenen Verzeichnissen. Das wurde mir zum kleinen Verhängnis, als ich gestern, durch einen Benutzerfehler und eine Verkettung ungünstiger Umstände, auf mein Backup wieder zugreifen musste.
Es ist schlichweg riesig und die ganze Sortierarbeit der letzten Wochen liegt erneut vor mir.
/sbin/shutdown -h 3 da der Server primär für dieses Backup gestartet wird, fahre ich ihn nach Beendigung des Backups wieder herunter. Die Dauer von 3 Minuten habe ich eingerichtet, damit ich den Vorgang ggf. abbrechen kann, falls ich den Server noch für andere Aufgaben nutzen will.
3.Stufe Sicherung und Verteilung – die Daten aus der Cloud, welche auf meinen lokalen Server mittels rsync kopiert wurden, werden auf eine externe USB Festplatte kopiert. Hier gibt es 5 Festplatten, welche je au 3 Standorte verteilt sind.