Die Illusion der Sicherheit
Jeder, der einen Homeserver oder ein Homelab betreibt, kennt die Redensart:
"Backups sind wie Zahnarztbesuche – man weiß, man sollte hingehen, aber man schiebt es gerne auf."
Die Folge sind oft Konstrukte, die man im Alltag zwar als "Backup" bezeichnet, die aber im Ernstfall schneller zusammenbrechen als ein Kartenhaus. Ein externer USB-Stick, der irgendwann mal angeschlossen wird, ein ungetesteter Cronjob, der seit Monaten im Hintergrund fehlschlägt, oder eine Nextcloud-Instanz, von der man hofft, dass sie sich schon irgendwie selbst sichert. Wenn dann aber ein Blitz einschlägt, die Festplatte ihren Geist aufgibt oder Ransomware das gesamte Netzwerk verschlüsselt, offenbart sich die bittere Wahrheit: Halbgare Backups sind keine Backups.
Genau an diesem Punkt setzt der aktuelle Ansatz des c't-Kanals an. Die Botschaft ist klar und radikal: Ein funktionierendes Backup-System muss so automatisiert und autark sein, dass es funktioniert, ohne dass man daran denkt. Ob man im Bett liegt oder im Urlaub ist – die Datensicherung muss laufen.
Der Unterschied zwischen "Mist, alles weg" und "kleines Problem"
Die psychologische Hürde beim Thema Backup ist die wahrgenommene Langeweile. Es ist ein Pflichtthema, bei dem der unmittelbare Nutzen fehlt – bis zur Katastrophe. Doch die Perspektive lässt sich umdrehen: Ein durchdachtes Backup-Konzept ist der Unterschied zwischen einem existenziellen Verlust ("Mist, alles weg") und einer banalen administrativen Aufgabe ("Problem erkannt, in 20 Minuten ist alles wieder da").
Um diesen Zustand zu erreichen, reicht es nicht, einfach Dateien von A nach B zu kopieren. Ein robustes System muss mehrere Bedingungen erfüllen:
- Vollständigkeit: Nextcloud, Fotos, Dokumente und vor allem die Konfigurationen der Docker Container müssen erfasst sein. Wer nur die Daten sichert, aber die Compose-Files und Volumes vergisst, muss im Ernstfall stundenlang Systeme neu aufsetzen.
- Automatisierung: Der menschliche Faktor muss eliminiert werden. Kein manueller Trigger, kein Knopfdruck. Das System muss im Hintergrund verlässlich arbeiten.
- Resilienz: Das Backup muss physisch und logisch vom Produktivsystem getrennt sein. Ein Backup auf demselben Laufwerk schützt nicht vor Ransomware oder Hardware-Ausfällen.
Vier Tools, drei Schritte – Der Architektur-Ansatz
Das im Video vorgestellte Konzept reduziert die Komplexität auf eine klare Struktur: vier Tools, drei Schritte. Warum ist diese Reduktion so wichtig? Weil komplexe Systeme fehleranfällig sind und seltener getestet werden. Wenn das Backup-Setup aus einem undurchsichtigen Geflecht von Skripten besteht, zögert man nicht nur die Einrichtung hinaus, sondern auch die dringend nötigen Restore-Tests.
Obwohl die konkrete Tool-Auswahl im Quellmaterial erst im weiteren Verlauf des Videos detailliert wird (klassische Kombinationen im Homelab-Bereich sind hier oft BorgBackup, Restic, Rclone oder Duplicati in Kombination mit dedizierten Docker-Backup-Lösungen), ist der architektonische Ansatz universell:
- Schritt 1: Daten konsolidieren. Alle relevanten Daten müssen an einem definierten Ort gesammelt werden. Bei Docker bedeutet das, dass die Volumes und Konfigurationsdateien der Container dynamisch in ein Zwischenverzeichnis exportiert werden.
- Schritt 2: Inkrementell sichern. Die gesammelten Daten werden verschlüsselt und inkrementell an ein Offsite-Ziel übertragen. Hier kommt die 3-2-1-Regel ins Spiel: Mindestens drei Kopien, auf zwei verschiedenen Medien, eine davon Offsite (z.B. in einem Object Storage oder bei einem Backup-Dienstleister).
- Schritt 3: Automatisieren und validieren. Der Prozess wird über Tools wie Cronjobs oder Automatisierungsplattformen (z.B. Ansible) gekoppelt und läuft völlig ohne Zutun ab.
Kritische Einordnung: Warum "keine Benachrichtigung" gefährlich sein kann
Das beschriebene System zeichnet sich durch einen Zustand aus, in dem man sich zurücklehnen kann. Dennoch muss ein erfahrener Admin hier kritisch nachhaken: Der Verzicht auf manuelle Trigger ist absolut korrekt und wichtig. Der Verzicht auf Benachrichtigungen im Fehlerfall ist jedoch ein Risiko.
Ein Backup-System, das im Hintergrund leise arbeitet, ist wunderbar – bis zu dem Tag, an dem es aus irgendeinem Grund (z.B. volles Ziellaufwerk, geänderte API-Keys des Offsite-Speichers) stillschweigend fehlschlägt. Wer keine Monitoring-Lösung (wie z.B. Healthchecks.io oder einfache E-Mail-Alerts bei Fehlschlägen) implementiert, läuft Gefahr, sich in trügerischer Sicherheit zu wiegen. Ein "Set and Forget"-System ist nur dann verlässlich, wenn es bei Ausfällen laut und aufdringlich wird.
Ebenso wird im Quellmaterial der wichtigste Punkt aller Backup-Strategien nur implizit angeschnitten: Der Restore. Ein ungetestetes Backup ist kein Backup. Die Erkenntnis, dass das alte System "halbgar und ungetestet" war, ist der erste Schritt. Die konsequente nächste Pflichtaufgabe muss sein, das neu aufgebaute System regelmäßig einem Disaster Recovery Test zu unterziehen. Nur wenn man beweist, dass sich die Nextcloud aus dem Backup in wenigen Minuten fehlerfrei wiederherstellen lässt, ist das Konzept wirklich abgeschlossen.
Fazit
Die Initiative, das Thema Backup nicht als lästige Pflichtaufgabe, sondern als essenzielle Infrastruktur des Homelabs zu begreifen, ist absolut richtig. Der Ansatz, Komplexität durch klare Tool-Auswahl und Automatisierung zu reduzieren, senkt die Hemmschwelle, das System überhaupt aufzusetzen. Wer heute noch ohne verlässliches Offsite-Backup und ohne Docker-Volume-Sicherung arbeitet, sollte sich das vorgestellte Konzept dringend ansehen und als Blaupause für die eigene Infrastruktur nehmen. Die Investition an einem Wochenende rettet später vielleicht Jahre voller Daten.
Quelle: c't 3003
