Praxisanleitung / Wiederherstellung testen

Ubuntu VPS Backup: Wiederherstellung mit Prüfsummen testen

Eine vorhandene Archivdatei sagt noch nicht, ob du deine Daten wiederherstellen kannst. Diese Übung sichert zwei kleine Beispieldateien, lagert das Archiv aus und prüft die Wiederherstellung in einem neuen Verzeichnis. Sie verändert keinen laufenden Webserver und ersetzt kein vollständiges VPS- oder Datenbank-Backup.

In dieser Anleitung

Was dieser Test nachweist und was nicht

Geprüft werden Archivierung, Übertragung und die unveränderte Wiederherstellung ausgewählter Dateien. Die Übung startet keinen wiederhergestellten Dienst und prüft keine Datenbankkonsistenz, Zertifikate, Benutzer oder vollständigen Systemzustand.

Für ein echtes Projekt legst du vorher fest, welche Daten unverzichtbar sind, wie alt eine Sicherung höchstens sein darf und wie lange die Wiederherstellung dauern darf. RPO und RTO sind Ziele; ohne Messung sind sie noch keine erreichten Werte.

Ein separates Testverzeichnis vorbereiten

Die Befehle verwenden Bash, GNU tar, sha256sum und gegebenenfalls scp. Führe zusammengehörige Schritte in derselben Sitzung aus, damit die Variablen erhalten bleiben. Die restriktive Dateimaske und mktemp halten die Übung von vorhandenen Verzeichnissen getrennt.

umask 077
backup_lab=$(mktemp -d "$HOME/ubuntu-vps-backup.XXXXXX")
mkdir -p "$backup_lab/payload/site" "$backup_lab/payload/nginx" "$backup_lab/export"
printf '%s\n' '<!doctype html><html lang="de"><title>Wiederherstellungstest</title><h1>Wiederhergestellte statische Seite</h1></html>' > "$backup_lab/payload/site/index.html"
printf '%s\n' 'server {' '    listen 8080;' '    server_name example.test;' '    root /var/www/first-site;' '}' > "$backup_lab/payload/nginx/first-site.conf"
printf 'Übungsverzeichnis: %s\n' "$backup_lab"

Die zwei erzeugten Beispieldateien enthalten keine echten Website-Daten. Wenn du stattdessen deine eigene statische Site exportieren möchtest, prüfe zuerst die tatsächlichen, lesbaren Pfade. Verwende den folgenden optionalen Export nicht ungeprüft:

install -m 600 /var/www/first-site/index.html "$backup_lab/payload/site/index.html"
install -m 600 /etc/nginx/sites-available/first-site "$backup_lab/payload/nginx/first-site.conf"

Der Export einer HTML-Datei und einer Nginx-Konfiguration ist keine vollständige Sicherung einer dynamischen Anwendung. Datenbanken, Uploads, Geheimnisse, Zertifikate und weitere Konfigurationen benötigen einen eigenen, konsistenten Umfang.

Dateimanifest und Archiv erstellen

Das innere Manifest prüft die ausgewählten Dateien nach der Wiederherstellung. Die äußere Prüfsumme prüft das transportierte Archiv als Ganzes.

(
    cd "$backup_lab/payload" &&
    sha256sum site/index.html nginx/first-site.conf > SHA256SUMS
)
tar -czf "$backup_lab/export/static-site.tar.gz" -C "$backup_lab/payload" site nginx SHA256SUMS
(
    cd "$backup_lab/export" &&
    sha256sum static-site.tar.gz > static-site.tar.gz.sha256
)
tar -tzf "$backup_lab/export/static-site.tar.gz"
printf 'Exportverzeichnis auf dem Server: %s\n' "$backup_lab/export"

Prüfsummen erkennen Änderungen gegenüber den mitgelieferten Vergleichswerten. Wenn Angreifer Archiv und Prüfsummendatei gemeinsam ersetzen können, beweist ein passender Hash keine Authentizität. Bewahre vertrauenswürdige Vergleichswerte beziehungsweise signierte Sicherungen getrennt auf.

Kopie außerhalb der Instanz ablegen

