Backup-Strategie für Homelabs: 3-2-1 heißt Restore-fähig, nicht nur mehrfach gespeichert

Der häufigste Homelab-Fehler ist nicht das Fehlen von Kopien, sondern das Fehlen eines klaren Wiederherstellungswegs. Genau hier setzen die BSI-Leitfäden an: Datensicherung ist kein beliebiges Ablegen von Dateien, sondern ein organisierter Prozess aus Sichern, Aufbewahren, Prüfen und Wiederherstellen.

Praktisch heißt das: Vor jeder Tool-Wahl musst du drei Fragen beantworten. Welche Daten sind wirklich kritisch? Wie viel Datenverlust ist akzeptabel? Wie schnell musst du im Fehlerfall wieder arbeitsfähig sein? Erst daraus ergeben sich Aufbewahrungsregeln, Backup-Frequenz und Zielsysteme.

Für ein Homelab ist diese Reihenfolge besonders wichtig, weil oft sehr unterschiedliche Daten in einem einzigen System landen: Familienfotos, Konfigurationsdateien, Container-Volumes, Medienbibliotheken und VM-Backups. Sie brauchen nicht alle denselben Schutzpfad, aber sie brauchen alle eine bewusst definierte Wiederherstellungslogik.

Eine belastbare Backup-Strategie beginnt mit Datenklassen und nicht mit Toolnamen. Der operative Gewinn ist einfach: Du sicherst nicht alles gleich, sondern nach Wiederherstellungswert.

Datenklasse	Typische Beispiele	Was daran kritisch ist	Saubere Backup-Folge
unersetzbar	Fotos, private Dokumente, Primärdaten	Verlust ist fachlich kaum oder gar nicht reparierbar	lokales schnelles Ziel plus getrenntes Off-Site- oder Offline-Ziel
wiederherstellbar, aber betriebsrelevant	Container-Volumes, Datenbanken, VM-Daten	Ausfallzeit und Restore-Ablauf sind wichtiger als die reine Dateimenge	häufige Sicherung, dokumentierter Restore und klarer Zielpfad
neu baubar	Konfiguration aus Git, reproduzierbare Installationen	nicht wertlos, aber oft schneller neu erzeugt als vollständig gesichert	schlank sichern oder als Rebuild-Pfad dokumentieren

Einordnung: Diese Datenklassen sind keine BSI-Norm. Sie sind ein belastbares Homelab-Schema, damit 3-2-1 nicht in denselben Sicherungsrhythmus für alles kippt.

Das BSI unterscheidet klassische Sicherungsarten wie Vollsicherung, inkrementelle Sicherung und differenzielle Sicherung. Für Homelabs ist die richtige Wahl keine Theoriesache, sondern eine Frage aus Speicherbedarf, Laufzeitfenster und Restore-Komplexität.

Sicherungsart	Stärke	Grenze	Wann sinnvoll
Vollsicherung	einfachster Restore-Pfad	hoher Speicher- und Zeitbedarf	für kleine, klar begrenzte Datensätze
Inkrementell	sparsam bei Zeit und Speicher	Restore hängt von mehreren Ständen ab	für regelmäßig gesicherte Alltagsdaten
Differentiell	Restore einfacher als bei vielen Inkrementen	wächst mit der Zeit stärker an	wenn du einen Mittelweg aus Platz und Restore-Einfachheit willst

Für viele Homelabs ist die eigentliche Lösung heute ein Mix: Das Backup-Werkzeug verwaltet versionierte Sicherungsstände technisch selbst, während du fachlich vorgibst, wie lange stündliche, tägliche oder monatliche Zustände erhalten bleiben sollen. Genau deshalb ist die Retention-Logik wichtiger als das Schlagwort auf der Kommandozeile.

Die 3-2-1-Regel wird erst dann belastbar, wenn jede Ebene ein anderes Schadensbild adressiert. Ein Snapshot ist kein Off-Site-Backup. Eine USB-Platte ist keine Standorttrennung. Ein Cloud-Ziel ist keine Garantie für schnellen Restore. Die Ebenen ergänzen sich, sie ersetzen sich nicht.

