Verschlüsselte Backups, die Sie tatsächlich wiederherstellen können.

Wählen Sie die Repository-Grenze

Verwenden Sie ein separates Ziel und separate Anmeldedaten vom Produktionsserver. Clientseitige Verschlüsselung kann gespeicherte Kopien schützen, aber das Repository-Passwort oder der Schlüssel muss privat gesichert werden. Geht er verloren, können alle verschlüsselten Snapshots unbrauchbar werden.

Erfassen Sie konsistente Daten

Verwenden Sie datenbankeigene Dumps oder ein anwendungsgestütztes Snapshot-Verfahren. Sichern Sie Konfiguration, Bereitstellungsanweisungen und die geschützten Geheimnisse, die für die Wiederherstellung erforderlich sind. Schließen Sie nur flüchtige Caches aus, wenn Sie wissen, dass sie neu erstellt werden können.

Erschweren Sie das Löschen

Erwägen Sie ein nur anhängendes oder unveränderliches Ziel, bei dem der Quellrechner nicht jede historische Kopie löschen kann. Halten Sie Aufbewahrungs- und Bereinigungs-Anmeldedaten nach Möglichkeit getrennt. Verschlüsselung allein hindert einen kompromittierten Server nicht daran, ein beschreibbares Repository zu löschen.

Prüfungen und Wiederherstellungsübungen planen

Überwachen Sie den Exit-Status des Jobs und das Alter des letzten guten Backups. Führen Sie die vom Tool unterstützten Integritätsprüfungen des Repositorys aus. Stellen Sie regelmäßig eine Stichprobe wieder her und führen Sie nach größeren Anwendungsänderungen eine vollständige Wiederherstellungsübung durch.

Das Hinzufügen einer Kopie vom Löschen des Verlaufs trennen

Ein nur anhängendes Ziel kann dem Produktionsserver erlauben, Snapshots hinzuzufügen, während die Löschbefugnis auf einer separaten vertrauenswürdigen Maschine bleibt. Die Aufbewahrung muss dennoch sorgfältig geprüft werden: gefälschte neuere Snapshots können einige kalenderbasierte Auswahlrichtlinien untergraben. Prüfen Sie die Anleitung des Werkzeugs, führen Sie einen Probelauf der Aufbewahrung durch und überwachen Sie die Kapazität. Der forget-Vorgang von Restic wählt Snapshots aus; das Pruning entfernt nicht referenzierte gespeicherte Daten.

• Halten Sie Wartungszugangsdaten für das Repository von der Produktionsmaschine fern
• Führen Sie einen Aufbewahrungs-Probelauf durch, bevor Sie das Löschen zulassen
• Verwenden Sie für jede Wiederherstellungsübung ein neues leeres Ziel

restic check
restic snapshots
restic restore latest --target /srv/restore-drill

Offizielle Dokumentation: Restic-Aufbewahrung und -Bereinigung

Eine Wiederherstellungsübung mit einer Bestehensbedingung

Wählen Sie einen realistischen Ausfall: eine gelöschte Datei, eine verlorene Datenbank oder einen vollständigen Neuaufbau der Maschine. Stellen Sie in ein separates Verzeichnis oder einen isolierten Host wieder her. Überprüfen Sie Dateiinhalte, Berechtigungen und die Fähigkeit der Anwendung, sie zu nutzen. Erfassen Sie die verstrichene Zeit und jeden manuellen Schritt, der im Runbook fehlte. Eine Repository-Prüfung bestätigt eine andere Eigenschaft als eine funktionierende Anwendungswiederherstellung.

• Stellen Sie die Live-Anwendung nicht als ersten Test wieder her
• Bestätigen Sie, dass Verschlüsselungsnachweise unabhängig wiederherstellbar sind
• Benachrichtigen Sie, wenn das neueste erfolgreiche Backup Ihr Wiederherstellungsziel überschreitet

Erstellen Sie ein Wiederherstellungsmanifest, bevor Sie Ausschlüsse wählen

