In den ersten beiden Teilen unserer großen Proxmox-Serie haben wir uns intensiv mit der Optimierung des Arbeitsspeichers und der strukturellen Trennung von Nextcloud-Daten beschäftigt. Doch all diese technischen Finessen sind im Ernstfall wertlos, wenn keine wasserdichte Backup-Strategie dahintersteht. In der IT-Welt gibt es ein ungeschriebenes Gesetz, das jeder Administrator schmerzhaft lernt: „Daten, die nicht gesichert sind, existieren nicht.“ Ein Datenverlust kann Jahre an Arbeit, Erinnerungen und Konfigurationen innerhalb von Millisekunden vernichten.

Besonders im privaten Homelab-Bereich stoßen wir jedoch oft auf Hardware-Restriktionen, die professionelle Lösungen erschweren. In diesem ausführlichen Guide besprechen wir die Umsetzung der legendären 3-2-1-Backup-Regel. Das Besondere an unserem Szenario: Wir lösen das Problem, wie man riesige VM-Images (teils über 300 GB) sicher auf einem Raspberry Pi speichert, dessen Festplatte im veralteten, aber kompatiblen FAT32-Dateisystem formatiert ist. Wir tauchen tief in die Welt des „VMA-Splittings“ ein und erklären, warum technische Kreativität oft wichtiger ist als ein unbegrenztes Budget.

Das Fundament: Die 3-2-1-Backup-Regel erklärt

Bevor wir eine einzige Zeile Code schreiben, müssen wir das konzeptionelle Fundament verstehen. Eine professionelle Datensicherung ist kein Zufallsprodukt, sondern folgt einer bewährten Methodik. Die 3-2-1-Regel ist der Goldstandard der Datensicherung, der ursprünglich aus der Fotografie stammt und heute in jedem Rechenzentrum der Welt Anwendung findet.

Die drei Säulen der Sicherheit:

• 3 Kopien der Daten: Das bedeutet, du besitzt deine Live-Daten (die aktive VM auf dem Host) plus mindestens zwei zusätzliche Backups. Warum drei? Weil die statistische Wahrscheinlichkeit, dass drei unabhängige Kopien gleichzeitig versagen, gegen Null tendiert.
• 2 verschiedene Medien: Vertraue niemals nur einem Speichertyp. Wenn der Controller deiner internen SSD stirbt, bringt es nichts, wenn das Backup auf derselben SSD lag. Wir nutzen in unserem Setup eine lokale USB-Festplatte mit NTFS-Dateisystem und einen entfernten Raspberry Pi, der via NFS (Network File System) angebunden ist.
• 1 Kopie außer Haus (Offsite): Ein lokales Backup schützt vor Festplattendefekten, aber nicht vor Diebstahl, Feuer oder Wasserschäden. Idealerweise sollte eine Kopie physisch an einem anderen Ort liegen – etwa verschlüsselt in der Cloud oder auf einer Festplatte bei Freunden.

In unserem aktuellen Setup erfüllen wir die ersten beiden Punkte durch eine hybride Speicherlösung, die sowohl lokale Geschwindigkeit als auch räumliche Trennung im Netzwerk bietet.

Die technische Hürde: Das 4-GB-Limit von FAT32

Viele Nutzer verwenden den Raspberry Pi als günstigen Einstieg in die Welt der Network Attached Storage (NAS) Systeme. Da diese Geräte oft auch für den Datenaustausch mit Windows oder macOS genutzt werden, sind die Festplatten häufig im FAT32-Format partitioniert. FAT32 (File Allocation Table) ist ein Urgestein der Dateisysteme, das bis heute eine fast universelle Kompatibilität genießt.

Doch FAT32 birgt eine gefährliche Falle für Systemadministratoren. Aufgrund der 32-Bit-Architektur der Dateigrößen-Adressierung ist es technisch unmöglich, Dateien zu speichern, die größer als 4 Gigabyte minus 1 Byte sind. Die exakte mathematische Grenze liegt bei:

$2^{32} - 1 \text{ Bytes} = 4.294.967.295 \text{ Bytes} \approx 4 \text{ GB}$

In Zeiten von 4K-Videos und riesigen virtuellen Maschinen ist dies ein massives Problem. Unsere Nextcloud-VM hat beispielsweise eine Kapazität von 320 GB. Auch wenn wir durch Trim-Optimierung nur ca. 46 GB real belegen, erzeugt Proxmox beim Sichern ein Image im VMA-Format (Virtual Machine Archive), das diese 4-GB-Marke spielend sprengt. Ein klassisches Backup würde sofort mit dem Fehler File too large oder einer Broken Pipe abbrechen. Wir müssen also einen Weg finden, diese physikalische Grenze per Software zu überlisten.

Ebene 1: Lokales Hochgeschwindigkeits-Backup auf NTFS

Der erste Teil unserer hybriden Strategie ist das lokale Backup. Direkt an unserem Proxmox-Host (thom7e) ist eine externe 2-TB-Festplatte angeschlossen. Diese haben wir mit dem von Microsoft entwickelten NTFS-Dateisystem formatiert. NTFS ist ein modernes Journaling-Dateisystem, das Dateien bis zu einer Größe von 16 Exabyte unterstützt – für unsere Zwecke also quasi unendlich.

Vorteile der USB-Direktsicherung:

• I/O-Performance: Die Datenübertragung erfolgt über USB 3.0 mit hoher Bandbreite, ohne die Netzwerklast zu beeinträchtigen.
• Native Proxmox-Integration: Wir können das grafische Backup-Interface von Proxmox nutzen, was die Verwaltung und Zeitplanung extrem vereinfacht.
• ZSTD-Kompression: Proxmox unterstützt nativ Zstandard (ZSTD), einen von Meta (Facebook) entwickelten Kompressionsalgorithmus. ZSTD bietet eine Kompressionsrate, die fast an GZIP herankommt, aber bei der Dekompression und Kompression wesentlich weniger CPU-Zyklen verbraucht. In unserem Test schrumpft das 320-GB-Image auf handliche 25 GB zusammen.

