Ein VPS-Backup, das Sie tatsächlich wiederherstellen können

Fragen Sie irgendjemanden, warum er Backups macht, und die Antwort lautet meist „falls die Festplatte stirbt“. Auf einem modernen VPS ist das ziemlich genau das Unwahrscheinlichste, was Ihnen passieren wird. Ihr Volume liegt auf NVMe in einem redundanten Array mit einem Hypervisor, der Sie von einem ausfallenden Host migriert, bevor Sie es überhaupt bemerken; ein Laufwerksausfall ist das Problem des Anbieters, und zwar ein gelöstes. Die gesamte Backup-Strategie darauf aufzubauen, ist, als würde man einen Feuerlöscher für ein Haus kaufen, das überflutet.

Hier ist, was Menschen tatsächlich die Daten nimmt, ungefähr nach Häufigkeit geordnet. An erster Stelle, mit deutlichem Abstand: Sie selbst. Ein rm -rf mit einer Variable, die zu nichts expandiert ist. Ein DROP DATABASE im falschen Terminal, weil zwei Tabs identisch aussahen. Ein Migrationsskript, das zweimal gelaufen ist. Ein docker compose down -v, bei dem das -v reines Muskelgedächtnis war. Das ist nicht exotisch; das ist Dienstag.

An zweiter Stelle: Anwendungen, die ihre eigenen Daten löschen. Ein Upgrade, das eine destruktive Migration ausführt und auf halbem Weg scheitert. Ein Plugin, das ein Cache-Verzeichnis leert, das sich als kein Cache herausstellt. Eine Log-Rotation, die gegen den falschen Pfad konfiguriert ist. An dritter Stelle: Kompromittierung – und hier will ein Angreifer ausdrücklich, dass die Backups verschwinden, was das Design auf eine Weise verändert, auf die wir weiter unten zurückkommen. An vierter Stelle, und auf einem No-KYC-Host leicht zu vergessen: der Verlust des Kontos. Ein Guthaben, das zur Neige ging, während Sie unterwegs waren, ein Passwortmanager-Eintrag, den Sie nie notiert haben, eine E-Mail-Adresse, die Sie aufgegeben haben. Wir sperren innerhalb weniger Stunden nach einem Nullsaldo und löschen sieben Tage später, und das ist bewusst gnadenlos – es ist die Rechnung, die es uns erlaubt, nicht zu fragen, wer Sie sind. Es gibt keinen Support-Mitarbeiter, der Ihre Identität nachschlagen und eine Ausnahme machen könnte, weil es keine Identität zum Nachschlagen gibt.

Diese letzte Kategorie ist es, die Privacy-First-Hosting vom Mainstream unterscheidet, und sie sollte Ihre Planung prägen. Jede Maßnahme, die diesen Server schwer auf Sie zurückführbar macht, macht es auch für jeden – uns eingeschlossen – schwer, ihn Ihnen zurückzugeben. Das Backup ist es, was diesen Tausch von einem Risiko in eine Entscheidung verwandelt.

Snapshots sind wunderbar, und Sie sollten sie nutzen. Erstellen Sie einen vor jedem Kernel-Upgrade, jeder Datenbankmigration, jedes Mal, wenn Sie etwas vorhaben, das Sie lieber rückgängig machen können sollten. Sie stellen in Sekunden wieder her, kosten fast nichts, und sie retten Ihnen ein Dutzend Mal im Jahr einen ganzen Nachmittag.

Trotzdem sind sie keine Backups, aus drei strukturellen Gründen, die kein noch so gutes Anbieter-Marketing ändert. Sie leben im selben Konto: Wer sich in Ihr Panel einloggen kann, kann sie löschen, und wenn das Konto aufhört zu funktionieren, hören auch die Snapshots auf zu existieren. Sie leben in der gleichen Fehlerdomäne: gleicher Anbieter, gleiche Kontrollebene, oft derselbe Storage-Cluster, was bedeutet, dass ein einziges schlimmes Ereignis plausibel sowohl das Original als auch die Kopie trifft. Und sie sind blind: Der Snapshot einer laufenden Maschine erfasst eine Datenbank mitten im Schreibvorgang genauso originalgetreu wie alles andere auch, sodass die Wiederherstellung eines Snapshots eines stark ausgelasteten MySQL-Servers Ihnen ein Crash-Recovery-Szenario liefert statt einer sauberen Datenbank.