Ebene	Schützt gut gegen	Schützt schlecht gegen	Praktische Rolle
Snapshots / Versionierung	Fehlbedienung, kurzfristige Änderungen	Standortverlust, Totalausfall des Primärsystems	schnellste Rückholung im Alltag
Lokales Backup auf getrenntem Ziel	Primärdefekt, beschädigte Volumes	Brand, Diebstahl, gemeinsamer Schaden am Standort	schneller Restore ohne Internetabhängigkeit
Offline-Kopie	Ransomware, versehentliche Löschketten, Fehlkonfiguration	veraltete Daten, wenn nie rotiert wird	Notfallreserve außerhalb des aktiven Systems
Off-Site-Backup	Standortverlust, längerer Totalausfall	schlechte Restore-Planung, hohe Rückholzeiten	Resilienz gegen lokale Katastrophen

BSI-Empfehlungen gegen Ransomware betonen genau diese Trennung: Sicherungen müssen existieren, geschützt aufbewahrt werden und im Ernstfall wiederherstellbar sein. Für ein Homelab heißt das sehr konkret: mindestens ein Sicherungsziel darf nicht dieselbe Dauerverbindung und denselben Fehlerpfad wie das Primärsystem teilen.

Das BSI stellt Wiederherstellung und geübten Wiederanlauf ausdrücklich ins Zentrum. Für das Homelab wird daraus eine nüchterne Regel: Du brauchst pro Datenklasse eine akzeptierte Verlustgrenze (RPO) und eine akzeptierte Wiederanlaufzeit (RTO). Diese Matrix ist keine offizielle BSI-Vorgabe, sondern eine belastbare Betriebsinferenz aus der Restore-Pflicht.

Daten- oder Dienstklasse	Typische RPO-Frage	Typische RTO-Frage	Praktische Folge
unersetzbare Primärdaten	Darf überhaupt mehr als ein Arbeitstag fehlen?	Wie schnell musst du sie wieder lesen können?	häufige Sicherung plus getrenntes Off-Site- oder Offline-Ziel
betriebsrelevante App- und VM-Daten	Wie viel Zustandsverlust ist vor Neustart noch akzeptabel?	Wie schnell muss der Dienst wieder sauber starten?	Restore-Prozedur und Startreihenfolge müssen dokumentiert sein
reproduzierbare Konfiguration	Ist Verlust fachlich tolerierbar, wenn Git oder IaC aktuell sind?	Ist Rebuild schneller als Restore?	manche Pfade können bewusst auf Rebuild statt Vollbackup gesetzt werden

Diese Denkweise verhindert zwei Extreme: alles gleich häufig zu sichern oder bei wichtigen Daten nur auf spontane Exporte zu vertrauen. Erst die akzeptierten Grenzen machen aus "wir haben Backups" eine prüfbare Betriebszusage.

Bei den Zielsystemen gibt es nicht die eine richtige Antwort, sondern nur unterschiedliche Betriebsmodelle. Gute Planung verbindet mindestens ein schnelles Ziel mit mindestens einem getrennten Ziel.

Ziel	Stärke	Grenze	Wann sinnvoll
externe HDD/SSD	einfach, schnell, günstig	nur wirksam, wenn regelmäßig getrennt wird	als rotierende lokale oder Offline-Kopie
Hetzner Storage Box	klassisches Remote-Ziel für dateibasierte Backups	kein Ersatz für lokale Restore-Geschwindigkeit	wenn du ein separates Off-Site-Ziel ohne eigenen zweiten Standort willst
Backblaze B2	nutzungsabhängiger Objektspeicher laut offizieller Preisübersicht	Rückholpfad, Zeit und Kosten müssen vorher mitgedacht werden	für verschlüsselte Off-Site-Backups mit Restic oder S3-kompatiblen Workflows

Die Planung wird dann robust, wenn du jeden Pfad klar benennst: Welches Ziel ist für schnelle Wiederherstellung gedacht? Welches Ziel deckt Standortverlust ab? Welches Ziel bleibt im Ransomware-Fall unangetastet? Sobald jede Rolle einen eigenen Zweck hat, wird aus 3-2-1 ein echtes Sicherheitsmodell statt einer Merkhilfe.

Restic dokumentiert den Repository-Pfad und den Passwortpfad ausdrücklich als eigene Betriebsparameter: RESTIC_REPOSITORY oder --repository-file für das Ziel sowie --password-file, RESTIC_PASSWORD_FILE oder --password-command für das Passwort. Genau daraus folgt eine häufig übersehene Regel: Der Zugangspfad gehört zur Sicherungsstrategie selbst.

