Wie Sie einen VPS auf verschlüsseltem Offshore-Storage sichern

Fast niemand richtet Backups am Tag ein, an dem ein Server bereitgestellt wird. Das passiert erst danach — nachdem eine Festplatte während eines Upgrades vollläuft, nachdem im falschen Verzeichnis gelöscht wurde, nachdem eine Migration eine Datenbank hinterlässt, die sauber startet und trotzdem falsch antwortet, nachdem jemand eingedrungen ist. Die Lücke zwischen dem Betrieb einer Maschine, auf die es ankommt, und dem Besitz einer Kopie, die sie überlebt, ist das gefährlichste Zeitfenster im gesamten Self-Hosting, und die meisten leben monatelang darin, ohne es zu bemerken, weil lange nichts schiefgeht — und dann alles auf einmal. Sie zu schließen ist weder schwer noch teuer. Was es schwer wirken lässt, ist, dass das Wort „Backup" für vier verschiedene Dinge benutzt wird, von denen am schlechten Tag nur eines tatsächlich noch da ist.

Die vier Dinge, die kein Backup sind

Jedes einzelne davon ist wirklich nützlich und die Mühe wert. Keines davon ist ein Backup, und das Gegenteil zu glauben ist der mit Abstand häufigste Grund, warum Menschen Daten verlieren, die sie für sicher hielten. Diese Unterscheidung ist keine Spitzfindigkeit — jedes von ihnen versagt genau in der Situation, in der Sie ein Backup am dringendsten brauchen.

• RAID ist Uptime, kein Backup. Ein Array übersteht eine tote Festplatte, ohne offline zu gehen — deshalb laufen unsere Storage-Server auf RAID-6 und verkraften zwei gleichzeitige Ausfälle. Es übersteht keinen gelöschten Ordner, kein missglücktes Upgrade, keinen von fremder Hand verschlüsselten Dateibaum und keine gelöschte Tabelle — jedes dieser Ereignisse wird im selben Moment gewissenhaft auf alle Festplatten geschrieben.
• Snapshots sind Rückgängig, kein Backup. Sie liegen auf demselben Storage wie die Daten, sind meist für root auf derselben Maschine sichtbar, und alles, was das Volume oder den Host zerstört, reißt die Snapshots mit sich. Schnell zurückgerollt, nutzlos, sobald die Box weg ist.
• Sync ist Replikation, kein Backup. Ein Sync-Tool sorgt dafür, dass die Gegenseite der Nahseite entspricht, also wird eine Löschung oder eine Beschädigung so schnell auf die Kopie übertragen, wie das Netzwerk es zulässt. Nextcloud, Dropbox und rclone sync verhalten sich alle so, und zwar absichtlich.
• Versionsverlauf und Papierkorb sind Komfort, kein Backup. Es sind Funktionen der Anwendung, gespeichert in der Datenbank der Anwendung, mit einem in Tagen gemessenen Aufbewahrungsfenster. Ist die Anwendung selbst das, was kaputtgegangen ist, geht ihre eigene Historie gleich mit.
• Eine Kopie auf demselben Server ist keine Offsite-Kopie. Betrifft der Ausfall die Maschine, das Provider-Konto, den Hypervisor oder eine Beschlagnahmung, liegt jede Datei auf dieser Maschine in derselben Ausfalldomäne — ganz gleich, in welchem Verzeichnis sie steckt.

Ein Backup ist eine Kopie, die räumlich getrennt, zeitlich getrennt und in der Kontrolle getrennt ist. Räumlich getrennt, damit ein Brand oder eine Beschlagnahmung nicht beide auf einmal mitnimmt. Zeitlich getrennt, damit Sie zu einem Zeitpunkt vor dem Schaden zurückkönnen statt zu einer originalgetreuen Kopie davon. In der Kontrolle getrennt, damit von der Live-Maschine gestohlene Zugangsdaten sie nicht erreichen. Fehlt eines dieser drei Merkmale, ist es eine Komfortfunktion im Backup-Kostüm.