Die alte 3-2-1-Regel – drei Kopien, auf zwei Arten von Medien, eine davon extern – wird meist zitiert, ohne zu bemerken, dass die mittlere Klausel auf gemieteter Infrastruktur bedeutungslos ist. Sie haben keine zwei Arten von Medien. Sie haben ein virtuelles Blockgerät und noch ein virtuelles Blockgerät, und beide sind irgendjemandes SAN. Was die Übersetzung auf einen VPS übersteht, ist der Teil, der schon immer zählte: Mindestens eine Kopie muss dort liegen, wo ein einzelnes schlimmes Ereignis sie nicht erreichen kann. Anderer Anbieter oder zumindest andere Region, andere Zugangsdaten, anderes Konto, und – wenn der Grund für Offshore-Hosting rechtlicher statt technischer Natur ist – eine andere Jurisdiktion, damit nicht ein einziger Gerichtsbeschluss beide Kopien auf einmal trifft.

Das ist der Abschnitt, den andere Backup-Tutorials nicht haben, und es ist derjenige, der am meisten zählt, wenn Sie diesen Server mit Monero bezahlt haben.

Der Standardrat überall im Internet lautet, Ihre Backups zu einem Objektspeicher zu pushen: Backblaze B2, Amazon S3, Wasabi, ein Google Drive über rclone. Das ist billig, es ist haltbar, es funktioniert. Es macht auch, mit einem einzigen Befehl, einen großen Teil dessen zunichte, was Sie vorhatten. Das Eröffnen dieses Kontos erforderte eine Karte und meist ein Ausweisdokument. Ab dem Moment, in dem der erste Snapshot hochlädt, besitzt dieser Anbieter einen zeitgestempelten Datensatz, der Ihren Namen und Ihre Zahlungsdaten mit der IP-Adresse Ihres Servers verknüpft, stündlich aktualisiert, für immer. Sie haben Ihre Identität nicht bei uns verifiziert; Sie haben sie bei denen verifiziert – und damit eine Linie zwischen beiden gezogen.

Die zweite Hälfte ist schlimmer, und das ist der Teil, den die meisten übersehen. Der API-Schlüssel, der diese Uploads autorisiert, ist eine Datei auf dem Produktivserver. Wer auch immer Root auf dieser Box bekommt – oder wer auch immer sich rechtmäßig die Festplatte beschafft –, bekommt nicht nur Ihre Daten. Er bekommt eine Zugangsberechtigung, die sich mit einem einzigen API-Aufruf zu einer Abrechnungsidentität auflöst. Der anonyme Server ist zu einem Wegweiser geworden, der auf Ihre Bank zeigt.

Nichts davon macht Objektspeicher falsch. Es macht ihn zu einer Entscheidung statt zu einem Standard. Drei Auswege, absteigend danach geordnet, wie gut sie das bewahren, womit Sie angefangen haben:

• Ein zweiter No-KYC-VPS, idealerweise in einer anderen Jurisdiktion als die Produktion, bezahlt aus demselben Krypto-Guthaben. Das Ziel erbt die Anonymitätseigenschaften der Quelle, statt ihnen zu widersprechen. Das ist es, was wir tun, und wovon der Rest dieser Anleitung ausgeht.
• Ein Speicheranbieter, der Krypto ohne Identität akzeptiert. Es gibt sie; sie sind kleiner; prüfen Sie, ob der Zahlungsweg wirklich identitätsfrei ist, bevor Sie dem Marketing vertrauen, und prüfen Sie die Egress-Preise, bevor Sie während einer Wiederherstellung davon überrascht werden.
• Eine Maschine, die Ihnen physisch gehört, die über WireGuard hinter Ihrem eigenen Anschluss pullt. Exzellent für Anonymität, schwach bei Verfügbarkeit, und es bedeutet, dass Ihre Restore-Geschwindigkeit Ihre heimische Upload-Geschwindigkeit ist. Vertretbar als dritte Kopie, schwach als einzige.

Für welche Option Sie sich auch entscheiden: Das Konto, das die Backups hält, sollte keine Zugangsdaten, E-Mail-Adresse oder Wiederherstellungsweg mit dem Konto teilen, das die Produktion hält. Der ganze Sinn ist, dass ein kompromittierter Login nicht beide erreichen darf. Das ist dieselbe Disziplin wie Identitäten anderswo getrennt zu halten, angewandt auf die unglamouröseste Ecke des Systems.

