Alle seine Daten an einem einzigen Ort zu sammeln klingt praktisch, aber auch gefährlich: man baut sich einen erstklassigen single point of failure. Dabei gibt es (mindestens) zwei Aspekte, die betrachtet weden müssen: menschliches Versagen und technisches Versagen. Gemäß Murphys Gesetzes wird alles, was schiefgehen kann, auch früher oder später schiefgehen -- von daher ist man gut daran beraten, für beide Fehlerquellen vorzusorgen.
Als menschliches Versagen betrachte ich das versehentliche Löschen oder anderweitige Beschädigen von Daten. Ist jedem schon mal passiert: "Sind Sie sicher?" - "Ja" - "Nein" - "Ohh!". Aber auch Ransomware-Angriffe fallen für mich in diese Kategorie; wenn Daten zerstört werden und dies wie eine legale Benutzeraktion aussieht, dann wandert das natürlich auch wunderbar in sämtliche Backups, wird remote repliziert, etc. weshalb hier ein besonderer Schutz notwendig ist.
Als technisches Versagen betrachte ich den Defekt einer Festplatte oder des Raspberry Pis als ganzes. Letzteres ist eigentlich gar nicht so schlimm, solange die USB-Festplatten nicht beschädigt werden und einfach an einem anderen System angeschlossen werden können. Gegen technisches Versagen hilft im Wesentlichen Redundanz -- wie hochgradig hängt davon ab, wie groß die Verlustängste sind.
Man hört gelegentlich von der 3-2-1-Regel für Backups. Sie besagt, dass man 3 Ausführungen seiner Daten haben sollte (1 Original plus 2 Kopien), auf 2 verschiedenen Medien(typen), davon 1 an einem externen Standort. Der Einsatz verschiedener Medientypen dient dem Schutz vor medientypischen Ausfällen; bei zwei unterschiedlichen Medientypen ist es unwahrscheinlicher, dass beide gleichzeitig den Geist aufgeben. Die eine Kopie am externen Standort schützt vor z.B. dem erwähnten Hausbrand. Früher war das typischerweise ein Band im Bankschließfach, heute wird oft auf Cloud-Storage zurückgegriffen.
Als erstes Sicherheitsnetz verwende ich rdiff-backup lokal auf dem
Raspberry Pi. rdiff-backup legt beim ersten Aufruf ein Spiegelbild der Dateien an, welches wie ein
gewöhnliches Verzeichnis mit Dateien aussieht und ebenso bearbeitet werden kann. Außerdem wird ein
Unterverzeichnis rdiff-backup-data angelegt, in dem Zusatzinformationen gespeichert werden. Bei
späteren Aufrufen werden Änderungen an den Original-Dateien nachgeführt (Inkremente angelegt) --
und hier ergibt sich ein Unterschied zu anderen Backup-Lösungen: das Spiegelbild der Dateien zeigt immer
den aktuellen Stand; in rdiff-backup-data werden die Änderungen so vermerkt, dass man
sie rückwärts anwenden kann, die Änderungen also ungeschehen machen kann. Die Tatsache,
dass das Spiegelbild immer den neuesten Stand zeigt, entschärft auch den unwahrscheinlichen Fall, dass
rdiff-backup eines Tages nicht mehr zur Verfügung stehen könnte: an den letzten Stand der
Daten kommt man immer noch dran, ein solches Backup hat also immer noch den Status einer Komplettsicherung. Man
kann
Um ein in sich konsistentes Backup zu erhalten, stoppe ich zunächst alle Dienste, führe dann das Backup durch, und starte danach die Dienste wieder. Es gibt zwar auch Möglichkeiten, Backups im laufenden Betrieb durchzuführen bzw. jeden Dienst einzeln zu behandeln, aber da ich mit einer kurzen Downtime prima leben kann, halte ich es mit dem KISS-Prinzip: Keep It Simple, Stupid. Damit die Downtime nicht weiter stört, führe ich das Backup per Cronjob nachts bzw. in den sehr frühen Morgenstunden aus.
Das lokale Backup ist schon gut und schützt vor dem menschlichen Versagen. Aber die Gefahr des technischen
Versagens ist immer noch gegeben: wenn die Backups auf dem gleichen physischen Datenträger lagern wie die
Original-Daten (oder in meinem Fall zumindest am selben Netzteil hängen; Blitzschlag!), dann wäre ein
Hardwaredefekt immer noch fatal. Dieses Problem lässt sich dadurch beseitigen, dass die Backups an weiteren
Orten gespeichert werden. Zu diesem Zweck verwende ich rsync, mit dem ich
einfach das von rdiff-backup angelegte Backup auf einen weiteren Rechner duplizieren kann.
rsync ist ziemlich clever was die Reduktion der zu transferierenden Daten betrifft (es werden
blockweise Deltas bestimmt und nur diese übertragen). Dementsprechend wenig stört es, diese
Remote-Replizierung regelmäßig durchzuführen.
Das von rdiff-backup erzeugte lokale Backup kann jederzeit kopiert werden, außer während
des (nächtlichen) Zeitfensters in dem das Backup aktualisiert wird. Somit kann das auch von einem Rechner
aus erfolgen, der typischerweise tagsüber an ist, wie z.B. in meinem Fall mein Netbook; es vergehen selten
mehrere Tage am Stück, an denen ich es nicht an habe. Im Falle eines Hardwaredefekts ist also zumindest ein
Backup vorhanden, das nicht älter als ein paar Tage ist. Um jetzt noch einen Langzeitschutz vor
"gebackuptem menschlichen Versagen" (also versehentlich beschädigter oder veränderter Daten, deren
Änderung schon länger als 6 Monate her ist) zu gewährleisten, kann dieses gespiegelte Backup
regelmäßig als Kopie archiviert werden. Ist der zeitliche Abstand zwischen den archivierten Kopien
geringer, als der Zeitraum den man innerhalb eines Backups zurückgehen kann, ist man sicher.
Ein Beispiel:
Damit könnte immer noch ein ganzes archiviertes Backup kaputt gehen, ohne dass Lücken entstehen. Als Offline-Medium für die Langzeitablage bieten sich bei den heutigen Datenmengen nur noch externe Festplatten an. Magnetband scheint tot zu sein, DVDs sind den Datenmengen nicht mehr gewachsen und USB-Sticks oder SD-Karten sind fehleranfälliger als ihre "große Schwester", die SSD.
Meine Befehlszeile für rdiff-backup sieht so aus, aufgerufen aus dem Basisverzeichnis:
rdiff-backup . /mnt/backup/filebox4
Das bedeutet: führe das Backup für das Verzeichnis . aus (also inklusive
bin, services und volumes) und speichere es im Zielverzeichnis
/mnt/backup/filebox4 ab. Letzteres ist bei mir die Magnetfestplatte, die mit 2 TB doppelt so
groß wie die SSD mit den Live-Daten ist und somit locker den Overhead von rdiff-backup
aufnehmen kann. Das Backup muss als root ausgeführt werden, weil manche Anwendungen
Verzeichnisse und Dateien unter anderem Benutzernamen anlegen (z.B. www-data), und der Benutzer
pi sie deshalb nicht lesen kann.
Für den Einsatz von rsync muss etwas mehr getan werden, weil ein Remote-Zugang benötigt
wird:
Um einen passwortlosen Root-Zugang anzulegen erstelle ich zunächst ein
SSH-Schlüsselpaar, lege den öffentlichen Schlüssel auf dem Raspberry Pi unter
/root/.ssh/authorized_keys ab und verwahre den privaten Schlüssel sorgsam in dem Verzeichnis,
in dem ich die Backups ablege (in dem Fall auf meinem Netbook). Selbstredend muss man auf den privaten
Schlüssel gut aufpassen, weil man sich damit eben passwortlos auf dem Raspberry Pi als
root anmelden kann -- was aber auch notwendig ist, weil das zuvor von root angelegte
Backup diverse Dateien beinhaltet, die pi (immer noch) nicht lesen kann. Wer möchte kann
für den privaten Schlüssel eine Passphrase vergeben, was allerdings die Automatisierung via Cronjobs
erschwert.
Auf meinem Netbook:
mkdir -m 700 /home/felix/filebox-backup # Arbeitsverzeichnis anlegen, Zugriffsrechte rwx------ cd /home/felix/filebox-backup # in Arbeitsverzeichnis wechseln mkdir ssh-keys # Verzeichnis für SSH-Schlüsselpaar anlegen ssh-keygen -f ssh-keys/backup # SSH-Schlüsselpaar erzeugen
Auf dem Raspberry Pi:
sudo mkdir -m 700 /root/.ssh # Konfigurationsverzeichnis erstellen, rwx------ sudo vi /root/.ssh/authorized_keys # Datei erzeugen, öffentlichen Schlüssel eintragen sudo chmod 600 /root/.ssh/authorized_keys # Zugriffsrechte auf rw------- reduzieren
Um die eigentliche Replizierung durchzuführen genügt nun diese Befehlszeile:
sudo rsync -avz --delete -e "ssh -i /home/felix/filebox-backup/ssh-keys/backup" root@filebox:/mnt/backup/filebox4 .
Mit -a wird der Archiv-Modus gesetzt, der u.a. die Eigentümer der Dateien beibehält. Das
ist auch der Grund, warum rsync lokal ebenfalls als root gestartet werden muss -- die
Dateien mit fremden Eigentümern müssen ja auch im lokalen Dateisystem diesen Benutzern gehören.
Der Parameter -v erhöht die Geschwätzigkeit und ist optional. Mit -z wird
die Kompression auf dem Übertragungsweg aktiviert, ebenfalls optional.
Etwas mehr Beachtung verdient wieder der Ausdruck mit -e; hier wird mitgeteilt, welche Remote-Shell
benutzt werden soll. Zwar ist ssh der Default, aber wegen des speziellen Key-Setups ist der Hinweis
auf das Identity-File (-i) notwendig. Alternativ könnte man sich einen persönlichen
Schlüssel anlegen, in ~/.ssh/id_rsa ablegen und diesen auf dem Pi unter
/root/.ssh/authorized_keys eintragen; dann entfällt der -e-Ausdruck komplett.
Allerdings fühlt sich das für mich nicht richtig an, weil es ja nicht mein Schlüssel im
Sinne meines Benutzers felix ist, sondern er speziell für den Zweck des Backups angelegt wurde
und auch nur so verwendet werden soll.