Ein Backup ist nur so gut wie der letzte erfolgreiche Restore. Und ein Restore funktioniert nur, wenn die Daten nicht im selben Gebäude liegen, das gerade brennt, überflutet oder von Ransomware verschlüsselt worden ist. ZFS-Replikation mit TrueNAS ist der technisch überlegene Weg für Offsite-Disaster-Recovery: atomar, konsistent, inkrementell — und ohne zusätzliche Backup-Software.
Dieser Artikel erklärt, wie ZFS-Replikation intern funktioniert, wie Sie sie in TrueNAS einrichten und wie Sie ein sauberes DR-Konzept mit messbaren RPO- und RTO-Werten aufbauen.
Warum ZFS-Replikation der Goldstandard für DR ist
Andere Backup-Methoden kopieren Dateien. ZFS repliziert Zustände. Ein ZFS-Snapshot ist ein konsistenter, atomarer Abbild eines Datasets zu einem exakten Zeitpunkt — alle Schreiboperationen, die zu diesem Moment noch nicht abgeschlossen waren, sind ausgeschlossen. Das ist der Kern des Unterschieds:
- Rsync kopiert Dateien inkrementell, aber ohne Transaktionsgarantie. Eine Datenbank, die zum Zeitpunkt des Rsync-Laufs schreibt, landet in einem inkonsistenten Zustand im Backup.
- Cloud Sync überträgt Objekte oder Dateien in einen Cloud-Bucket — gut für Archivierung, aber ohne native Snapshot-Semantik.
- Veeam und ähnliche Agentenlösungen sind leistungsfähig, aber teuer, proprietär und benötigen Agenten auf den gesicherten Systemen.
- ZFS send/receive arbeitet auf Blockebene: Es überträgt nur die Blöcke, die sich seit dem letzten gemeinsamen Snapshot geändert haben — schnell, konsistent, ohne Agenten.
Der weitere Vorteil: Das Replikat auf dem Zielsystem ist ein vollständig nutzbares ZFS-Dataset. Es braucht keine Entpackung, keine Konvertierung — im Notfall wird es einfach importiert und ist sofort produktiv.
Wie ZFS send/receive funktioniert
Der erste Replikationslauf überträgt einen vollständigen Snapshot. Alle folgenden Läufe nutzen inkrementelle Snapshots:
# Vollständiger initialer Transfer (Quelle → Ziel)
zfs send tank/data@2026-03-29-00:00 | ssh backup@dr-site.example.com zfs receive backup/data
# Inkrementeller Transfer: nur die Änderungen seit dem letzten Snapshot
zfs send -i tank/data@2026-03-28-00:00 tank/data@2026-03-29-00:00 \
| ssh backup@dr-site.example.com zfs receive backup/dataDer -i-Parameter gibt den Ausgangssnapshot an. ZFS berechnet dann nur die geänderten Blöcke zwischen den beiden Snapshots — bei einem 10-TB-Dataset mit täglich 50 GB Änderungen überträgt der inkrementelle Lauf nur diese 50 GB, nicht 10 TB.
Für Produktionsumgebungen empfiehlt sich der -R-Flag, der alle Kind-Datasets und Snapshots rekursiv repliziert:
zfs send -Ri tank/data@2026-03-28-00:00 tank/data@2026-03-29-00:00 \
| ssh backup@dr-site.example.com zfs receive -F backup/dataReplikation in der TrueNAS-GUI einrichten
TrueNAS kapselt zfs send/receive in einer komfortablen GUI. Die Einrichtung erfolgt unter Data Protection > Replication Tasks.
Schritt 1: Quelle und Ziel definieren
Data Protection > Replication Tasks > Add
Source Location: On this System
Source Dataset: tank/data
Recursive: Ja (empfohlen, repliziert Kind-Datasets)
Destination Location: On a Different System
SSH Connection: dr-truenas (vorher unter System > SSH Connections anlegen)
Destination Dataset: backup/dataSchritt 2: Snapshot-Strategie
Replikation ohne Snapshot-Zeitplan ist nutzlos. Unter Data Protection > Periodic Snapshot Tasks legen Sie fest, wie häufig Snapshots erstellt werden:
Dataset: tank/data
Recursive: Ja
Schedule: Stündlich (empfohlen für RPO < 1 Stunde)
Keep: 24 stündliche + 7 tägliche + 4 wöchentliche SnapshotsDer Replikations-Task referenziert diese Snapshots und überträgt nur die jeweils neuen.
Schritt 3: Zeitplan und Optionen
Schedule: Stündlich (nach dem Snapshot-Task)
Replication from Scratch: Nein (nur beim ersten Lauf nötig)
Encryption: Ja (nutzt SSH-Transport-Verschlüsselung)
Limit (Bandwidth): 50 MiB/s (optional, verhindert WAN-Sättigung)Schritt 4: SSH-Verbindung zum Ziel-TrueNAS
Unter System > SSH Connections > Add wird die Verbindung zum DR-System konfiguriert:
Name: dr-truenas
Setup Method: Semi-automatic (empfohlen zwischen TrueNAS-Systemen)
TrueNAS URL: https://10.20.30.1
Username: replication
Password: [einmalig für Key-Exchange benötigt]TrueNAS tauscht dabei automatisch SSH-Keys aus. Nach dem initialen Setup ist keine Passwort-Authentifizierung mehr erforderlich — der Replikations-Task läuft vollautomatisch mit Key-Authentifizierung.
Bandbreitenlimitierung: WAN-Leitung nicht überlasten
Der erste vollständige Replikationslauf eines großen Datasets kann eine WAN-Leitung tagelang saturieren. TrueNAS bietet zwei Mechanismen zur Kontrolle:
Option 1: Limit im Replication Task — direkt in der GUI unter Limit (bytes/second). Der Wert wird in Bytes angegeben: 50 MiB/s = 52428800.
Option 2: pv (Pipe Viewer) auf der CLI für feingranulare Kontrolle beim manuellen Transfer:
zfs send -Ri tank/data@snap-alt tank/data@snap-neu \
| pv --rate-limit 52428800 \
| ssh backup@dr-site.example.com zfs receive backup/dataFür den initialen Seed-Transfer eines sehr großen Datasets empfiehlt sich ein anderer Weg: Das Ziel-Dataset wird lokal auf einer externen Festplatte vorbereitet, physisch zum DR-Standort transportiert und dort importiert. Danach übernimmt die reguläre inkrementelle Replikation über das WAN — und überträgt nur noch die Änderungen seit dem Seed.
Replikation auf VPS oder Cloud-Instanz
Wer keinen zweiten TrueNAS-Standort betreibt, kann ZFS-Replikation auf einem VPS einrichten, der ebenfalls ZFS ausführt (z. B. Ubuntu 22.04 + OpenZFS):
# Auf dem VPS: ZFS-Pool auf einem Volume-Block-Device erstellen
zpool create backup /dev/vdb
# Dann empfängt der VPS Replikate per SSH:
# (Auf TrueNAS wird der VPS als SSH Connection konfiguriert)Für rein cloud-native Ablage (S3, Backblaze B2) ersetzt rclone in Kombination mit ZFS-Snapshots den direkten zfs receive-Ansatz:
# Snapshot als Stream exportieren, komprimieren und in S3 hochladen
zfs send -Ri tank/data@snap-alt tank/data@snap-neu \
| gzip \
| rclone rcat s3:mein-backup-bucket/data-$(date +%F).zfs.gzDieser Ansatz ist günstiger als ein VPS mit großem Block-Storage, verzichtet aber auf die sofortige Importierbarkeit — für den Restore muss der Stream zurückgeholt und mit zfs receive importiert werden.
RPO und RTO: Was wirklich zählt
RPO (Recovery Point Objective) beschreibt den maximal akzeptablen Datenverlust im Katastrophenfall — gemessen in Zeit. Bei stündlicher Replikation ist der RPO theoretisch 1 Stunde: Im schlimmsten Fall gehen die letzten 59 Minuten vor dem Ausfall verloren.
RTO (Recovery Time Objective) beschreibt, wie schnell das System nach einem Ausfall wieder produktiv ist. Bei ZFS-Replikation ist der RTO gering, weil kein Restore-Prozess nötig ist — das Replikat wird direkt importiert und freigegeben.
| Replikationsintervall | RPO (worst case) | Typischer Einsatz |
|---|---|---|
| Stündlich | 60 Minuten | Produktionsdaten, Datenbanken |
| 4-stündlich | 4 Stunden | Sekundäre Systeme |
| Täglich | 24 Stunden | Archivdaten, Entwicklungsumgebungen |
| Kontinuierlich (sync) | Nahe 0 | Kritische Finanz- oder Medizindaten |
Kontinuierliche Replikation (synchrones ZFS-Mirroring über zwei Standorte) ist technisch möglich, erfordert aber eine Netzwerkverbindung mit sehr niedriger und stabiler Latenz zwischen den Standorten.
Failover testen: Repliziertes Dataset importieren
Ein DR-Plan, der nicht getestet wurde, ist kein DR-Plan. Das Importieren eines replizierten ZFS-Datasets ist bewusst einfach gehalten:
# Dataset auf dem DR-System schreibbar machen (read-only-Flag entfernen)
zfs set readonly=off backup/data
# Alternativ: neues Dataset aus Snapshot klonen (non-destructive)
zfs clone backup/data@2026-03-29-00:00 restore/data-test
# Freigabe per NFS oder SMB aktivieren (auf dem DR-TrueNAS per GUI)Empfehlung: Führen Sie den Failover-Test mindestens quartalsweise durch — nicht nur als technischen Check, sondern als vollständiges Prozess-Walkthrough: Wer entscheidet den Failover? Wer aktiviert die Freigaben? Wer informiert die Nutzer?
Vergleich: DR-Methoden im Überblick
| Methode | Konsistenz | RPO | RTO | Komplexität | Kosten |
|---|---|---|---|---|---|
| ZFS Replikation | Sehr hoch (atomar) | Minuten bis Stunden | Sehr niedrig | Mittel | Niedrig |
| Cloud Sync (rclone/S3) | Mittel | Stunden | Mittel (Restore nötig) | Niedrig | Variabel |
| Rsync | Niedrig (kein Snapshot) | Stunden | Mittel | Niedrig | Sehr niedrig |
| Veeam / Agentenlösung | Sehr hoch | Minuten bis Stunden | Niedrig | Hoch | Hoch |
ZFS-Replikation kombiniert die Konsistenz einer Agentenlösung mit den niedrigen Kosten von Rsync — bei deutlich besserem RTO als Cloud Sync.
Monitoring mit DATAZONE Control
Replikation, die still fehlschlägt, ist schlimmer als keine Replikation — denn sie erzeugt ein falsches Sicherheitsgefühl. DATAZONE Control überwacht alle TrueNAS-Replikations-Tasks kontinuierlich:
- Task-Status: Letzter erfolgreicher Lauf, Fehlermeldungen, Übertragungsdauer
- Dataset-Aktualität: Vergleich des neuesten Snapshots auf Quelle und Ziel — Abweichung über dem RPO-Schwellenwert löst einen Alarm aus
- Netzwerk-Durchsatz: Erkennung von Bandbreitenengpässen, die Replikationsfenster verschieben
- Snapshot-Verbrauch: Erkennung aufgelaufener, nicht bereinigter Snapshots, die den Pool füllen
Bei jedem Replikationsfehler erhält das zuständige Team sofort eine Benachrichtigung — lange bevor das nächste DR-Fenster verpasst wird.
Fazit
ZFS-Replikation mit TrueNAS ist die technisch sauberste Methode für Offsite-Disaster-Recovery im KMU-Umfeld: keine proprietären Agenten, keine komplexen Backup-Formate, kein manueller Restore-Prozess. Das Replikat ist jederzeit ein vollständig nutzbares Dataset — Import, Freigabe, produktiv.
Der Schlüssel ist Konsequenz: Regelmäßige Snapshots, getesteter Failover und kontinuierliches Monitoring. Replikation, die nicht überwacht und nicht getestet wird, ist nur eine Illusion von Sicherheit.
Sie möchten ZFS-Replikation für Ihre TrueNAS-Umgebung einrichten und Ihr Disaster-Recovery-Konzept auf eine solide technische Basis stellen? Kontaktieren Sie uns — wir planen RPO, RTO und Replikationsarchitektur passend zu Ihrer Infrastruktur.
Mehr zu diesen Themen:
Weitere Artikel
Backup-Strategie für KMU: Proxmox PBS + TrueNAS als zuverlässiges Backup-Konzept
Backup-Strategie für KMU mit Proxmox PBS und TrueNAS: 3-2-1-Regel umsetzen, PBS als primäres Backup-Target, TrueNAS-Replikation als Offsite-Kopie, Retention Policies und automatisierte Restore-Tests.
TrueNAS mit MCP: KI-gestützte NAS-Verwaltung per natürlicher Sprache
TrueNAS mit MCP (Model Context Protocol) verbinden: KI-Assistenten für NAS-Verwaltung, Status-Abfragen, Snapshot-Erstellung per Chat, Sicherheitsaspekte und Zukunftsausblick.
ZFS SLOG und Special VDEV: Sync Writes beschleunigen und Metadaten optimieren
ZFS SLOG (Separate Intent Log) und Special VDEV erklärt: Sync Writes beschleunigen, SLOG-Sizing, Special VDEV für Metadaten, Hardware-Auswahl mit Optane und Risiken bei Ausfall.