Öffne auf einem anderen Rechner eine lokale Bash-Sitzung. Verwende deinen geprüften SSH-Zugang und ersetze den markierten entfernten Pfad durch das tatsächlich ausgegebene Exportverzeichnis. Kopiere Archiv und Prüfsummendatei:

umask 077
recovery_dir=$(mktemp -d "$HOME/ubuntu-vps-restore.XXXXXX")
remote_backup=/home/deploy/ubuntu-vps-backup.REPLACE/export
scp -i ~/.ssh/ubuntu_vps "deploy@203.0.113.10:$remote_backup/static-site.tar.gz" "$recovery_dir/"
scp -i ~/.ssh/ubuntu_vps "deploy@203.0.113.10:$remote_backup/static-site.tar.gz.sha256" "$recovery_dir/"

Vergleiche beim Verbindungsaufbau die Serveridentität wie sonst auch. Eine zweite Datei auf demselben VPS ist keine unabhängige Kopie. Prüfe die heruntergeladenen Dateien, bevor du die Instanz oder Originaldaten entfernst.

In ein neues Verzeichnis wiederherstellen

Prüfe zuerst die Archiv-Prüfsumme und lasse den Inhalt auflisten. Erwartet werden nur die vorbereiteten relativen Dateinamen, ohne absolute Pfade oder ..-Ausbrüche. Verwende für fremde, nicht vertrauenswürdige Archive nicht einfach diesen Übungsablauf.

(
    cd "$recovery_dir" &&
    sha256sum -c static-site.tar.gz.sha256
)
tar -tzf "$recovery_dir/static-site.tar.gz"

Extrahiere in das frisch angelegte Verzeichnis. Die Optionen erhalten vorhandene Dateien und übernehmen keine fremden Eigentümer. Danach prüfst du das innere Dateimanifest:

restore_dir=$(mktemp -d "$recovery_dir/restored.XXXXXX")
tar -xzf "$recovery_dir/static-site.tar.gz" -C "$restore_dir" --keep-old-files --no-same-owner
(
    cd "$restore_dir" &&
    sha256sum -c SHA256SUMS
)
cat "$restore_dir/site/index.html"

Beide Prüfungen müssen erfolgreich sein. Bei einem Fehler untersuchst du Übertragung, Archiv und Umfang, bevor du etwas in produktive Pfade kopierst. Die Nginx-Beispieldatei mit Port 8080 wird hier bewusst nicht aktiviert.

Aus der Dateiprüfung einen Betriebsplan machen

Für echte Wiederherstellungstests brauchst du zusätzlich den Start der Anwendung, eine passende Datenbankwiederherstellung, Berechtigungen, Dienste, Netzwerk und gegebenenfalls Schlüssel oder Zertifikate. Teste diese Schritte in einer isolierten Umgebung.

Notiere Sicherungszeitpunkt, wiederhergestellten Datenstand, verstrichene Dauer und fehlende Schritte. Erst damit kannst du die erreichbare Wiederherstellungszeit mit deinem Ziel vergleichen. Prüfe außerdem Aufbewahrung, Zugriffsschutz und den Fall, dass das Hosting-Konto selbst nicht mehr erreichbar ist.

Fragen und Antworten

Reicht ein Snapshot?

Das hängt von Konsistenz, Speicherort, Aufbewahrung und Wiederherstellungsweg ab. Eine unabhängige Sicherung kann Risiken abdecken, die ein Snapshot im gleichen Konto nicht abdeckt.

Beweisen Prüfsummen ein vollständiges Backup?

Nein. Sie vergleichen nur die erfassten Dateien mit den erwarteten Werten. Nicht aufgenommene Daten werden dadurch nicht sichtbar.

Kann ich das Archiv direkt über die produktive Site entpacken?

Für diese Prüfung nicht. Stelle zuerst in ein neues Verzeichnis wieder her und kontrolliere Inhalt und Anwendung, bevor du produktive Daten ersetzt.

VPSuntu: Der Ablauf mit den kleinen Beispieldateien wurde zuvor unter Git Bash auf Windows geprüft. Daraus folgt kein Nachweis eines vollständigen Ubuntu-, Datenbank- oder Cloud-Recovery-Tests.
Weiterführende Aufgaben

Dein nächster Schritt