VPS-Backup und -Restore: verschlüsselt, Off-site und tatsächlich getestet

Snapshots sind keine Backups — und Sie wollen beide

Ein Snapshot ist eine Kopie eines Volumes zu einem bestimmten Zeitpunkt, die auf demselben Storage-Fabric liegt wie das Volume, das er kopiert hat. Das ist keine Kritik, sondern eine Beschreibung, und sie erklärt genau, worin ein Snapshot hervorragend ist und was er nicht kann. Jeder Tarif hier enthält stündliche Snapshots mit sieben Tagen Aufbewahrung, das Wiederherstellen eines einzelnen dauert etwa dreißig Sekunden, und sie sind die richtige Antwort auf den mit Abstand häufigsten Vorfall im Serverbetrieb: Sie haben um vier Uhr nachmittags eine Konfigurationsdatei bearbeitet, und der Dienst ist seitdem nicht mehr gestartet. Für dieses Fehlerbild kommt nichts anderes auch nur annähernd heran — es ist schneller als jedes Backup-Werkzeug, es läuft bereits, und es kostet nichts extra.

Was ein Snapshot nicht kann, ist das zu überleben, worauf er gespeichert ist. Er teilt das Schicksal des Volumes, des Hosts, des Hypervisors und, in den meisten Designs, des Kontos. Wird die Maschine beschlagnahmt, wird das Konto geschlossen, hat das Rechenzentrum einen sehr schlechten Tag, gehen die Snapshots mit unter — sie sind eine Kopie der Daten, keine unabhängige. Diese Unterscheidung ist nicht akademisch bei einem Anbieter, der Sie absichtlich nicht identifizieren kann: Es gibt keinen Support-Weg, der Ihren Server aus den Unterlagen eines anderen rekonstruiert, keinen Wiederherstellungsprozess, der an eine Telefonnummer gekoppelt ist, und keine Abrechnungshistorie, die mit Ihrem rechtlichen Namen verknüpft ist. Was Sie gesichert haben, ist alles, was Sie haben.

Auch ein Sieben-Tage-Fenster hilft nicht bei den beiden langsamen Fehlerarten. Die Datei, die Sie vor fünf Wochen gelöscht haben, ist aus jedem Snapshot verschwunden, lange bevor Sie es bemerken. Stille Korruption — eine fehlerhafte Anwendung, die subtil falsche Daten schreibt, eine missglückte Migration, ein Sync-Client, der einen Fehler getreulich weiterverbreitet — wird oft erst einen Monat später entdeckt, und zu diesem Zeitpunkt enthält bereits jede aufbewahrte Kopie die Korruption. Backups mit längerer Aufbewahrung und einer echten Historie decken genau das ab, und sie decken es genau deshalb ab, weil sie keine fortlaufenden Spiegel des aktuellen Zustands sind.

Das Framework, das es hier zu verinnerlichen gilt, ist alt und trotzdem noch richtig. Die 3-2-1-Regel verlangt drei Kopien der Daten, auf zwei unterschiedlichen Arten von Speicher, davon eine Off-site. Der moderne Zusatz fügt zwei weitere Ziffern hinzu — 3-2-1-1-0 —, wobei die zusätzliche Eins eine Kopie ist, die unveränderlich oder offline ist, und die Null die Anzahl der Fehler bei Ihrer letzten Verifizierung. Die Ziffern sind eher eine Merkhilfe als ein Standard, aber sie kodieren die drei Eigenschaften, die wirklich zählen: Unabhängigkeit, Unveränderlichkeit und der Nachweis, dass die Sache funktioniert. Stündliche Snapshots liefern Ihnen eine der drei.

Lesen Sie diese Tabelle als Argument dafür, beide zu betreiben, statt sich zwischen ihnen zu entscheiden. Snapshots übernehmen Häufigkeit und Geschwindigkeit; Backups übernehmen Unabhängigkeit und Historie. Sie kosten unterschiedliche Dinge, sie versagen auf unterschiedliche, sich nicht überschneidende Weisen, und die Kombination ist weit stärker als jedes der beiden doppelt genommen.

Die zwei Zahlen, die alles andere bestimmen