Fast jedes Backup-Tutorial erzeugt dieselbe Architektur: einen Cron-Job auf dem Produktivserver, der sich bei einem entfernten Repository authentifiziert und dorthin schreibt. Das ist einfach, es funktioniert, und es hat eine Eigenschaft, die niemand erwähnt – der Produktivserver besitzt eine Zugangsberechtigung, die das gesamte Repository löschen kann. Das Aufräumen alter Snapshots erfordert Löschrechte, also ist der Schlüssel, der Ihren nächtlichen Job ausführt, auch der Schlüssel, der den Tresor leert.

Überlegen Sie, was das im Fall einer Kompromittierung bedeutet. Ein Angreifer mit Root auf der Box muss Ihre Backups nicht erst finden; Sie haben ihm freundlicherweise eine funktionierende Zugangsberechtigung und eine Konfigurationsdatei mit dem Namen des Repositorys hinterlassen. Backups aufzuspüren und zu zerstören, bevor irgendetwas Sichtbares ausgelöst wird, ist keine hypothetische Feinheit – es ist gängige Praxis, weil es genau das ist, was aus einem Vorfall eine Verhandlung macht. Ihr nächtlicher Job war die Aufklärung.

Es gibt drei Bauformen, und der Unterschied zwischen ihnen dreht sich vollständig darum, welche Maschine welchen Schlüssel besitzt.

Plain Push ist die oben beschriebene. Die Produktion hat Read-Write-Delete. Bequem, und sie versagt vollständig genau in dem Szenario, in dem Sie ein Backup am dringendsten brauchen. Nutzen Sie sie nur, wenn die einzige Bedrohung, die Sie wirklich interessiert, Ihre eigenen Finger sind.

Append-only Push behält dieselbe Form, entfernt aber das gefährliche Verb. Das Repository wird von etwas bedient, das das Protokoll versteht und Löschungen verweigert: rest-server --append-only für restic, oder ein über authorized_keys erzwungenes borg serve --append-only. Die Produktion kann neue Snapshots erstellen und keine alten entfernen. Das Aufräumen passiert später, von woanders, mit einem anderen Schlüssel. Das ist eine erhebliche Verbesserung für etwa zwanzig Minuten Arbeit, und für die meisten Leute ist es der richtige Punkt, an dem man stehen bleiben sollte.

Pull kehrt die Verbindung um. Der Backup-Host greift über SSH in die Produktion hinein, kopiert, was er braucht, und führt das Backup-Tool lokal auf seiner eigenen Platte aus. Die Produktion besitzt überhaupt keine Backup-Zugangsdaten – es gibt nichts auf dieser Maschine zu finden, weil die Maschine nicht weiß, wo ihre Backups leben. Das ist die stärkste Anordnung, und es ist das, was die Schritt-für-Schritt-Anleitung unten aufbaut.

Seien Sie ehrlich darüber, was Pull kostet, denn gratis ist es nicht. Sie haben den Schlüssel verschoben statt ihn zu eliminieren: Der Backup-Host besitzt jetzt einen SSH-Schlüssel in die Produktion hinein, sodass eine Kompromittierung des Backup-Hosts vorwärts in das Live-System durchgreift. Das ist ein besserer Tausch – der Backup-Host führt nichts aus, exponiert nichts außer SSH und ist ein weit kleineres Ziel als ein öffentlicher Webserver –, aber es bleibt ein Tausch, und Sie schließen den größten Teil der verbleibenden Lücke, indem Sie diesen Schlüssel auf einen Read-only-Befehl zwingen, sodass er zu nichts anderem taugt, als Dateien zu lesen.

Drei Werkzeuge decken im Grunde jeden Fall ab, und die Wahl ist weniger quälend, als es Forenthreads vermuten lassen.

