VPS-Backups und Wiederherstellung planen

1. Definieren Sie eine erfolgreiche Wiederherstellung

Das Recovery Point Objective (RPO) beschreibt, wie viele neue Änderungen Sie im Störungsfall zu verlieren bereit sind. Das Recovery Time Objective (RTO) beschreibt die angestrebte Zeit bis zur Wiederherstellung des Dienstes. Beides sind Planungsziele, keine eingekaufte Garantie. Bei einer täglichen Sicherung kann ungefähr ein Tag seit der letzten erfolgreichen Sicherung ungeschützt bleiben; unbemerkte Fehler können die Lücke deutlich vergrößern.

Berücksichtigen Sie beim Zeitbedarf den Neuaufbau der Umgebung, den Datenabruf, die Wiederherstellung von Geheimnissen, die Verkehrsumstellung und die Anwendungsprüfung. Wenn Ihr Ziel keine improvisierten Abläufe erlaubt, dokumentieren oder automatisieren Sie diese Schritte und testen Sie das Ergebnis vor einem Vorfall.

2. Erstellen Sie ein Verzeichnis vor der Werkzeugauswahl

• Persistente Anwendungsdaten und Volumes.
• Ein konsistenter Datenbankexport oder eine vom Datenbanksystem unterstützte physische Sicherung.
• Konfiguration von Webserver, Prozessverwaltung und Deployment.
• Anwendungsgeheimnisse und Verschlüsselungsschlüssel, die nach der Wiederherstellung benötigt werden.
• Anwendungsversion oder Image-Digest und die Startreihenfolge der Komponenten.

Bewahren Sie das Repository-Passwort an einem Ort auf, der beim Verlust des VPS erreichbar bleibt. Seine einzige Kopie innerhalb der verschlüsselten Sicherung zu speichern, verhindert die Wiederherstellung. Schützen Sie Repository-Zugangsdaten und Anwendungsgeheimnisse ebenso sorgfältig wie den Produktionszugang.

Ein Archiv auf demselben VPS-Datenträger kann als Zwischenablage dienen, ist aber keine unabhängige Kopie gegen den Verlust dieses VPS oder Datenträgers. Planen Sie ein getrenntes, geschütztes Ziel und klären Sie, wer es löschen oder verändern kann. Wenn ein kompromittierter Produktionsserver sämtliche Sicherungen löschen kann, löst Verschlüsselung allein das Problem nicht.

3. Bereiten Sie den Repository-Zugang vor und prüfen Sie ihn

Das folgende Beispiel setzt eine für Ihre Distribution und Version geeignete Restic-Installation voraus. Gezeigt wird eine Ubuntu-Paketinstallation in einer von Ihnen verwalteten Umgebung. Daraus folgt nicht, dass ein bestimmtes Betriebssystem-Image in einem VPS-Paket enthalten ist. Lesen Sie vor der Anwendung die Paket- und Restic-Dokumentation.

Der SFTP-Hostname backup.example ist ein Platzhalter für einen getrennten Server unter Ihrer Kontrolle. Ersetzen Sie Konto, Hostname und beschreibbaren Pfad. Prüfen Sie vor der Repository-Initialisierung den SSH-Hostschlüssel und den Zugang. Deaktivieren Sie die Hostprüfung nicht, um einen Verbindungsfehler zu umgehen.

sudo apt update
sudo apt install restic nano
sudo -i

Das nächste Beispiel läuft in dieser Administrations-Shell. Tragen Sie ein einzigartiges Repository-Passwort mit dem Editor ein. Schreiben Sie das Passwort selbst nicht in eine Befehlszeile oder den Shell-Verlauf. Bewahren Sie eine unabhängige, gesicherte Aufzeichnung auf.

umask 077
touch /root/restic-password
chmod 600 /root/restic-password
nano /root/restic-password
export RESTIC_PASSWORD_FILE=/root/restic-password
export RESTIC_REPOSITORY="sftp:backupuser@backup.example:/srv/restic/serverq"
restic init
restic snapshots

Verwenden Sie init nur zum Erstellen eines neuen Repositorys. Mit snapshots prüfen Sie den Zugriff auf ein bestehendes Repository. Die SSH-Zugangsdaten müssen dem Konto zur Verfügung stehen, das die Sicherung ausführt. Diese Umgebungsvariablen gelten nur in der aktuellen Shell; ein geplanter Auftrag benötigt dieselbe Konfiguration ausdrücklich und sicher bereitgestellt.

4. Brechen Sie bei einem fehlgeschlagenen Datenbankexport ab