Bestandteil	Warum er restore-kritisch ist	Saubere Praxis
Repository-Ort	ohne klaren Zielpfad ist das Backup nicht reproduzierbar auffindbar	Zielsystem, Zugangspfad und Backend dokumentieren
Passwort- oder Schlüsselpfad	Verschlüsselung schützt nur, wenn du im Ernstfall noch entschlüsseln kannst	Passwort- und Recovery-Pfad getrennt vom Primärsystem dokumentieren
Automationskonto	ein verlorener oder überprivilegierter Zugang kann sowohl Restore als auch Sicherheit brechen	klare Trennung zwischen Backup-Job und Adminzugang

Praktisch heißt das: Ein verschlüsseltes Repository ohne dokumentierten Entschlüsselungsweg ist im Ernstfall kein Backup, sondern nur verschlüsselter Speicher.

BorgBackup und Restic sind beide seriöse Werkzeuge, weil sie Verschlüsselung, Versionierung und Prüfroutinen ernst nehmen. Der Unterschied liegt weniger in der Marketingbotschaft als im Betriebsmodell.

• Borg passt gut, wenn du klassische dateibasierte Ziele planst und Deduplizierung, Prüfläufe und bewusst gesteuerte Prune-/Compact-Abläufe magst.
• Restic passt gut, wenn du Remote-Ziele und besonders Objektspeicher sauber einbinden willst und ein flexibles Repository-Modell suchst.
• Beide verlangen Disziplin: Prüfen, Retention anwenden, Restore üben und Zugangsdaten sicher verwalten.

Der professionelle Unterschied entsteht nicht durch das Logo, sondern durch den Pflegeprozess. Ein vergessenes Prune, ein nie getestetes Repository-Passwort oder ein nie geübter Restore macht auch ein gutes Tool betrieblich wertlos.

Die offizielle Dokumentation beider Werkzeuge ist hier deutlich präziser als viele Tutorials. Borg trennt prune und compact: prune markiert Archive für die Löschung, Platz wird erst durch compact wieder freigegeben. Restic trennt ebenfalls Richtlinie und Platzfreigabe: forget entfernt Snapshots gemäß Policy, prune räumt die nicht mehr referenzierten Daten auf; restic check ist danach ausdrücklich sinnvoll.

Werkzeug	Offiziell belegbare Betriebslogik	Was das im Homelab bedeutet
Borg	prune wirkt auf Retention, compact gibt Platz frei; Dry-Run wird ausdrücklich empfohlen	Retention nie blind fahren und Platzfreigabe separat einplanen
Restic	forget plus prune, dazu Dry-Run und check nach dem Aufräumen	Remote-Repositories brauchen Wartungsfenster, nicht nur Backup-Jobs

Das ist mehr als Kosmetik. Ohne diese Pflege entstehen entweder unkontrolliert wachsende Repositories oder scheinbar erfolgreiche Backups, deren Aufbewahrungslogik nie wirklich getestet wurde.

Viele Homelabs sichern regelmäßig, aber pflegen die Sicherungsstände nicht. Das führt zu zwei Risiken: unkontrolliertes Wachstum und ein trügerisches Sicherheitsgefühl. Deshalb braucht jedes Setup einen festen Rhythmus für Aufbewahrungsregeln, Integritätsprüfung und Speicherpflege.

1. Retention definieren: zum Beispiel kurze Intervalle für aktuelle Daten, längere Intervalle für Monats- und Jahresstände.
2. Integrität prüfen: Borg und Restic dokumentieren eigene Check-Routinen; diese gehören in deinen Wartungsplan.
3. Speicherverbrauch kontrollieren: Aufbewahrungsregeln erst anwenden, dann beobachten, ob das Zielsystem zu deinem Wachstumspfad passt.
4. Passwort- und Schlüsselpfad absichern: Ein verschlüsseltes Backup ohne sicher dokumentierten Entschlüsselungsweg ist im Ernstfall kein Backup.

Der richtige Blick ist also nicht nur "Läuft der Job?", sondern "Ist das Repository gesund, bleibt die Retention beherrschbar und komme ich im Notfall wirklich wieder an die Daten?".