restic verschlüsselt standardmäßig, dedupliziert über Snapshots hinweg, spricht SFTP, S3, REST und ein Dutzend weiterer Backends und kommt als einzelnes statisches Binary, das Sie auf so ziemlich alles fallen lassen können. Sein Repository-Format ist inhaltsadressiert, sodass ein Snapshot billig ist und identische Daten nur einmal gespeichert werden, egal wie viele Maschinen sie einliefern. Die Kosten sind real, aber moderat: Es braucht Arbeitsspeicher proportional zum Repository-Index, und ein unterbrochener Lauf kann einen veralteten Lock hinterlassen, über den sich der nächste Lauf weigert hinwegzugehen, bis Sie ihn mit restic unlock aufheben. Das ist die Standardempfehlung und das, was die Schritte unten verwenden.

Borg dedupliziert besser, komprimiert besser und ist bei Repositories mit Millionen kleiner Dateien merklich schneller. Der Preis dafür ist Kopplung: Borg muss auf beiden Seiten installiert sein, die Versionen müssen eng zusammenpassen, ein Repository ist wirklich für einen einzigen Client gedacht, und es hat ohne eine Hilfsschicht kein natives Objektspeicher-Backend. Wenn Ihre Quelle ein großer Mail-Spool oder ein Dateisystem voller kleiner Dateien ist und Sie beide Maschinen kontrollieren, wird Borg halb so viel Platz brauchen. Sein --append-only-Modus ist zudem die sauberste Umsetzung dieser Idee in beiden Werkzeugen.

rsync ist kein Backup-Tool, und so zu tun, als wäre es eines, ist der Weg, wie man am Ende eine treu gespiegelte Kopie eines beschädigten Verzeichnisses hat. Es hat keine Versionierung, keine Deduplizierung und keine Verschlüsselung im Ruhezustand; rsync --delete pflanzt Ihren Fehler mit Kabelgeschwindigkeit in die Kopie fort. Trotzdem ist es das richtige Werkzeug, um Bytes zwischen zwei Maschinen zu bewegen, die Sie kontrollieren – genau das ist seine Aufgabe in einem Pull-Design, wobei restic Versionierung und Verschlüsselung übernimmt, sobald die Bytes gelandet sind. Nutzen Sie jedes für das, was es ist.

Eines sollten Sie nicht tun: sich mit tar und einem datumsgestempelten Dateinamen etwas Eigenes zusammenbasteln. Das funktioniert etwa vier Monate lang, bis zu dem Tag, an dem die Platte volläuft, weil nie etwas abgelaufen ist, oder bis zu dem Tag, an dem Sie entdecken, dass eine vollständige Kopie jede Nacht bei einem 40-GB-Datensatz 1,2 TB Speicher im Monat bedeutet, den Sie bezahlen, um dreißig fast identische Dinge vorzuhalten.

Der Instinkt sagt, das gesamte Dateisystem zu sichern. Widerstehen Sie ihm. Ein Root-Dateisystem besteht größtenteils aus Distributionspaketen, die Sie in neunzig Sekunden neu installieren können, und sie einzuschließen kostet Speicher, Übertragungszeit und, schlimmer noch, Aufmerksamkeit – ein 40-GB-Backup, das niemand testen will, ist weniger nützlich als eines mit 900 MB, das vierteljährlich wiederhergestellt wird.

Was sich wirklich nicht rekonstruieren lässt, ist kurz: /etc (Ihre gesamte Konfiguration und der Grund, warum ein Wiederaufbau eine Stunde statt eines Wochenendes dauert), /home und /root, /srv und /var/www, Anwendungszustand unter /var/lib/ und /opt/, benannte Docker-Volumes, Cron- und systemd-Units, die Sie selbst geschrieben haben, und Ihre Datenbank-Dumps. Lassen Sie /proc, /sys, /dev, /run, /tmp, /var/cache, Swap-Dateien, Sockets und /var/lib/docker/overlay2 aus – Letzteres lässt sich aus Ihrer Compose-Datei wieder aufbauen und ist oft das mit Abstand größte Verzeichnis auf der Platte.

Jetzt der Teil, der Wiederherstellungen still und leise ruiniert. Das Datenverzeichnis einer Datenbank zu kopieren, während die Datenbank läuft, erzeugt einen Dateisatz, der mit hoher Wahrscheinlichkeit unbrauchbar ist. Die Engine hält Zustand im Arbeitsspeicher, schreibt über mehrere Dateien hinweg in einer Reihenfolge, die wichtig ist, und Ihre Kopie durchläuft diesen Baum über mehrere Minuten und erwischt dabei verschiedene Dateien zu verschiedenen Zeitpunkten. InnoDB erholt sich davon manchmal per Crash-Recovery und manchmal nicht; der Fehler zeigt sich Monate später, bei einer Wiederherstellung, an einem Tag, der ohnehin schon schlecht läuft.