Bevor irgendein Werkzeug installiert wird, schreiben Sie zwei Kennzahlen auf. Das Recovery Point Objective (RPO) gibt an, wie viele Daten Sie sich zu verlieren leisten können, gemessen in Zeit — wenn die letzte brauchbare Kopie sechs Stunden alt ist, beträgt Ihr RPO sechs Stunden, und die sechs Stunden Arbeit dazwischen sind verloren. Das Recovery Time Objective (RTO) gibt an, wie lange Sie nicht verfügbar sein können, während Sie wiederaufbauen. Alles Weitere — Zeitplan, Methode, wo die zweite Kopie liegt, wie viel Sie ausgeben — ergibt sich aus diesen beiden Zahlen, und wer zuerst die Software auswählt, landet bei einer aufwendigen Antwort auf eine Frage, die niemand gestellt hat.

Beiläufig gefragt, sagen die meisten Menschen null und null. Das ist kein Budget, das ist ein Wunsch, und er hat einen Preis, den man deutlich benennen sollte: Ein RPO nahe null bedeutet kontinuierliche Replikation statt geplanter Kopien, und ein RTO nahe null bedeutet eine bereits laufende warme zweite Maschine. Beides ist umsetzbar, und beides verdoppelt ungefähr die Betriebskosten dessen, was Sie schützen. Für die überwältigende Mehrheit selbst gehosteter Workloads liegen die ehrlichen Antworten irgendwo zwischen einer Stunde und einem Tag für den Recovery Point und bei ein paar Stunden für die Recovery Time, was von einem geplanten verschlüsselten Backup und einem dokumentierten Wiederaufbau bequem bedient wird.

Die Zahlen unterscheiden sich außerdem je Datensatz auf derselben Maschine, und genau dieses Detail macht sie nützlich. Mail ist das schärfste Beispiel: Eine Nachricht, die vor zwanzig Minuten angekommen ist, existiert nirgendwo sonst, kann nicht neu erzeugt werden, und ihr Absender hat keine Ahnung, dass sie erneut gesendet werden muss — ein Mailserver will daher einen in Minuten gemessenen Recovery Point, obwohl sich die Software selbst an einem Nachmittag neu installieren lässt. Ein Bitcoin-Node kehrt das vollständig um: Die Chain-Daten sind mehrere hundert Gigabyte, die Ihnen jeder Peer im Netzwerk bereitwillig erneut sendet, sodass ihre Sicherung größtenteils Speicherplatzverschwendung ist, während die Wallet-Datei daneben nicht wiederherstellbar und wie ein privater Schlüssel schützenswert ist — weil sie genau das ist.

Diese letzte Zeile verdient es, laut ausgesprochen zu werden, denn ein Guide über Backups hat einen offensichtlichen Anreiz, das nicht zu tun. Manche Maschinen brauchen gar keins. Ein Build-Agent, dessen gesamter Zustand aus einem git-Repository stammt, eine Wegwerf-Sandbox, ein zustandsloser Reverse-Proxy, dessen Konfiguration in der Versionskontrolle liegt — für diese sind die im Tarif enthaltenen stündlichen Snapshots eine vollständige und vertretbare Antwort, und die richtige Menge an Backup-Engineering ist keine. Zu wissen, welche Ihrer Server in diese Kategorie fallen, ist mehr wert, als sie alle schlecht zu sichern.

Was Sie kopieren sollten — und der viel größere Haufen, den Sie auslassen sollten

Der Instinkt ist, ein Image der gesamten Festplatte zu ziehen, und auf einer gemieteten virtuellen Maschine ist dieser Instinkt falsch. Das Betriebssystem ist verzichtbar: Eine frische Instanz wird hier im Median in einundvierzig Sekunden bereitgestellt, und Pakete von einem Distributions-Mirror neu zu installieren ist schneller und zuverlässiger, als sie aus einer eigenen Kopie wiederherzustellen. Was nicht verzichtbar ist, ist eine überraschend kleine Menge, und die Disziplin, diese Menge explizit zu benennen, ist der Großteil der Arbeit — ein Backup, das Sie in einem Absatz beschreiben können, ist eines, das Sie überprüfen können, während ein Image der gesamten Platte etwas ist, worauf Sie nur hoffen.