Hetzners Storage-Box-Dokumentation ist für Homelabs deshalb wertvoll, weil sie die Betriebsgrenze offen benennt: über Port 23 stehen SSH, rsync, BorgBackup und SFTP bereit, aber es gibt keine volle Shell. Genau das ist keine Schwäche, sondern eine wichtige Planungsgrenze. Du kaufst dort keinen allgemeinen Linux-Host, sondern ein klar begrenztes Off-Site-Ziel.

Zieltyp	Offiziell belegbarer Anker	Praktische Folge
Hetzner Storage Box	SSH/rsync/BorgBackup/SFTP über Port 23, keine volle Shell, Restic via SFTP nativ unterstützt	gut für klar geführte Backup-Workflows, aber kein generischer Remote-Server
Backblaze B2	offizielle B2-Preis- und Produktseite als Objektspeicher-Anker	gut für verschlüsseltes Off-Site, wenn Rückholpfad und Folgekosten mitgedacht sind

Gerade diese Protokoll- und Admingrenzen machen die Planung robuster. Ein Off-Site-Ziel ist dann gut gewählt, wenn seine betriebliche Begrenzung zu deiner Strategie passt und nicht nur seine Speichermenge.

Viele Homelabs behandeln Backups als rein logisches Thema. In der Praxis hängen daran aber immer drei Budgets: lokaler Speicher, 24/7-Betrieb des Backup-Pfads und Zeit für den Restore. Erst wenn diese drei Größen zusammenpassen, ist die Strategie freigegeben.

Budget	Was es steuert	Womit du es vorab prüfst
Speicherbudget	wie lange lokale und entfernte Sicherungsstände real vorgehalten werden können	Retention-Regeln gegen die tatsächliche Datenmenge und Zielkapazität prüfen
Betriebsbudget	ob ein lokaler Backup-Host oder ein zweites NAS dauerhaft mitlaufen muss	NAS-Rechner und Stromkosten-Rechner für den 24/7-Pfad
Wiederanlaufbudget	ob Rückholung aus Off-Site, Storage Box oder Objektspeicher ins geforderte Fenster passt	Transfer-Rechner als offene Zeitplanung vor dem echten Restore-Test
Mehrjahresbudget	ob lokaler Zweitpfad, Cloud-Ziel oder Mischmodell wirtschaftlich zusammenpassen	TCO-Rechner für die Gesamtentscheidung statt nur Startkosten

Einordnung: Diese Matrix ergänzt die offiziellen BSI-, Borg-, Restic- und Zielsystemquellen um die betriebliche Sicht. Sie macht deutlich, warum ein theoretisch gutes Backup ohne Speicher-, Strom- oder Zeitfenster in der Praxis trotzdem scheitern kann.

Die glaubwürdigste Sicherungsstrategie ist die, die unter echten Bedingungen geübt wurde. Für ein Homelab reicht oft schon ein kleines, aber ernst gemeintes Runbook:

1. Testobjekt wählen: eine echte Datei, ein Konfigurationsverzeichnis, eine Datenbank oder ein kleines Service-Volume.
2. Quelle festlegen: Snapshot, lokale Sicherung oder Off-Site-Ziel.
3. Restore durchführen: nicht nur auflisten, sondern tatsächlich zurückholen.
4. Ergebnis prüfen: Datei öffnen, Dienst starten, Integrität kontrollieren.
5. Dokumentieren: Dauer, Stolperstellen, Zugangsdaten, notwendige Nacharbeiten.

Nach jeder größeren Änderung am Storage, nach Tool-Wechseln oder nach Umbauten im Homelab sollte dieser Test wiederholt werden. Ein ungeübter Restore ist im Ernstfall meistens langsamer und fehleranfälliger als gedacht.

Ein einzelner Test-Download beweist noch keine Strategie. Sinnvoller ist eine kleine Übungsmatrix, die pro Datenklasse einen anderen Rückholpfad bewusst trainiert.