Die 3-2-1-Regel, und die Version, die 2026 übersteht

Die alte Regel lautet: drei Kopien der Daten, auf zwei verschiedenen Arten von Storage, eine davon offsite. Sie hat sich gut gehalten, weil es im Kern eine Regel über unkorrelierte Ausfälle ist und nicht über Bänder. Seither haben sich zwei Ergänzungen ihren Platz verdient, und beide gibt es wegen Dingen, die zur Zeit der ursprünglichen Regel noch nicht üblich waren.

• Drei Kopien. Die Live-Daten plus zwei weitere. Bei zwei Kopien trennt Sie nur ein einziger Ausfall von einem Single Point of Failure, und Single Points of Failure haben die Angewohnheit, genau dann zu versagen, während Sie noch vorhatten, den ersten Ausfall zu beheben.
• Zwei Arten von Storage. Andere Hardware, andere Software, idealerweise ein anderer Anbieter. Zwei Volumes auf demselben Host teilen sich einen Hypervisor, ein Control Panel und ein Konto — und damit auch jeden Weg, auf dem ein Konto verloren geht.
• Eine offsite. Physisch woanders, auf einer Infrastruktur, die nicht ausfällt, wenn Ihre es tut. Das ist die Kopie, die bei Brand, Diebstahl, Beschlagnahmung und einem ohne Vorwarnung gesperrten Konto zählt.
• Eine unveränderlich oder offline. Ransomware und ein kompromittierter root-Zugriff suchen beide zuerst nach Backups, und ein Ziel, auf das Ihr Server schreiben kann, ist ein Ziel, das Ihr Server auch löschen kann. Append-only-Zugangsdaten oder ein Pull-Design macht daraus eine Unannehmlichkeit statt einer Katastrophe.
• Null ungetestete Wiederherstellungen. Ein Backup, das Sie nie wiederhergestellt haben, ist eine Vermutung. Das ist die Ergänzung, die am häufigsten übersprungen und am bittersten bereut wird, denn ein Backup-Job, der zwei Jahre lang Erfolg gemeldet hat, kann zwei Jahre lang unbrauchbare Archive geschrieben haben.

Was Sie sichern sollten: Zustand, nicht die ganze Maschine

Der erste Instinkt ist, den gesamten Server als Image zu sichern. Meist ist das die falsche Form: Image-Backups sind groß, langsam, unhandlich beim selektiven Wiederherstellen, und das meiste, was sie enthalten, ist ein Standard-Betriebssystem, das sich in einer Minute neu installieren lässt. Was Sie nicht neu erzeugen können, ist der Zustand — die Dinge, die nur existieren, weil Sie sie geschaffen haben.

• Datenbanken, per Dump gesichert statt kopiert. Eine Live-Datenbankdatei, die kopiert wird, während die Engine gerade schreibt, ist eine zerrissene Datei, die sich vielleicht wiederherstellen lässt, vielleicht falsch wiederherstellen lässt — und Ihnen nicht sagt, welches von beidem. Nutzen Sie das eigene Dump-Tool der Engine, stoppen Sie den Dienst, oder ziehen Sie einen Dateisystem-Snapshot und dumpen von dort.
• Anwendungsdatenverzeichnisse. Hochgeladene Dateien, Medien, generierte Assets — der Dateibaum, auf den eine Datenbank verweist. Er muss zum selben Zeitpunkt erfasst werden wie seine Datenbank, sonst stellen Sie einen Index wieder her, der Dateien beschreibt, die es gar nicht gibt.
• Konfiguration und alles, was Sie von Hand bearbeitet haben. Webserver- und Reverse-Proxy-Konfiguration, systemd-Units, Cron-Einträge, Firewall-Regeln, die zwanzig kleinen Korrekturen, die Sie um zwei Uhr morgens vorgenommen haben und an die Sie sich nicht mehr erinnern werden.
• Secrets und Schlüssel, getrennt und mit besonderer Sorgfalt behandelt. TLS-Zertifikate und ihre privaten Schlüssel, SSH-Host-Keys, API-Tokens, und vor allem Wallet-Dateien und Seeds. Diese verdienen eine eigene verschlüsselte Kopie, die nicht nur auf einer gemieteten Maschine liegt.
• Container-Definitionen und Volumes. Die Compose-Dateien und Environment-Dateien, dazu die benannten Volumes — der Teil, den man vergisst, weil sich die Container selbst mühelos neu erzeugen lassen, ihre Volumes aber nicht.
• Die Liste dessen, was installiert ist, nicht die Installation selbst. Ein kurzes Inventar aus Paketen, Versionen und was wo läuft, stellt sich schneller und kompakter wieder her als ein Image des gesamten Root-Dateisystems.

