Kein Backup ist sicher, bis es getestet ist: Die 3-2-1-Strategie für Self-Hoster

Neun von zehn Datenverlust-Katastrophen haben dieselbe Wurzel: Während der Sache lief, wurde etwas kopiert – ein Snapshot auf denselben Datenträger, ein synchrones Mirror in dieselbe Rack-Zone, ein rsync-Lauf, der ohne Prüfsumme lief. Das Ergebnis sieht aus wie ein Backup. Es ist es nicht.

Eine Wiederherstellung aus einer Kopie, die noch nie angefasst wurde, ist wie ein Rettungsplan, den niemand bis zum Schiffbruch gelesen hat. In der Selbsthosting-Praxis wird dieser Unterschied täglich ignoriert – bis die Festplatte klickt, die VM-Umgebung beschädigt ist oder der Provider-Version-Upload die Datenbank korruptiert. Der Rest der Geschichte ist langweiliger und teurer als das, was man hätte tun können.

Das Kernproblem: Eine Kopie ist kein Backup

Eine Kopie erfüllt drei Bedingungen nicht automatisch:

• Sie liegt an einem anderen physischen Ort.
• Sie ist von dem originalen System unabhängig (andere Hardware, anderer Host, anderes Netzwerk).
• Sie wurde tatsächlich wiederhergestellt – nicht nur gelesen, sondern vollständig in einen lauffähigen Zustand gebracht.

Wenn ein rsync-Job dieselbe Festplatte auf einen anderen Pfad schreibt, gibt es technisch gesehen eine Kopie, aber keine Redundanz gegen den Plattencrash. Wenn ein Proxmox-Backup auf ein NAS schreibt, das denselben Rechner über dasselbe VLAN versorgt, hilft es nicht gegen einen Stromschlag am Rack. Wenn ein Docker-Volumes-Backup als tarball auf denselben Host schlägt, hilft es nicht gegen eine fehlerhafte Image-Aktualisierung, die das originale Volumen überschreibt.

Backup heißt: unabhängig, versioniert, wiederherstellungstauglich, geprüft.

Die 3-2-1-Regel: Definition und konkrete Umsetzung

Die 3-2-1-Regel ist alt und bleibt vollständig gültig: drei Kopien, zwei verschiedene Medien, eine Kopie extern. Für Self-Hoster bedeutet das:

• Kopie 1 (Primär): Das aktive System – Proxmox-host mit VMs und Containern, Docker-Hosts mit Volumes und Konfiguration.
• Kopie 2 (lokal, anders): Ein NAS, eine zweite Festplatte in einem anderen Gehäuse oder ein anderer Storage-Pool auf demselben Proxmox-Host, aber mit anderer Failure-Domain. Die Mount-Points und Zugriffsrechte müssen so gestaltet sein, dass ein beschädigtes Host-Betriebssystem nicht automatisch das Backup volume unbrauchbar macht.
• Kopie 3 (extern): Ein Offsite-Ziel – ein zweiter Proxmox-Host in einem anderen Ort, ein klug verschlüsseltes Backup in ein kleines VPS, ein lokales Backup-Laufwerk, das physisch an einen anderen Ort getragen wird, oder eine  Object-Storage-Upload (S3-kompatibel mit kluger Verschlüsselung).

Konkret auf Proxmox: Eine typische Einrichtung nutzt vzdump mit einem Backup-Scheduler, der die VM- und Container-Dumps als .vma.lzo oder .tar.zst auf einen separaten Storage schreibt. Der Storage sollte kein Mount aus dem laufenden Host sein, der den gleichen Controller bedient. Ein guter Minimalaufbau:

• Proxmox-Host mit einer Datenpartition (z.B. /var/lib/vz oder ein dedizierter LVM-Thin-Pool) als Hochleistungslager.
• Backup-Speicher über NFS oder iSCSI von einem separaten NAS – mit eigenen Credentials, nicht mit dem Root-Zugang des Hosts.
• Externe Kopie: Ein Skript, das den letzten Backup-Satz verschlüsselt auf ein Offsite-Ziel überträgt – z.B. mit rclone zu einem Remote oder mit restic zu einem Repository.