Übung	Was du damit real prüfst	Warum genau diese Übung wichtig ist
Datei oder Dokument zurückholen	Versionierung, Entschlüsselung und schneller Alltagsrestore funktionieren	das ist der häufigste echte Fehlerfall und darf kein Spezialwissen verlangen
Container- oder Servicezustand zurückholen	Repository, Datenpfad und Startreihenfolge des Dienstes sind vollständig dokumentiert	nur so zeigt sich, ob ein Backup auch einen nutzbaren Dienst erzeugt und nicht nur Dateien
Off-Site-Rückholung antesten	Bandbreite, Zugangspfad und Zeitfenster des entfernten Ziels sind realistisch	der Transfer-Rechner wird hier mit einem echten Restore gegenvalidiert
Entschlüsselungs- und Zugangspfad prüfen	Passwort- oder Schlüsselweg funktioniert auch außerhalb des Primärhosts	ein verschlüsseltes Repository ohne Wiederzugriff ist nur scheinbar sicher

Diese Matrix verhindert den typischen Schönwettertest. Statt "irgendetwas einmal wiederhergestellt" bekommst du pro Datenklasse einen belastbaren Nachweis darüber, dass der richtige Pfad im Ernstfall wirklich funktioniert.

Ein Job gilt nicht deshalb als erfolgreich, weil er ohne Fehlermeldung endete. Ein Restore-Test ist erst dann bestanden, wenn das fachliche Ziel erreicht wurde. Für Homelabs heißt das:

1. Die richtige Datenversion wurde gefunden: nicht nur irgendein Snapshot, sondern der erwartete Sicherungsstand.
2. Die Entschlüsselung funktioniert vollständig: Repository, Passwort- oder Schlüsselpfad und Zielzugang sind reproduzierbar nutzbar.
3. Die Daten sind wirklich verwendbar: Dateien lassen sich öffnen, Datenbanken starten, Konfigurationen werden akzeptiert, Dienste booten.
4. Die Dauer wurde gemessen: ohne gemessene Restore-Zeit gibt es kein belastbares RTO.
5. Der Weg ist dokumentiert: Wer macht was, mit welchem Zugang und in welcher Reihenfolge?

Gerade der letzte Punkt macht den Unterschied zwischen einem persönlichen Notizzettel und einem echten Runbook. Wenn ein Restore nur mit Erinnerung, Spezialwissen oder improvisierten Passwörtern funktioniert, ist die Strategie noch nicht freigegeben. Fuer die Vorplanung grosser Rueckholpfade kannst du den Transfer-Rechner als offene Zeitabschaetzung nutzen, bevor du den realen Restore gegenmisst.

Änderung	Warum der alte Restore-Nachweis nicht mehr reicht
neues Zielsystem oder neuer Anbieter	Protokollpfad, Bandbreite, Credentials und Rückholzeit ändern sich sofort
Wechsel von Repository-, Passwort- oder Schlüsselpfad	genau der Entschlüsselungsweg ist Teil der Wiederherstellung, nicht bloß der Automation
Umbau an Storage, RAID oder Volumes	der technische Datenpfad und die Reihenfolge beim Restore ändern sich
neue Kritikalität eines Dienstes	wenn ein früheres Nebenprojekt plötzlich wichtig wird, reichen alte RPO/RTO-Annahmen nicht mehr
Änderung der Strom- oder Shutdown-Kette	ohne passenden Wiederanlaufpfad helfen auch gute Datenstände nur begrenzt, deshalb gehört USV in dieselbe Risikoanalyse

Deshalb hängen RAID erklärt, Homelab-Monitoring und Backup-Strategie fachlich zusammen: Speicherverhalten, Alarmierung und Wiederanlauf dürfen nicht getrennt gepflegt werden.

Restic dokumentiert für Append-only-Repositories eine wichtige Sicherheitsgrenze: Zum Entfernen von Snapshots und zum Platzfreimachen über forget und prune wird wieder voller Lese-, Schreib- und Löschzugriff benötigt. Die offizielle Empfehlung ist deshalb ein separater, gut gesicherter Administrations-Client für Wartungsaufgaben. Zusätzlich verweist die Dokumentation ausdrücklich auf --keep-within als wichtigen Schutzpfad bei policybasierter Bereinigung.

Einordnung: Für Homelabs heißt das sehr konkret: Append-only ist ein wertvoller Zusatz gegen manche Lösch- und Ransomware-Pfade, aber kein Ersatz für Offline-Kopien, Off-Site-Ziele oder saubere Admin-Trennung.