Jedes Backup funktioniert – bis zu dem Tag, an dem es gebraucht wird. Der Snapshot liegt auf der Plattform, die gerade ausgefallen ist. Das nächtliche Tarball-Backup schlägt schon seit März still fehl, seit eine Festplatte volllief. Der Datenbank-Dump war eine Dateikopie, die mitten im Schreibvorgang entstand, und lässt sich zu nichts wiederherstellen. Backups sind der eine Teil eines Servers, den Sie nicht durch Ansehen beurteilen können — nur durch Wiederherstellen. So bauen Sie eines, das einen Hardwareausfall, Ihre eigenen Hände und jemanden, der Ihre Zugangsdaten in der Hand hält, übersteht, ohne eine lesbare Kopie der Maschine an denjenigen zu übergeben, der sie speichert.
Vier Dinge zerstören einen Server, und jedes braucht etwas anderes
Bauen Sie das Backup um den Ausfall herum, nicht um das Werkzeug. Vier Szenarien decken im Grunde jeden realen Verlust ab, und jedes verlangt etwas anderes von der Kopie, die Sie aufbewahren. Ein Setup, das eines davon abdeckt, wirkt völlig ausreichend — bis es auf ein anderes trifft.
Hardware- oder Host-Ausfall
Die Festplatte, der Node oder das Rechenzentrum fällt aus. Jede Kopie, die irgendwo anders liegt, rettet Sie. Das ist der einzige Ausfall, den ein Snapshot auf derselben Plattform zuverlässig abdeckt — genau deshalb glauben so viele, Snapshots seien genug.
Ihre eigenen Hände
Ein falsches Flag, ein Migrationsskript, das auf Produktion zielte, ein Aufräumen, das mehr entfernt hat als beabsichtigt. Der Schaden repliziert sich sofort auf alles, was spiegelt — was Sie rettet, ist also Historie: eine Version von vor dem Fehler, nicht eine aktuelle Kopie von danach.
Kompromittierung und Ransomware
Ein Angreifer mit Root-Rechten hat genau die Reichweite, die auch Ihr Backup-Job hat: dieselben Zugangsdaten, dasselbe Ziel, denselben Zeitplan. Kann der Server seine eigenen Backups löschen, werden sie gelöscht. Das Überleben hängt davon ab, dass die Kopie nur anhängbar ist oder völlig außer Reichweite liegt.
Das Konto verlieren, nicht den Server
Eine ausgesetzte Zahlung, ein gesperrtes Konto, eine Abschaltung in der falschen Jurisdiktion. Die Hardware ist in Ordnung, Sie kommen nur schlicht nicht mehr heran. Hier hilft nur eine Kopie bei einem anderen Anbieter, mit einem anderen Zahlungsweg.
Schreiben Sie auf, gegen welches der vier Szenarien Sie sich tatsächlich absichern, bevor Sie irgendetwas auswählen. Eine nächtliche Kopie in ein zweites Verzeichnis auf derselben Festplatte deckt genau eines davon ab — das unwahrscheinlichste — und fühlt sich dabei vollständig wie ein Backup an. Die meisten Setups, die in der Produktion versagen, versagen, weil nie jemand das Szenario benannt hat.
Snapshots sind keine Backups
Die Begriffe werden synonym verwendet, dabei beschreiben sie unterschiedliche Objekte mit unterschiedlichen Ausfallbereichen. Zu wissen, welches der beiden Sie haben, entscheidet darüber, ob Sie überhaupt etwas haben.
Nutzen Sie Snapshots für das, worin sie wirklich hervorragend sind: ein Fünf-Sekunden-Rückgängig, bevor Sie den Kernel, den Bootloader oder ein Datenbankschema anfassen. Erstellen Sie einen, machen Sie die riskante Sache, löschen Sie ihn, wenn es funktioniert hat. Was Sie niemals zulassen dürfen: dass "es gibt ja einen Snapshot" zum Grund dafür wird, kein Backup zu haben — ein Snapshot teilt sein Schicksal mit der Plattform, die ihn hält, und ein gesperrtes Konto nimmt beide auf einmal mit.
3-2-1, und die zwei Zahlen, die jeder weglässt
Die alte Regel hält sich, weil sie Unabhängigkeit beschreibt und kein Ablagesystem: drei Kopien der Daten, auf zwei verschiedenen Arten von Speicher, eine davon woanders. Zwei Ergänzungen decken Ausfälle ab, die selten waren, als die Regel geschrieben wurde, und heute Routine sind.
- Drei Kopien. Die Live-Daten plus zwei Backups. Zwei Kopien bedeuten, dass Sie nur eine misslungene Wiederherstellung von null entfernt sind.
- Zwei Medien, oder zwei Anbieter. Bei gemieteter Infrastruktur bedeutet "Medium" eigentlich administrative Unabhängigkeit — eine zweite Kopie unter demselben Konto, auf derselben Plattform, bezahlt aus demselben Guthaben, ist eine Kopie mit Umwegen.
- Eine davon extern. Anderes Gebäude, anderes Netzwerk, andere Jurisdiktion, falls Ihnen das wichtig ist. /locations ist die praktische Umsetzung davon: Wählen Sie eine Region, die unabhängig von der ausfällt, die Sie schützen.
- Eine davon unveränderlich oder offline. Eine Kopie, die der Server selbst nicht löschen kann, weil derjenige, der den Server besitzt, auch dessen Zugangsdaten besitzt.
- Null ungeprüfte Wiederherstellungen. Ein Backup, das Sie nie wiederhergestellt haben, ist eine Hypothese. Die Zahl, die zählt, ist, wie viele Wiederherstellungen Sie abgeschlossen haben — nicht, wie viele Jobs Erfolg gemeldet haben.
Sichern Sie die Daten, bauen Sie den Rest neu auf
Der Instinkt sagt: alles imagen. Das ist teuer, langsam wiederherzustellen, und es bewahrt originalgetreu die kompromittierte Binärdatei, den kaputten Paketstatus und die Config-Drift, an deren Entstehung Sie sich längst nicht mehr erinnern. Ein Server enthält drei Arten von Inhalt, und nur eine davon gehört ins Backup.
- Beziehen Sie /etc, /home, /root, /srv, Ihr Web-Root, das State-Verzeichnis Ihrer Anwendung, benannte Container-Volumes und ein Verzeichnis mit frischen Datenbank-Dumps mit ein.
- Beziehen Sie das Deployment-Rezept selbst mit ein — Compose-Dateien, Ansible- oder Shell-Skripte, die Notizen, die Sie um zwei Uhr nachts geschrieben haben. Halten Sie es zusätzlich in der Versionsverwaltung, aber legen Sie auch eine Kopie ins Backup, damit die Wiederherstellung nie davon abhängt, dass ein zweiter Dienst erreichbar ist.
- Schließen Sie /proc, /sys, /dev, /run und die temporären Verzeichnisse aus. Das sind Kernel-Schnittstellen und Scratch-Bereiche; sie zu kopieren verschwendet Zeit oder lässt den Job schlicht hängen bleiben.
- Schließen Sie Paket-Caches, Build-Verzeichnisse, Dependency-Bäume und virtualenvs aus — alles, was ein Build-Schritt neu erzeugt. Auf einem typischen Anwendungsserver ist das der größte Teil der Festplatte.
- Schließen Sie die Live-Datenbankdateien aus, wenn Sie die Datenbank ordentlich dumpen. Beides zu sichern bedeutet, dass die größere, nutzlose Kopie diejenige ist, die jemand um drei Uhr morgens wiederherstellt.
- Schließen Sie versteckte Dateien nicht aus. Die Hälfte von dem, was auf einer Linux-Maschine wichtig ist, beginnt mit einem Punkt.
Datenbanken überleben keine Dateikopie
Das ist der mit Abstand häufigste Grund, warum eine Wiederherstellung scheitert. Eine laufende Datenbank hält Zustand im Speicher und schreibt außer der Reihe; ihre Dateien zu kopieren, während sie läuft, erfasst einen zerrissenen, halb geschriebenen Zustand, der sich wiederherstellen lässt, sich still beschädigt wiederherstellen lässt, oder sich überhaupt nicht wiederherstellen lässt. Erstellen Sie einen ordentlichen Dump, und sichern Sie dann den Dump.
- PostgreSQL: pg_dump pro Datenbank, oder pg_dumpall für den gesamten Cluster einschließlich Rollen. Wo der Verlust eines Tages inakzeptabel ist, ergänzen Sie WAL-Archivierung, damit Sie auf einen bestimmten Zeitpunkt statt auf die letzte Nacht wiederherstellen können.
- MySQL oder MariaDB: mysqldump mit --single-transaction liefert bei InnoDB einen konsistenten Snapshot, ohne Schreibvorgänge zu blockieren. Bei MyISAM funktioniert das nicht — ein weiterer Grund, kein MyISAM zu betreiben. Bei großen Datenmengen stellt ein physisches Tool wie mariabackup weit schneller wieder her, als einen Dump abzuspielen.
- SQLite: Kopieren Sie die Datei niemals. Verwenden Sie den Befehl .backup oder VACUUM INTO, die den Lock korrekt setzen. Eine Datenbank mit aktivem Write-Ahead-Log zu kopieren ist ein Münzwurf, den Sie irgendwann verlieren.
- Redis: Lösen Sie ein Background-Save aus und sichern Sie die entstehende Snapshot-Datei, oder betreiben Sie es im Append-only-Modus und sichern Sie das Log. Einen Live-Snapshot mitten im Schreibvorgang zu kopieren bringt Ihnen eine abgeschnittene Datei ein, die als leerer Datensatz geladen wird.
- Container: Das Volume ist die Daten. Halten Sie den Stack für die Sekunden an, die eine Kopie braucht, oder führen Sie das Dump-Tool innerhalb des Containers aus — aber tarren Sie nicht das Volume einer laufenden Datenbank und nennen es ein Backup.
- Alles andere mit einem dauerhaften Prozess — Suchindizes, Message Queues, Ledger-Daemons — hat seinen eigenen Befehl für konsistente Exporte. Finden Sie ihn jetzt, nicht während des Ausfalls.
Dateisystem-Snapshots lösen das aus der anderen Richtung: LVM, ZFS und btrfs frieren eine konsistente Sicht auf das Volume innerhalb von Millisekunden ein, und Sie sichern die eingefrorene Sicht, während die Datenbank weiter bedient. Das ist die richtige Antwort für Datenmengen, bei denen ein Dump Stunden dauert. Es ist kein Grund, den Dump bei einer Datenbank mit 200 MB auszulassen, wo der Dump einfacher, über Engine-Versionen hinweg portabel und von einem Menschen lesbar ist, wenn irgendetwas seltsam gelaufen ist.
Ein Werkzeug wählen
Vier Werkzeuge decken fast jeden Fall ab. Die wichtigste Eigenschaft ist, wo die Verschlüsselung stattfindet. Werden Daten nur während der Übertragung verschlüsselt und danach im Ruhezustand vom Storage-Anbieter, kann der Storage-Anbieter sie lesen — und das Backup ist still und leise zur schwächsten Stelle in einem System geworden, das Sie sonst überall gehärtet haben.
Wofür Sie sich auch entscheiden: Die Passphrase oder der Schlüssel muss irgendwo existieren, das nicht der gesicherte Server selbst ist. Das ist die Falle, in die sorgfältige Menschen tappen: der Repository-Schlüssel liegt in /root und wird brav mit ins Repository gesichert, das er entsperrt. Drucken Sie ihn aus, oder bewahren Sie ihn in einem Passwort-Manager auf, den Sie von einer Maschine öffnen können, die noch lebt. Ein Repository, das Sie nicht entschlüsseln können, ist nicht von einem fehlenden Backup zu unterscheiden.
Wo die zweite Kopie liegen sollte
Das Ziel ist ebenso sehr eine Jurisdiktion und eine Zahlungsbeziehung wie Speicherplatz. Vier Optionen, grob geordnet danach, wie unabhängig sie vom Server sind, den Sie schützen.
Ein zweiter Server in einer anderen Region
Die naheliegende Antwort: eine günstige Instanz in einem anderen Land, erreichbar über SSH, auf der nichts läuft außer sshd und einem Repository. Ein Plan mit 1 GB auf /vps fasst die Backups einer kleinen Flotte, und das Konto lässt sich auf einen einzigen erzwungenen Befehl beschränken, sodass ein gestohlener Schlüssel keine Shell öffnet.
Speicherplatz der Storage-Klasse
Sobald der Datenbestand auf Hunderte Gigabyte anwächst, kostet HDD-Kapazität an einem ungemessenen Uplink pro Terabyte weit weniger als NVMe, und Backup-Schreibvorgänge brauchen keine NVMe-Latenz. /storage ist genau dafür gebaut: RAID-geschützter Speicher im Terabyte-Bereich, voller Root-Zugriff, keine Inhaltsprüfung.
S3-kompatibler Object Storage
Bequem, pro Gigabyte abgerechnet, und oft mit Object-Lock-Unterstützung, die echte Unveränderlichkeit bietet. Lesen Sie die Egress-Preise, bevor Sie sich darauf verlassen — ein Terabyte im Notfall zurückzuholen ist ein schlechter Moment, um zu entdecken, was der Abruf kostet.
Eigene Hardware
Eine externe Festplatte oder eine Maschine zu Hause, geholt statt geschickt. Langsamer und manuell, und die einzige Kopie auf dieser Liste, die kein Anbieter, kein Gerichtsbeschluss und kein Zahlungsstreit anfassen kann. Es lohnt sich, sie für Daten zu führen, die Sie wirklich nicht neu erzeugen können, selbst wenn sie eine Woche hinterherhinkt.
Passen Sie die Privatsphäre-Eigenschaften des Backups an die des Servers an. Eine Festplatte mit LUKS zu verschlüsseln und dann nächtlich Klartext-Backups zu einem Bucket zu schicken, der auf Ihre Karte registriert ist, macht die ganze Übung zunichte: Die Daten sind jetzt lesbar, und sie sind unter Ihrem Namen abgelegt. Wenn es sich gelohnt hat, den Server anonym zu bezahlen, dann lohnt sich das auch für die Kopie — verschlüsseln Sie clientseitig, und kaufen Sie das Ziel auf dieselbe Weise, wie Sie den Ursprung gekauft haben.
Schritt für Schritt aufbauen
- 1
Zuerst die zwei Zahlen festlegen
Wie viele Daten Sie sich zu verlieren leisten können — die Lücke zwischen zwei Läufen — und wie lange Sie sich einen Ausfall leisten können. Alles andere folgt aus diesen beiden Antworten. Stündliche Backups einer statischen Website sind Theater; nächtliche Backups einer Bestelldatenbank sind eine Entscheidung, die Sie bewusst treffen sollten, statt sie von einem Tutorial zu übernehmen.
- 2
Das Ziel anlegen
Eine zweite Instanz in einer anderen Region mit eigenem SSH-Schlüssel und einem dedizierten unprivilegierten Benutzer, dessen Home-Verzeichnis das Repository ist. Dort läuft sonst nichts. Beschränken Sie den Schlüssel auf einen erzwungenen Befehl, sodass gestohlene Zugangsdaten nur Backups anhängen können, niemals eine Shell öffnen.
- 3
Den Schlüssel erzeugen und anderswo aufbewahren
Eine lange, zufällige Passphrase, notiert an einem Ort, der den Verlust des Servers übersteht. Initialisieren Sie das Repository, und beweisen Sie dann, dass Sie seinen Inhalt von einer dritten Maschine aus auflisten können, allein mit dem, was Sie sich notiert haben. Wenn nicht, beheben Sie das, bevor Sie auch nur ein einziges Backup schreiben.
- 4
Zuerst die Datenbanken dumpen
Ein kurzes Skript, das konsistente Dumps in ein Staging-Verzeichnis schreibt und bei einem Fehlschlag mit einem Exit-Code ungleich null beendet — ausgeführt vor dem Datei-Backup, nicht parallel dazu. Ein Job, der nach einem fehlgeschlagenen Dump einfach weitermacht, ist der Grund, warum Leute am Ende dreißig Tage voller Null-Byte-Dateien haben.
- 5
Die wichtigen Pfade sichern
Richten Sie das Werkzeug auf die Include-Liste, wenden Sie die Excludes an, und prüfen Sie den ersten Lauf auf Plausibilität. Kommt ein frisches Repository eines Servers mit 40 GB auf 300 MB, wird irgendetwas still übersprungen; kommt es auf 38 GB, funktionieren Ihre Excludes nicht.
- 6
Planen Sie es ein, und sorgen Sie dafür, dass Fehlschläge auffallen
Ein systemd-Timer mit zufälliger Verzögerung, oder cron, falls das die Gewohnheit ist. Lassen Sie den Job dann berichten: einen Heartbeat an einen Monitor bei Erfolg, und einen Alarm, wenn der Heartbeat ausbleibt. Stiller Fehlschlag ist der normale Fehlermodus von Backups, weil nichts sichtbar kaputtgeht, wenn sie aufhören — bis plötzlich alles kaputt ist.
- 7
Aufbewahrung festlegen und tatsächlich bereinigen
Stündlich für einen Tag, täglich für zwei Wochen, wöchentlich für ein paar Monate, monatlich für ein Jahr. Führen Sie dann das Prune aus, und bestätigen Sie, dass das Repository aufhört zu wachsen. Eine Aufbewahrungsregel, die konfiguriert, aber nie ausgeführt wird, füllt das Ziel und reißt die Backups mit sich.
- 8
Stellen Sie noch heute etwas wieder her
Kein Testjob — eine echte Datei, in ein Scratch-Verzeichnis, geöffnet und geprüft. Tragen Sie dann ein Datum für die ganze Maschine in den Kalender ein. Die erste vollständige Wiederherstellung fördert immer etwas zutage: einen fehlenden Pfad, eine Berechtigung, ein Zertifikat, einen Datenbankbenutzer, der nur je auf der alten Maschine existierte.
Schieben Sie das Backup vom Server nach außen, so haben Sie akzeptiert, dass jeder mit Root darauf jede Kopie zerstören kann. Machen Sie es andersherum — der Backup-Host verbindet sich hinein, holt ab und trennt die Verbindung wieder —, und ein kompromittierter Server kann das Repository überhaupt nicht erreichen, weil er keine Zugangsdaten dafür besitzt. Pull ist aufwendiger einzurichten, und es ist die mit Abstand größte Verbesserung, die die meisten Setups vornehmen können.
Aufbewahrung, und warum länger billiger ist, als es klingt
Die Aufbewahrungsdauer wird meist einfach danach festgelegt, was auf die Festplatte passt, und dann vergessen. Sie verdient einen bewussten Gedanken, denn sie entscheidet, welche Fehler sich beheben lassen. Ein Sieben-Tage-Fenster fängt eine Datei ab, die am Dienstag gelöscht wurde. Es fängt keine Beschädigung ab, die vor sechs Wochen begann und auffiel, als ein Report falsch herauskam, und auch keinen Eindringling, der einen Monat lang still auf der Maschine saß, bevor er handelte.
Deduplizierung macht das weit billiger, als die Tabelle vermuten lässt: Der zweite Lauf gegen einen größtenteils unveränderten Server speichert nur, was sich geändert hat, sodass ein Jahr monatlicher Wiederherstellungspunkte auf einer Maschine mit 40 GB typischerweise ein paar Gigabyte kostet statt ein halbes Terabyte. Legen Sie die Richtlinie danach fest, wovon Sie sich erholen müssen, und prüfen Sie dann die Rechnung. Meist werden Sie feststellen, dass Sie sich die großzügige Version leisten können.
Unveränderlichkeit: der Teil, der Ransomware stoppt
Alles bisher Gesagte geht davon aus, dass der Gegner die Entropie ist. Ist der Gegner ein Mensch mit Root-Rechten, ist ein gewöhnlicher Backup-Job eine Bedienungsanleitung — die Zugangsdaten liegen auf der Maschine, das Ziel steht in der Konfiguration, und das Repository wird gelöscht, bevor die Verschlüsselung beginnt. Vier Mechanismen durchbrechen diese Kette, und jeder einzelne davon ändert das Ergebnis.
- Append-only-Repositories. Borgs serverseitiger Append-only-Modus, oder restics REST-Server im Append-only-Modus, akzeptieren neue Daten und verweigern Löschungen. Der Server kann schreiben; nur Sie, von woanders, können bereinigen.
- Pull-basierte Backups. Der Backup-Host baut die Verbindung auf und besitzt die einzigen Zugangsdaten. Der Produktivserver hat keinen Schlüssel, keine Zieladresse und überhaupt keinen Weg zum Repository.
- Object Lock. S3-kompatibler Speicher mit einer Aufbewahrungsfrist, die auf Bucket-Ebene erzwungen wird, wo die Speicherschicht selbst Löschungen verweigert, ganz gleich, was die Zugangsdaten sonst erlauben würden.
- Getrennte Zugangsdaten pro Host. Eine kompromittierte Maschine sollte nicht die Historie jeder anderen Maschine offenlegen. Unterschiedliche Schlüssel, unterschiedliche Pfade, unterschiedliche Einschränkungen.
- Eine Kopie, die wirklich offline ist. Eine ausgesteckte Festplatte ist gegen jeden je geschriebenen Remote-Angriff immun. Altmodisch, und ungeschlagen.
Die Wiederherstellungsübung
Eine Wiederherstellung ist ein Verfahren, und ein Verfahren, das nie jemand durchgeführt hat, ist Fiktion. Führen Sie dies einmal jetzt und dann alle sechs Monate durch, und schreiben Sie auf, was Sie dabei lernen — die Notizen erweisen sich am Ende als ebenso wertvoll wie die Daten.
- 1
Eine leere Instanz bereitstellen
Dieselbe Betriebssystemversion, sonst nichts installiert. Ein kurzlebiger VPS genügt, und die ganze Übung kostet weniger als ein Mittagessen.
- 2
Nur mit dem wiederherstellen, was Sie sich notiert haben
Die Repository-Adresse, die Passphrase, die Befehle. Brauchen Sie etwas, das nur auf dem Server existiert, den Sie sich als tot vorstellen, haben Sie gerade die Schwachstelle gefunden — an einem Tag, an dem sie nichts kostet.
- 3
Erst die Daten zurückholen, dann die Anwendung
Laden Sie den Datenbank-Dump, legen Sie die Dateien dorthin, wo sie hingehören, und korrigieren Sie dann Besitzer und Rechte. Der Besitzer ist die übliche Überraschung: numerische User-IDs von der alten Maschine passen auf der neuen selten zusammen.
- 4
Den Dienst starten und ihn tatsächlich benutzen
Kein Statusbefehl — melden Sie sich an, laden Sie eine Seite, führen Sie eine Abfrage aus, senden Sie eine Nachricht. Ein Dienst, der startet, ist nicht dasselbe wie ein Dienst, der funktioniert.
- 5
Stoppen Sie die Zeit, und notieren Sie die Zahl
Wie lange hat das Ganze gedauert? Das ist Ihre echte Recovery-Zeit, und sie ist fast immer ein Vielfaches der Schätzung. Bewahren Sie die Notizen neben der Passphrase auf, und aktualisieren Sie beide, sobald sich der Stack ändert.
Was es kostet, ehrlich betrachtet
Backup ist die billigste Versicherung in der Infrastruktur, und sie wird routinemäßig aus Preisgründen ausgelassen. Ein paar konkrete Zahlen für einen kleinen Server, unter der Annahme, dass die Daten sich so komprimieren und deduplizieren lassen wie gewöhnliche Daten.
Vergleichen Sie jede dieser Zahlen mit den Kosten des Ausfalls, den sie verhindern. Die Zahl zu benennen ist der eigentliche Punkt — das Argument gegen Backups dreht sich nie wirklich um Geld, sobald das Geld einmal aufgeschrieben ist.
Wo der Host ins Bild kommt
Ein Backup-Plan hat dieselben zwei Abhängigkeiten wie der Server, den er schützt: einen unabhängigen Ort für die Kopie, und einen Zahlungsweg, der keine neue Spur zu Ihrer Identität hinterlässt. Beides zählt hier sogar noch mehr als am Ursprung, weil das Backup eine vollständige Kopie von allem ist, was der Ursprung schützte.
Jeder Plan auf /vps und /storage wird hier aus einem vorausbezahlten Krypto-Guthaben ohne KYC bereitgestellt, über fünfzehn Regionen hinweg, aufgelistet auf /locations — sodass die zweite Kopie unter einer anderen Jurisdiktion liegen kann als die erste, ohne eine zweite Identitätsprüfung irgendwo in der Kette. Instant-Snapshots sind auf jeder Instanz für das Fünf-Sekunden-Rückgängig inbegriffen, ungemessene Bandbreite bedeutet, dass weder der erste Upload noch die Notfall-Wiederherstellung ein abgerechnetes Ereignis ist, und /storage bietet RAID-geschützten Speicher im Terabyte-Bereich ab $8.99/mo ohne Inhaltsprüfung. /pay-with behandelt die akzeptierten Coins, /offshore-hosting legt dar, was die Jurisdiktion wirklich ändert, und /guides bietet die Begleitstücke zur Festplattenverschlüsselung und dazu, was ein Host über eine Maschine sehen kann und was nicht.
Die Checkliste
- Benennen Sie den Ausfall, gegen den Sie sich absichern, bevor Sie ein Werkzeug wählen.
- Behandeln Sie Snapshots als Rückgängig-Taste, niemals als das Backup.
- Sichern Sie Daten und Konfiguration; bauen Sie das Betriebssystem aus einem Skript neu auf.
- Dumpen Sie jede Datenbank mit ihrem eigenen Befehl für konsistente Exporte, und sichern Sie den Dump.
- Verschlüsseln Sie clientseitig, bevor irgendetwas die Maschine verlässt.
- Bewahren Sie die Repository-Passphrase an einem Ort auf, der den Verlust des Servers übersteht.
- Legen Sie mindestens eine Kopie bei einem anderen Anbieter, in einer anderen Region und über einen anderen Zahlungsweg ab.
- Machen Sie eine Kopie append-only, pull-basiert oder offline, sodass kompromittierter Root-Zugriff sie nicht löschen kann.
- Schlagen Sie Alarm beim Ausbleiben eines erfolgreichen Laufs — Fehlschläge sind still, und Stille ist das Symptom.
- Stellen Sie noch heute eine Datei wieder her und zweimal im Jahr die ganze Maschine. Stoppen Sie die Zeit, und notieren Sie sie.
Reichen Snapshots des Anbieters allein aus?
Nein, und das ist die häufigste Lücke in sonst sorgfältigen Setups. Ein Snapshot liegt auf derselben Plattform wie das Volume, das er kopiert, also übersteht er weder einen Ausfall auf Plattformebene noch eine Kontosperrung noch eine ausgesetzte Zahlung — drei der Szenarien, in denen Sie ihn am dringendsten brauchen. Außerdem behält er meist nur eine kurze Historie, sodass er weder eine letzten Monat gelöschte Datei noch eine vor sechs Wochen begonnene Beschädigung wiederherstellt. Snapshots sind hervorragend als Fünf-Sekunden-Rückgängig vor einer riskanten Änderung: Behalten Sie sie, nutzen Sie sie täglich, und bewahren Sie ein echtes Backup woanders auf.
restic oder Borg — was sollte ich verwenden?
restic, wenn das Ziel Object Storage oder ein einfacher SSH-Account ist, weil es am anderen Ende nichts Installiertes braucht und S3 nativ spricht. Borg, wenn das Ziel eine Linux-Maschine ist, die Sie kontrollieren, und Sie den Append-only-Servermodus und etwas straffere Kompression wollen. Beide deduplizieren, beide verschlüsseln und authentifizieren clientseitig, beide sind ausgereift und weit verbreitet, und beides ist eine vertretbare Wahl. Die falsche Antwort ist, einen Monat mit dem Vergleich zu verbringen, während der Server überhaupt kein Backup hat — entscheiden Sie sich heute Nachmittag für eines, und ändern Sie später Ihre Meinung, falls es je darauf ankommt.
Wie oft sollte ich einen VPS sichern?
Das Intervall ist schlicht die maximale Menge an Arbeit, die Sie bereit sind, noch einmal zu machen. Für eine statische Website ist wöchentlich ehrlich. Für alles, worauf Nutzer schreiben, ist nächtlich das Minimum, und stündlich ist billig, sobald die Deduplizierung die Arbeit übernimmt — der zweite Lauf des Tages speichert meist nur ein paar Megabyte. Wägen Sie den Wert eines Tages an Daten gegen die Kosten ab, vierundzwanzig Wiederherstellungspunkte statt einem zu speichern, und die Antwort ist normalerweise offensichtlich.
Sollte ich die ganze Festplatte sichern oder nur meine Daten?
Daten und Konfiguration, in fast jedem Fall. Ein vollständiges Disk-Image stellt die Maschine exakt so wieder her, wie sie war, einschließlich der Kompromittierung, von der Sie sich gerade erholen, und des Paketstatus, den Sie längst nicht mehr durchschauen — und es ist sowohl beim Erstellen als auch bei der Wiederherstellung langsamer. Ein Backup auf Dateiebene von /etc, Ihren Anwendungsdaten und Ihren Datenbank-Dumps, kombiniert mit einem Skript, das das Betriebssystem neu aufbaut, stellt schneller und sauberer wieder her. Erstellen Sie ein Image der Festplatte, wenn Sie eine bitgenaue forensische Bewahrung brauchen, oder wenn die Maschine eine Blackbox ist, die jemand anderes gebaut hat.
Mein Anbieter sagt, die Festplatten seien verschlüsselt — ist mein Backup verschlüsselt?
Nicht in einem Sinne, der Ihnen hilft. Anbieterseitige Verschlüsselung schützt davor, dass ein Laufwerk aus einem Rack getragen wird; der Anbieter besitzt den Schlüssel, also bleiben die Daten für den Anbieter lesbar und für jeden, der den Anbieter dazu zwingen kann. Clientseitige Verschlüsselung — restic, Borg, rclones Crypt-Schicht oder ein verschlüsseltes Archiv — bedeutet, dass das, was am Ziel ankommt, ohne eine Passphrase bedeutungslos ist, die nie Ihre Maschine verlassen hat. Für einen privatsphärekritischen Stack ist genau das der springende Punkt, weil das Backup eine vollständige Kopie von allem ist, was der Server schützte.
Wie verhindere ich, dass Ransomware auch meine Backups verschlüsselt?
Gehen Sie davon aus, dass ein Angreifer mit Root-Rechten alles zerstören kann, was der Server erreicht — die Zugangsdaten, das Ziel und der Zeitplan liegen allesamt auf der Maschine. Durchbrechen Sie diese Reichweite auf eine von drei Arten: ein Append-only-Repository, das Schreibvorgänge akzeptiert, aber Löschungen verweigert, ein Pull-Modell, bei dem der Backup-Host sich nach innen verbindet und der Server überhaupt keine Zugangsdaten besitzt, oder Object Storage mit einer Sperre, die die Speicherschicht selbst erzwingt. Ergänzen Sie das dann um eine lange Aufbewahrungsdauer, damit eine langsame und stille Kompromittierung nicht einfach aus dem Fenster herausaltert, bevor es jemand bemerkt, und bewahren Sie eine Kopie offline auf, wo kein Remote-Angriff sie erreichen kann.
