Einen Ausfall im Homelab bemerkt man im Haushalt oft schneller als das Monitoring die erste Warnung verschickt. Damit ich bei einer Störung sofort weiß, welche Reihenfolge zählt, habe ich für sieben im Alltag spürbare Dienste aufgeschrieben, was meine aktuelle Sicherung und Replikation im Ernstfall hergeben: wie lange ein Dienst nach einem Ausfall fehlt (RTO, Recovery Time Objective) und wie viel Datenverlust maximal entsteht (RPO, Recovery Point Objective). Zu jedem Dienst gehört außerdem ein Satz, der festhält, was die Familie während der Unterbrechung konkret merkt.
Drei Sicherungswege bestimmen die echten Zeiten
Wenn du RTO und RPO rückwärts aus dem vorhandenen Aufbau ableitest, ersparst du dir Wunschwerte auf dem Papier, die im Störungsfall ohnehin reißen. In meinem Cluster laufen derzeit drei regelmäßige Mechanismen, die jede Wiederherstellzeit begrenzen:
- ZFS-Replikation zwischen den Proxmox-Knoten im Takt von 15 bis 30 Minuten für wichtige Gäste, deren virtuelle Platten auf einem ZFS-Pool liegen.
- Eine nächtliche Komplettsicherung über einen zentralen Proxmox-Job, der sämtliche virtuellen Maschinen und Container dedupliziert in den Proxmox Backup Server (PBS) schreibt.
- Ein tägliches Konfigurations-Backup auf dem Admin-Container, das zusätzlich die System- und Clusterkonfiguration der Knoten, die Einstellungen der Firewall, eine Sicherung der Monitoring-Instanz und die Konfiguration von Home Assistant einsammelt.
Einen automatischen Anlauf der ZFS-Replikate über Proxmox High Availability habe ich bewusst nicht eingerichtet. Fällt ein Knoten aus, prüfe ich die Meldung aus dem Monitoring und starte den betroffenen Gast von Hand auf dem Zielknoten. Alle RTO-Zahlen gelten deshalb nur tagsüber, wenn jemand erreichbar ist.
Die sieben Dienste im Überblick
Die folgende Tabelle zeigt den dokumentierten Ist-Schutz je Dienst. Die vier Stufen (niedrig, mittel, hoch, kritisch) orientieren sich an meinem internen Dienstregister. Auf eine prozentuale Verfügbarkeit wie 99,5 Prozent habe ich verzichtet; falls ich sie brauche, wertet das Monitoring die tatsächlichen Laufzeiten aus.
| Dienst | Stufe | Ist-Schutz | RTO (Ist) | RPO (Ist) | Was die Familie merkt |
|---|---|---|---|---|---|
| Internet und Firewall (OPNsense) | kritisch | ZFS-Replik alle 15 min auf einen zweiten Knoten, tägliches Konfigurations-Backup | 30–60 min (Handstart, gemessen 7–42 min) | 15 min | Kein Internet und kein VPN; das WLAN bleibt verbunden, leitet aber keinen Verkehr nach außen |
| DNS und Verzeichnisdienst (AdGuard Home, Domänencontroller) | kritisch | Je zwei Instanzen auf getrennten Knoten, Nachtsicherung im PBS und Systemsicherung | sofort (zweite Instanz antwortet weiter) | 0 min | Fällt ein einzelner Knoten aus, merkt niemand etwas; Namensauflösung und Anmeldung laufen weiter |
| Smart Home (Home Assistant) | hoch | ZFS-Replik alle 30 min, Nachtsicherung im PBS, tägliches Konfigurations-Backup | 1 h aus der Replik; 2–4 h aus der Nachtsicherung | 30 min (Replik); 24 h (Sensor-Verlauf aus PBS) | Automationen und Dashboard antworten nicht; klassische Wandtaster schalten das Licht weiter |
| Medienserver (Plex) | niedrig | Nachtsicherung der VM im PBS, tägliche Sicherung der internen Datenbank | 4 h aus der Nachtsicherung | 24 h (Datenbank und Wiedergabestand) | Abspielen über den Medienserver geht nicht; der Wiedergabestand springt höchstens einen Tag zurück |
| Mail (Postfächer extern, lokales Archiv) | mittel | Postfächer beim Anbieter; Archiv-Container holt täglich ab und liegt in der Nachtsicherung | laufender Mailverkehr: sofort; Archiv: 4 h aus dem PBS | 24 h für das lokale Archiv | Keine Einschränkung beim Senden und Empfangen, nur ältere Mails sind im lokalen Archiv nicht durchsuchbar |
| Doku und Intranet (Management-VM) | mittel | ZFS-Replik alle 30 min auf Nachbarknoten, Nachtsicherung im PBS, tägliche Kopie der Doku-Quellen | 1 h aus der Replik; 4 h aus der Nachtsicherung | 30 min | Interne Startseite und Dokumentation laden nicht; der normale Familienalltag bleibt unberührt |
| Backup (Proxmox Backup Server) | hoch | Tägliches Konfigurations-Backup, regelmäßiges Aufräumen und Prüfsummenkontrolle | 24 h (nächster geplanter Lauf nach Neuaufbau) | 24 h | Im Alltag merkt die Familie nichts |
Internet, DNS und Smart Home: warum ich auf Automatik verzichte
Bei der Namensauflösung liegt die Wiederherstellzeit bei null, weil sowohl die beiden AdGuard-Container als auch die beiden Domänencontroller (samt Active Directory, DNS und regelmäßigem DHCP-Abgleich) verteilt auf verschiedenen Knoten laufen. Fällt ein Host weg, beantwortet der verbleibende Server alle Anfragen ohne Unterbrechung.
Anders sieht es bei der OPNsense-Firewall aus. Sie existiert als virtuelle Maschine nur einmal, wird aber alle 15 Minuten per ZFS auf einen zweiten Knoten repliziert. Bei bisherigen Ausfällen oder Wartungen habe ich zwischen 7 und 42 Minuten gebraucht, um die Replik von Hand zu starten. Ich hatte drei Optionen auf dem Tisch: den Handbetrieb mit einem ehrlichen Zielwert von einer Stunde beibehalten, Proxmox HA für ein 15-Minuten-Ziel aktivieren oder eine zweite Firewall-Appliance aufbauen. Ich bleibe beim Handstart. Eine zweite Appliance kostet zusätzliche Hardware und Strom, und bei Proxmox HA müsste ich erst das Quorum-Verhalten mit den verwendeten Netzwerkadaptern sauber absichern, bevor ein falscher Fencing-Entscheid im Fehlerfall noch mehr Dienste abreißt.
Bei Home Assistant hilft im Alltag vor allem die Elektrik in der Wand: Weil herkömmliche Taster physisch weiter schalten, sitzt bei einem Serverausfall niemand im Dunkeln, auch wenn Dashboard, Zeitpläne und Automationen bis zu einer Stunde lang stehen. Muss ich statt der ZFS-Replik auf das nächtliche Abbild aus dem Backup-Server zurückgreifen, dauert es zwei bis vier Stunden, und die Sensorkurven des laufenden Tages fehlen.
Medien und Massendaten: System vom Datenbestand trennen
Nicht jede Datenmenge im Haus passt in denselben Sicherungsweg wie eine schlanke System-VM. Beim Medienserver trenne ich deshalb zwischen der virtuellen Maschine samt ihrer Datenbank und den eigentlichen Mediendateien auf dem Dateiserver. Die VM selbst und die Datenbank mit den Metadaten und dem Wiedergabestatus werden täglich gesichert. Nach einem Ausfall der VM steht der Dienst innerhalb von vier Stunden wieder bereit, und gesehene Folgen springen maximal um einen Tag zurück.
Wer große Medienbestände oder laufende Videoaufzeichnungen im Homelab betreibt, sollte bei der Planung von RTO und RPO genau prüfen, welche Daten bei einem Plattentod wirklich verloren wären. Unersetzliche eigene Dateien und Dokumente brauchen eine echte Zweitkopie auf getrenntem Speicher und außer Haus. Bei großen, wiederbeschaffbaren Mediensammlungen oder kurzlebigen Aufzeichnungen im Ringpuffer lohnt es sich dagegen oft, nur das Basissystem und die Konfiguration im nächtlichen Backup-Job zu halten, statt blind jedes Terabyte doppelt vorzuhalten.
Warum Ist-Werte ehrlicher sind als Wunschwerte
In vielen Konzepten stehen für RTO und RPO ehrgeizige Zielwerte, die jemand aus einer Vorlage abgeschrieben hat. Im Homelab bringt dir eine Tabelle mit Wunschwerten nichts, wenn die eigene Infrastruktur sie technisch oder zeitlich gar nicht einlösen kann. Ehrliche Ist-Werte zwingen dazu, drei Dinge nüchtern festzuhalten:
- Nachtausfall heißt nächster Morgen: Ohne Bereitschaftsdienst und ohne automatisches Failover zählt abends ab 22 Uhr keine Minutenangabe mehr. Fällt nachts um drei ein Knoten aus, beginnt die Wiederherstellung erst nach dem Aufstehen.
- Gemeinsame Ausfallpunkte prüfen: Eine RTO-Angabe von vier Stunden aus dem Backup-Server stimmt nur, wenn das Backup-Ziel nicht auf demselben Host oder derselben Platte liegt wie die ausgefallenen Gäste. Erst eine räumlich getrennte Zweitkopie schützt davor, dass Produktivdienst und Sicherung gleichzeitig verschwinden.
- Nur gemessene Restores zählen: Eine Sicherung, die im Bericht grün leuchtet, belegt noch keine Wiederherstellzeit. Wie lange ein Restore inklusive Nacharbeiten dauert, weißt du erst, wenn du die Maschine mit laufender Stoppuhr in eine isolierte Testumgebung zurückgespielt hast.
In meinem Backup-Plan sind deshalb feste Prüfintervalle vorgesehen: vierteljährlich ein Test-Restore für normale Gäste aus dem Proxmox Backup Server sowie halbjährlich ein Probelauf für Verzeichnisdienst und Firewall-Konfiguration. Erst die Zeiten, die bei diesen Übungen auf der Uhr stehen, gehören als zugesagte Werte in die Dokumentation.
Schreibe einen Kommentar