Die unersetzliche Menge besteht meist aus vier Dingen. Erstens Anwendungsdaten: das Maildir, das Datenverzeichnis, der Media Store, der Uploads-Ordner. Zweitens Datenbanken, die eine eigene Behandlung brauchen und den nächsten Abschnitt bekommen. Drittens Secrets — und das ist die Kategorie, die Sie vergessen, bis es teuer wird. Private TLS-Schlüssel und der ACME-Kontoschlüssel, SSH-Host-Schlüssel, falls Sie den Fingerprint nicht auf jedem Client neu vertrauen wollen, der DKIM-Signaturschlüssel, ohne den Ihre Mail die Authentifizierung nicht mehr besteht, private WireGuard-Schlüssel, und vor allem der private Schlüssel des Onion-Service, der die .onion-Adresse ist: Verlieren Sie ihn, ist die Adresse dauerhaft weg, ohne irgendein Register, an das Sie sich wenden könnten. Viertens die Handvoll Dateien unter /etc, die Sie tatsächlich geändert haben, plus die systemd-Units, Cron-Einträge und das Firewall-Regelwerk, die die Maschine so verhalten lassen, wie sie es tut.

Der Haufen, den Sie auslassen sollten, ist viel größer und meist offensichtlich, sobald er ausgesprochen wird. Pseudo-Dateisysteme wie /proc, /sys und /dev sind Kernel-Ansichten und keine Daten. Paket-Caches, Container-Images, virtuelle Umgebungen und Dependency-Verzeichnisse lassen sich alle in Sekunden aus einer Lockfile neu ableiten. Logs jenseits Ihrer Aufbewahrungsrichtlinie sind Rauschen, das schlecht dedupliziert und jeden nachfolgenden Lauf aufbläht. Und große, erneut synchronisierbare Datensätze — Blockchain-Zustand, ein öffentlicher Mirror, eine Medienbibliothek, die Sie erneut rippen können — verdienen eine bewusste Entscheidung statt einer Standardeinstellung: Dreihundert Gigabyte Chain-Daten zu sichern kostet jeden Monat echtes Geld, um einen Re-Sync zu vermeiden, den Sie kostenlos durchführen könnten, während der Dienst beeinträchtigt, aber funktionsfähig ist.

Der Teil, in den fast jeder zu wenig investiert, ist die Antwort auf die Frage „Wohin wiederherstellen?“. Daten ohne Ziel sind keine Wiederherstellung. Wenn die Art, wie Ihr Server aufgebaut wurde, nur in Ihrer Erinnerung existiert und in einer Shell-History, die Sie inzwischen verloren haben, ist Ihre Wiederherstellungszeit unbegrenzt, egal wie gut das Repository ist. Die Lösung ist billig und unspektakulär: Bewahren Sie die Provisioning-Schritte als Skript oder als Klartext-Runbook auf, legen Sie es innerhalb des Backup-Repositorys ab, sodass es zusammen mit den Daten wiederhergestellt wird, und aktualisieren Sie es, wann immer Sie die Maschine ändern. Schon hundert Zeilen Notizen — Pakete, Versionen, Speicherorte von Konfigurationsdateien, DNS-Einträge, die Reihenfolge, in der Dienste starten müssen — verwandeln eine schlechte Woche in einen schlechten Nachmittag.

Eine Nuance ist für alle wichtig, die Festplattenverschlüsselung einsetzen: Der LUKS-Header und seine Schlüssel-Slots gehören ebenfalls zu Ihrer unersetzlichen Menge. Ein beschädigter Header macht aus einer völlig intakten Platte reines Rauschen, der Header ist wenige Megabyte groß, und ihn zu sichern kostet nichts. Bewahren Sie ihn genauso sorgfältig auf wie die Passphrase — wer beides in der Hand hält, hält die Platte.

Datenbanken: Die Datei, die Sie kopieren, ist nicht die Datenbank

Das ist mit Abstand die häufigste Art, wie ein ansonsten kompetentes Backup sich als wertlos herausstellt. Eine Datenbank-Engine hält ihren Zustand im Arbeitsspeicher, in einem Write-Ahead- oder Redo-Log und in Datendateien, die fortlaufend verändert werden. Diese Dateien zu kopieren, während die Engine läuft, erfasst sie zu unterschiedlichen Zeitpunkten — Seite vier einer Tabelle von vor einer Transaktion, Seite fünf von danach —, und das Ergebnis ist eine Menge von Dateien, die einzeln intakt und zusammen inkonsistent sind. Das Grausame daran ist, dass sich eine solche Kopie meistens wiederherstellen lässt. Sie startet, sie beantwortet Abfragen, und der Schaden zeigt sich erst Wochen später als beschädigter Index oder als Zeile, die gegen einen Constraint verstößt, den die Engine hoch und heilig durchzusetzen behauptet. Ein Backup, das laut scheitert, ist weit besser als eines, das still scheitert.