Die Trennlinie ist einfach: Lässt es sich in zehn Minuten aus einem Skript oder einem Paketmanager neu erzeugen, sichern Sie es nicht — schreiben Sie stattdessen auf, wie. Existiert es dagegen nur, weil Sie oder ein Nutzer etwas getan haben, braucht es eine Kopie. Dieses Prinzip skaliert von einer kleinen Website über eine BTCPay-Instanz, bei der Wallet und Datenbank alles sind und der Rest neu installierbar ist, bis zu einem Nextcloud-Server, bei dem Dateibaum und Datenbank gemeinsam erfasst werden müssen, sonst ist keines von beiden viel wert.

Das Ziel dimensionieren, und was es wirklich kostet

Die meisten überschätzen das gewaltig, meist indem sie die erste vollständige Kopie bepreisen und dann mit der Anzahl der Tage multiplizieren, die sie aufbewahren wollen. So arbeitet ein modernes Backup-Tool nicht. Es teilt Daten in Chunks auf, speichert jeden einzigartigen Chunk nur einmal und komprimiert, was sich komprimieren lässt — der zweite Snapshot eines größtenteils unveränderten Servers kostet also fast nichts, und dreißig tägliche Snapshots sind bei Weitem nicht das Dreißigfache des ersten.

• Kalkulieren Sie ungefähr die Größe Ihres Live-Zustands, plus dreißig bis fünfzig Prozent für die Historie — für eine typische Aufbewahrungsrichtlinie auf einem Server, der sich in normalem Tempo verändert.
• Die Aufbewahrungsdauer treibt das Wachstum weit stärker als die Häufigkeit. Stündliche Snapshots, zwei Tage aufbewahrt, sind günstiger als tägliche Snapshots, drei Jahre aufbewahrt. Entscheiden Sie, wie weit Sie realistisch je zurückgehen würden, und richten Sie automatisches Pruning darauf ein.
• Bereits komprimierte Daten komprimieren sich kein zweites Mal. Video, Fotos, Archive und verschlüsselte Blobs landen nahe ihrer ursprünglichen Größe, also braucht ein medienlastiger Server echte Kapazität statt cleverer Einstellungen.
• Datenbanken dedupliziert man zwischen einzelnen Dumps nur schlecht, weil der komprimierte Dump einer leicht veränderten Datenbank ein völlig anderer Bytestrom ist. Dumpen Sie unkomprimiert und überlassen Sie die Komprimierung dem Backup-Tool, dann sinken Ihre Storage-Kosten deutlich.
• Der erste Upload ist der einzige langsame Teil. Danach überträgt ein nächtlicher Lauf nur noch das Delta, bei den meisten Servern Megabyte. Transfer ist hier unmetered, der erste Durchlauf ist also eine Frage der Geduld, nicht des Budgets.