In Containern ist die Lage anders: Ein Docker-Volume-Backup ist kein VM-Heat-Backup. Container sind zerstörbar, ihre Daten liegen in Volumes und Konfigurationsdateien. Ein sinnvoller Container-Backup-Ansatz:

• Datenvolumes exportieren, z.B.:

```bash

docker run --rm -v meinedaten:/data -v $(pwd):/backup alpine tar czf /backup/meinedaten-$(date +%F).tar.gz -C /data .

```

• Docker Compose-Konfigurationen und Umgebungsvariablen als Dateien festhalten (docker-compose.yml, .env, benötigte Secrets) und in den Backup-Zyklus einbeziehen.
• Datenbanken konsistent sichern: Für PostgreSQL etwa pg_dump, für MySQL/MariaDB mysqldump – nicht nur das Volumen kopieren, wenn die Datenbank schreibt.

Ein häufiger Amateurfehler ist, den Container einfach zu committen oder ein Volume zu kopieren, ohne die Konsistenz der laufenden Datenbank zu sichern. Das Ergebnis ist eine Kopie, die beim Wiederherstellungsversuch Fehler verbergen.

Die 3-2-1-Regel im Detail – Konkrete Umsetzung auf Proxmox und in Containern

Die 3-2-1-Regel klingt simpel, wird aber von fast allen Self-Hostern falsch umgesetzt. Zuerst die Regel rein: Drei Kopien der Daten, auf zwei verschiedenen Speichermedien, von denen eine extern liegt. Das klingt nach Mathematik, ist aber im Detail eine Logistics-Frage.

Auf einem Proxmox-Host bedeutet das konkret: Die laufende VM ist Kopie eins. Eine lokale Backup-Partition auf einer zweiten Festplatte – besser noch ein anderes RAID-Level oder eine andere Controller-Schiene – ist Kopie zwei. Kopie drei muss physisch weg vom Rechner sein: ein zweiter Proxmox-Host im anderen Zimmer, ein NAS in der Wohnung des Elternhauses, ein VPS mit OwnBackups oder ein Objektspeicher mit clientseitiger Verschlüsselung. Was nicht funktioniert: Eine Kopie auf demselben Storage-Array, das dieselbe Stromversorgung teilt. Was auch nicht funktioniert: Ein Snapshot, der auf demselben Logical Volume liegt und nur einen anderen Dateisystem-Pfad hat.

Proxmox bietet zwei relevante Wege: vzdump für ganze VMs und Container, und die Storage-Backup-Strategie für rein containerisierte Umgebungen. vzdump erstellt konsistente Snapshots, kann Kompression und Verschlüsselung anwenden und werdenüber Cron geplant. Ein typischer Cron-Eintrag in /etc/cron.d/pve-backup:

0 3 * * * root /usr/sbin/vzdump --mode snapshot --compress zstd --storage backup-nas --all 1>>/var/log/pve-backup.log 2>&1

Das reicht nicht. Der Storage backup-nas darf nicht derselbe Pfade sein wie die VM-Disks. Besser: ein separater NFS-Mount aus einem anderen Rechner, oder ein lokaler Backup-Pool auf einer physisch anderen Platte. Und: Backups müssenEncrypted sein, bevor sie ins Netz gehen.

In Docker-Umgebungen ist die Lage subtler. Ein Volume-Backup mit docker run --rm -v meindb-data:/data -v $(pwd):/backup alpine tar czf /backup/meindb-data-$(date +%F).tar.gz -C /data . ist eine Kopie – aber nur, wenn sie an einen anderen Ort geht. Ebenfalls wichtig: Datenbanken müssen konsistent gesichert werden. Ein gewöhnliches Volume-Snapshot einer laufenden Datenbank ist mit hoher Wahrscheinlichkeit korrupt, wenn es während des Schreibens genommen wurde. Für PostgreSQL ist pg_dump der richtige Weg, für MySQL/MariaDB mysqldump. Container-Konfigurationen – docker-compose.yml, .env, Secrets – müssen als Dateien ebenfalls in den Backup-Kreislauf.

Auf Proxmox: vzdump, Storage-Regeln und External Targets

Proxmox-Backups sind einfach, aber nur wenn man die Failure-Domains respektiert. Ein vzdump auf denselben ZFS-Pool, aus dem die VMs laufen, ist eine Kopie, aber kein Backup gegen Pool-Ausfall. Ziel:

• Backup-Storage auf anderer Hardware, besser noch anderer Stromversorgung.
• Übertragung zum externen Ziel verschlüsselt – nicht nur Transport-verschlüsselt, sondern Ende-zu Ende verschlüsselt, damit der Empfänger die Daten ohne den Schlüssel nicht lesen kann.

Ein Minimal-Pfad für das externe Ziel ist ein rclone-Kommando, das den letzten Backup-Ordner verschlüsselt hochlädt, oder ein restic-Repository auf einem S3-kompatiblen Endpoint. Beides lassen sich in den Backup-Cron integrieren.

In Containern: Volumes, Datenbanken, Compose-Konfig

Container-User laufen Gefahr, die Backup-Strategie an der Virtualisierung festzumachen und die Applikationsdaten zu vergessen. Ein Docker-Setup ohne Datenbank-Backup ist blind. Beispiel:

# Datenbankkonsistente Sicherung vor dem Volume-Backup
docker exec meinedb pg_dump -U dbuser meinedb > /backup/meinedb-$(date +%F).sql
# Danach Volume exportieren – veraltete Daten wird man so vermeiden
docker run --rm -v meinedb-data:/src -v /backup:/backup alpine tar czf /backup/meinedb-data-$(date +%F).tar.gz -C /src .

Die Konfigurationsdateien gehören ebenfalls ins Backup: docker-compose.yml, .env, Secrets, Netzwerk-Definitionen.

Getestete gegenüber ungetesteter Wiederherstellung

Ein ungetestetes Backup ist ein Versprechen, das niemand eingelöst hat. Wiederherstellungstests werden nicht gemacht, weil sie Arbeit sind und keinen sichtbaren Gewinn bringen – bis sie gebraucht wird.

Ein getestetes Backup ist eines, bei dem man:

• Eine Wiederherstellung in eine isolierte Test-Umgebung durchgeführt hat (z.B. eine temporäre VM, die nicht ins Produktions-Netz geht).
• Die Applikation nach dem Restore gestartet und die Daten auf Plausibilität geprüft hat – nicht nur die Dateien existieren, sondern die Anwendung sie liest.
• Die Wiederherstellungszeit dokumentiert hat, zumindest grob: Wie lange dauert ein Restore einer typischen VM? Wie lange die Datenbank?

Ohne Test bleibt unklar, ob der Backupstrom komplett ist, ob Kompressions- oder Verschlüsselungsfehler die Dateien unbrauchbar machen, ob Applikations-Config-Dateien dabei sind, und ob die Wiederherstellung überhaupt möglich ist.

Sinnvoller Ablauf: Einmal im Monat eine schematische Wiederherstellung – nicht vollständig alle Daten, aber eine repräsentative Auswahl. Eine VM aus dem letzten Backup, ein Datenbankdump, ein Container-Image mit Volume. Das Ergebnis wird dokumentiert: erfolgreich / fehlgeschlagen, Zeitbedarf, auffälligkeiten.

Verschlüsselung des Backups und Key-Management

Backups enthalten die ganzen Daten – auch Passwörter, Tokens, sensible Konfigurationen. Wenn das externe Backup unverschlüsselt liegt, ist der Verlust dieses Backups genauso schlimm wie ein Einbruch in das aktive System.

Ein solides Modell:

• Clientseitige Verschlüsselung bevor das Backup das Haus verlässt – vzdump mit dem eingebauten Verschlüsselungsparameter, oder eine zusätzliche Schicht mit gpg, restic mit seinem Verschlüsselungs-Ansatz, oder rclone mit Crypt-remote.
• Schlüsselverwaltung getrennt vom Backup – der Verschlüsselungsschlüssel (oder das Passwort) darf nicht im selben Backup-Stream liegen. Typischerweise auf einem separat verwahrten Stick, in einem Passwort-Manager mit physischer Mehrfachanforderung, oder als physisch getrennte Kopie.

Konkret auf Proxmox: vzdump unterstütützt Verschlüsselung mit einem Passwort:

vzdump <vmid> --compress zstd --storage backup-nas --encrypt-key /etc/vzdump/backup-key

