Backups: drei Kopien, ein fehlender Beweis
Das Rechenzentrum in der Wohnung, gemessen an 3-2-1: was gesichert wird, wo es landet, was darüber wacht, und die Lücke — eine vollständige Wiederherstellungsübung, die noch nicht stattgefunden hat. Das Backup, das dreizehn Tage lang still stehen blieb, ist der Grund, warum es das Monitoring gibt. Seit September gehen die Archive an einen eigenen Backup-Server, der sie dedupliziert, sie erneut liest, um zu beweisen, dass sie noch lesbar sind, und sie verschlüsselt entgegennimmt — die Speicherbox darunter hält also Kopien, die sie nicht öffnen kann, was die schwierigste offene Frage vom Geheimtext auf die Verwahrung des Schlüssels verschiebt. Stand 2026-09-08.
Die Regel, die jeder zitiert, ist 3-2-1: drei Kopien der Daten, auf zwei Arten von Medien, eine davon woanders. Jede Zahl beantwortet einen anderen Weg, die Daten zu verlieren — die Kopie, die verdirbt, das Regal, das als ganze Charge ausfällt, das Gebäude, das brennt. Die Regel zählt Kopien, keine Beweise: Ob eine der drei je wieder geöffnet wurde, ist die Frage, mit der diese Notiz endet.
Was gesichert wird
Fast jeder Gast, jede Nacht. Seit September gehen die Archive nicht mehr direkt auf eine Netzfreigabe. Sie gehen an einen eigenen Backup-Server, der neben dem Rest der Flotte läuft, sie dedupliziert, je Gast die letzten fünf behält und das Gehaltene nach eigenem Zeitplan erneut liest und prüfsummt — womit „die Kopie existiert“ und „die Kopie ist lesbar“ aufgehört haben, dieselbe Behauptung zu sein. Die Bytes landen weiterhin auf der Speicherbox darunter — dem NAS, denn dort ist der Platz. Geändert hat sich, dass sie auf dem Knoten verschlüsselt werden, bevor sie ihn verlassen: Das NAS hält Archive, die es nicht lesen kann.
Der Backup-Server ist der eine Gast, der das nicht nutzen kann: Ein Archiv des Backup-Servers, gespeichert im Backup-Server, ist kein Backup. Er schreibt seine eigene nächtliche Kopie direkt auf die Freigabe, und dieses eine Archiv ist die deklarierte Ausnahme, kein Versehen.
Eine Maschine bleibt ganz außerhalb des nächtlichen Laufs. Sie bleibt so lange draußen, bis ihr Umgang mit Geheimnissen dem Rest der Flotte entspricht, denn die Regel hier lautet, dass kein Backup-Speicher ein Geheimnis im Klartext hält.
Der nächtliche Lauf besteht aus fünf Jobs, nicht aus einem. Sie starten nacheinander in den frühen Morgenstunden, damit nie zwei Dumps gleichzeitig auf dieselbe Freigabe schreiben. Jedes Zeitfenster ist so breit wie der langsamste Lauf, der über eine jüngere Reihe von Nächten gemessen wurde, zuzüglich Puffer — nicht so breit wie eine gute Nacht. Jeder Job läuft im Snapshot-Modus, auf Speicher, der Snapshots beherrscht — das ist die Abhilfe für etwas, das auf die harte Tour gelernt wurde: Ein Gast, den die HA-Schicht des Clusters übernommen hatte, hörte an dem Tag still auf, gesichert zu werden, an dem er aufgenommen wurde, während sein Nachbar im selben Job weiterlief. Zwei der fünf sind an einen Knoten geheftet und drei nicht, und auch das ist eine Lehre: Ein ungehefteter Job feuert auf jedem Knoten gleichzeitig, und genau diese Gleichzeitigkeit sollen die gestaffelten Zeitfenster verhindern.
Die Backup-Jobs leben in Git. Ein Backup-Zeitplan, der nur in der Proxmox-Oberfläche existiert, ist ein Zeitplan, ohne den ein neu gebauter Knoten hochkommt — und nichts schlägt fehl, die Backups hören einfach auf. Deshalb ist die Job-Liste im Hub-Repository deklariert und wird bei jedem Deploy konvergiert, wobei die von der Oberfläche erzeugten Job-IDs wörtlich übernommen werden, damit kein Gast je doppelt gesichert wird. Trägt der Cluster einen Job, den Git nicht kennt, schlägt der Deploy laut fehl, statt ihn zu löschen: Ein nicht deklarierter Job könnte das einzige Backup von irgendetwas sein.
Home Assistant sichert sich selbst auf eine eigene Freigabe auf dem NAS, und der Container bindet diese Freigabe ein, sodass eine Wiederherstellung ein nativer Vorgang ist und kein Upload. Bevor die Zentrale auf eine andere Maschine umziehen durfte, wurde eines dieser Backups außerhalb der Kiste entschlüsselt und isoliert gestartet — eine Wiederherstellung, die tatsächlich durchgeführt wurde. Es ist zugleich die Hälfte eines Wiederaufbaus, die Git nicht liefern kann: Der eigene Deploy-Weg der Zentrale trägt die geprüfte Konfiguration, dieses Backup trägt alles, was dieser Weg nie sieht.
Der Geheimnis-Tresor nimmt jede Nacht einen Snapshot auf das NAS, auf dem immer scharfen Zeitplan, der auch die Drift-Prüfung fährt. Auch sein Wiederherstellungsjob ist tatsächlich gelaufen, zuletzt am 2026-08-20.
Zwei weitere Sicherungswege gibt es auf dem NAS selbst. Hyper Backup repliziert vom NAS auf ein Ziel in einem anderen Gebäude; Active Backup for Business sichert die Arbeitsstation des Haushalts auf das NAS. Keiner von beiden ist im Repository deklariert oder wird von einem Deploy konvergiert — beide sind in der Oberfläche des NAS von Hand eingerichtet, was sie in dieselbe Klasse stellt wie einen Backup-Zeitplan, der nur in einer GUI lebt, mit demselben Risiko. Wie weit der Job außer Haus reicht, ist hier nicht festgestellt: Die dritte Kopie zählt als dritte Kopie, noch nicht als Deckung für irgendetwas Bestimmtes.
Die Firewalls und Switches sind Code, ihr Backup ist also das Repository plus das generierte Netzmodell.
Was darüber wacht
Der Ausfall, der diesen Abschnitt geformt hat: Zwischen 2026-07-13 und 2026-07-26 lief das nächtliche Backup nicht, und nichts sagte es. Proxmox schickt bei Fehlschlag eine Mail, aber ein Job, der nie startet, schlägt nicht fehl. Eine gesunde Flotte und eine Flotte ohne Backups sahen auf jedem Dashboard identisch aus.
Deshalb veröffentlicht jetzt jeder Knoten das Alter des neuesten Archivs pro Gast als Metrik, gelesen aus der Proxmox-API gegen denselben geteilten Speicher. Ein Gast ganz ohne Archiv wird als unendlich alt veröffentlicht — „nie gesichert“ alarmiert genau wie „veraltet“, was bedeutet, dass ein neuer Gast alarmiert, bis der Lauf der nächsten Nacht durch ist. Das ist Absicht; ein ungesicherter Gast ist der Zustand. Der Collector weigert sich, eine Teildatei zu schreiben: Wirft die API einen Fehler, veraltet die vorherige Datei und der Frische-Alarm feuert, statt dass ein Gast still aus der Liste verschwindet.
Die Smart-Home-Zentrale wendet dieselbe Regel auf sich selbst an: Gemessen wird ihre eigene nächtliche Kopie an den Entitäten, die sie über das Ergebnis führt, nie daran, dass der Aufruf zurückkam.
Ehrlich gezählt
| 3-2-1 verlangt | Was existiert |
|---|---|
| Drei Kopien | Drei, soweit der Job außer Haus reicht: die eigene Platte des Gastes, das nächtliche Archiv auf dem NAS und die Kopie, die Hyper Backup in ein anderes Gebäude schreibt |
| Zwei Arten von Medien | Ja: SSDs der Knoten auf der einen Seite, das NAS-Array auf der anderen |
| Eine Kopie außer Haus | Ja: Hyper Backup repliziert vom NAS auf ein Ziel in einem anderen Gebäude — auf dem NAS von Hand eingerichtet statt im Repository deklariert, und keine Wiederherstellung daraus ist verzeichnet |
| Eine bewiesene Wiederherstellung | Teilweise — der Tresor, die Smart-Home-Zentrale und ein Gast, der aus dem verschlüsselten Speicher zurückgeholt wurde; die Übung über die ganze Flotte fehlt weiter |
Die letzte Zeile ist die, die den Plan bestimmt. Ein Backup, das nie zurückgespielt wurde, ist eine hoffnungsvolle Kopie, deshalb bleibt der Wiederherstellungsbeweis über die ganze Flotte ein offenes Tor. Ein Gast wurde inzwischen aus dem verschlüsselten Speicher zurückgeholt, was die Verschlüsselung und das Werkzeug beweist; für die Flotte beweist es nichts.
Die Zeile außer Haus hat sich zuletzt geändert, die Zeile zur Wiederherstellung nicht. Eine Kopie in einem anderen Gebäude hebt die Zahl an dem Tag, an dem sie geschrieben wird; die Zuversicht hebt sie erst an dem Tag, an dem etwas daraus zurückgeholt wird.
Die Tabelle fragt nach Kopien, Medien und Entfernung und sagt überhaupt nichts über Verschlüsselung — die Zeile, in der dieser Aufbau inzwischen am besten abschnitte, und die, in der die verbleibende Arbeit nicht der Geheimtext ist, sondern die Verwahrung. Der Schlüssel, der diese Archive öffnet, liegt im Geheimnis-Tresor der Flotte selbst. Eine Kopie auf Papier, außerhalb der Flotte, fehlt: Ein Schlüssel, der nur in dem liegt, was er aufschließt, ist noch keiner, den man hat.
Was geplant ist
- Verwahrung für den Archiv-Schlüssel, außerhalb der Flotte und auf Papier. NAS und Cluster gemeinsam zu verlieren, mit dem Schlüssel nur im Tresor, ließe jedes Archiv unlesbar zurück — genau der Ausfall, den die Verschlüsselung überlebbar machen sollte, nur von der anderen Seite.
- Der verbleibende Klartext. Jeden Backup-Speicher dazu zu bringen, nur noch Geheimtext zu halten, ist weiterhin die größte offene Backup-Arbeit; die Gast-Archive sind fertig, andere Speicher nicht.
- Die Wiederherstellungsübung selbst. Snapshot, Export, Löschen, Wiederherstellen, dann Zähl- und Wertprüfungen, gefahren von einem Pfad, der nicht vom NAS abhängt — denn die Übung muss an dem Tag funktionieren, an dem das NAS das Opfer ist.
- Eine Kopie außer Haus des Tresor-Exports mit definiertem Auffrischungspunkt. Der Export-Job läuft; ihn außer Haus zu bringen ist eine menschliche Handlung, und eine menschliche Handlung ohne festgehaltenes Datum zählt als unbewiesen — und ob der Job außer Haus auf dem NAS ihn längst mitträgt, gehört zu dem, was nicht festgestellt ist.
Nichts davon wartet auf Hardware: Was der Liste fehlt, sind ausgeführte Handlungen und festgehaltene Zeitpunkte.
Job-Deklarationen, Monitoring und Plan geprüft gegen das Hub-Repository, die Proxmox-API und die Backup-Alter-Metrik am 2026-09-08; der Archivspeicher, seine Aufbewahrung und sein Verifikationsstand am selben Tag aus dem Cluster gelesen. Die beiden Backup-Jobs, die auf dem NAS selbst laufen — die Replikation außer Haus und das Backup der Arbeitsstation —, sind so, wie der Betreiber sie am 2026-09-09 angegeben hat; sie sind in der Oberfläche des NAS konfiguriert und wurden nicht aus dem Repository gelesen, und wie weit der Job außer Haus reicht, ist nicht festgestellt. Geplante Punkte sind als geplant markiert.