Das folgende Beispiel exportiert eine MariaDB-Datenbank namens wordpress, bevor Anwendungsdateien und Zwischenablage gesichert werden. --single-transaction gilt für transaktionale Tabellen wie InnoDB und garantiert nicht für jede Speicher-Engine oder gleichzeitige Schemaänderung Konsistenz. Vermeiden Sie während des Exports Updates, die Tabellen verändern.

Wenn Datenbank und Dateien denselben Anwendungsstand abbilden müssen, planen Sie ein passendes Wartungsfenster, eine Schreibpause oder ein von der Anwendung unterstütztes konsistentes Sicherungsverfahren. Eine erfolgreiche Dateikopie kann einen zuvor gescheiterten Datenbankexport nicht reparieren.

install -d -m 0700 /root/backup-staging
if mariadb-dump --single-transaction --routines --events wordpress > /root/backup-staging/wordpress.sql.tmp; then
  mv /root/backup-staging/wordpress.sql.tmp /root/backup-staging/wordpress.sql
else
  echo "Database export failed; backup stopped." >&2
  exit 1
fi
restic backup /var/www/wordpress /etc/nginx /root/backup-staging
restic snapshots
restic check

restic check prüft die Repository-Struktur. Das Lesen aller Datenpakete mit restic check --read-data ergänzt eine stärkere Prüfung der lesbaren Daten, benötigt jedoch Zeit und kann bei einem entfernten Repository Übertragungsvolumen verursachen. Planen Sie dies nach Datenmenge und Anbieterbedingungen. Ein geplanter Auftrag belegt noch keine abgeschlossene Sicherung.

5. Stellen Sie getrennt wieder her und prüfen Sie die Anwendung

RESTORE_DIR=$(mktemp -d /var/tmp/serverq-restore.XXXXXX)
restic restore latest --target "$RESTORE_DIR"
find "$RESTORE_DIR" -maxdepth 3 -type d
restic check --read-data

Prüfen Sie die Snapshots und wählen Sie den gewünschten Wiederherstellungspunkt. latest ist für eine Probe praktisch, doch auch die jüngste erfolgreiche Sicherung kann einen neuen Fehler enthalten. Wählen Sie im Ernstfall den Snapshot passend zum Wiederherstellungsziel. Kopieren Sie das wiederhergestellte Verzeichnis nicht automatisch über die laufende Produktionsanwendung.

1. Prüfen Sie wichtige Dateien und vergleichen Sie gegebenenfalls erwartete Anzahlen oder Prüfsummen.
2. Importieren Sie die Datenbank in eine getrennte Testdatenbank, bei der Probe niemals über die produktive Datenbank.
3. Starten Sie die passende Anwendungsversion mit den benötigten Geheimnissen in einer isolierten Umgebung.
4. Deaktivieren oder ersetzen Sie produktive E-Mails, Zahlungen, Webhooks und geplante Aufgaben.
5. Prüfen Sie Anmeldung, einen typischen Lese- und Schreibvorgang sowie den Abruf einer Datei oder eines Mediums.
6. Notieren Sie die Wiederherstellungsdauer, fehlende Schritte und den wiederhergestellten Datenstand.

Bei n8n kann eine wiederhergestellte Datenbank ohne den richtigen Verschlüsselungsschlüssel gespeicherte Zugangsdaten unbrauchbar lassen. Bei WordPress können fehlende Uploads zu ladenden Seiten mit defekten Bildern führen. Prüfen Sie die tatsächlich benötigte Geschäftsfunktion, nicht nur den Prozessstatus oder einen erfolgreichen Restic-Rückgabecode.

6. Prüfen Sie Aufbewahrung, Zugriff und Kosten gemeinsam

restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --dry-run

Dies ist ein Beispiel für eine Aufbewahrungsverteilung und keine rechtliche oder betriebliche Empfehlung für jedes Unternehmen. Prüfen Sie die Ausgabe des Probelaufs, die Snapshot-Gruppierung und unabhängige Kopien, bevor Sie eine Löschregel übernehmen. Das Freigeben von Repository-Speicher mit prune ist ein eigener Vorgang, der Daten löscht und geplant sowie geprüft werden sollte.

Berücksichtigen Sie Repository, Wiederherstellungstraffic, Zwischenablage und Verwaltung im Budget. Reservieren Sie auf dem VPS Platz für vorübergehende Exporte und Protokolle, während die unabhängige Kopie andernorts liegt. Dokumentieren Sie den Notfallzugriff auf das Passwort und prüfen Sie, wer Sicherungen lesen oder löschen darf. Wiederholen Sie die Wiederherstellungsprobe nach wesentlichen Änderungen an Anwendung, Datenbank oder Deployment.