3-2-1-1-0: Die erweiterte Backup-Formel für 2026

Die klassische 3-2-1-Regel — drei Kopien, zwei Medien, eine Kopie außer Haus — ist seit Jahrzehnten der Goldstandard im Backup. Sie stammt aus einer Zeit, in der der Hauptfeind der Wasserschaden im Serverraum war, nicht ein automatisierter Ransomware-Angriff, der gezielt nach Ihrem Veeam-Repository sucht. 2026 reicht das nicht mehr. Moderne Angreifer verweilen im Durchschnitt Wochen im Netzwerk, bevor sie zuschlagen — und der erste Angriffsvektor ist heute fast immer das Backup-System selbst.

Die erweiterte Formel 3-2-1-1-0 schließt diese Lücken. Sie ergänzt die klassische Regel um zwei Ziffern, die genau die zwei Schwachstellen adressieren, an denen Backups in den letzten Jahren am häufigsten gescheitert sind: eine unveränderliche oder physisch getrennte Kopie — und die konsequente Verifikation jedes Restores. In diesem Artikel zeigen wir, was jede Ziffer im SMB-Kontext konkret bedeutet, wie eine saubere Implementierung mit TrueNAS SCALE, Proxmox Backup Server und einem S3-Objektspeicher aussieht und wo die typischen Fallstricke liegen.

Die Formel im Überblick

Jede Ziffer der Formel adressiert ein spezifisches Ausfallszenario. Wer eine der Zahlen streicht, deckt genau eine dieser Bedrohungen nicht mehr ab:

Ziffer	Bedeutung	Adressiert
3	Drei Datenkopien insgesamt (Produktion + zwei Backups)	Einzelfehler, Datenkorruption
2	Zwei unterschiedliche Medien-/Storage-Klassen	Silent Corruption, Firmware-Bugs, Media-Ausfall
1	Eine Kopie geografisch entfernt (Offsite)	Feuer, Wasserschaden, Diebstahl
1	Eine Kopie immutable oder air-gapped	Ransomware, Insider-Angriffe, Fehlbedienung
0	Null Fehler bei Restore-Tests	Blindes Vertrauen in Backup-Jobs

Die entscheidende Beobachtung: Die ersten drei Zahlen schützen vor technischen Ausfällen, die vierte vor aktiven Angreifern, die fünfte vor sich selbst. Und genau die letzte ist die am häufigsten übersehene.

Die zusätzliche 1: Immutable oder Air-Gapped

Ransomware-Gruppen wissen genau, dass Backups ihr Geschäftsmodell zerstören. Deshalb ist der erste Schritt nach dem Einbruch heute die Suche nach dem Backup-Server, seinen Credentials und der Löschung oder Verschlüsselung der Repositories. Ein einfaches “Backup auf NAS” ist damit wertlos, wenn das NAS mit einem Domänen-Konto oder SMB-Freigabe erreichbar ist.

Es gibt drei praktikable Wege, diese zusätzliche 1 im Mittelstand umzusetzen:

a) ZFS-Snapshots mit Retention-Lock: Auf einem TrueNAS-System werden Snapshots per Task-Scheduler erstellt und über eine Retention-Policy geschützt. Der Repository-User (z. B. der PBS-Datastore) hat nur Zugriff auf das Live-Dataset, nicht auf die .zfs/snapshot/-Verzeichnisse. Selbst wenn ein Angreifer den Datastore verschlüsselt, bleiben die Snapshots erhalten — ein rekursives zfs destroy ist ohne Root-Zugriff nicht möglich.

b) Object Lock via S3: Storj, Wasabi, AWS S3 oder ein selbst gehostetes MinIO/Ceph bieten S3 Object Lock im Compliance-Modus. Objekte lassen sich für eine definierte Retention weder überschreiben noch löschen — auch nicht vom Konto-Root. Proxmox Backup Server 3.4 und Veeam 13 sprechen S3 nativ.

c) Klassisches Air-Gap: Ein Wechseldatenträger (LTO-Tape, USB-Wechselplatte) wird nach dem Backup physisch getrennt. Aufwendig, aber die einzige Variante, die auch gegen Zero-Day-Angriffe auf die Storage-Firmware absolut sicher ist. Für viele KMU-Kunden fahren wir eine Kombination aus a) und b).

Die 0: Verifizierte Restores

Die wichtigste Ziffer der Formel ist die 0. Ein Backup, das nie zurückgespielt wurde, ist strenggenommen ein Hoffnungswert. Wir sehen in unseren Kundenprojekten regelmäßig Situationen, in denen der Backup-Job monatelang grün gemeldet hat — aber der Restore an einem korrupten Deduplication-Chunk, einer geänderten Verschlüsselungs-Passphrase oder schlicht an fehlender Verify-Konfiguration scheitert.

Proxmox Backup Server bietet dafür zwei eingebaute Mechanismen, die zusammen fast alle Fehlerklassen abfangen:

# Wöchentlicher tiefer Verify aller Snapshots im Datastore
# (prüft Chunk-Integrität gegen die gespeicherten SHA-256-Hashes)
proxmox-backup-manager verify-job create weekly-verify \
    --store main \
    --schedule "sat 02:00" \
    --outdated-after 7 \
    --ignore-verified true

# Automatisierter Test-Restore einer VM in ein isoliertes Netz
qm importsnapshot 9999 backup:vm/101/2026-08-25T22:00:00Z \
    --storage restore-test --target-vlan 4094