Dumpen Sie stattdessen über die Engine, und sichern Sie dann den Dump:

# MariaDB / MySQL — InnoDB gets a consistent snapshot from one transaction
mariadb-dump --single-transaction --quick --routines --triggers --events \
  --all-databases | zstd -T0 > /var/backups/db/all-$(date -u +%F).sql.zst

# PostgreSQL — pg_dump is consistent by design; grab roles separately
pg_dumpall --globals-only > /var/backups/db/globals.sql
pg_dump -Fc -Z6 mydb    > /var/backups/db/mydb.dump

# SQLite — never cp a live database; WAL mode makes that a torn file
sqlite3 /var/lib/app/app.db ".backup /var/backups/db/app.db"

Zwei Fußnoten sind es wert, festgehalten zu werden. --single-transaction gibt Ihnen Konsistenz nur für InnoDB – falls eine Tabelle noch MyISAM ist, wird sie außerhalb der Transaktion kopiert und kann inkonsistent zum Rest sein, also konvertieren Sie diese Tabellen oder sperren Sie sie. Und sobald Sie dumpen, schließen Sie das Live-Datenverzeichnis vom Datei-Durchlauf aus. Beides zu sichern bedeutet, neben der guten Kopie eine große zerrissene Kopie zu speichern und einer zukünftigen Wiederherstellung zwei Kandidaten zu geben, von denen einer still und leise falsch ist.

Container ändern nichts am Prinzip, nur am Pfad: Führen Sie den Dump mit docker compose exec -T db mariadb-dump … aus und sichern Sie die resultierende Datei, nicht das darunterliegende Volume.

Client-seitige Verschlüsselung ist der ganze Grund, warum es akzeptabel ist, Ihre Daten auf einer Maschine zu speichern, die nicht diejenige ist, von der sie stammen. restic und Borg verschlüsseln beide, bevor irgendetwas die Quelle verlässt, sodass der Backup-Host nur Chiffretext besitzt und als nicht vertrauenswürdiger Speicher behandelt werden kann. Diese Eigenschaft ist genau so viel wert wie Ihr Umgang mit dem Schlüssel, und keinen Deut mehr.

Das Fehlerbild ist deprimierend häufig. Das Repository-Passwort liegt in /etc/restic/env auf dem Produktivserver, was für die Automatisierung in Ordnung und notwendig ist. Dann verlieren Sie ausgerechnet die Produktion – zerstört, beschlagnahmt oder einfach mit dem Konto verschwunden –, und Sie stehen vor mehreren hundert Gigabyte verschlüsselter Blöcke und der aufdämmernden Erkenntnis, dass die einzige Kopie des Schlüssels in genau dem lag, wovor Sie sich eigentlich schützen wollten.

Also: Das Passwort auf dem Server ist eine Arbeitskopie, niemals das Original. Das Original lebt irgendwo, das den Server überlebt – ein Passwortmanager, dessen Tresor selbst anderswo gesichert wird, oder auf Papier in einer Schublade, oder beides. Notieren Sie den Repository-Standort und den genauen Restore-Befehl direkt daneben, denn eine Passphrase ohne Kontext ist ein Rätsel, das Sie in achtzehn Monaten unter Stress lösen werden. Und nehmen Sie sich fünf Minuten, um sie zu verifizieren: Führen Sie von einer anderen Maschine aus, nur mit dem, was im Passwortmanager steht, restic snapshots gegen das Repository aus. Wenn das funktioniert, haben Sie ein Backup. Wenn es etwas braucht, das nur auf der Produktion existiert, haben Sie einen sehr teuren Ordner.

Beide Werkzeuge unterstützen mehrere Schlüssel auf einem Repository (restic key add), was der saubere Weg ist, dem Prune-Job oder einem zweiten Admin Zugriff zu geben, ohne die ursprüngliche Passphrase zu teilen. Und wenn die Produktivplatte mit LUKS verschlüsselt ist, halten Sie die beiden Geheimnisse wirklich getrennt – die restic-Passphrase im LUKS-Volume zu speichern und die LUKS-Passphrase im restic-Repository ist eine Schleife, die auf beiden Seiten sicher verriegelt scheitert.

