TrueNAS ZFS-Replikation: Bandbreite drosseln ohne Backup-Lücke

ZFS-Replikation ist eines der stärksten Argumente für TrueNAS: blockbasiert, inkrementell, kryptografisch geprüft und mit nahezu beliebiger Frequenz planbar. In der Praxis scheitert die Einführung aber selten an ZFS selbst, sondern am Uplink. Ein 10-TB-Pool, der nachts ein paar hundert Gigabyte Delta erzeugt, kollidiert auf einem 100-Mbit-Anschluss schnell mit Telefonie, Cloud-Backups oder den ersten Anwendern, die um 6:30 Uhr ihren Outlook-Cache synchronisieren.

Dieser Artikel zeigt, wie Sie die Bandbreite einer TrueNAS-Replikation gezielt drosseln, ohne dass Ihr RPO (Recovery Point Objective) aus dem Ruder läuft. Wir betrachten den eingebauten speed_limit, den Klassiker pv, den Puffer-Spezialisten mbuffer sowie die Zeitfenster-Logik im TrueNAS-Scheduler — jeweils mit konkreten Werten für ein typisches SMB-Szenario.

Das Szenario: 10 TB Pool, 100 Mbit Offsite

Als Referenz dient ein mittelständischer Kunde im Raum Neuburg/Donau: ein primäres TrueNAS SCALE 25.04 mit 10 TB Nutzdaten (VM-Images, Dateifreigaben, Veeam-Repository), das auf ein zweites TrueNAS in einem Rechenzentrum repliziert wird. Der Offsite-Anschluss liefert 100 Mbit symmetrisch, abzüglich Overhead bleiben in der Praxis rund 11 MB/s. Tägliches Delta: 80 — 250 GB, abhängig von Veeam-Jobs und Datenbank-Wartung.

Ohne Drosselung saturiert die Replikation den Uplink komplett. Mitarbeiter melden langsame Cloud-Tools, VoIP-Gespräche brechen ab, und der Geschäftsführer steht spätestens am dritten Tag im Serverraum. Gleichzeitig darf die Replikation nicht so stark gedrosselt werden, dass das vereinbarte RPO von vier Stunden verletzt wird.

Variante 1: Eingebauter speed_limit im TrueNAS-Replikationsjob

TrueNAS SCALE bringt seit 24.04 einen sauberen Schalter mit, der die meisten Anwendungsfälle abdeckt. Im Webinterface unter Data Protection -> Replication Tasks -> Edit finden Sie das Feld Limit (KiB/s). Der Wert wird intern an zettarepl weitergereicht und greift auf den ZFS-Send-Stream, bevor dieser über SSH verschickt wird.

Sinnvolle Richtwerte für unser Szenario:

Zeitfenster	Limit	Effektiv	Anwendungslogik
06:00 — 18:00	2.048 KiB/s	~2 MB/s	Geschaeftszeit, VoIP-Prioritaet
18:00 — 22:00	6.144 KiB/s	~6 MB/s	Ramp-up, weniger Nutzer
22:00 — 06:00	0 (unlimited)	~11 MB/s	Volle Bandbreite
Wochenende	0 (unlimited)	~11 MB/s	Volle Bandbreite

In dieser Staffelung repliziert das System auch tagsueber laufend, sodass das RPO nie reissen kann. Faellt nachts mal ein Window aus, holt die naechste Nacht den Rueckstand auf, ohne dass die Anwender etwas merken.

Wichtig: Der speed_limit arbeitet pro Replikationsjob. Wenn Sie drei Datasets in drei getrennten Tasks replizieren, summieren sich die Limits. Entweder bündeln Sie die Datasets in einem rekursiven Job, oder Sie verteilen die Limits explizit.

Variante 2: Drei Zeitfenster statt eines Limits

Eleganter als ein einzelner statischer Wert sind mehrere Replication Tasks, die per Cron-Ausdruck unterschiedliche Fenster bedienen. TrueNAS erlaubt im Scheduler beliebige * * * * *-Kombinationen, und jeder Task kann ein eigenes Limit tragen.

In der Praxis hat sich bewaehrt:

• Task A “tagsueber”: alle 30 Minuten, Limit 2.048 KiB/s, aktiv 06:00 — 18:00, Mo — Fr.
• Task B “Abend”: stuendlich, Limit 6.144 KiB/s, aktiv 18:00 — 22:00.
• Task C “Nacht”: einmal um 22:30, kein Limit, laeuft, bis er fertig ist.

So bleibt das RPO unter vier Stunden, auch wenn der naechtliche Vollabzug aus irgendeinem Grund einmal scheitert. Achten Sie darauf, dass alle drei Tasks denselben Snapshot-Namespace nutzen (gleiche Naming Schema), sonst erkennt der Empfaenger das Delta nicht als kontinuierlich.

Variante 3: pv und mbuffer fuer Custom-Skripte

Nicht jeder Kunde repliziert nur ueber den TrueNAS-Wizard. Wer ZFS-Send/Receive aus eigenen Skripten heraus startet — typisch bei Cross-Vendor-Setups Richtung Proxmox-ZFS oder zu einem reinen Linux-Backupziel — greift zu den Klassikern aus der Unix-Welt.

