Server-Backups: die 3-2-1-Regel und die Wiederherstellung

Die 3-2-1-Regel besagt: Halten Sie drei Kopien Ihrer wichtigen Daten (das Original und zwei Sicherungen) auf zwei verschiedenen Speicherarten, und bewahren Sie mindestens eine Kopie an einem anderen Ort auf. Auf einem VPS heißt das: Zusätzlich zu den Daten auf dem Server selbst gibt es mindestens eine Kopie außerhalb des Servers.

Dieselbe Regel wird im Papier Data Backup Options empfohlen, das für US-CERT erstellt und auf der Website der CISA veröffentlicht wurde. Ihr Zweck ist sicherzustellen, dass ein einzelner Ausfall, Fehler oder Angriff nicht alle Kopien auf einmal zerstören kann.

Sicherung, Snapshot und Festplattenredundanz sind nicht dasselbe

• Sicherung: eine separate Kopie Ihrer Daten, meist mit früheren Versionen. Sie bringt eine versehentlich gelöschte oder beschädigte Datei zurück.
• Snapshot: hält den Zustand des Servers in diesem Moment fest. Er eignet sich als schneller Rückweg vor einem großen Update. Er hängt aber von der ursprünglichen Festplatte ab und ersetzt deshalb keine Sicherung.
• Festplattenredundanz: dieselben Daten werden gleichzeitig auf zwei Festplatten geschrieben. Sie schützt Sie, wenn eine Festplatte ausfällt. Eine gelöschte Datei ist auf beiden Festplatten gelöscht, und von Ransomware verschlüsselte Daten sind auf beiden verschlüsselt. Es ist also keine Sicherung.

So wenden Sie 3-2-1 auf einem VPS an

Die tägliche Sicherung aus dem Panel können Sie als eine Ihrer Kopien zählen. Die Kopie, die die Bedingung „an einem anderen Ort“ erfüllt, ist aber eine, die Sie selbst einrichten und kontrollieren. Auch die Nutzungsbedingungen von Seturack bitten Sie, eine Kopie Ihrer wichtigen Daten separat aufzubewahren.

Was gesichert werden sollte

Wenn Sie die Dateien einer laufenden Datenbank kopieren, kann die Sicherung inkonsistent werden. Erstellen Sie zuerst einen Dump. Diese Befehle laufen als root, wie in einem Cron-Skript:

mysqldump --single-transaction --all-databases | gzip > /var/backups/mysql-$(date +%F).sql.gz

sudo -u postgres pg_dumpall | gzip > /var/backups/pg-$(date +%F).sql.gz

Bei Dateien genügt Folgendes: /etc, die Dateien Ihrer Websites, der Datenordner Ihrer Anwendung, Docker-Volumes, falls Sie Docker nutzen, und .env-Dateien. Sichern Sie nicht, was Sie erneut herunterladen können, etwa Pakete und Docker-Images. Wenn Ihre Anwendung einen Verschlüsselungsschlüssel hat, bewahren Sie auch ihn separat auf. Bei manchen Anwendungen ist eine Sicherung ohne den Schlüssel nutzlos.

Wie oft Sie sichern, hängt davon ab, wie viele Daten Sie sich zu verlieren leisten können. Eine Sicherung pro Tag bedeutet im schlimmsten Fall den Verlust von bis zu einem Tag an Daten. Bei einer Anwendung, die Bestellungen oder Zahlungen erfasst, ist es sicherer, die Datenbank stündlich zu dumpen und vom Server wegzuschicken.

Eine Sicherung außerhalb des Servers mit restic

restic ist ein Open-Source-Backup-Werkzeug, das Ihre Sicherungen verschlüsselt und wiederholte Daten nur einmal speichert. Das folgende Beispiel schreibt die Sicherung auf einen anderen Server, der über SFTP erreicht wird. Das Ziel braucht eine passwortlose (schlüsselbasierte) SSH-Anmeldung, weil eine automatische Sicherung keine Passwortabfrage beantworten kann. Erstellen Sie die Passwortdatei (/root/.restic-password) in einem Texteditor und führen Sie chmod 600 darauf aus.

sudo apt install -y restic

export RESTIC_REPOSITORY=sftp:[email protected]:/backups/vps

export RESTIC_PASSWORD_FILE=/root/.restic-password

restic init

restic backup /etc /var/www /var/backups

restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

Die restic-Dokumentation warnt: Wenn Sie das Passwort verlieren, sind Ihre Daten für immer weg. Bewahren Sie das Passwort auch in einem Passwortmanager auf. Legen Sie die beiden export-Zeilen, die Datenbank-Dumps, restic backup und restic forget in dieser Reihenfolge in ein Skript wie /usr/local/bin/backup.sh und machen Sie es mit chmod +x ausführbar. Vergessen Sie nicht, am Ende eine Zeile hinzuzufügen, die alte Dumps löscht, find /var/backups -name '*.sql.gz' -mtime +2 -delete, sonst füllen die Dump-Dateien die Festplatte. Führen Sie das Skript dann jede Nacht aus, zum Beispiel aus /etc/cron.d/backup mit dieser Zeile:

30 3 * * * root /usr/local/bin/backup.sh

borg ist ein ähnliches Werkzeug. Für einfache Dateikopien können Sie rsync nutzen, zum Übertragen auf Objektspeicher rclone.

Der eigentliche Test: die Wiederherstellung

Eine Sicherung, die Sie nicht wiederherstellen können, ist wertlos. Probieren Sie es gleich nach der Einrichtung aus und dann in regelmäßigen Abständen:

• Entpacken Sie mit restic die neueste Sicherung in einen leeren Ordner und prüfen Sie die Dateien: restic restore latest --target /tmp/restore-test
• Laden Sie einen Datenbank-Dump in eine temporäre Datenbank und sehen Sie sich die Tabellen an.
• Klicken Sie im Panel neben einer Sicherung auf das Symbol Dateien daraus wiederherstellen, stöbern Sie darin und laden Sie eine Datei herunter. Eine vollständige Wiederherstellung ersetzt die gesamte aktuelle Festplatte, daher ist die Wiederherstellung einer einzelnen Datei der sicherere Test.

Wählen Sie die Aufbewahrungsdauer danach, wie spät Sie ein Problem bemerken könnten. Die Panel-Sicherung hält die letzten 7 Tage vor, weiter zurück können Sie nicht gehen. Wenn Sie ältere Versionen brauchen könnten, bewahren Sie wöchentliche und monatliche Versionen in Ihrer eigenen Kopie auf. Einzelheiten zur Panel-Sicherung stehen im Artikel zu täglichen Sicherungen.

Häufige Fehler

• Die Sicherung auf die Festplatte desselben Servers schreiben. Läuft die Festplatte voll oder geht der Server verloren, geht die Sicherung mit.
• Das Sicherungspasswort oder den Schlüssel am selben Ort wie die Sicherung aufbewahren.
• Nicht bemerken, dass das Skript fehlschlägt. Bauen Sie eine Benachrichtigung in das Skript ein oder prüfen Sie ab und zu mit restic snapshots das Datum der letzten Sicherung.
• Nicht beobachten, wie sich das Sicherungsziel füllt. Ein volles Ziel bedeutet Sicherungen, die unbemerkt scheitern.