Aufbewahrung sieht aus wie eine Frage der Speicherkosten und ist in Wirklichkeit eine Frage der Erkennungslatenz. Die Zahl, die zählt, ist nicht, wie viel Speicherplatz Sie ausgeben wollen; es ist, wie lange ein Problem in Ihrem System unbemerkt bleiben kann. Was auch immer dieser Zeitraum ist, Ihr ältestes Backup muss älter sein als er.

Sieben tägliche Snapshots fühlen sich großzügig an und sind in der Praxis dünn. Eine beschädigte Tabelle, die niemand abfragt, eine langsame Löschung durch einen sich falsch verhaltenden Cron-Job, ein Eindringen, das einen Monat lang still verharrte, bevor es irgendetwas Sichtbares tat – all das braucht routinemäßig länger als eine Woche, um aufzufallen, und wenn Ihre Historie sieben Tage tief ist, dann ist jeder Snapshot, den Sie besitzen, bereits kontaminiert. Die Verweildauer bei echten Einbrüchen wird regelmäßig in Wochen gemessen. Günstige monatliche Snapshots sind genau die Verteidigung dagegen, und Deduplizierung macht sie wirklich sehr günstig: Ein ein Jahr lang aufbewahrter Monats-Snapshot fügt nur einen Bruchteil einer vollen Kopie hinzu, weil nur die Blöcke, die sich tatsächlich geändert haben, ein zweites Mal gespeichert werden.

restic forget \
  --keep-daily 7 --keep-weekly 5 --keep-monthly 12 --keep-yearly 2 \
  --prune

Diese Leiter – eine Woche aus Tagen, ein Monat aus Wochen, ein Jahr aus Monaten, ein paar Jahre aus Jahren – sind etwa sechsundzwanzig Snapshots und, bei typischen Daten, deutlich unter dem Doppelten der Größe einer einzelnen vollen Kopie. Das ist der Standard, für den wir plädieren würden, sofern Sie keinen konkreten Grund haben, davon abzuweichen.

Zwei operative Hinweise. forget ohne --prune entfernt nur die Markierungen, sodass der Platz erst freigegeben wird, wenn Sie prunen – was Leute überrascht, die eine Platte beobachten, die einfach nicht schrumpft. Und --prune erfordert Löschrechte auf dem Repository, läuft also in einem Append-only- oder Pull-Design nicht auf dem Produktivserver. Es läuft auf dem Backup-Host oder von Ihrem Laptop aus, mit einem Schlüssel, den die Produktion nie gesehen hat. Diese Trennung ist der ganze Sinn der Sache; heben Sie sie nicht im letzten Schritt der Bequemlichkeit halber wieder auf.

Die klassische Backup-Katastrophe ist kein Job, der abstürzt. Es ist ein Job, der aufhört zu laufen und es niemandem sagt, entdeckt elf Monate später von jemandem, der ihn gebraucht hätte. Jedes Element unten existiert, um genau dieses Ergebnis unmöglich zu machen.

Verwenden Sie einen systemd-Timer statt Cron. Sie bekommen echte Logs im Journal mit angehängten Exit-Status, Persistent=true, damit ein Lauf, der verpasst wurde, während die Maschine aus war, beim nächsten Boot nachgeholt wird, statt für immer übersprungen zu werden, und RandomizedDelaySec, damit nicht eine ganze Flotte den Backup-Host exakt um 03:00 Uhr überrennt. Crons Fehlerbenachrichtigung ist eine E-Mail an eine lokale Mailbox, die auf einem modernen Server genau nirgendwohin geht.

# /etc/systemd/system/backup.timer
[Unit]
Description=Nightly encrypted backup

[Timer]
OnCalendar=*-*-* 03:17:00
RandomizedDelaySec=1800
Persistent=true

[Install]
WantedBy=timers.target