# Drosselung auf 2 MB/s mit pv, plus 1 GB Puffer via mbuffer
zfs send -I tank/data@2026-06-01_22:00 tank/data@2026-06-02_06:00 \
  | pv -L 2m -q \
  | mbuffer -q -m 1G -s 128k \
  | ssh -c aes128-gcm@openssh.com backup@offsite.example.de \
      "mbuffer -q -m 1G -s 128k | zfs receive -s -F backup/tank/data"

pv -L 2m begrenzt den Durchsatz auf 2 MB/s. mbuffer glaettet Latenzspitzen und verhindert, dass der ZFS-Send bei jedem Netzwerk-Hickser blockiert. Der -s aes128-gcm@openssh.com-Chiffre auf der SSH-Seite senkt die CPU-Last spuerbar, ohne dass die Vertraulichkeit leidet — gerade auf kleineren NAS-Boxen mit Atom-CPUs ein wichtiger Hebel.

Wer es noch sauberer mag, ersetzt pv durch trickle, das die Drosselung pro Prozess statt pro Pipe steuert — dann lassen sich mehrere parallele Send-Streams gemeinsam auf ein Gesamtbudget begrenzen.

QoS auf der OPNsense als zweite Verteidigungslinie

Verlassen Sie sich nicht ausschliesslich auf das Limit im NAS. Wenn der Replikations-Daemon abstuerzt und neu startet, ist die letzte Konfiguration eventuell verloren — und der Vollabzug ueberrollt den Uplink. Ein Shaper auf der Firewall fängt das auf.

Auf einer OPNsense 25.04 koennen Sie eine Pipe mit fixem Bandbreitenlimit fuer den SSH-Port 22 zur Replikations-Gegenseite definieren und sie mit einem Schedule koppeln, der nur zwischen 06:00 und 22:00 aktiv ist. So entsteht ein Sicherheitsnetz: Auch wenn TrueNAS “vergisst” zu drosseln, bremst die Firewall den Strom.

Eine typische OPNsense-Konfiguration sieht so aus:

Element	Wert
Pipe Bandwidth	6 Mbit/s
Queue Weight	10
Mask	dst-ip
Schedule	Mo — Fr 06:00 — 22:00
Rule Match	proto tcp, dst 203.0.113.42, dst-port 22

RPO-Check: Wie viel Drosselung ist sicher?

Eine grobe Faustformel hilft bei der Auslegung: tägliches Delta in GB geteilt durch verfügbare Stunden ergibt die mindestens noetige Bandbreite in MB/s mal 3,6. Beispiel: 150 GB Delta in 14 verfuegbaren Stunden = 10,7 GB/h = rund 3 MB/s Dauerlast. Liegt Ihre Drosselung darunter, schiebt sich Delta in die naechste Nacht und das RPO wandert mit.

Pruefen Sie das in der TrueNAS-Web-UI unter Data Protection -> Replication Tasks -> Show Details: Dort sehen Sie pro Task die letzte Laufzeit, die uebertragene Datenmenge und die effektive Geschwindigkeit. Wer es genauer braucht, exportiert die Werte ueber die TrueNAS-API in Backup-Reports oder ein Grafana-Dashboard.

Fallstricke aus der Praxis

Drei Punkte, die in unseren Projekten regelmaessig zu Stoerungen fuehren:

1. MTU-Mismatch: Ein gedrosselter Stream kaschiert lange einen MTU-Bug. Erst wenn nachts voll repliziert wird, brechen die Sessions ab. Setzen Sie auf beiden Seiten konsistente 1500 oder 9000.
2. Snapshot-Aufraeumen: Wer mit aggressiven Hold-Policies arbeitet, riskiert, dass der Sender einen Snapshot loescht, bevor das Delta drueben angekommen ist. Halten Sie mindestens 24 Stunden Puffer.
3. SSH-Keepalive: Bei sehr starker Drosselung (unter 1 MB/s) und grossen Records killt die Firewall die Session als “idle”. ClientAliveInterval 30 auf dem Empfaenger verhindert das.

Fazit

Bandbreitendrosselung ist in TrueNAS kein Hexenwerk, sondern eine Frage der richtigen Kombination: speed_limit fuer den Standardfall, mehrere zeitlich gestaffelte Tasks fuer feinere Steuerung, pv und mbuffer fuer Custom-Skripte, und ein QoS-Shaper auf der OPNsense als Netz mit doppeltem Boden. Wer die RPO-Rechnung sauber aufstellt, kann auch ueber einen 100-Mbit-Anschluss 10-TB-Pools zuverlaessig offsite spiegeln, ohne dass der Geschaeftsbetrieb darunter leidet.

DATAZONE unterstuetzt mittelstaendische Unternehmen in Neuburg, Ingolstadt und ganz Bayern bei der Auslegung, Einfuehrung und dem Betrieb von TrueNAS-Replikationsstrecken — von der ersten Pool-Planung ueber die Bandbreiten-Auslegung bis zum Disaster-Recovery-Test. Wenn Sie Ihre Replikation absichern oder neu aufsetzen wollen, sprechen Sie uns an. Wir bringen die Praxiserfahrung aus dutzenden ZFS-Projekten mit und finden den passenden Drossel-Mix fuer Ihre Leitung.