Listen Sie die Dinge auf, die sich nicht durch Neuinstallation eines Pakets wiederherstellen lassen: Datenbankinhalte, Uploads, Anwendungskonfiguration, Signier- oder Verschlüsselungsschlüssel und Deployment-Versionen. Notieren Sie neben jedem Eintrag die Konsistenzmethode. Ein Datenbank-Dump gehört zu einem definierten Zeitpunkt; das Kopieren eines stark beanspruchten Datenbankverzeichnisses kann ein anderes Ergebnis liefern. Bewahren Sie den Repository-Zugang, seine Passphrase und jeden Borg-Schlüsselexport an einem separaten, privaten Wiederherstellungsort auf. Testen Sie, ob eine Ersatzmaschine das Repository öffnen kann, bevor Sie es zur einzigen Wiederherstellungskopie machen.

• Legen Sie das Recovery Point Objective fest: wie viel aktuelle Arbeit verloren gehen darf. Richten Sie den Zeitplan an dieser Anforderung aus.
• Geben Sie das Wiederherstellungsziel an: wie lange ein Rebuild dauern darf. Beziehen Sie den Datenbankimport und DNS-Änderungen in die Übung ein.
• Prüfen Sie, dass ein für Caches gedachter Ausschluss nicht auch Uploads, Container-Volumes oder geschützte Konfiguration entfernt.
• Verwenden Sie die Dokumentation für die installierte Borg-Hauptversion; Repository-Formate und Befehle sind nicht zwischen allen Versionen austauschbar.

Offizielle Dokumentation: Borg: Verschlüsselung, Konsistenz und Wiederherstellung

Prüfen Sie gespeicherte Daten sowie Repository-Metadaten

Die standardmäßige Repository-Prüfung von Restic und eine Read-Through-Verifikation leisten unterschiedliche Arbeit. Planen Sie die Datenverifikation unter Berücksichtigung ihrer Bandbreiten- und Laufzeitkosten. Das Beispiel prüft ein definiertes Fünftel der Pack-Dateien; nachfolgende geplante Prüfungen müssen die übrigen Anteile verwenden, um das Repository abzudecken. Eine zufällig ausgewählte Teilmenge bietet nicht dieselbe Abdeckungsgarantie. Keiner der beiden Vorgänge beweist, dass die Anwendung mit wiederhergestellten Daten starten kann.

restic check --read-data-subset=1/5
restic snapshots --host example-host
restic restore latest --host example-host --target /srv/restore-drill

Offizielle Dokumentation: restic: Repository-Prüfungen und Datenverifizierung

Halten Sie Wartungsarbeiten außerhalb der Reichweite des kompromittierten Clients

Borg-Append-Only-Speicher bewahrt committete Segmentdaten, aber ein Client kann die sichtbare Archivliste dennoch ändern; Wiederherstellung und Kompaktierung erfordern das dokumentierte administrative Verfahren. Beschränken Sie die Remote-Backup-Anmeldedaten auf Borgs Serverbefehl, nicht auf eine uneingeschränkte Shell- oder Dateisystem-Anmeldung, die diese Schutzmaßnahmen umgehen könnte. Prüfen Sie bei restic die Keep-Within-Anleitung für Append-Only-Aufbewahrung. Inspizieren Sie vor jeder Wartung, die den Verlauf entfernen kann, die Repository-Gesundheit und sehen Sie die Auswahl von einem vertrauenswürdigen Rechner aus in der Vorschau an.

• Überwachen Sie das Alter der letzten erfolgreichen Kopie, das Repository-Wachstum, den Cache-Speicher und die freie Kapazität an beiden Enden.
• Wenn eine Wiederherstellung fehlschlägt, bewahren Sie das ursprüngliche Repository und die Protokolle auf, bevor Sie Reparaturen oder Bereinigungen versuchen.
• Wenn der Auftrag erfolgreich ist, aber erwartete Dateien fehlen, prüfen Sie den Archivinhalt und die Ausschlussmuster, bevor Sie die Aufbewahrung ändern.
• Schließen Sie die Übung ab, indem Sie Dateien öffnen und Anwendungsprüfungen isoliert ausführen; halten Sie Produktionsziele aus dem Wiederherstellungsbefehl heraus.

Offizielle Dokumentation: Borg: Append-only-Betrieb und Wartung · restic: Aufbewahrung und Append-only-Überlegungen