Der richtige Ansatz hängt von der Engine ab und ist in jedem Fall gut dokumentiert. Für MariaDB und MySQL ist ein logischer Dump innerhalb einer einzigen konsistenten Transaktion richtig für alles bis zu einigen Dutzend Gigabyte; danach übernimmt Mariabackup eine physische Hot-Copy, während der Server läuft. Für PostgreSQL liefert pg_dump einen portablen logischen Snapshot, und pg_basebackup kombiniert mit archivierten Write-Ahead-Logs liefert Ihnen Point-in-Time-Recovery — die Fähigkeit, auf 14:32 Uhr wiederherzustellen statt auf den Zeitpunkt, zu dem zufällig der letzte Dump lief. Für SQLite verwenden Sie das eingebaute Online-Backup oder VACUUM INTO; cp auf einer laufenden Datenbankdatei ist genau der oben beschriebene Fehler, und SQLite ist die Engine, bei der er am häufigsten passiert, weil sie wie eine gewöhnliche Datei aussieht.

Konsistenz zwischen der Datenbank und den Dateien, die sie beschreibt, ist die zweite Hälfte des Problems, und es ist die Hälfte, die speziell Dateisync- und Forensoftware beißt. Die Datenbank sagt, dass unter einem Pfad eine Datei existiert; das Dateisystem ist der Ort, an dem die Bytes liegen; wenn Sie die Datenbank um 02:00 Uhr dumpen und das Datenverzeichnis um 02:40 Uhr kopieren, existiert alles, was dazwischen entstanden ist, entweder als Bytes ohne Zeile oder als Zeile ohne Bytes. Anwendungen, die einen Wartungsmodus anbieten — Nextcloud ist das naheliegendste Beispiel —, lösen das, indem sie kurz Schreibzugriffe verweigern, während beides erfasst wird. Wo das nicht akzeptabel ist, liefert ein in einem einzigen Moment aufgenommener Dateisystem- oder Volume-Snapshot ein konsistentes Paar, von dem Sie in Ruhe kopieren können — derselbe Trick, den auch die stündlichen Snapshots verwenden.

Ein kleines betriebliches Detail zahlt sich sofort aus: Schreiben Sie Dumps unkomprimiert und überlassen Sie die Kompression dem Backup-Werkzeug. Sowohl restic als auch borg deduplizieren mittels inhaltsdefiniertem Chunking, sodass sich zwei Dumps, die einen Tag auseinanderliegen, den überwältigenden Großteil ihrer Chunks teilen und der zweite fast nichts zusätzlich kostet, um gespeichert zu werden. Komprimieren Sie den Dump zuerst, kaskadiert ein einziges geändertes Byte nahe dem Anfang durch den gesamten komprimierten Stream, kein Chunk passt mehr zu irgendetwas, und jeder Lauf speichert eine vollständige Kopie. Teams stellen aus genau diesem Grund regelmäßig fest, dass ihr Repository täglich um die volle Größe der Datenbank wächst — die Lösung besteht darin, eine einzige Pipe aus einem Shell-Skript zu entfernen.

Entscheiden Sie schließlich bewusst, ob Sie Point-in-Time-Recovery brauchen, denn sie ist die Antwort auf einen Fehler, den der tägliche Dump nicht abdecken kann. Wenn jemand um 14:32 Uhr eine destruktive Query ausführt und Sie es um 17:00 Uhr entdecken, verlieren Sie mit der Wiederherstellung des gestrigen Dumps einen Arbeitstag. Kontinuierliche Archivierung spielt das Log stattdessen bis 14:31 Uhr erneut ein. Es kostet mehr Speicherplatz und deutlich mehr operative Komplexität, deshalb ist es kein Standard — aber überall dort, wo ein Mensch mit Schreibzugriff Daten schneller zerstören kann, als Sie es bemerken, ist es der Unterschied zwischen einem Vorfall und einer Katastrophe.