In der Praxis ist das die günstigste Versicherung in Ihrem gesamten Stack. Ein Storage-Server beginnt bei $7.99/mo für 1 TB auf RAID-6 — weit mehr, als der Zustand einer Handvoll VPS-Instanzen belegen wird —, und STO-2 für $12.99/mo verdoppelt das. Bei Medienbibliotheken und langer Aufbewahrung wird Kapazität tatsächlich zur Frage: STO-4 für $22.99/mo gibt Ihnen 4 TB, STO-8 für $39.99/mo gibt Ihnen 8 TB. Das Ziel spricht rsync, SFTP und eine S3-kompatible API, sodass jedes gängige Backup-Tool ohne Plugin damit arbeitet, und Volumes sind im Ruhezustand AES-256-verschlüsselt, mit Unterstützung für eigene Schlüssel — auch wenn Sie, wie der nächste Abschnitt zeigt, ohnehin schon verschlüsseln sollten, bevor die Daten die Quelle verlassen.

Ein Tool wählen, und wofür jedes davon eigentlich gut ist

Hier gibt es nichts, worüber Sie sich den Kopf zerbrechen müssen. Drei Tools decken im Grunde jeden Fall ab, alle sind kostenlos, und der Unterschied zwischen ihnen zählt weniger als der Unterschied zwischen einem davon und keinem. Wählen Sie nach der Form Ihres Problems, nicht nach Benchmark.

• restic — die Standardempfehlung für die meisten Server. Clientseitig verschlüsselt, deduplizierend, eine einzige statische Binary ohne Daemon, und es schreibt nativ nach SFTP, S3-kompatible Endpunkte und einfache Verzeichnisse. Sein Append-only-Modus ist der einfachste Weg zu einem Ziel, das ein kompromittierter Server nicht löschen kann.
• BorgBackup — exzellente Deduplizierung und Komprimierung, sehr effizient über langsame Leitungen, ausgereift und vielfach bewährt. Für entfernte Repositories braucht es einen eigenen Agenten am Ziel — eine kleine Einschränkung im Tausch gegen einen spürbar geringeren Storage-Bedarf.
• rclone — das richtige Tool, wenn es eigentlich darum geht, Daten zwischen Object Stores zu bewegen, oder wenn Sie einen Mirror statt einer versionierten Historie wollen. Kombinieren Sie es mit seinem Crypt-Layer, wenn Sie es direkt einsetzen, und denken Sie daran, dass ein einfacher Sync Löschungen mit überträgt.
• Für Datenbanken immer die nativen Dump-Tools. mysqldump, pg_dump und ihre Äquivalente erzeugen eine konsistente logische Kopie, die die Engine mit Sicherheit wieder einlesen kann. Dumpen Sie in eine Datei, und lassen Sie dann restic oder Borg diese Datei abholen — versuchen Sie nicht, den Dump durch eine clevere Kopie auf Dateiebene zu ersetzen.
• Provider-Snapshots nur als schnelle lokale Schicht. Nutzen Sie sie für schnelle Rollbacks rund um riskante Upgrades, und zählen Sie sie niemals als eine Ihrer drei Kopien.

Schritt für Schritt: ein funktionierendes verschlüsseltes Backup an einem Nachmittag

