ZFS-Replikation ist eines der leistungsfähigsten Features von TrueNAS: Auf Blockebene werden nur geänderte Daten zwischen zwei Systemen übertragen. In Kombination mit einem Virtual Air-Gap — einem dedizierten, isolierten Backup-Netzwerk — entsteht eine Backup-Lösung, die selbst gegen gezielte Ransomware-Angriffe resilient ist. Dieser Artikel zeigt den kompletten Aufbau, inspiriert von der Diskussion im T3 Podcast (Episode 058).

Grundlagen: ZFS Send/Receive

ZFS-Replikation basiert auf dem Mechanismus ZFS Send/Receive. Ein Snapshot wird serialisiert und an ein Zielsystem gesendet, wo er als identische Kopie wiederhergestellt wird.

Initiale Replikation (Full Send)

# Erster Snapshot erstellen
zfs snapshot tank/data@initial

# Vollständigen Snapshot an Remote-System senden
zfs send -Rv tank/data@initial | ssh backup-nas zfs recv -Fv backup-pool/data

Die Option -R (replication stream) sendet alle untergeordneten Datasets mit. -v zeigt den Fortschritt an.

Inkrementelle Replikation

Nach der initialen Replikation werden nur noch die Unterschiede zwischen zwei Snapshots übertragen:

# Neuen Snapshot erstellen
zfs snapshot tank/data@2026-04-13

# Nur die Differenz senden
zfs send -Rvi tank/data@initial tank/data@2026-04-13 | \
  ssh backup-nas zfs recv -Fv backup-pool/data

Die inkrementelle Übertragung ist dramatisch schneller und bandbreitenschonender als ein Full Send. Bei einem 10-TB-Dataset mit 50 GB täglicher Änderung werden statt 10 TB nur 50 GB übertragen.

TrueNAS Replication Tasks

TrueNAS SCALE bietet eine komfortable GUI zur Einrichtung von Replication Tasks, die ZFS Send/Receive automatisieren.

Push vs Pull: Zwei Ansätze

Modus	Beschreibung	Datenfluss
Push	Quell-NAS sendet aktiv an Ziel-NAS	Quelle → Ziel
Pull	Ziel-NAS holt aktiv vom Quell-NAS	Quelle ← Ziel

Push ist der einfachere Ansatz: Das Produktivsystem sendet seine Daten an das Backup-System.

Pull bietet einen Sicherheitsvorteil: Das Backup-System kontrolliert den Prozess. Das Produktivsystem benötigt keinerlei Zugriff auf das Backup-System. Für Air-Gap-Szenarien ist Pull die bessere Wahl.

SSH-Key-Konfiguration

Die Replikation nutzt SSH als Transportkanal. Für automatisierte Tasks werden SSH-Keys statt Passwörter verwendet.

Auf dem Quell-System (bei Push):

# SSH-Key generieren (auf TrueNAS über GUI oder CLI)
ssh-keygen -t ed25519 -f /root/.ssh/replication_key -N ""

# Public Key auf dem Ziel-System hinterlegen
ssh-copy-id -i /root/.ssh/replication_key.pub root@backup-nas

Auf dem Ziel-System (bei Pull):

# SSH-Key generieren
ssh-keygen -t ed25519 -f /root/.ssh/replication_key -N ""

# Public Key auf dem Quell-System hinterlegen
ssh-copy-id -i /root/.ssh/replication_key.pub root@production-nas

In der TrueNAS GUI unter Credentials > Backup Credentials > SSH Keypairs:

SSH Keypair erstellen:
├── Name: replication-to-backup
├── Private Key: (automatisch generiert)
└── Public Key: (auf dem Zielhost hinterlegen)

SSH Connection erstellen:
├── Name: backup-nas
├── Method: Semi-automatic oder Manual
├── Host: 10.0.99.10 (Backup-Netzwerk)
├── Port: 22
├── Username: root
├── Private Key: replication-to-backup
└── Cipher: AES-256-GCM (schneller als Standard)

Replication Task einrichten

In der TrueNAS GUI unter Data Protection > Replication Tasks:

Replication Task:
├── Direction: Push (oder Pull)
├── Transport: SSH
├── SSH Connection: backup-nas
├── Source:
│   ├── Dataset: tank/data
│   └── Recursive: ✓ (untergeordnete Datasets einschließen)
├── Destination:
│   └── Dataset: backup-pool/data
├── Scheduling:
│   ├── Frequency: Daily
│   ├── Time: 02:00
│   └── Begin/End: 02:00 - 06:00
├── Snapshot:
│   ├── Naming Schema: auto-%Y-%m-%d_%H-%M
│   ├── Lifetime: 30 days (auf Quelle)
│   └── Lifetime (Remote): 90 days (auf Ziel)
├── Replication:
│   ├── Incremental: ✓
│   ├── Compressed: ✓ (LZ4 für Transport)
│   └── Speed Limit: 100 MB/s (optional)
└── Retention Policy:
    └── Same as source / Custom