Verschlüsseln, bevor es den Server verlässt: restic, borg und der Schlüssel, den Sie nicht verlieren dürfen

Die Eigenschaft, die alles andere in diesem Guide erst möglich macht, ist clientseitige Verschlüsselung: Die Daten werden auf der Maschine verschlüsselt, die sie erzeugt hat, bevor auch nur ein einziges Byte das Netzwerk überquert, mit einem Schlüssel, den das Ziel nie zu sehen bekommt. Genau diese eine Design-Entscheidung macht aus dem Backup-Ziel einen nicht vertrauenswürdigen Speicher, und ein nicht vertrauenswürdiger Speicher kann überall liegen — ein billiger Server in einem anderen Land, ein Objektspeicher, das NAS eines Freundes —, ohne dass einer von ihnen in der Lage wäre, Ihre Daten zu lesen. Anbieter, die serverseitig verschlüsseln, schützen Sie vor einer anderen und deutlich engeren Gruppe von Bedrohungen, und dieser Unterschied zählt am meisten genau in den Situationen, für die Sie Offshore-Hosting kaufen, um sie zu überstehen.

Restic und Borg machen das beide korrekt, und die Wahl zwischen ihnen ist wirklich knapp. Restic ist ein einzelnes statisches Binary ohne Abhängigkeiten, spricht nativ eine lange Liste von Backends — SFTP, S3-kompatibler Objektspeicher, einfache lokale Pfade — und lässt sich von den beiden leichter aus einem Container oder einem minimalen Image heraus betreiben. Borg ist das ältere und in mancher Hinsicht chirurgischere Werkzeug, mit stärkeren Komprimierungsoptionen, exzellenter Append-only-Unterstützung auf der Serverseite und einem Repository-Format, das viele Leute leichter nachvollziehbar finden; es verlangt, dass borg auf beiden Seiten installiert ist, wenn es über SSH läuft, was eine kleine Einschränkung ist, die gelegentlich den Ausschlag gibt.

Für welches Sie sich auch entscheiden, die Passphrase ist jetzt das, worauf alles ankommt, und sie verdient es, so behandelt zu werden, wie Sie einen Wallet-Seed behandeln würden. Sie darf nicht ausschließlich auf der Maschine liegen, die sie schützt — eine Passphrase, die neben den Daten aufbewahrt wird, die sie verschlüsselt, schützt Sie vor genau gar nichts, denn jedes Szenario, das den Server nimmt, nimmt auch den Schlüssel mit. Bewahren Sie sie in einem Passwort-Manager auf einem anderen Gerät auf, oder auf Papier in einem anderen Gebäude, und idealerweise beides. Borg erlaubt es, den Repository-Schlüssel in eine separate Datei zu exportieren, restic erlaubt es einem Repository, mehrere unabhängige Schlüssel zu tragen, und beide Mechanismen geben Ihnen einen zweiten Weg hinein, der nicht davon abhängt, sich eine Zeichenkette zu merken. Es gibt keine Wiederherstellung, keinen Reset-Link und kein Support-Ticket, das das rückgängig macht: ein verschlüsseltes Repository ohne seinen Schlüssel ist von Zufallsdaten nicht zu unterscheiden, was genau der Sinn der Sache ist.

Es lohnt sich, deutlich zu machen, warum einfaches rsync auf einen anderen Server kein Ersatz ist, da es das Erste ist, wonach die Leute greifen. Rsync erzeugt einen Spiegel, und ein Spiegel hat keine Historie: Löschen Sie heute eine Datei, löscht der Lauf von heute Nacht sie dort ebenso brav mit. Es gibt keine Deduplizierung, sodass die Aufbewahrung von dreißig Tagen dreißig Kopien bedeutet, es sei denn, man behilft sich geschickt mit Hardlinks. Es gibt keine eingebaute Verschlüsselung im Ruhezustand, sodass das Ziel alles lesen kann. Und es gibt keine Verifizierung über das erneute Einlesen der Quelle hinaus. Es ist ein exzellenter Transport und ein schlechtes Backup, und der Unterschied zeigt sich an dem Tag, an dem Sie die Version von vor drei Wochen brauchen.

Append-only, oder es ist eine Kopie statt eines Backups

