3-2-1-Backup-Strategie für Homelab und Kleinbetrieb
3 Kopien, 2 Medien, 1 offsite: Was die 3-2-1-Regel wirklich bedeutet, wo sie an Grenzen stößt und wie du sie konkret umsetzt.
9 Min. LesezeitReini
Die meisten Datenverluste, die in kleinen Umgebungen passieren, haben nichts mit fehlenden Backups zu tun. Es gab Backups. Sie liefen sogar. Sie lagen nur alle auf demselben Gerät, das gestorben ist – oder sie ließen sich nicht zurückspielen, weil das seit drei Jahren niemand ausprobiert hatte.
Die 3-2-1-Regel ist die kürzeste brauchbare Antwort auf dieses Problem. Sie ist alt, sie ist unspektakulär, und sie deckt trotzdem den Großteil dessen ab, woran Datensicherungen in der Praxis scheitern.
Was die 3-2-1-Regel besagt
Drei Zahlen, drei Anforderungen:
- 3 Kopien deiner Daten – das Original plus zwei Sicherungen.
- 2 verschiedene Speichermedien – nicht beide Backups auf derselben Art von Gerät.
- 1 Kopie außer Haus – räumlich getrennt vom Original.
Der eigentliche Gedanke dahinter ist nicht „viel hilft viel“, sondern: keine zwei Kopien dürfen durch dasselbe Ereignis verloren gehen.
Daran misst sich jede Backup-Architektur. Wenn ein einziger Vorfall – ein Netzteil, das
die angeschlossenen Platten mitnimmt, ein Wasserschaden, ein verschlüsselnder Trojaner,
ein versehentliches rm -rf – zwei deiner drei Kopien erwischt, hast du keine
3-2-1-Strategie, sondern eine 3-2-1-förmige Illusion.
Warum RAID kein Backup ist
Das ist der häufigste Denkfehler, und er verdient einen eigenen Abschnitt.
RAID schützt gegen Hardwareausfall einzelner Datenträger. Mehr nicht. Es schützt nicht gegen:
| Szenario | RAID hilft? |
|---|---|
| Festplatte fällt aus | ja – dafür ist es da |
| Datei versehentlich gelöscht | nein – die Löschung wird sofort auf alle Platten übernommen |
| Ransomware verschlüsselt Dateien | nein – die Verschlüsselung wird übernommen |
| Controller schreibt fehlerhafte Daten | nein – sie werden zuverlässig redundant gespeichert |
| Netzteil zerstört mehrere Platten | nein |
| Gerät wird gestohlen | nein |
| Wasser- oder Brandschaden | nein |
| Dateisystem korrumpiert | meist nein |
RAID ist eine Verfügbarkeitsmaßnahme: Der Server läuft weiter, wenn eine Platte stirbt. Backup ist eine Wiederherstellungsmaßnahme: Du bekommst einen früheren Zustand zurück. Zwei verschiedene Probleme – das eine ersetzt das andere nicht.
Dasselbe gilt für Synchronisation. Ein rsync-Job, der jede Nacht spiegelt, repliziert
eine Verschlüsselung ebenso zuverlässig wie eine gewollte Änderung. Synchronisation
ist kein Backup, solange sie keine Versionen aufbewahrt.
Die drei Anforderungen im Detail
3 Kopien
Original plus zwei Sicherungen. Der Grund für die Zwei statt der Eins ist banal: Backups fallen ebenfalls aus. Wenn genau in dem Moment, in dem du das Backup brauchst, das Backup-Medium defekt ist, stehst du ohne da. Zwei unabhängige Sicherungen machen diesen gleichzeitigen Ausfall unwahrscheinlich.
Wichtig: Drei Kopien desselben Stands sind nur ein Teil der Antwort. Wenn alle drei den Stand von heute Nacht enthalten und du gestern etwas gelöscht hast, was du heute brauchst, helfen dir drei Kopien nicht. Dafür ist die Aufbewahrung zuständig – siehe Backup-Aufbewahrung planen.
2 verschiedene Medien
„Medien“ ist heute weiter zu fassen als damals, als es Band oder Platte hieß. Praktisch übersetzt: die zwei Kopien dürfen nicht dieselbe Ausfallursache teilen.
Zwei Platten desselben Modells aus derselben Charge im selben Gehäuse sind formal zwei Datenträger, praktisch aber ein einziges Risiko. Sinnvolle Kombinationen:
- interne SSD im Server + externe Platte
- lokaler Backup-Server + Objektspeicher bei einem Anbieter
- NAS + LTO-Band (im Kleinbetrieb ab einer gewissen Datenmenge wieder attraktiv)
Für Homelab-Setups ist die praktikabelste Variante meist: ein dedizierter Backup-Server lokal, dazu ein Cloud-Ziel. Konkret in Proxmox Backup Server einrichten und Offsite-Backup: Storage Box oder S3.
1 Kopie außer Haus
Die Offsite-Kopie schützt gegen alles, was den Standort trifft: Brand, Wasser, Einbruch, Blitzschlag.
„Außer Haus“ heißt tatsächlich außer Haus. Die externe Festplatte im Schrank neben dem Server ist keine Offsite-Kopie. Der Keller unter dem Serverraum auch nicht – Wasser läuft nach unten.
Realistische Varianten:
- Cloud-Ziel (Objektspeicher, Storage Box) – automatisierbar und dadurch zuverlässig, weil niemand es vergessen kann.
- Rotierende Wechselplatten, eine davon immer an einem anderen Ort. Billig und funktionsfähig – scheitert aber an der Disziplin. Wenn die Rotation von einem Menschen abhängt, plane den Ausfall dieses Menschen mit ein.
- Zweiter Standort, wenn vorhanden. Für Betriebe mit zwei Filialen die eleganteste Lösung.
Die Erweiterung: 3-2-1-1-0
Die klassische Regel stammt aus einer Zeit vor Ransomware. Sie wurde deshalb um zwei Ziffern erweitert – die Schreibweise stammt ursprünglich aus dem Umfeld kommerzieller Backup-Hersteller, die Anforderung dahinter ist aber herstellerunabhängig sinnvoll:
- 1 Kopie offline oder unveränderlich (offline, air-gapped oder immutable)
- 0 Fehler bei der Überprüfung der Sicherung
Die vierte Ziffer ist die Antwort auf verschlüsselnde Schadsoftware. Moderne Angriffe suchen gezielt nach erreichbaren Backup-Zielen und löschen oder verschlüsseln sie, bevor sie die Produktivdaten angehen – teils Wochen vorher, damit die Sicherungen unbrauchbar sind, wenn der Schaden auffällt. Eine Kopie, die zum Zeitpunkt des Angriffs nicht beschreibbar ist, ist die einzige verlässliche Gegenmaßnahme. Details in Ransomware-sichere Backups.
Die Null ist die unbequemere der beiden Ergänzungen: Ein Backup, das nie zurückgespielt wurde, ist kein Backup, sondern eine Annahme. Wie daraus ein belastbarer Nachweis wird, steht in Restore testen.
Vorher klären: RPO und RTO
Bevor du Medien und Ziele auswählst, brauchst du zwei Zahlen. Ohne sie planst du ins Blaue.
RPO – Recovery Point Objective: Wie viel Datenverlust ist tolerierbar? Die Antwort bestimmt das Sicherungsintervall. Ein RPO von 24 Stunden heißt: nächtliches Backup genügt, im Ernstfall ist ein Arbeitstag weg.
RTO – Recovery Time Objective: Wie lange darf die Wiederherstellung dauern? Diese Zahl bestimmt die Technik. Ein RTO von zwei Stunden schließt eine schmale Internetleitung als einzigen Rückweg für mehrere Terabyte aus – rechne das nach, bevor du dich auf eine reine Cloud-Sicherung verlässt.
Beispielrechnung Rückweg aus der Cloud (reine Übertragungszeit):
500 GB bei 100 Mbit/s -> ca. 11-12 Stunden
500 GB bei 50 Mbit/s -> ca. 23-24 Stunden
Real kommen Entpacken, Entschlüsseln und Prüfsummen dazu.
Genau deshalb sieht ein sinnvolles Setup zwei Rückwege vor: die schnelle lokale Kopie für den Normalfall, die Offsite-Kopie für den Katastrophenfall.
Ein konkretes Schema fürs Homelab
So sieht eine 3-2-1-1-0-Umsetzung aus, die mit vertretbarem Aufwand läuft:
Produktivsystem (Kopie 1)
|
| taeglich, inkrementell
v
Backup-Server im selben Netz (Kopie 2) <- schneller Restore, niedriges RTO
|
| taeglich, verschluesselt
v
Objektspeicher beim Anbieter (Kopie 3) <- offsite
|
+-- Objekt-Sperre / Aufbewahrungsregel <- die "1": unveraenderlich
|
+-- automatische Pruefung + Restore-Test <- die "0"
Die Zuordnung zur Regel:
| Anforderung | Erfüllt durch |
|---|---|
| 3 Kopien | Produktivsystem, Backup-Server, Objektspeicher |
| 2 Medien | lokale Platten vs. Objektspeicher beim Anbieter |
| 1 offsite | Objektspeicher |
| 1 unveränderlich | Objekt-Sperre am Cloud-Ziel |
| 0 Fehler | automatische Verifikation + regelmäßiger Restore-Test |
Der Zugang zum Cloud-Ziel sollte eigene Zugangsdaten mit reinen Schreibrechten verwenden – kein Löschen, kein Überschreiben. Damit kann ein kompromittiertes Produktivsystem die Offsite-Kopie nicht mit vernichten.
Umsetzung im Kleinbetrieb
Für Betriebe kommen zwei Anforderungen dazu, die im Homelab keine Rolle spielen:
Aufbewahrungsfristen. In Österreich sind Bücher und Aufzeichnungen samt Belegen grundsätzlich sieben Jahre aufzubewahren (§ 132 BAO); für bestimmte Fälle, etwa im Zusammenhang mit Grundstücken, gelten längere Fristen. Was das für deine Daten konkret bedeutet, gehört zum Steuerberater und nicht in einen Blogartikel – aber es beeinflusst, wie lange du Sicherungen vorhalten musst. Zur Umsetzung: Backup-Aufbewahrung planen.
Nachweisbarkeit. Im Betrieb reicht „läuft schon“ nicht. Es braucht ein Protokoll, wer wann was geprüft hat – spätestens gegenüber einer Versicherung nach einem Vorfall. Der Weg dorthin führt über automatische Benachrichtigung: Backup-Monitoring.
Was die Regel nicht abdeckt
Ehrlichkeitshalber: 3-2-1 ist ein Minimum, keine Vollabdeckung. Offen bleiben:
Schleichende Beschädigung. Wird eine Datei still korrumpiert und fällt das erst nach Monaten auf, sind alle Sicherungen innerhalb deines Aufbewahrungszeitraums betroffen. Gegenmittel: Prüfsummen auf Dateisystemebene und längere Aufbewahrung für selten geänderte Daten.
Schlüsselverlust. Verschlüsselte Backups ohne verfügbaren Schlüssel sind gleichwertig zu keinen Backups. Dieser Fall kommt häufiger vor als Hardwaredefekte. Siehe Backup-Verschlüsselung.
Das Konfigurationswissen. Die Daten sind zurück – aber weißt du noch, wie das System konfiguriert war? Dokumentation und Konfigurationsdateien gehören ins Backup, und zwar an eine Stelle, die du auch ohne das ausgefallene System erreichst.
Fremdgehostete Dienste. Daten in einem Cloud-Dienst sind nicht automatisch gesichert. Die meisten Anbieter sichern gegen ihren eigenen Ausfall, nicht gegen dein versehentliches Löschen – und schon gar nicht gegen eine Kontosperre.
Mehr davon: Typische Backup-Fehler.
Checkliste
Geh diese Punkte für deine Umgebung durch. Jedes „nein“ ist eine offene Baustelle:
- Es existieren mindestens drei Kopien der wichtigen Daten.
- Kein einzelnes Ereignis kann zwei davon gleichzeitig vernichten.
- Mindestens eine Kopie liegt an einem anderen Standort.
- Mindestens eine Kopie ist unveränderlich oder offline.
- Das Produktivsystem hat keine Löschrechte auf dem Backup-Ziel.
- RPO und RTO sind benannt – nicht gefühlt, sondern aufgeschrieben.
- Die Sicherungen werden automatisch verifiziert.
- Ein vollständiger Restore wurde in den letzten sechs Monaten durchgeführt.
- Bei Fehlschlag wird jemand aktiv benachrichtigt.
- Der Verschlüsselungsschlüssel ist unabhängig vom gesicherten System verfügbar.
- Es ist dokumentiert, wer im Ernstfall was tut.
Häufige Fragen
Reicht ein Cloud-Backup allein? Als einzige Sicherung nein – wegen der Wiederherstellungsdauer. Als Offsite-Bestandteil einer 3-2-1-Kette ist es dagegen die praktikabelste Lösung, weil es ohne menschliches Zutun läuft.
Wie oft sollte gesichert werden? Das ergibt sich aus dem RPO, nicht aus einer Faustregel. Für die meisten Homelabs sind tägliche Sicherungen richtig; für Systeme, an denen laufend gearbeitet wird, häufiger.
Sind Snapshots ein Backup? Nur wenn sie auf einem anderen System liegen. Snapshots auf demselben Speicher sind schnell zurückgespielt und deshalb wertvoll – aber sie verschwinden mit dem Speicher.
Wie lange aufbewahren? Getrennt betrachten: kurzfristig für „gestern gelöscht“ (Tage), mittelfristig für „vorletzte Woche war es noch richtig“ (Wochen), langfristig für gesetzliche Fristen (Jahre). Siehe Backup-Aufbewahrung planen.
Wie es weitergeht
Diese Seite ist der Überblick. Die Umsetzung steht in den einzelnen Artikeln:
- Proxmox Backup Server einrichten – die lokale Kopie
- restic, Borg oder PBS? – Werkzeugwahl
- Offsite-Backup: Storage Box oder S3 – die Kopie außer Haus
- Backup-Verschlüsselung – bevor Daten das Haus verlassen
- Ransomware-sichere Backups – die „1“
- Restore testen – die „0“
- Backup-Aufbewahrung planen – wie viele Stände
- Backup-Monitoring – merken, wenn etwas fehlschlägt
- Typische Backup-Fehler – was in der Praxis schiefgeht