Die Handhabung des Keys ist der kritische Teil: Der Key muss auf einem Ort liegen, der nicht durch denselben Ausfall betroffen ist wie das Backup. Ein Key, der auf derselben NAS liegt wie das Backup, macht die Verschlüsselung wertlos.

Für Container-Backups gilt dasselbe: Der Backup-Pfad, der das Passwort zum Entschlüsseln enthält, ist kein Backup, sondern ein Risiko.

Key-Management heißt hier nicht Only-Key-Here-selbst, sondern: wer kann im Notfall den Schlüssel finden, ohne dass er mit dem Backup zusammenfällt? Wenigstens: Schlüssel an anderer Stelle, dokumentiert, von einer zweiten Person zugänglich, wenn nötig.

Monatlicher Wiederherstellungstest als Routine

Routine ist nötig, weil sich Systeme ändern. Eine Backup-Strategie, die vor einem Jahr funktionierte, kann nach drei Kubernetes-Updates, einer Datenbank-Migration oder einem Storage-Wechsel defekt sein, ohne dass es auffällt.

Monatlich sollten:

• Wenigstens eine VM aus dem letzten Backup in einer isolierten Umgebung wiederhergestellt werden.
• Eine Datenbank aus dem letzten Dump importiert und auf grundlegende Lesbarkeit geprüft werden.
• Ein Container-Backup ausgelesen, der Container gestartet und die App verifiziert werden.

Eine einfache Checklisten-Dokumentation reicht: Datum, was wiederhergestellt wurde, Erfolg / Misserfolg, Zeitbedarf, Bemerkungen. Ohne Dokumentation wird der Test nicht wiederholt.

Typische Fehler von Self-Hostern

Die häufigsten Fehler sind nicht technisch komplex, sondern strukturell:

• Ein Backup, das denselben Ort teilt – Snapshot auf derselben Platte, Backup auf demselben NAS wie das Produktivsystem, Sync in denselben Cloud-Account.
• Keine Wiederherstellungstests – Backups werden erstellt, nie wieder eingelesen.
• Verschlüsselung fehlt oder der Schlüssel ist mit im Backup – Ergebnis ist eine Verschlüsselung ohne Schutz.
• Backup-Skripte ohne Protokoll – Wenn etwas fehlschlägt, ist niemandem klar, seit wann die Lücke besteht.
• Datenbanken als Volume kopiert, ohne Konsistenz sicherzustellen – Datenbank-Dumps fehlen, oder Daten sind beim Wiederherstellen korrupt.
• Konfiguration nicht mitgesichert – Nur Daten, keine Container-Definitionen, keine Netzwerk-Skripte, keine Umgebungsvariablen.

All diese Fehler haben dieselbe Wurzel: Die Illusion, dass die Kopie die Arbeit erledigt, ohne die Wiederherstellung zu prüfen.

BsN: Backup-Konfigurationen als Dienstleistung

Eine funktionierende Backup-Strategie für eigene Clouds ist wenig Aufwand, wenn sie einmal richtig aufgesetzt ist – aber die Details sind langweilig und fehleranfällig. BsN, Benjamin Nickl, richtet für Self-Hoster und kleine Betriebe Backup-Konfigurationen ein: Proxmox-Backup-Jobs, externe Kopien, encrypted Storage, wiederherstellungstests in Kombination mit dem jeweiligen Umfeld.

Was dabei varriert: ob der Kunde bereits eine Infrastruktur hat, ein völlig neuer Aufbau gewünscht wird, welchen Schutzgrad die Daten haben – private Cloud, kleine Firma, sensibler Betrieb. Der konkrete Ort für Fragen: homelab.brillianze.de.

Fazit: Was zählt, wird getestet

Die 3-2-1-Regel ist ein Minimalstandard, kein Luxus. Ohne sie läuft jeder Self-Host auf einem zweifelhaften Untergrund. Getestete Wiederherstellung ist der einzige Beweis, dass ein Backup existiert. Verschlüsselung + getrenntes Key-Management ist der Mindeststandard für externe Backups. Und der monatliche Test ist die Routine, die aus einer guten Absicht etwas macht, das funktioniert, wenn es zählt.

Hinweis: Dieser Artikel ist redaktioneller Inhalt und enthält keine Affiliate- oder Partner-Links. Alle Angaben entsprechen dem Stand 2026 und können sich ändern.