1. 01Das Ziel bereitstellen und absichernEin Storage-Server in einer anderen Region als die Server, die er schützt. SSH ausschließlich per Schlüssel, ein eigener Nutzer, und keine Wiederverwendung von Zugangsdaten der Maschinen, die später darauf schreiben.
2. 02Die Zustandsliste festlegen, bevor Sie ein Tool anfassenSchreiben Sie jeden Pfad und jede Datenbank auf, die überleben muss. Zehn Minuten mit einer Textdatei jetzt verhindern den Restore, bei dem Sie das eine Verzeichnis entdecken, das niemand aufgelistet hat.
3. 03Ein verschlüsseltes Repository initialisierenErzeugen Sie ein starkes Repository-Passwort, initialisieren Sie das Repository über SFTP oder S3, und bewahren Sie dieses Passwort irgendwo auf, das nicht der gesicherte Server selbst ist. Ein Repository, dessen Schlüssel nur auf der toten Maschine existiert, ist nicht wiederherstellbar.
4. 04Erst Datenbanken dumpen, dann archivierenEin Wrapper-Skript, das jede Datenbank in ein Staging-Verzeichnis dumpt und danach einen einzigen Backup-Durchlauf über die Dumps und den Dateibaum zusammen ausführt. Genau diese Reihenfolge macht Datenbank und Dateien konsistent zueinander.
5. 05Das erste Backup laufen lassen und abwartenDer erste Durchlauf ist der lange. Führen Sie ihn in einem Terminal-Multiplexer aus, damit eine abgebrochene Verbindung ihn nicht tötet, und notieren Sie die Dauer — damit kennen Sie jetzt auch Ihr Restore-Zeitfenster.
6. 06Aufbewahrung festlegen und automatisch prunenEtwa sieben tägliche, vier wöchentliche und sechs monatliche Snapshots passen für die meisten Server. Konfigurieren Sie das Pruning im selben Job, sonst wächst das Repository, bis es eines Tages nicht mehr funktioniert.
7. 07Einplanen, und Fehlschläge laut machenEin nächtlicher Timer oder Cron-Eintrag, dazu ein Alert, wenn der Job keinen Erfolg meldet. Ein stiller Backup-Job ist von gar keinem Backup-Job nicht zu unterscheiden — so viele Monate lang, wie Sie brauchen, es zu bemerken.
8. 08Noch heute etwas wiederherstellen, aus dem Backup, auf einer anderen MaschineKein bloßes Auflisten des Archivs — ein echter Restore einer realen Datei und einer realen Datenbank auf einen Wegwerf-Server. Bis Sie das einmal getan haben, haben Sie ein Backup-Skript, kein Backup.

Dafür sorgen, dass die Kopie übersteht, was den Server getötet hat

Das ist der Teil, der ein Backup von einer bloßen Unannehmlichkeit für einen Angreifer unterscheidet. Hält der Server Zugangsdaten, mit denen sich die Backups löschen lassen, erreicht ein kompromittierter root-Zugriff, ein Ransomware-Lauf oder ein fehlerhaftes Skript beide Kopien in derselben Minute. Die Lösung ist strukturell, keine Frage stärkerer Passwörter.

• Verwenden Sie Append-only-Zugangsdaten von der Quelle aus. restic und Borg unterstützen beide einen Modus, in dem die schreibende Maschine neue Snapshots erzeugen, aber bestehende weder löschen noch prunen kann. Das Pruning läuft dann von woanders aus, nach Zeitplan, mit einem eigenen Schlüssel.
• Bevorzugen Sie, wo möglich, ein Pull-Design. Ein Ziel, das sich die Daten von der Quelle holt, statt dass die Quelle sie schiebt, bedeutet, dass die Quelle überhaupt nie Zugangsdaten zum Archiv besitzt.
• Verwenden Sie SSH-Schlüssel oder Repository-Passwörter nie serverübergreifend. Eine kompromittierte Maschine soll Sie die Backups einer Maschine kosten, nicht den gesamten Bestand.
• Bewahren Sie mindestens eine Kopie in einer anderen Rechtsprechung und einer anderen Ausfalldomäne auf. Verteilung über mehrere Regionen ist keine Paranoia — sie ist der Unterschied zwischen einem Hardware-Vorfall und einem Totalverlust.
• Bewahren Sie den Repository-Schlüssel vollständig außerhalb der Infrastruktur auf. Ein Passwort-Manager, ein Hardware-Token, Papier im Safe. Überall, nur nicht auf den Maschinen, die das Repository schützt.
• Achten Sie auf Backups, die verdächtig schnell anfangen, erfolgreich zu sein. Ein Job, der früher zwanzig Minuten brauchte und jetzt vierzig Sekunden, sichert meist ein leeres oder nicht eingehängtes Verzeichnis — und wird dabei trotzdem weiter Erfolg melden.