Scheduling-Strategien

Strategie	Frequenz	Geeignet für
Stündlich	Alle 1–4 Stunden	Geschäftskritische Daten mit niedrigem RPO
Täglich	Einmal nachts	Standard für die meisten Umgebungen
Wöchentlich	Einmal pro Woche (Wochenende)	Große Datasets mit wenig Änderung
Gestaffelt	Stündlich (werktags) + täglich (Wochenende)	Flexible Anforderungen

# Beispiel: Gestaffeltes Scheduling
Replication Task 1 (Geschäftsdaten):
├── Mo-Fr: Alle 4 Stunden (08:00, 12:00, 16:00, 20:00)
└── Sa-So: Einmal um 02:00

Replication Task 2 (Mediendaten):
└── Sonntag 03:00 (wöchentlich)

Virtual Air-Gap Aufbau

Netzwerk-Architektur

                    ┌──────────────┐
                    │  OPNsense    │
                    │  Firewall    │
                    └──┬───────┬───┘
                       │       │
              VLAN 10  │       │  VLAN 99
           ┌───────────┘       └───────────┐
           │                               │
    ┌──────┴──────┐                 ┌──────┴──────┐
    │ Produktiv-  │                 │ Backup-NAS  │
    │ TrueNAS     │                 │ TrueNAS     │
    │ 10.0.10.20  │   Replikation   │ 10.0.99.20  │
    │             │ ──────────────► │             │
    └─────────────┘                 └─────────────┘

Firewall-Regeln (OPNsense)

# VLAN 10 → VLAN 99 (Produktiv → Backup):
ALLOW  TCP  10.0.10.20  →  10.0.99.20  Port 22 (SSH/Replikation)
DENY   ANY  10.0.10.0/24 →  10.0.99.0/24  (alles andere blockieren)

# VLAN 99 → VLAN 10 (Backup → Produktiv):
DENY   ANY  10.0.99.0/24 →  10.0.10.0/24  (ALLES blockieren)

# VLAN 99 → Internet:
DENY   ANY  10.0.99.0/24 →  0.0.0.0/0     (ALLES blockieren)

# VLAN 99 → VLAN 99 (Management):
ALLOW  TCP  10.0.99.1    →  10.0.99.20  Port 443 (Web-GUI nur von Firewall)

Das Backup-NAS kann:

Eingehende SSH-Verbindungen vom Produktiv-NAS annehmen (Replikation)
Nicht ins Produktivnetz kommunizieren
Nicht ins Internet kommunizieren
Nur von der Firewall-IP aus verwaltet werden

Pull-Modus für maximale Sicherheit

Im Pull-Modus initiiert das Backup-NAS die Replikation. Die Firewall-Regeln ändern sich:

# VLAN 99 → VLAN 10 (Backup → Produktiv, nur Pull):
ALLOW  TCP  10.0.99.20  →  10.0.10.20  Port 22 (SSH/Replikation)
DENY   ANY  10.0.99.0/24 →  10.0.10.0/24  (alles andere blockieren)

# VLAN 10 → VLAN 99:
DENY   ANY  10.0.10.0/24 →  10.0.99.0/24  (ALLES blockieren)

Vorteil: Das Produktivsystem hat keinerlei Netzwerk-Zugang zum Backup-System. Selbst bei vollständiger Kompromittierung des Produktiv-NAS kann der Angreifer das Backup nicht erreichen.

Dedizierter Replikations-User mit reduzierten Rechten

Viele Anleitungen nutzen root für SSH-Verbindungen zwischen Replikationspartnern. Das ist bequem, aber gefährlich: Wird ein System kompromittiert, kann der Angreifer über die bestehende SSH-Session beliebige Befehle auf dem Gegenstück ausführen — inklusive zfs destroy auf den Backup-Snapshots.

Richtig ist ein dedizierter User auf dem Zielsystem, der ausschließlich die für Replikation nötigen ZFS-Rechte delegiert bekommt — und sonst gar nichts.

# 1. User auf dem Backup-NAS anlegen (ohne Shell-Login)
pw useradd -n replrecv -s /sbin/nologin -m -c "Replication Receiver"

