Backups im Homelab haben oft ein typisches Schicksal: Irgendwann wird ein Job für die zwei wichtigsten VMs angelegt, später kommen neue Gäste dazu, und niemand nimmt sie in den Job auf. Ob sich die Sicherung zurückspielen lässt, hat nie jemand ausprobiert. Ich wollte es anders machen und sichere meinen Proxmox-Cluster mit drei Knoten über den Proxmox Backup Server (PBS): ein Job für alle Gäste, bewusste Ausnahmen, ein Test-Restore, eine Übersicht mit Ampel. Die größte Lücke ist die Kopie außer Haus, und die gibt es bisher nicht.
Der Aufbau
Der PBS läuft bei mir als LXC-Container auf Knoten 3 mit 4 vCPU und 4 GB RAM. Anfangs hatte er nur 2 GB. Das reichte, solange er nichts zu tun hatte, aber Garbage Collection und Verify brauchen mit einem gefüllten Datastore mehr Speicher. Die Systemplatte des Containers ist 15 GB groß, davon sind nicht einmal 3 GB belegt.
Die Daten liegen auf einer 3-TB-Festplatte, die per SATA an Knoten 3 hängt und als Mountpoint in den Container gereicht wird. Diesen Mountpoint habe ich mit backup=0 markiert, sonst würde Proxmox beim Sichern des Containers versuchen, den gesamten Datastore mitzusichern. In der /etc/fstab des Hosts ist die Platte per UUID und mit nofail eingetragen, damit der Knoten auch dann startet, wenn die Platte einmal fehlt.
# Mountpoint in den Container, ohne ihn selbst zu sichern
pct set <CTID> -mp0 /mnt/pbs-platte,mp=/mnt/datastore,backup=0
Ein Konto, das sichern, aber nicht löschen darf
Proxmox VE meldet sich nicht mit dem Root-Konto am PBS an, sondern mit einem eigenen Benutzer und API-Token. Das Token hat die Rolle DatastoreBackup, und zwar nur auf diesem einen Datastore. Damit darf es Sicherungen schreiben, aber keine löschen und kein Prune auslösen. Wird ein Proxmox-Knoten kompromittiert, kann ein Angreifer mit diesem Token die vorhandenen Sicherungen nicht einfach entfernen. Das Token-Geheimnis liegt nur auf den Proxmox-Hosts mit restriktiven Rechten, nicht in der Doku und nicht in einem Repository.
In Proxmox VE ist der PBS als Speicher im ganzen Cluster eingetragen, mit dem Fingerabdruck seines Zertifikats. Tauscht man später das Zertifikat des PBS aus, etwa gegen eines der eigenen CA, schlagen die Backups fehl, bis der Speichereintrag angepasst ist. Nach dem Tausch starte ich deshalb sofort einen Backup-Job von Hand, statt bis zur Nacht zu warten.
Ein Job für alle Gäste
Statt einzelne VMs auszuwählen, habe ich genau einen Backup-Job angelegt: täglich um 02:15 Uhr im Snapshot-Modus, für alle Gäste außer einer kurzen Ausnahmeliste. Ein Job mit Auswahl vergisst jeden neuen Gast, ein Job mit Ausschlüssen nimmt ihn automatisch mit. Nach ein paar Tagen habe ich geprüft, ob alle Gäste, die nach dem Anlegen des Jobs dazugekommen waren, Sicherungen hatten. Sie hatten.
Zwei Gäste sind ausgenommen, jeweils mit Begründung; anfangs waren es drei. Der PBS selbst ist nicht im Job: Ein Backup-Server, der sich in sich selbst sichert, hilft im Ernstfall nicht. Seine Konfiguration (Benutzer, Token, Jobs) steckt in einer separaten täglichen Konfigurationssicherung und ist nur wenige KB groß. Der zweite Ausgenommene ist ein gestoppter Container für ein späteres Projekt.
Dazu kommt eine Ausnahme innerhalb eines Gastes: Beim Fileserver sichert der Job nur die System- und Datenplatte der VM. Die durchgereichten großen Medienplatten sind mit backup=0 markiert und fehlen bewusst, sie würden den Datastore sprengen und brauchen eine eigene Lösung. Das gehört in die Doku. Wer später „alle Gäste werden gesichert“ liest, darf nicht annehmen, dass damit auch die Mediensammlung gemeint ist.
Aufbewahrung, Garbage Collection, Verify
| Aufgabe | Zeitpunkt | Einstellung |
|---|---|---|
| Backup aller Gäste | täglich 02:15 | Snapshot-Modus |
| Prune | täglich 05:30 | 7 täglich, 4 wöchentlich, 6 monatlich |
| Garbage Collection | sonntags 06:00 | gibt Platz frei |
| Verify | monatlich am 1. um 04:00 | prüft die Prüfsummen aller Sicherungen |
Prune entfernt nur die Verweise auf alte Sicherungen, den Platz gibt erst die Garbage Collection frei. Deshalb wird der Datastore nach einem Prune nicht sofort leerer. Verify liest alle Chunks und prüft ihre Prüfsummen. Bei einer einzelnen, älteren Festplatte will ich wissen, ob sie schleichend Daten verliert, bevor ich eine Sicherung brauche. Der erste Verify-Lauf steht für den 1. November an.
Dank der Deduplizierung ist der Platzbedarf überschaubar. Anfang Oktober waren mit 16 gesicherten Gästen rund 16 Prozent der Platte belegt. Inzwischen sind es 22 Gäste mit je sechs bis acht Versionen und 36 Prozent (1,07 von 2,95 TB).
Der Test-Restore
Eine Sicherung, die nie zurückgespielt wurde, ist eine Hoffnung. Ich habe deshalb eine unkritische VM aus dem PBS als isolierte Test-VM wiederhergestellt. Das hat funktioniert, und ich will es vierteljährlich wiederholen. Das genaue Datum dieses ersten Tests habe ich nicht dokumentiert, das war ein Fehler: Ohne Datum, Gast und Ergebnis weiß ich beim nächsten Mal nicht, wie lange der letzte Test her ist.
Beim Testen achte ich auf drei Dinge. Die wiederhergestellte VM bekommt eine neue ID. Sie startet ohne Netzwerk oder in einem abgeschotteten Netz, damit sie nicht mit dem Original kollidiert. Und ich prüfe nicht nur, ob sie bootet, sondern ob die Anwendung darin läuft und die Daten stimmen.
Was der PBS nicht abdeckt
Ein Image-Backup aller Gäste ist die Basis, aber nicht alles. Daneben laufen weitere Sicherungen.
Die Konfigurationssicherung läuft täglich per Skript mit 14 Tagen Aufbewahrung: Auszüge aus /etc der Proxmox-Knoten, die Cluster-Konfiguration aus /etc/pve, die Konfigurationsdatei der Firewall, ein Backup der Monitoring-Instanz, die Konfiguration von Home Assistant ohne Datenbank und die des PBS. Diese Dateien sind klein und beim Wiederaufbau oft schneller als ein ganzes Image.
Für die Domänencontroller sichert Windows Server Backup zusätzlich zum Image täglich den Systemstatus jedes DCs auf eine Freigabe. Ohne das Kennwort für den Verzeichnisdienst-Wiederherstellungsmodus (DSRM) lässt sich ein Systemstatus nicht zurückspielen. Das habe ich am 15. Oktober auf beiden DCs neu gesetzt und im Passwortmanager abgelegt. Die ausgedruckte Offline-Kopie fehlt noch. Außerdem meldet die Sicherung des einen DCs seit dem 13. Oktober einen Fehler, und ein Test-Restore des Systemstatus hat noch nie stattgefunden.
Anwendungsdaten mit eigenem Bedarf, etwa die Datenbank eines Medienservers oder die Daten auf einem Steuer-PC, sind über das Image der VM gesichert. Eine separate oder verschlüsselte Zusatzkopie fehlt noch.
Die Lücke: alles an einem Ort
Der Datastore liegt auf einer einzelnen Platte, die fast fünf Jahre alt ist. Die SMART-Werte sind sauber, aber Redundanz gibt es nicht. Und die Platte hängt am selben Knoten wie der PBS und wie viele der gesicherten Gäste. Das schützt mich vor Fehlern in einer VM, vor einem verpfuschten Update und vor versehentlich gelöschten Dateien. Es schützt mich nicht vor dem Ausfall von Knoten 3, vor dem Ausfall dieser Platte und erst recht nicht vor Brand oder Diebstahl. Fällt die Platte aus, sind alle Gäste-Backups weg.
Der Plan hat zwei Schritte. Erstens eine zweite Kopie des Datastores auf einer anderen Platte oder, besser, ein PBS auf einer zweiten Maschine, per Sync-Job; dafür ist ein eigener Backup-Knoten vorgesehen. Zweitens eine verschlüsselte Kopie außer Haus bei einem Online-Speicher, geplant mit restic über rclone. Dafür brauche ich ein Konto dort und ein Kennwort, das außerhalb der Infrastruktur liegt. Liegt es nur auf einem Server im Homelab, ist es nach einem Totalverlust zusammen mit allem anderen weg.
Mein Datastore ist außerdem nicht verschlüsselt. Solange er im Haus liegt, ist das vertretbar. Für die Kopie außer Haus muss die Verschlüsselung auf meiner Seite passieren, bevor die Daten das Haus verlassen.
Die Ampel
Damit ich nicht jeden Morgen in den PBS schauen muss, erzeugt ein Skript täglich eine Backup-Übersicht mit Ampel. Die Regeln:
- Grün: Die letzte Sicherung ist jünger als 36 Stunden.
- Gelb: Sie ist älter als 36 Stunden, nur teilweise vorhanden, oder eine Zusatzkopie fehlt.
- Rot: Sie ist älter als 72 Stunden, fehlgeschlagen, nicht eingerichtet oder noch nie getestet.
- Weiß: bewusst nicht gesichert, mit Begründung.
„Noch nie getestet“ gehört bewusst zu Rot. Eine Sicherung, die täglich läuft, deren Wiederherstellung aber nie geprüft wurde, ist für mich nicht in Ordnung. Das betrifft zum Beispiel den Systemstatus der Domänencontroller und die Firewall-Konfiguration. Zusätzlich meldet ein Check im Monitoring, wenn eine Sicherung zu alt ist. Bei der letzten Übersicht am 20. Oktober standen 40 Einträge auf Grün, 7 auf Gelb, 8 auf Rot und 2 auf Weiß.
Schreibe einen Kommentar