Die Wahl der Region ist hier eine echte Entscheidung und kein Detail, denn Ihr Backup und Ihr Produktivserver sollten sich nicht in derselben Aktion beschlagnahmen lassen. Spielt das bei dem, was Sie betreiben, eine Rolle, lohnt sich die bewusste Wahl des Standorts ein paar Minuten, und das Ziel in eine andere Rechtsordnung als die Quelle zu legen, ist genau der Sinn der Übung.

Wiederherstellen: der Teil, den niemand übt

Restores scheitern aus langweiligen Gründen, und sie scheitern im denkbar schlechtesten Moment, weil das für die meisten der einzige Moment ist, in dem sie es überhaupt versuchen. Jeder der folgenden Fehler zeigt sich in Minuten während eines Probelaufs — und in Stunden während eines echten Ausfalls.

• Das Repository-Passwort lag nur auf dem Server, der gestorben ist — die Archive sind intakt und für immer unlesbar.
• Die Datenbank wurde wiederhergestellt, aber der Dateibaum stammte aus einem Lauf drei Stunden später, sodass die Anwendung Datensätze zeigt, deren Dateien nicht existieren.
• Das Backup erfasste ein Verzeichnis, das lautlos aufgehört hatte, eingehängt zu sein — ein Jahr lang wurde jede Nacht gewissenhaft ein leerer Ordner archiviert.
• Niemand kannte die Restore-Reihenfolge — zuerst die Datenbank oder zuerst die Dateien, Dienst gestoppt oder laufend — und der halb wiederhergestellte Zustand musste verworfen und neu begonnen werden.
• Der Restore braucht elf Stunden über die verfügbare Leitung, die niemand vorher gemessen hatte, und der Recovery-Plan war von einer Stunde ausgegangen.
• Dateibesitzer und -rechte kamen falsch zurück, sodass alles vorhanden ist und die Anwendung sich trotzdem weigert zu starten.
• Getestet wurde immer nur der neueste Snapshot, und die Beschädigung, von der gerade wiederhergestellt wird, begann vor sechs Wochen.

Ein Probelauf zweimal im Jahr behebt das alles. Stellen Sie einen Wegwerf-VPS bereit, stellen Sie aus dem echten Repository darauf wieder her, starten Sie den Dienst, sehen Sie sich die Daten an, zerstören Sie die Maschine. Das kostet ein paar Dollar und eine Stunde und macht aus dem gesamten Backup-System eine Tatsache statt einer Annahme. Tun Sie es einmal mit offenem Runbook, und korrigieren Sie das Runbook überall dort, wo es Sie belogen hat.

Die Privatsphäre-Ebene: Ein Backup kann Ihre Anonymität rückgängig machen

Dieser Punkt ist spezifisch fürs Offshore-Betreiben, und er lässt sich nur dann richtig hinbekommen, wenn Sie schon vor dem ersten Upload darüber nachdenken, nicht danach. Ein Backup ist eine vollständige, indizierte, langlebige Kopie Ihrer Infrastruktur, die irgendwo anders liegt — das macht es genauso sensibel wie das Original, und erheblich leichter zu vergessen.

• Dateinamen und Verzeichnisstruktur sind Metadaten, selbst wenn der Inhalt verschlüsselt ist. Die clientseitige Verschlüsselung in restic und Borg deckt auch die Namen ab; ein einfacher rsync-Mirror tut das nicht, und ein Verzeichnis-Listing reicht oft aus, um zu erkennen, was ein Server ist und wer ihn betreibt.
• Das Konto am Ziel gehört zur Geschichte dazu. Ein Backup-Tresor, gemietet mit einer Karte auf Ihren echten Namen, verknüpft diesen Namen mit allem, was der Tresor enthält — ganz gleich, wie sorgfältig die Quellmaschine sauber gehalten wurde.
• Backup-Traffic ist eine dauerhafte, geplante Verbindung mit hohem Volumen zwischen zwei Adressen. Es ist eines der leichter lesbaren Muster, die ein Server erzeugt, und es zeigt jede einzelne Nacht auf das Ziel.
• Alte Snapshots überleben die Entscheidungen, die zu ihnen geführt haben. Etwas, das Sie vor einem Jahr aufgehört haben zu speichern, steckt weiterhin im Archiv, wenn die Aufbewahrung es nie geprunt hat — gut für die Wiederherstellung, schlecht für die Exposition.
• Logs und Shell-History werden mit allem anderen eingesammelt. Das Archiv enthält häufig genau die IP-Adressen, Befehle und Zugangsdaten, bei denen Sie auf der Live-Maschine vorsichtig waren.