Hier ist das Szenario, das die Architektur bestimmt. Jemand erlangt Root auf Ihrem Server — über eine ungepatchte Anwendung, einen geleakten Token, eine Abhängigkeit, die feindlich geworden ist. Diese Person befindet sich nun in einer Maschine, die gültige Zugangsdaten zu ihrem eigenen Backup-Ziel besitzt, denn genau so funktionieren geplante Backups. Alles, was diese Maschine löschen kann, kann auch der Angreifer löschen, und das Löschen der Backups ist bei einem modernen Einbruch kein nachträglicher Gedanke, sondern der erste Schritt. Dasselbe gilt auch ohne Angreifer: Ein gut gemeintes Skript mit einer verirrten Variablen, als Root ausgeführt, ist ohne Weiteres in der Lage, ein Repository bis auf nichts herunterzustutzen.

Die Kontrolle, die das schließt, ist die Append-only-Erzwingung auf der empfangenden Seite. So konfiguriert, kann der Client neue Snapshots erstellen, aber alte weder entfernen noch überschreiben — die Einschränkung wird durch den Prozess auf dem Backup-Host erzwungen, nicht durch den guten Willen des Clients. Borg setzt das mit borg serve --append-only um, festgepinnt an den Schlüssel in der authorized_keys des Ziels, sodass der Client um nichts anderes bitten kann. Restic erreicht dasselbe über rest-server mit --append-only. Bei Objektspeicher ist das Äquivalent Versionierung plus eine Object-Lock-Aufbewahrungsrichtlinie, die dasselbe Ergebnis über einen anderen Mechanismus erreicht.

Die SSH-Konfiguration, die das trägt, ist es wert, exakt richtig gemacht zu werden, denn sie ist die tragende Zeile. Stellen Sie in der authorized_keys des Backup-Benutzers dem Schlüssel des Clients einen forcierten Befehl sowie die Einschränkungen voran, die das sshd-Handbuch dokumentiert: command="borg serve --append-only --restrict-to-path /srv/backups/web01",restrict. Diese einzige Zeile bedeutet, dass ein vom Client gestohlener Schlüssel keine Shell öffnen, keinen Port weiterleiten, das Repository eines anderen Hosts nicht berühren und nichts löschen kann. Geben Sie jedem Client seinen eigenen Schlüssel und seinen eigenen Pfad.

Das wirft die naheliegende Frage auf: Wenn der Client niemals löschen kann, was entfernt dann alte Snapshots? Das Pruning geschieht anderswo, nach einem Zeitplan, mit einer Zugangsberechtigung, die die geschützte Maschine nie besessen hat. In der Praxis bedeutet das, dass der Backup-Host seine eigenen Repositories über einen lokalen Cron-Job bereinigt, oder dass eine dritte, kleine Maschine den privilegierten Schlüssel hält und die Aufbewahrung wöchentlich durchführt. Borg hat hier eine bekannte Eigenheit — ein Append-only-Repository muss seine Kompaktierung auf der Serverseite laufen lassen statt durch den Client —, und den Backup-Host als Eigentümer der Aufbewahrung zu behandeln, löst das sauber. Das Prinzip lässt sich verallgemeinern: Die Maschine, die Backups schreibt, sollte niemals die Maschine sein, die sie zerstören kann.

Die Aufbewahrung selbst ist eine Richtlinienfrage mit einer konventionellen Antwort, die funktioniert: die letzten mehreren Tages-Snapshots behalten, vier oder fünf Wochen-Snapshots und sechs bis zwölf Monats-Snapshots. Beide Werkzeuge drücken das deklarativ aus, sodass Sie die gewünschte Form angeben und das Werkzeug entscheiden lassen, welche Snapshots sie erfüllen. Die Monats-Snapshots sind es, die langsame Korruption abfangen, und sie sind auch die, die Leute als Erstes streichen, wenn das Repository wächst — was genau falsch herum ist, da ein komprimierter, deduplizierter Monats-Snapshot eines Datensatzes, der sich kaum ändert, fast nichts kostet.

Wohin die zweite Kopie geht, wenn niemand Sie identifizieren kann