# 2. SSH-Public-Key in ~replrecv/.ssh/authorized_keys hinterlegen
mkdir -p /home/replrecv/.ssh
echo "ssh-ed25519 AAAA... replication-source" >> /home/replrecv/.ssh/authorized_keys
chown -R replrecv:replrecv /home/replrecv/.ssh
chmod 700 /home/replrecv/.ssh
chmod 600 /home/replrecv/.ssh/authorized_keys

# 3. Minimale ZFS-Rechte auf dem Ziel-Dataset delegieren
zfs allow replrecv create,mount,receive,hold backup-pool/data

# 4. Rechte prüfen
zfs allow backup-pool/data

Was dieser User nicht kann:

zfs destroy — Snapshots oder Datasets löschen
zfs rollback — Snapshots zurückrollen
zfs send — Daten zurück zum Produktivsystem übertragen
Login per Shell — kein interaktiver Zugriff möglich
Dateien außerhalb des delegierten Datasets verändern

Selbst wenn das Produktivsystem kompromittiert wird und der Angreifer den privaten SSH-Key in die Hände bekommt, kann er auf dem Backup-NAS nur neue Snapshots empfangen — nicht aber bestehende löschen. Die Retention auf dem Ziel wird ausschließlich durch eine lokale Snapshot-Task auf dem Backup-NAS gesteuert, nicht durch den Replication-User.

# Auf dem Backup-NAS: eigene Retention-Policy (unabhängig vom Source)
zfs set com.sun:auto-snapshot:daily=true backup-pool/data
zfs set com.sun:auto-snapshot:weekly=true backup-pool/data

# Periodic Snapshot Task in der GUI:
# Data Protection > Periodic Snapshot Tasks > Add
#   Dataset: backup-pool/data
#   Lifetime: 90 days (unabhängig vom Source-Lifetime)
#   Naming: local-%Y-%m-%d_%H-%M

Zusätzlich sollte der SSH-Zugang des Users in ~/.ssh/authorized_keys eingeschränkt werden:

command="/sbin/zfs receive backup-pool/data",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-ed25519 AAAA... replication-source

Damit kann der Key ausschließlich zfs receive auf genau diesem Dataset ausführen — beliebige andere Befehle werden von sshd abgewiesen. Das ist die stärkste Ausbaustufe: Selbst mit Key in der Hand kann der Angreifer keinen anderen Befehl als Daten-Empfang anstoßen.

Snapshot Retention

Auf dem Quell-System (Produktiv-NAS)

Snapshots auf dem Produktivsystem dienen primär der schnellen Wiederherstellung (z. B. versehentlich gelöschte Dateien):

Snapshot Retention (Quelle):
├── Hourly:   24 (letzten 24 Stunden)
├── Daily:    7  (letzte Woche)
├── Weekly:   4  (letzter Monat)
└── Monthly:  0  (keine, das übernimmt das Backup-NAS)

Auf dem Ziel-System (Backup-NAS)

Das Backup-NAS hält Snapshots für die Langzeitarchivierung:

Snapshot Retention (Ziel):
├── Daily:    30  (letzter Monat)
├── Weekly:   12  (letztes Quartal)
├── Monthly:  12  (letztes Jahr)
└── Yearly:   3   (3 Jahre Archiv)

Retention in TrueNAS konfigurieren

Data Protection > Periodic Snapshot Tasks:
├── Dataset: tank/data
├── Recursive: ✓
├── Schedule: Hourly
├── Lifetime: 24 Hours
├── Naming Schema: auto-%Y-%m-%d_%H-%M
└── Enabled: ✓

Data Protection > Periodic Snapshot Tasks (2):
├── Dataset: tank/data
├── Schedule: Daily (00:00)
├── Lifetime: 7 Days
└── Naming Schema: daily-%Y-%m-%d

Disaster Recovery Workflow

Szenario 1: Einzelne Dateien wiederherstellen

# Auf dem Produktiv-NAS: Verfügbare Snapshots anzeigen
zfs list -t snapshot tank/data | tail -10

# Snapshot mounten und Dateien kopieren
mkdir /mnt/restore
mount -t zfs tank/data@daily-2026-04-12 /mnt/restore

# Datei zurückkopieren
cp /mnt/restore/documents/wichtig.docx /mnt/tank/data/documents/

# Snapshot unmounten
umount /mnt/restore

In der TrueNAS GUI einfacher: Datasets > data > Snapshots > Browse

Szenario 2: Komplettes Dataset wiederherstellen