Fügen Sie dann einen Totmannschalter hinzu, die mit Abstand wertvollste Zeile in dieser ganzen Anleitung. Ganz am Ende des Skripts – nachdem das Backup erfolgreich war, nicht davor – stellen Sie eine HTTPS-Anfrage an einen Monitor, der erwartet, täglich von Ihnen zu hören, und Alarm schlägt, wenn er es nicht tut. Das kehrt die Benachrichtigungslogik um: Statt sich darauf zu verlassen, dass ein Fehlschlag eine Nachricht erzeugt, wird die Abwesenheit selbst zum Alarm. Ein Job, der seit drei Tagen tot ist, wird so zu einer Nachricht in Ihrem Posteingang statt zu einer Entdeckung in einer Krise. Hosten Sie den Monitor selbst auf dem Backup-Host, wenn Sie lieber kein weiteres Drittanbieter-Konto anlegen wollen; es sind ein paar Zeilen und ein eigener Timer.

Schließlich die kleinen operativen Gefahren, in die wir alle mindestens einmal gelaufen sind. Ein unterbrochener Lauf hinterlässt einen Lock, und jeder folgende Lauf schlägt mit einer Meldung fehl, die Sie ab der vierten Nacht nicht mehr lesen – behandeln Sie restic unlock bewusst, nicht reflexartig. Eine volle Zielplatte lässt jeden Job scheitern, bis jemand hinschaut; alarmieren Sie auf freien Speicherplatz, nicht nur auf Job-Status. Ein SSH-Schlüssel mit Ablaufdatum, ein rotierter Host-Key, eine nftables-Regel, die während einer unabhängigen Arbeit hinzugefügt wurde – jedes davon kappt den Pull, still und leise. Und systemctl enable --now, nicht nur start: Ein Timer, der nie aktiviert wurde, funktioniert wunderbar, bis zum ersten Reboot, und läuft danach nie wieder.

Alles oben ist Vorbereitung. Das hier ist der Teil, der daraus ein Backup macht, und es ist der Teil, den fast jeder überspringt.

Einmal im Quartal deployen Sie einen frischen VPS – der 5-$-Starter reicht völlig, und die Abrechnung ist stündlich und sekundengenau anteilig, sodass die ganze Übung ein paar Cent kostet. Stellen Sie darauf nur mit dem wieder her, was Sie bei einer echten Katastrophe hätten: die Repository-Adresse, die Passphrase aus Ihrem Passwortmanager und die schriftliche Anleitung. Verwenden Sie bewusst nichts von der Produktion, denn in dem Szenario, das Sie proben, existiert die Produktion nicht. Bringen Sie die Anwendung hoch, richten Sie einen Hosts-Datei-Eintrag auf die neue IP, klicken Sie sich durch. Zerstören Sie ihn dann.

# on a throwaway machine, with nothing but the passphrase
export RESTIC_REPOSITORY=sftp:[email protected]:/srv/restic/prod
restic snapshots                      # can you even see the history?
restic restore latest --target /restore
restic check --read-data-subset=10%   # verify stored blocks, not just metadata

Was das aufdeckt, ist nie das, was Sie erwarten. Es ist die Konfigurationsdatei, die in einem Verzeichnis lag, das die Include-Liste nicht abdeckte. Der Datenbank-Dump, der seit fünf Wochen null Bytes groß ist, weil sich ein Passwort geändert hat und das Skript den Exit-Status nicht geprüft hat. Die Anwendung, die nicht startet, weil ein Geheimnis in einer Umgebungsvariable liegt, die der Orchestrator hält, und die nie im Dateisystem existiert hat. Der undokumentierte DNS-Eintrag. Das Zertifikat, das neu ausgestellt werden muss, bevor irgendetwas auf 443 antwortet. Jedes davon ist ein Zehn-Minuten-Fix an einem ruhigen Nachmittag und zwei hässliche Stunden um drei Uhr morgens.

Notieren Sie, wie lange die Übung von Anfang bis Ende gedauert hat. Diese Zahl – nicht die Backup-Frequenz – ist Ihre echte Wiederherstellungszeit, und sie ist die einzige ehrliche Antwort, wenn jemand fragt, wie lange Sie ausfallen würden. Fügen Sie außerdem restic check --read-data-subset=5% zu einem monatlichen Timer hinzu: Er liest und verifiziert eine rotierende Stichprobe der tatsächlich gespeicherten Blöcke statt nur des Index, und so finden Sie stille Korruption, solange es noch eine gute Kopie gibt, auf die Sie zurückfallen können. Wenn Sie irgendwann den gesamten Server zu einem neuen Anbieter umziehen, ist eine geprobte Wiederherstellung auch schon der größte Teil der Migration.