Off-site leistet in der 3-2-1-Regel eine Menge Arbeit, und bei einem No-KYC-Anbieter bedeutet das etwas Spezifischeres als „ein anderes Gebäude". Es bedeutet eine Kopie, deren Fortbestehen nicht von derselben Firma, demselben Konto, derselben Zahlungsbeziehung oder derselben Rechtsordnung abhängt wie das Original. Zwei Server in einem Konto sind zwei Server mit einem einzigen Schicksal, wie weit die Rechenzentren auch voneinander entfernt liegen: Ein aus irgendeinem Grund geschlossenes Konto nimmt beide mit, und ein einer Entität zugestelltes Rechtsinstrument erreicht alles, was diese Entität besitzt. Unabhängigkeit ist eine Eigenschaft der Beziehung, nicht nur der Geografie.

Die praktische Version davon ist einfacher, als es klingt, denn dasselbe Panel bietet bereits vier Rechtsordnungen an. Eine Produktionsinstanz in den Niederlanden, deren Repository auf einen Starter-Tarif in Island gepusht wird, kostet $8.50 im Monat und bringt Ihre Wiederherstellung außerhalb der Reichweite jedes einzelnen nationalen Verfahrens — und weil sich die Rechtsordnungen darin unterscheiden, was sie tatsächlich abwehren, ist die Paarung einen Moment des Nachdenkens wert und keinen Münzwurf. Da das Repository verschlüsselt wird, bevor es die Quelle verlässt, ist der Backup-Host konstruktionsbedingt nicht vertrauenswürdig: Was Sie mit dem zweiten Standort kaufen, sind Verfügbarkeit und rechtliche Distanz, nicht Vertraulichkeit. Vertraulichkeit haben Sie bereits.

Für eine wirklich unabhängige dritte Kopie kehrt die stärkste Architektur die Richtung der Verbindung um. Statt dass der Server zu einem Ziel pusht, für das er Zugangsdaten besitzt, zieht eine Maschine, die Sie kontrollieren — eine Box zu Hause, ein NAS, ein Laptop, der nach Zeitplan aufwacht — die Daten vom Server. Die Produktionsmaschine besitzt dann keinerlei Zugangsdaten zu irgendeinem Backup-Ziel, was das Kompromittierungsszenario aus dem vorigen Abschnitt strukturell unmöglich macht statt es nur abzumildern. Es kostet Sie eine Maschine, die nach Zeitplan erreichbar oder wach sein muss, weshalb sie eine gepushte Off-site-Kopie ergänzt, statt sie zu ersetzen.

Zwei Einschränkungen, die speziell für diese Art von Hosting gelten, sind es wert, ohne Verzierung ausgesprochen zu werden. Es gibt keine Kontowiederherstellung: kein Ausweisdokument zum Vorzeigen, keine Telefonnummer, um einen Code zu empfangen, kein Vertreter, der bestätigen kann, dass Sie Sie sind. Das ist genau die Eigenschaft, für die Sie bei der Anmeldung bezahlen, und sie gilt symmetrisch — was die Passphrase und das Runbook auf eine Weise tragend macht, wie sie es bei einem Mainstream-Anbieter einfach nicht sind. Und wenn das Backup-Ziel bezahlt werden muss, muss es auch anonym bezahlt werden, sonst führt die zweite Kopie stillschweigend genau die Identitätsverknüpfung wieder ein, die die erste vermeiden sollte. Beide Maschinen aus derselben Krypto-Wallet zu bezahlen ist unproblematisch; das Backup mit einer Karte zu bezahlen ist eine Entscheidung, kein Versehen.

Die Übung, und wie Sie herausfinden, dass sie aufgehört hat zu funktionieren

Backup-Jobs scheitern normalerweise nicht dramatisch. Sie scheitern graduell: ein Exclude-Muster, das bei einer Aufräumaktion zu weit gefasst wurde, eine Zugangsberechtigung, die nur auf einer Seite rotiert wurde, eine Festplatte, die sich auf dem Ziel füllt, ein Cron-Eintrag, der bei einem Distributions-Upgrade verlorenging. In jedem dieser Fälle läuft die Maschine weiter, nichts schlägt Alarm, und das Repository hört still auf zu wachsen. Das Design, das das abfängt, lautet nicht „Alarm bei Fehlschlag" — ein Job, der nicht mehr läuft, kann seinen eigenen Fehlschlag nicht melden —, sondern Alarm beim Ausbleiben des Erfolgs. Lassen Sie jeden erfolgreichen Lauf einen Dead-Man's-Switch-Endpunkt anpingen, und lassen Sie diesen Endpunkt Alarm schlagen, wenn der Ping nicht rechtzeitig ankommt. Das ist zehn Minuten Einrichtungsaufwand, und es ist der Unterschied zwischen einem Bemerken innerhalb eines Tages und einem Bemerken erst während einer Wiederherstellung.