Dieses lokale Backup ist unser „Rettungsboot“ für den schnellen Zugriff. Sollte ein Update der Nextcloud fehlschlagen, können wir diese Sicherung in wenigen Minuten wieder einspielen (RTO - Recovery Time Objective).

Ebene 2: Remote-Backup auf den Raspi via Splitting

Um die 4-GB-Hürde des Raspberry Pi zu nehmen, ohne die Festplatte neu formatieren zu müssen, nutzen wir ein klassisches Unix-Prinzip: Pipes und Redirection. In der Linux-Welt kann die Ausgabe eines Programms direkt als Eingabe für ein anderes dienen, ohne dass die Daten zwischendurch auf der Festplatte zwischengespeichert werden müssen.

Der technische Deep-Dive in das Split-Verfahren

Wir nutzen ein automatisiertes Bash-Skript, das den Backup-Stream von Proxmox abgreift und in mundgerechte Stücke zerteilt. Hier kommt das GNU-Tool split zum Einsatz. Der entscheidende Befehl lautet:

# Backup generieren und direkt in 3,5 GB Häppchen zerlegen
vzdump 102 --stdout --mode snapshot --compress zstd | split -b 3500M - "/mnt/pve/raspi-storage/dump/vzdump-102-part-"

Was passiert hier im Hintergrund?

1. vzdump 102 --stdout: Proxmox erstellt das Backup der VM 102 (Nextcloud). Der Parameter --stdout sorgt dafür, dass die Daten nicht in eine Datei geschrieben, sondern in den „Standard Output“ (den Datenstrom) geleitet werden.
2. Die Pipe (|): Sie ist das Bindeglied. Sie reicht den Datenstrom in Echtzeit an das nächste Programm weiter.
3. split -b 3500M: Das Programm split nimmt den Strom entgegen. Sobald 3500 MB (sicher unter der 4-GB-Grenze) erreicht sind, schließt es die aktuelle Datei und öffnet eine neue (part-aa, part-ab, usw.).

Dadurch liegen am Ende auf dem Raspberry Pi vielleicht 10 Dateien à 3,5 GB. Für FAT32 ist jede dieser Dateien völlig legal, und wir haben dennoch das komplette 35-GB-Archiv gesichert.

Automatisierung und proaktives Monitoring

Ein Backup, das man manuell starten muss, ist kein Backup – es ist ein guter Vorsatz, der im Alltag untergeht. Wahre Datensicherheit entsteht erst durch radikale Automatisierung. Wir nutzen den Cron-Daemon von Linux, um unsere Skripte jede Nacht um 03:00 Uhr zu triggern, wenn die Systemlast am geringsten ist.

Doch Automatisierung ohne Rückmeldung ist gefährlich. Hier kommt unser gestern konfigurierter Postmaster auf Basis von Postfix ins Spiel. Unser Skript ist so programmiert, dass es sämtliche Log-Ausgaben sammelt. Nach Abschluss des Vorgangs – egal ob Erfolg oder Fehler – wird eine E-Mail generiert.

Warum das für SEO wichtig ist: Suchmaschinen wie Google bewerten die Zuverlässigkeit und Uptime deiner Web-Projekte. Wenn deine Website (VM 101) aufgrund eines Fehlers offline geht und du es erst Tage später merkst, stürzt dein Ranking ab. Ein automatisiertes Backup-System mit Mail-Benachrichtigung stellt sicher, dass du innerhalb von Minuten reagieren kannst. Es ist die technische Versicherung für dein SEO-Ranking.

Der Ernstfall: Wiederherstellung von gesplitteten Backups

Ein Backup-Konzept ist nur so gut wie sein Restore-Prozess. Viele Admins vergessen zu testen, ob sie die Daten auch wiederherstellen können. Bei gesplitteten Dateien wirkt der Prozess erst kompliziert, ist aber dank des cat-Befehls (Concatenate) trivial:

# Die Teile auf dem Host wieder zusammenfügen
cat vzdump-102-part-* > /tmp/full-backup.vma.zst

# Integrität prüfen und mit Proxmox-Tools wiederherstellen
qmrestore /tmp/full-backup.vma.zst 102 --storage local-lvm

Wichtig: Man benötigt für diesen kurzen Moment den doppelten Speicherplatz (die Fragmente plus die zusammengefügte Datei). Da wir aber unser RAM- und Speicher-Management optimiert haben, stellt dies für unseren Host kein Problem dar.

Fazit: Strategie schlägt Hardware-Limits

Die Ausrede „Meine Hardware ist zu alt“ oder „Mein Dateisystem unterstützt das nicht“ lassen wir nicht gelten. Mit technischem Verständnis für Linux-Bordmittel wie Pipes, split und cat lässt sich auch auf einem Raspberry Pi mit FAT32 eine Backup-Lösung realisieren, die Enterprise-Standards in Sachen Redundanz erfüllt. Durch die Kombination aus schnellem lokalen NTFS-Backup und gesplittetem Remote-Backup sind wir gegen fast alle Eventualitäten abgesichert.

Im letzten Teil unserer Serie führen wir alle Fäden zusammen. Wir werfen einen Blick auf die Gesamtarchitektur meines Servers. Wir schauen uns an, wie Nextcloud, Webserver, Wireguard und Pi-hole in einer harmonischen Proxmox-Umgebung zusammenarbeiten. Bleib dran für das große Finale!

Nächster Artikel: Die Homelab-Infrastruktur 2026 – Ein Blick unter die Haube.