Die Lösungen dafür sind gewöhnlich. Nutzen Sie ein Tool, das Namen genauso verschlüsselt wie Inhalte. Mieten Sie das Ziel genauso, wie Sie die Quelle gemietet haben — bei einem Host, der nie gefragt hat, wer Sie sind, finanziert aus einem Krypto-Guthaben, mit einem Monero-Aufladen, wenn Sie auch die Zahlungsspur geschlossen haben wollen. Leiten Sie die Übertragung über einen WireGuard-Tunnel, wenn Sie schon das Muster selbst stört. Und wenden Sie dieselbe Härtung der ersten zehn Minuten auch auf die Storage-Box an, die Sie auf die Produktivmaschine angewendet haben, denn eine Maschine, die eine Kopie von allem hält, ist kein weniger wertvolles Ziel als das Original — sie ist häufig ein wertvolleres.

Fehler, die Menschen ihre Daten kosten

• RAID, Snapshots oder einem Sync-Ordner als Backup vertrauen — und erst an dem Tag erfahren, in welche Kategorie sie tatsächlich gehörten, an dem es zählte.
• Die einzige Kopie auf demselben Server, demselben Konto oder demselben Anbieter aufbewahren wie das, was sie eigentlich schützen soll.
• Eine Live-Datenbankdatei kopieren statt sie zu dumpen — und ein Archiv wiederherstellen, das auf subtile, stille Weise falsch ist.
• Dateibaum und Datenbank zu unterschiedlichen Zeitpunkten sichern, sodass beim Restore keines von beiden zum anderen passt.
• Das Repository-Passwort auf genau der Maschine speichern, die das Repository schützen soll.
• Der Quelle vollständige Löschrechte am Ziel geben, sodass eine einzige Kompromittierung die Archive gleich mitreißt.
• Nie prunen, bis das Ziel vollläuft und der nächtliche Job seit Wochen still vor sich hin scheitert.
• Hunderte Gigabyte öffentlicher Blockchain-Daten sichern, während die Wallet-Datei in keinem einzigen Archiv steckt.
• Alerts für Fehlschläge einrichten, aber nie für Abwesenheit, sodass ein Job, der komplett aufgehört hat zu laufen, gar nichts mehr meldet.
• Nur den neuesten Snapshot testen — und während eines echten Vorfalls feststellen, dass die Beschädigung schon vorher bestand.

Backups sind das uninteressanteste, was Sie an einem Server konfigurieren werden, und das einzige, dessen Fehlen sich nicht wiedergutmachen lässt. Alles andere an einem Server lässt sich aus einem Paketmanager und einem Nachmittag neu aufbauen; der Zustand nicht. Investieren Sie einen Nachmittag: Listen Sie auf, was überleben muss, dumpen Sie die Datenbanken, schicken Sie ein verschlüsseltes Archiv an einen Storage-Server in einem anderen Land, prunen Sie nach Zeitplan, alarmieren Sie bei Stille, und stellen Sie noch vor dem Schließen des Terminals etwas Echtes wieder her. Dann lassen Sie es in Ruhe. Das Maß für ein gutes Backup-System ist, dass Sie vergessen, dass es existiert — bis zu dem einen Morgen, an dem es aus einer Katastrophe eine leicht ärgerliche Stunde macht.