Backups: drei Kopien, ein Wiederherstellungstest fehlt
Dreizehn Tage lang lief ein Backup nicht, bevor es jemand bemerkte. Heute wird neben der Lesbarkeit auch das Alter der Kopien geprüft. Verschlüsselte Archive liegen auf dem dritten Knoten, eine weitere Kopie auf dem NAS. Ein Wiederherstellungstest über alle Gäste und ein Archivschlüssel außerhalb des Clusters fehlen noch.
Die Regel, die jeder zitiert, ist 3-2-1: drei Kopien der Daten, auf zwei Arten von Medien, eine davon woanders. Jede Zahl deckt eine andere Art ab, die Daten zu verlieren — die Kopie, die beschädigt wird, die Plattencharge, die auf einmal ausfällt, das Gebäude, das brennt.
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 den anderen Gästen läuft, sie dedupliziert, je Gast die letzten fünf behält und seinen Bestand nach eigenem Zeitplan erneut liest und gegen Prüfsummen prüft — womit „die Kopie existiert“ und „die Kopie ist lesbar“ nicht mehr dieselbe Aussage sind. Seit dem 14. September landen die Bytes auf dem HDD-Speicher des dritten Knotens, einem verschlüsselten Pool aus fünf Platten, und nicht mehr auf dem NAS. Das NAS zieht jeden Morgen eine zweite Kopie vom Backup-Server. Die Archive werden auf dem Knoten verschlüsselt, bevor sie ihn verlassen: Das NAS hält Archive, die es nicht lesen kann.
Der Backup-Server ist der einzige Gast, der diesen Weg 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 bewusst ganz außerhalb des nächtlichen Laufs. Sie bleibt draußen, bis ihr Umgang mit Zugangsdaten dem der übrigen Systeme entspricht, denn die Regel hier lautet, dass kein Backup-Speicher Zugangsdaten 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 letzten Nächte, zuzüglich Puffer — nicht so breit wie eine gute Nacht. Jeder Job läuft im Snapshot-Modus, auf Speicher, der Snapshots unterstützt — das ist die Lehre aus einem Fehler: Ein Gast wurde ab dem Tag, an dem ihn die HA-Schicht des Clusters übernahm, stillschweigend nicht mehr gesichert, während sein Nachbar im selben Job weiter gesichert wurde. Zwei der fünf sind an einen Knoten gebunden und drei nicht, und auch das ist eine Lehre: Ein ungebundener 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 an den Sollzustand angeglichen. Die von der Oberfläche erzeugten Job-IDs werden dabei unverändert übernommen, damit kein Gast je doppelt gesichert wird. Trägt der Cluster einen Job, den Git nicht kennt, bricht der Deploy mit einem Fehler ab, 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, die nicht auf der Maschine selbst liegen, entschlüsselt und isoliert gestartet. Es ist zugleich die Hälfte eines Wiederaufbaus, die Git nicht liefern kann: Der eigene Deploy-Weg der Zentrale liefert die Konfiguration aus Git, dieses Backup enthält alles, was dieser Weg nie sieht.
Der Tresor für die Zugangsdaten schreibt jede Nacht einen Snapshot auf das NAS, im selben ständig aktiven Zeitplan, der auch den Soll-Ist-Vergleich ausfü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 an den Sollzustand angeglichen — beide sind in der Oberfläche des NAS von Hand eingerichtet; damit gilt für sie dasselbe Risiko wie für einen Backup-Zeitplan, der nur in einer GUI existiert. Was der Job außer Haus abdeckt, steht hier nicht fest: 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
Zwischen 2026-07-13 und 2026-07-26 lief das nächtliche Backup nicht, und nichts meldete es. Proxmox schickt bei Fehlschlag eine Mail, aber ein Job, der nie startet, schlägt nicht fehl. Ein gesunder Cluster und einer ohne Backups sahen auf jedem Dashboard identisch aus.
Deshalb veröffentlicht jetzt jeder Knoten das Alter des neuesten Archivs pro Gast als Metrik, abgefragt über die Proxmox-API für denselben gemeinsamen Speicher. Ein Gast ganz ohne Archiv wird als unendlich alt veröffentlicht — „nie gesichert“ löst denselben Alarm aus wie „veraltet“, was bedeutet, dass ein neuer Gast Alarm auslöst, bis der Lauf der nächsten Nacht durch ist. Das ist Absicht; ein ungesicherter Gast ist genau der Alarmfall. Der Collector weigert sich, eine Teildatei zu schreiben: Wirft die API einen Fehler, bleibt die letzte Datei unverändert stehen, und nach einer Stunde ohne Aktualisierung schlägt ein Alarm an, 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.
Kopien und Wiederherstellungstests
| 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 HDD-Speicher des dritten Knotens mit seiner zweiten Kopie 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, die Festplatten im dritten Knoten 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 getestete Wiederherstellung | Teilweise — der Tresor, die Smart-Home-Zentrale und ein Gast, der aus dem verschlüsselten Speicher zurückgeholt wurde; der Wiederherstellungstest über alle Gäste steht noch aus |
Was geplant ist
- Verwahrung des Archivschlüssels, außerhalb des Clusters und auf Papier. Gehen NAS und Cluster gemeinsam verloren und liegt der Schlüssel nur im Tresor, ist kein Archiv mehr lesbar.
- Der verbleibende Klartext. Die Gast-Archive sind verschlüsselt; andere Backup-Speicher müssen noch verschlüsselt werden.
- Der Wiederherstellungstest selbst. Snapshot, Export, Löschen, Wiederherstellen, dann Zähl- und Wertprüfungen, ausgeführt über einen Weg, der nicht vom NAS abhängt — denn der Test muss an dem Tag funktionieren, an dem das NAS ausgefallen ist.
- Eine Kopie des Tresor-Exports außer Haus, mit festgelegtem Aktualisierungszeitpunkt. Der Export-Job läuft. Ob die Replikation des NAS außer Haus diesen Export einschließt, wurde noch nicht geprüft.
Zeitpläne, Aufbewahrung und Monitoring wurden am 8. September 2026 anhand der Konfiguration, der Proxmox-API und der Metrik für das Backup-Alter geprüft. Die NAS-Jobs für Replikation außer Haus und das Backup der Arbeitsstation beschrieb der Betreiber am 9. September; ihr vollständiger Umfang wurde nicht geprüft. Der Speicherumzug vom 14. September wurde später ergänzt und ist vom früheren Prüfdatum nicht abgedeckt.