Der zweite Baustein ist der automatisierte Restore-Test: Eine kleine Auswahl kritischer VMs wird wöchentlich in eine isolierte VLAN-Zone (bei uns typischerweise VLAN 4094 auf der OPNsense) zurückgespielt, gebootet und per einfachem HTTP- oder SSH-Check auf Funktion geprüft. Wer keine echten Restores testet, testet auch nicht seine Runbooks — und im Ernstfall stellt man dann fest, dass die AD-Anmeldung ohne DC nicht funktioniert, weil das DC selbst noch nicht wiederhergestellt ist.

Referenz-Setup für den Mittelstand

Ein typisches Backup-Setup, das wir bei DATAZONE für 20-100-Mitarbeiter-Umgebungen ausrollen, sieht wie folgt aus:

• Kopie 1 — Produktion: Proxmox-Cluster mit ZFS-basierten Datastores, lokale ZFS-Snapshots alle 15 Minuten (Retention 24h).
• Kopie 2 — Primäres Backup: Proxmox Backup Server 3.4 mit dediziertem TrueNAS-Datastore, verschlüsselt, tägliche Backups, wöchentlicher Verify.
• Kopie 3 — Sekundäres Backup: PBS-Sync-Job auf ein zweites TrueNAS SCALE 25.10 an einem zweiten Standort oder im DATAZONE-Rechenzentrum, verbunden über WireGuard.
• Die zusätzliche 1 — Immutable: Zusätzlicher Sync-Job auf Storj mit Object Lock (30 Tage Compliance-Mode) für die letzten 4 Wochen an geschäftskritischen Snapshots.
• Die 0 — Verify: Wöchentlicher Deep-Verify aller Snapshots + monatlicher Test-Restore der Top-3-VMs in ein isoliertes VLAN.

Dieses Setup deckt alle fünf Ziffern ab, ist mit ausschließlich Open-Source-Software realisierbar und skaliert bis in den zweistelligen TB-Bereich mit einem sehr überschaubaren Storage-Budget. Die Kombination aus lokalem PBS und Object-Storage-Copy ist dabei bewusst gewählt: Der lokale PBS liefert schnelle Restores bei alltäglichen Ausfällen (versehentlich gelöschte VM, korruptes Guest-OS), die Immutable-Copy bei Storj greift ausschließlich im Katastrophenfall.

Häufige Umsetzungsfehler

Auch mit dem passenden Konzept scheitern Implementierungen an denselben wiederkehrenden Punkten. Die vier häufigsten:

1. Ein Domänen-Konto für alles: Der PBS-Server hängt in der Domäne, das Service-Konto hat Zugriff auf alle Repositories. Nach einer Kompromittierung des DCs ist alles verloren. Backup-Systeme gehören in eine getrennte Authentifizierungsdomäne mit lokalen Accounts und MFA.
2. Ein Netzwerk für alles: Backup-Traffic und Produktions-Traffic teilen sich ein VLAN, der Backup-Server ist per SMB oder Web-UI aus dem Client-LAN erreichbar. Backup-Netze gehören in eine separate Security-Zone mit strikten Firewall-Regeln — Verbindungen dürfen nur vom Backup-Server zum Ziel initiiert werden.
3. Retention ohne Immutability: Eine “30-Tage-Retention” im Backup-Tool ist ein Ordnungs-Feature, keine Sicherheitsfunktion. Wer Löschungen verhindern will, braucht ZFS-Snapshots mit Retention-Lock oder S3 Object Lock — Punkt.
4. Verify ist optional: Der Job-Report zeigt “OK”, aber Verify ist deaktiviert oder läuft nur bei neuen Chunks. Silent-Bit-Rot auf HDD-Pools trifft dann erst beim echten Restore auf.

Migration von 3-2-1 zu 3-2-1-1-0

Wer heute ein funktionierendes 3-2-1-Setup betreibt, muss nicht bei Null anfangen. Der Weg zur erweiterten Formel läuft in drei überschaubaren Schritten: Zuerst wird der bestehende Backup-Repository von einem klassischen SMB-Share auf einen PBS-Datastore mit ZFS-Snapshot-basierter Immutability migriert — oder ein zusätzlicher Object-Storage-Sync mit Object Lock eingerichtet. Anschließend werden Verify-Jobs und ein wöchentliches Test-Restore-Playbook etabliert. Erst dann folgt die organisatorische Härtung: getrennte Auth-Domäne für die Backup-Systeme, dedizierte Firewall-Zone, MFA für alle administrativen Zugriffe.

In der Praxis ist der zweite Schritt der teuerste — nicht in Lizenzen, sondern in Prozessdisziplin. Ein automatisiertes Restore-Playbook, das monatlich läuft und dessen Ergebnis auf einem Dashboard landet, ist der Unterschied zwischen “wir haben Backup” und “wir können wiederherstellen”.

---

DATAZONE unterstützt mittelständische IT-Teams beim Aufbau von Backup-Infrastrukturen nach der 3-2-1-1-0-Formel — vom Konzept über die Umsetzung mit TrueNAS, Proxmox Backup Server und immutablem Object Storage bis zum dokumentierten Disaster-Recovery-Playbook. Wenn Sie Ihr bestehendes Backup-Setup auditieren oder neu aufsetzen möchten, sprechen Sie uns an — wir prüfen Ihr aktuelles Konzept auf alle fünf Ziffern und zeigen konkret, wo die Lücken sind.