# Auf dem Backup-NAS: Dataset vom Backup zum Produktiv-NAS senden
zfs send -Rv backup-pool/data@daily-2026-04-12 | \
  ssh production-nas zfs recv -Fv tank/data-restored

# Auf dem Produktiv-NAS: Altes Dataset umbenennen und neues aktivieren
zfs rename tank/data tank/data-corrupted
zfs rename tank/data-restored tank/data

# SMB/NFS-Shares prüfen und ggf. neu starten
systemctl restart smbd

Szenario 3: Kompletter NAS-Ausfall (Bare-Metal Recovery)

Neues TrueNAS installieren auf der Ersatz-Hardware
ZFS-Pool importieren (wenn Disks noch funktionieren) oder:
Replikation vom Backup-NAS zum neuen System starten

# Auf dem Backup-NAS: Vollständige Replikation zum neuen System
zfs send -Rv backup-pool/data@daily-2026-04-12 | \
  ssh new-production-nas zfs recv -Fv tank/data

SMB/NFS-Shares, Benutzer und Konfiguration wiederherstellen
Replication Tasks auf das neue System umkonfigurieren

Recovery Time Objective (RTO) und Recovery Point Objective (RPO)

Szenario	RPO	RTO
Datei-Wiederherstellung (lokal)	Letzter Snapshot (1–4 Stunden)	Minuten
Dataset-Restore vom Backup	Letzter replizierter Snapshot (4–24 Stunden)	1–4 Stunden
Bare-Metal Recovery	Letzter replizierter Snapshot	4–12 Stunden

Monitoring und Alerting

Replikations-Status überwachen

# Letzten Replikations-Job prüfen
midclt call replication.query | python3 -m json.tool | grep -A5 state

# Letzte Snapshots auf dem Backup-NAS
zfs list -t snapshot -o name,creation backup-pool/data | tail -5

Alerts konfigurieren

In TrueNAS unter System > Alert Settings:

Alert Rules:
├── Replication Failed:    ✓ Critical (E-Mail + Notification)
├── Replication Delayed:   ✓ Warning (> 2x normales Intervall)
├── Snapshot Space:        ✓ Warning (> 80% des Pools)
└── Pool Health:           ✓ Critical (Degraded/Faulted)

Regelmäßige Restore-Tests

Ein Backup ohne Restore-Test ist kein Backup. Empfehlung:

Restore-Test-Plan:
├── Wöchentlich:   Einzelne Dateien stichprobenartig wiederherstellen
├── Monatlich:     Komplettes Dataset in Test-Umgebung restoren
├── Quartalsweise: Bare-Metal Recovery simulieren
└── Dokumentation: Jeder Test wird mit Ergebnis protokolliert

Performance-Optimierung

Komprimierung während der Übertragung

# ZFS Send mit LZ4-Komprimierung über SSH
zfs send -Rv tank/data@snap | lz4 | ssh -c aes256-gcm@openssh.com backup-nas "lz4 -d | zfs recv -Fv backup-pool/data"

SSH-Cipher-Optimierung

Der SSH-Cipher hat erheblichen Einfluss auf die Übertragungsgeschwindigkeit:

Cipher	Durchsatz (ca.)	Sicherheit
`aes256-gcm@openssh.com`	800–1200 MB/s	Sehr hoch
`chacha20-poly1305`	400–600 MB/s	Sehr hoch
`aes128-ctr`	600–900 MB/s	Hoch

In der TrueNAS SSH-Connection kann der Cipher explizit konfiguriert werden.

Bandwidth-Limiting

Für Umgebungen, in denen die Replikation den Produktivbetrieb nicht stören darf:

Replication Task > Speed Limit:
├── Werktags 08:00-18:00:  50 MB/s  (Bürozeiten)
└── Nachts/Wochenende:     Unlimited

Fazit

TrueNAS ZFS-Replikation in Kombination mit einem Virtual Air-Gap ist eine der effektivsten Backup-Strategien für KMU und Homelabs. Die blockbasierte, inkrementelle Übertragung minimiert Bandbreite und Zeit, während die Netzwerk-Isolation das Backup vor Ransomware schützt. Der Pull-Modus bietet die höchste Sicherheit, da das Produktivsystem keinen Zugriff auf das Backup hat. Mit klar definierten Retention-Policies und regelmäßigen Restore-Tests entsteht ein resilientes Backup-System, das im Ernstfall den Geschäftsbetrieb retten kann.

TrueNAS Replikation: Air-Gap Backup mit ZFS Send/Receive