Die Integritätsprüfung ist die zweite Hälfte. Beide Werkzeuge können verifizieren, dass die Metadaten des Repositorys kohärent sind, und nützlicherweise auch, dass die gespeicherten Chunks sich tatsächlich entschlüsseln lassen und zu ihren Hashes passen. Alles zu lesen ist teuer an Bandbreite, daher bieten beide eine partielle Form an — restic prüft pro Lauf einen Prozentsatz der Daten, borg verifiziert Daten auf Anfrage —, und ein sinnvoller Rhythmus ist eine vollständige Metadatenprüfung wöchentlich und eine partielle Datenprüfung monatlich, so bemessen, dass ein vollständiger Durchlauf über ein Quartal hinweg stattfindet. Speicher verrottet tatsächlich, und der Sinn der Prüfung ist, das zu erfahren, solange Sie noch eine weitere Kopie haben.

Nichts davon ist ein Beweis dafür, dass Sie wiederherstellen können. Für diesen Beweis gibt es genau eine Quelle, nämlich das tatsächliche Wiederherstellen. Setzen Sie eine frische Instanz auf — der kleinste Tarif kostet $8.50, und Sie werden sie innerhalb der Stunde wieder zerstören —, stellen Sie das Repository darauf wieder her, und tun Sie dann den Teil, den die Leute überspringen: die Anwendung starten und sich echte Daten ansehen. Loggen Sie sich ein. Öffnen Sie ein Dokument vom letzten Monat. Senden Sie eine Testnachricht über den Mailserver. Fragen Sie eine Tabelle ab, die die Zeilen von gestern enthalten sollte. Dass die Dateien existieren, ist nicht der Test; dass der Dienst darauf funktioniert, ist es. Tun Sie das beim ersten Einrichten des Backups, und danach in einem Kalenderintervall, das Sie tatsächlich einhalten, denn die Übung validiert auch das Runbook, und das Runbook verfällt schneller als die Daten.

Das Runbook verdient einen eigenen Absatz, denn es ist der billigste Posten hier und der am häufigsten fehlende. Schreiben Sie der Reihe nach auf: wo das Repository liegt und wie man es erreicht, wo die Passphrase aufbewahrt wird, wie man eine Ersatzmaschine provisioniert, welche Pakete und Versionen zu installieren sind, was in welcher Reihenfolge wiederherzustellen ist, welche DNS-Einträge zu ändern sind, und wie man bestätigt, dass es funktioniert hat. Bewahren Sie es außerhalb der Maschine auf, die es beschreibt — im Repository selbst, in einem Passwort-Manager, auf Papier — und gehen Sie davon aus, dass die Person, die es liest, müde ist, zu einer unangenehmen Stunde arbeitet und möglicherweise nicht Sie selbst ist. Diese letzte Annahme ist es, die aus einer Ansammlung von Notizen etwas macht, das ein Kollege oder ein Familienmitglied ausführen kann.

Zusammengesetzt ist das gesamte Design unspektakulär, und genau das ist seine Stärke: die stündlichen Snapshots, die Ihr Tarif bereits für die Unfälle der letzten paar Tage enthält, ein verschlüsseltes Repository, das nachts in eine zweite Rechtsordnung gepusht wird, wo es nicht gelöscht werden kann, eine Passphrase irgendwo, wo der Server sie nie zu Gesicht bekommen hat, ein Ping, der sich beschwert, wenn der Job verstummt, und eine Probe im Kalender. Nichts auf dieser Liste ist schwierig, das meiste davon ist ein Nachmittag, und das Ganze kostet pro Monat weniger als der Kaffee, den Sie kaufen würden, während Sie von null aufbauen. Wenn Sie das jetzt einrichten, dauert die Bereitstellung der zweiten Maschine etwa eine Minute — beginnen Sie mit der Wiederherstellung, die Sie noch nie getestet haben, denn sie ist der einzige Teil davon, der Ihnen die Wahrheit sagt.