ZFS Snapshot-Replikation in TrueNAS SCALE: Remote Backup mit Push und Pull

ZFS Snapshot-Replikation ist eine der mächtigsten Funktionen von TrueNAS für Disaster Recovery und Datensicherung. Im Gegensatz zu herkömmlichen Backup-Lösungen nutzt die Replikation die inhärenten Snapshots von ZFS, um effiziente, punkt-in-time-konsistente Kopien zwischen Systemen zu erstellen.

Dieser Artikel erklärt das Prinzip der Remote-Replikation in TrueNAS SCALE, zeigt den Unterschied zwischen Push- und Pull-Replikation und führt durch die GUI-Konfiguration.

Hinweis zu TrueNAS CORE: Die GUI und Konfiguration in TrueNAS CORE (FreeBSD-basiert) ist sehr ähnlich. Replikation zwischen CORE und SCALE ist möglich – idealerweise von CORE zu SCALE, da SCALE die neuere ZFS-Version verwendet und ZFS abwärtskompatibel ist. Eine Replikation von SCALE zu CORE kann bei neueren ZFS-Features zu Kompatibilitätsproblemen führen.

Was ist ZFS Snapshot-Replikation?

#

Das Grundprinzip

#

ZFS Snapshots sind read-only Momentaufnahmen eines Datasets zu einem bestimmten Zeitpunkt. Die Replikation überträgt diese Snapshots zwischen verschiedenen TrueNAS-Systemen, wodurch eine exakte Kopie der Daten am Zielort entsteht.

TrueNAS verwendet intern zettarepl , ein Python-Framework für ZFS-Replikation, das die gesamte Snapshot-Verwaltung, SSH-Kommunikation und Scheduling übernimmt. Die GUI ist letztlich ein Frontend für dieses leistungsfähige Tool.

Hinweis für Fortgeschrittene: Zettarepl ist nicht zwingend erforderlich. Wer lieber direkte Kontrolle möchte, kann Replikation manuell mit zfs send/zfs receive und Cronjobs konfigurieren:

# Beispiel: Snapshot erstellen und via SSH replizieren
zfs snapshot tank/data@backup-$(date +%Y%m%d-%H%M%S)
zfs send -I tank/data@previous tank/data@latest | ssh backup-server "zfs receive backup/data"

Die GUI bietet jedoch deutlich mehr Komfort:

• Automatisches Snapshot-Management: Integration mit Periodic Snapshot Tasks
• Snapshot-Filterung: Auswahl über Naming Schema (auto-%Y-%m-%d_%H-%M) oder reguläre Ausdrücke
• Fehlerbehandlung: Automatische Wiederholungsversuche bei temporären Fehlern
• Logging und Status-Überwachung: Detaillierte Logs und Real-Time-Status in der GUI
• Retention-Management: Automatische Löschung alter Snapshots nach Zeitplan

Wichtige Eigenschaften:

• Inkrementiell: Nach dem initialen Transfer werden nur Änderungen (Deltas) übertragen
• Konsistent: Snapshots sind immer in einem konsistenten Zustand (atomare Operation)
• Effizient: ZFS sendet nur geänderte Blöcke, nicht ganze Dateien
• Komprimiert: Daten werden während der Übertragung komprimiert (wenn konfiguriert)

Abgrenzung zu anderen Backup-Methoden

#

Snapshot-Replikation vs. Rsync/File-Copy:

• Replikation arbeitet auf ZFS-Block-Ebene, nicht auf Datei-Ebene
• Deutlich effizienter bei großen Datasets mit vielen kleinen Änderungen
• Behält ZFS-Eigenschaften (Compression, Deduplication, etc.)
• Kann verschlüsselte Datasets replizieren, ohne sie zu entschlüsseln

Snapshot-Replikation vs. traditionelle Backups:

• Block-Level-Transfer statt File-Level
• Replikation ist geografisch getrennt möglich
• Replikation behält Historie (mehrere Snapshots)

Remote-Replikation: Push vs. Pull

#

TrueNAS SCALE unterstützt zwei Replikationsmodi, die unterschiedliche Anwendungsfälle abdecken: Push und Pull.

Push-Replikation (Standard)

#

Funktionsweise:

Das Quellsystem initiiert die Verbindung zum Zielsystem und “schiebt” die Snapshots zum Remote-Server.

[Quell-TrueNAS] --SSH--> [Ziel-TrueNAS]
     (aktiv)              (passiv)

Konfiguration:

• Source Location: On this System
• Destination Location: On a Different System
• SSH-Verbindung vom Quellsystem zum Ziel konfigurieren

Vorteile:

• Einfacheres Security-Modell: Nur das Quellsystem benötigt Zugriff auf das Ziel
• Zentrale Kontrolle: Backup-Zeitplan wird auf dem Quellsystem verwaltet
• Typischer Anwendungsfall: Produktionssystem pusht zu Backup-System

Sicherheitsrisiko bei Push-Replikation:

Bei Push-Replikation hat das Quellsystem Schreibzugriff auf das Zielsystem. Ein Angreifer, der das Quellsystem kompromittiert, kann:

• Snapshots am Ziel löschen (inklusive älterer Backups)
• Snapshots am Ziel manipulieren (durch Löschen und Neusenden)
• Ransomware-Szenarien: Angreifer verschlüsselt Quelle UND löscht Backups am Ziel

Unter TrueNAS wird das erschwert, da das Zielsystem eine eigene SSH-Key benötigt, der ist aber nicht im Filesystem des Quellsystems gespeichert, sondern in der Config-Datenbank des Quellsystems. Aber ein Angriffeer könnte den Key aus der Config-Datenbank des Quellsystems extrahieren und verwenden.

Pull-Replikation

#

Funktionsweise:

Das Zielsystem initiiert die Verbindung und “zieht” Snapshots vom Quellsystem.

[Quell-TrueNAS] <--SSH-- [Ziel-TrueNAS]
     (passiv)              (aktiv)

Konfiguration:

• Source Location: On a Different System
• Destination Location: On this System
• SSH-Verbindung vom Zielsystem zur Quelle konfigurieren

Wichtig bei Pull-Replikation:

Bei der Pull-Replikation müssen die Snapshots auf dem Quellsystem erstellt werden, nicht auf dem Ziel. Das bedeutet:

• Auf dem Quellsystem muss ein Periodic Snapshot Task konfiguriert sein
• Das Zielsystem repliziert nur bereits existierende Snapshots
• Der Replication-Task am Ziel kann keine Snapshots auf der Quelle erstellen

Vorteile:

• Backup-System kontrolliert Zeitplan: Unabhängig vom Quellsystem
• Typischer Anwendungsfall: Zentrale Backup-Appliance zieht von mehreren Quellen
• Sicherheitsvorteil: Quellsystem hat keinen Schreibzugriff auf Zielsystem, Ein Angreifer kann keine Snapshots am Ziel löschen.

Herausforderungen:

• Zielsystem benötigt SSH-Zugriff auf Quellsystem
• Snapshot-Erstellung muss separat auf Quelle konfiguriert werden

Sicherheitsvorteil bei Pull-Replikation:

Bei Pull-Replikation hat das Quellsystem keinen Schreibzugriff auf das Zielsystem. Ein Angreifer, der das Quellsystem kompromittiert:

• Kann keine Snapshots am Ziel löschen (nur lesender SSH-Zugriff)
• Kann keine Backups manipulieren (Ziel kontrolliert Empfang)
• Ransomware-Schutz: Selbst bei vollständiger Kompromittierung der Quelle bleiben Backups am Ziel intakt

Best Practice für maximale Sicherheit:

• Pull-Replikation von produktiven Systemen zu dedizierten Backup-Appliances
• Read-only SSH-Keys mit eingeschränkten Berechtigungen auf Quelle
• Air-Gap-Strategie: Zusätzlich offline Backups (z.B. Tape, ausgesteckte Festplatten)

Sicherheit & Verschlüsselung

#

Advanced & Transport

#

Transport-Methoden: SSH vs. Netcat

#

Remote-Replikation unterstützt zwei Transport-Methoden für die Datenübertragung.

SSH (Standard und empfohlen)

#

SSH ist die Standard-Transport-Methode für ZFS-Replikation:

Vorteile:

• Verschlüsselt: Alle Daten werden über SSH verschlüsselt
• Authentifizierung: Public-Key-basierte Authentifizierung
• Firewall-freundlich: Standard-Port 22, meist bereits offen
• Bandbreiten-Kontrolle: TrueNAS kann Bandwidth-Limits setzen
• Kompression: Optional: SSH-Kompression; zusätzlich zur ZFS-Stream-Kompression

Nachteile:

• CPU-Overhead: Verschlüsselung kostet Rechenleistung
• Langsamerer Transfer: Bei schnellen LANs (10GbE+) kann SSH zum Bottleneck werden

Netcat (für schnelle, unverschlüsselte Transfers)

#

Netcat (nc) ermöglicht unverschlüsselte, direkte Socket-Verbindungen für Bulk-Daten:

Wichtig zu verstehen:

Auch bei Netcat-Replikation wird SSH weiterhin benötigt:

• SSH-Verbindung: Wird für Kontrolle, Authentifizierung und ZFS-Befehle verwendet
• Netcat-Kanäle: Separate TCP-Verbindungen nur für die eigentlichen ZFS-Stream-Daten
• Ablauf:
  1. TrueNAS stellt SSH-Verbindung her (Authentifizierung, Setup)
  2. Über SSH werden Netcat-Listener auf Quelle/Ziel gestartet
  3. ZFS-Snapshot-Daten fließen durch Netcat-Socket (unverschlüsselt, schnell)
  4. SSH bleibt für Koordination und Abschluss aktiv

Vorteile:

• Höchstgeschwindigkeit: Minimaler CPU-Overhead für Bulk-Daten, volle Link-Auslastung
• Ideal für 10GbE/25GbE+: Keine Verschlüsselungs-Bottlenecks für große Datenmengen
• Einfaches Protokoll: Direkter TCP-Stream ohne Overhead für Snapshot-Daten

Nachteile:

• ZFS-Daten unverschlüsselt: Snapshot-Stream wird im Klartext übertragen (SSH-Kontrolle bleibt verschlüsselt)
• Zusätzliche Ports: Netcat benötigt separate Ports (neben SSH Port 22)
• Keine Bandbreiten-Kontrolle: Volle Auslastung auf Netcat-Kanal, kann Netzwerk überlasten
• Nur für vertrauenswürdige Netze: Niemals über Internet oder unsichere LANs

Wann Netcat verwenden?

Netcat ist sinnvoll in folgenden Szenarien:

• Dediziertes Backup-VLAN ohne andere Dienste
• Initiale Replikation großer Datasets (mehrere TB) im LAN
• 10GbE+ Netzwerke wo SSH-Verschlüsselung limitiert
• Bereits verschlüsselte Datasets (raw send) - doppelte Verschlüsselung unnötig

Wichtig: Für die meisten Produktivumgebungen ist SSH die bessere Wahl. Netcat nur in isolierten, vertrauenswürdigen Netzwerken verwenden.

Active Side und Port-Range (Firewall):

• In den Replikations‑Optionen die „Active side“ definieren (Quelle oder Ziel öffnet Verbindungen)
• Feste Port‑Range konfigurieren (z.B. 35000–35100) und in der Firewall freigeben
• SSH bleibt für Steuerung aktiv (Port 22); Netcat nutzt zusätzliche Datenports

SSH-Verbindung konfigurieren

#

SSH ist die Standard-Transport-Methode und erfordert Zugriff zwischen den Systemen.

Voraussetzungen

#

Auf dem Zielsystem (bei Push) bzw. Quellsystem (bei Pull):

1. Admin-User mit Home-Directory:

   • Benutzer muss ein Home-Directory haben (NICHT /var/empty)
   • Standardmäßig /root für root-user
   • Wird für SSH-Key-Storage benötigt
   • Wichtig bei TrueNAS 13.0-U6.x (CORE): Remote-User ist immer root

2. SSH-Service aktiviert:

   • System → Services → SSH (auf “Running” setzen)
   • SSH-Service muss während der Task-Ausführung laufen (nicht nur beim Setup)
   • Password Authentication kann für das Setup kurzzeitig aktiviert werden
   • Nach dem Setup wieder deaktivieren und ausschließlich Key-Authentifizierung verwenden

3. Sudo-Rechte für ZFS-Befehle:

   • Admin-User benötigt passwordless sudo für zfs/zpool Befehle
   • In TrueNAS SCALE: Standard-Admin hat dies bereits
   • Alternative: “Use Sudo for ZFS Commands” in der GUI aktivieren (empfohlen)

SSH-Connection in der GUI erstellen

#

TrueNAS bietet zwei Methoden zur SSH-Konfiguration:

Option 1: Semi-automatic (empfohlen für TrueNAS-zu-TrueNAS):

1. Credentials → Backup Credentials → SSH Connections
2. Klick auf Add
3. Setup Method: Semi-automatic (TrueNAS only)
4. TrueNAS URL: https://remote-truenas.example.com (oder IP)
5. Admin Username/Password: Root-User des Remote-Systems
6. Name: Beschreibender Name (z.B. “offsite-backup”)

Semi-automatic erstellt automatisch:

• SSH-Key-Pair auf dem lokalen System
• Installiert Public-Key auf Remote-System
• Testet die Verbindung

Option 2: Manual (für Non-TrueNAS oder erweiterte Kontrolle):

1. SSH-Key manuell generieren
2. Public-Key auf Remote-System in ~/.ssh/authorized_keys eintragen
3. Private-Key in TrueNAS importieren

GUI-Konfiguration: Schritt für Schritt

#

Vorbereitung

#

Vor dem Start:

1. Dataset am Zielort erstellen:

   • Gehe zu Datasets
   • Erstelle ein neues Dataset für replizierte Daten (z.B. backup/replicated)
   • Wichtig: Der Wizard kann fehlende Ziel-Unterdatasets am angegebenen Pfad anlegen (keine neuen Pools)

2. Periodic Snapshot Task erstellen (Quelle):

   • Data Protection → Periodic Snapshot Tasks → Add
   • Dataset: Quell-Dataset auswählen
   • Snapshot Lifetime: z.B. 7 Tage
   • Schedule: z.B. stündlich oder täglich

Hinweis: TrueNAS kann theoretisch automatisch einen Periodic Snapshot Task erstellen, wenn keiner existiert. In der Praxis ist es jedoch empfehlenswert, den Task manuell zu erstellen, um volle Kontrolle über Naming Schema und Retention zu haben.

Push-Replikation konfigurieren

#

Szenario: Produktionssystem (lokal) soll zu Backup-System (remote) pushen.

1. Replication Task Wizard öffnen

#

• Data Protection → Replication Tasks
• Klick auf Add

Der Wizard führt durch die Konfiguration.

2. What and Where (Quelle und Ziel)

#

Source Location: On this System

• Klick auf Folder-Icon neben Source
• Dataset auswählen (z.B. tank/production)
• Recursive: Aktivieren, wenn Unterverzeichnisse inklusive sein sollen

Destination Location: On a Different System

• SSH Connection: Dropdown → Generate New oder bestehende auswählen
• Falls neu: Semi-automatic Wizard (siehe SSH-Abschnitt oben)
• Destination Dataset: Pfad auf Remote-System (z.B. backup/replicated/production)
  • Tipp: Neue Unterverzeichnisse können direkt angelegt werden durch Anhängen von /neuer-ordner am Pfad

Replicate Custom Snapshots (optional):

• Standard: Nur automatisch erstellte Snapshots (von Periodic Snapshot Tasks) werden repliziert
• Aktivieren: Um auch manuell erstellte Snapshots zu replizieren
• Naming Schema: Pattern mit strftime-Format (z.B. manual-%Y-%m-%d)
• Regex Pattern: Alternativ regulärer Ausdruck für komplexe Muster (Performance-Hinweis: Regex kann bei vielen Snapshots langsam sein)

3. When (Zeitplan)

#

Replication Schedule:

• Run On a Schedule: Aktivieren für geplante Replikation
  • Schedule: Daily, Hourly, Weekly, Monthly oder Custom (Cron)
  • Beispiel: Täglich um 02:00 Uhr
• Run Once: Einmalige Ausführung direkt nach Erstellung

Destination Snapshot Lifetime (Retention am Ziel):

• Same as Source: Identische Aufbewahrungsdauer wie Quelle
• Never Delete: Snapshots werden nicht automatisch gelöscht (manuelles Cleanup erforderlich)
• Custom: Eigene Aufbewahrungsdauer (z.B. 30 Tage, wenn Quelle nur 7 Tage behält)

Make Destination Dataset Read-only?

• Aktivieren: Verhindert versehentliche Änderungen am Ziel-Dataset
• Empfohlen für dedizierte Backup-Systeme
• Deaktivieren: Wenn am Ziel aktiv gearbeitet werden soll (nicht empfohlen für Backups)

4. Security and Task Name

#

Encryption (Dataset-Verschlüsselung am Ziel):

Diese Einstellung erstellt ein verschlüsseltes Dataset am Zielort:

• Unencrypted: Ziel-Dataset wird unverschlüsselt erstellt (Standard)
• Encrypted: Ziel-Dataset wird mit Encryption erstellt
  • Encryption Key Format: Hex (Base 16) oder Passphrase (alphanumerisch)
  • Generate Encryption Key: Automatische Key-Generierung für Ziel-Dataset
  • Store Encryption key in Sending TrueNAS database:
    • Aktiviert (Standard): Quelle speichert den Ziel-Key (ermöglicht automatische Replikation)
    • Deaktiviert: Key wird NICHT auf Quelle gespeichert (höhere Sicherheit, Ziel muss manuell entsperrt werden)

Wichtig zu verstehen:

• Diese Option erstellt Verschlüsselung am Ziel, nicht während des Transports
• Wenn deaktiviert: Ziel kennt eigenen Key nicht (Zero-Knowledge), muss nach Replikation manuell mit Key entsperrt werden
• Ideal für Offsite-Backups: Quelle kann replizieren, aber Ziel-Daten bleiben ohne separaten Key-Import unlesbar
• Unterschied zu “raw send”: Raw send repliziert bereits verschlüsselte Datasets; diese Option verschlüsselt am Ziel neu

Use Case:

• Unverschlüsselte Quelle → verschlüsseltes Ziel (z.B. für Compliance am Backup-Standort)
• Key nicht auf Quelle speichern = maximale Sicherheit (selbst bei Kompromittierung der Quelle bleibt Ziel geschützt)

Key Handling (Empfehlung):

• Schlüssel nach Möglichkeit NICHT in der Sending‑TrueNAS‑Datenbank speichern
• Schlüssel separat sichern (siehe Abschnitt „Disaster‑Recovery‑Szenario“)
• Für Pull: Schlüssel nie auf der Quelle ablegen; Ziel verwahrt eigene Keys
• Für Push: Nur speichern, wenn automatisches Entsperren betrieblich zwingend ist

Task Name: Beschreibend benennen (z.B. production-to-offsite)

• Wird automatisch aus Quelle/Ziel generiert, kann aber überschrieben werden

Advanced Options:

5. Save und Execute

#

• Save: Task wird erstellt
• Status: Erscheint als “Pending” in der Liste
• Run Now: Für initiale Replikation klicken

Pull-Replikation konfigurieren

#

Szenario: Backup-System (lokal) zieht von Produktionssystem (remote).

Unterschiede zu Push

#

Source Location: On a Different System

• SSH Connection: Verbindung zum Remote-Quellsystem
• Remote Dataset: Pfad auf Remote-System

Destination Location: On this System

• Local Dataset: Lokales Ziel-Dataset

Wichtig: SSH-Connection muss vom Backup-System zum Produktionssystem zeigen.

Alle anderen Schritte sind identisch.

Hinweise speziell für Pull

#

• Snapshots werden auf der Quelle durch Periodic Snapshot Tasks erzeugt (Ziel kann keine erstellen)
• Hold pending snapshots auf der Quelle aktivieren, damit Snapshots nicht vor Replikation gelöscht werden
• Bei mehreren Quellsystemen hilfreicher Betriebsmodus: Zentrale Backup‑Appliance zieht parallel (Bandbreitenlimit pro Task setzen)

Lokale Replikation (im selben System)

#

• Source Location: On this System → Dataset A
• Destination Location: On this System → Dataset B (anderer Pool oder anderes Dataset)
• Nützlich für Migrationen zwischen Pools oder schnelle „Kaltkopie“ im selben Host

Betrieb & Troubleshooting

#

Replikation Status prüfen

#

Data Protection → Replication Tasks:

• State: SUCCESS, PENDING, RUNNING, FAILED
• Last Snapshot Sent: Letzter replizierter Snapshot
• Enabled: Task ist aktiv

Details anzeigen:

• Klick auf Task → Expand Symbol
• Zeigt detaillierte Logs und Transfer-Statistiken

Stündlich:  auto-hourly-%Y-%m-%d_%H-%M   (behalten: 24 Stunden)
Täglich:    auto-daily-%Y-%m-%d         (behalten: 7 Tage)
Wöchentlich: auto-weekly-%Y-W%U         (behalten: 4 Wochen)
Monatlich:  auto-monthly-%Y-%m          (behalten: 12 Monate)

Mini-Glossar

#

• Raw send: ZFS sendet verschlüsselte Blöcke unverändert; Ziel erhält Daten ohne Schlüssel
• Hold: Schutzmarkierung auf Snapshots gegen Löschen (bis Replikation/Manuell entfernt)
• Stale Snapshots: Ziel‑Snapshots, die an der Quelle nicht mehr existieren (Drift)
• Resume‑Token: Marker, mit dem abgebrochene Replikationen fortgesetzt werden
• Periodic Snapshot Task: Zeitplan zur automatischen Snapshot‑Erstellung auf der Quelle
• Naming Schema: Namensmuster für Snapshots; muss mit Replikations‑Filter übereinstimmen
• Replication Task: Automatisierter zfs send/receive‑Job zwischen Quelle und Ziel
• Push/Pull: Richtung der Initiierung (Quelle schiebt / Ziel zieht)
• Netcat: Unverschlüsselter Datenpfad für den Stream; SSH bleibt Steuerkanal
• Stream‑Kompression: Komprimiert den Sendestream; meist vorteilhaft über WAN
• Large blocks / Embedded / Compressed / Dedup: ZFS‑Send‑Flags; Dedup selten sinnvoll
• Properties/ACLs: Mitübernahme von ZFS‑Eigenschaften und Berechtigungen
• snapdir: Steuert Sichtbarkeit des .zfs‑Verzeichnisses (Einzeldatei‑Restore)
• Clone/Rollback: Schreibbarer Abzweig aus Snapshot / vollständiges Zurücksetzen des Datasets
• Active side / Port‑Range: Seite, die Datenverbindungen öffnet / freizugebende Ports
• Seeding: Erste Vollübertragung lokal; danach inkrementell über WAN
• Air‑Gap: Zeitweise physisch/logisch getrennte Backups für Ransomware‑Schutz

Weiterführende Links

#

• TrueNAS SCALE Docs – Data Protection (Replikation, Snapshots, SSH)
• Zettarepl (TrueNAS Replikations‑Engine)
• OpenZFS – Konzepte zu Snapshots/Clones/Send‑Receive
• Microsoft – Volume Shadow Copy (Vorgängerversionen)

Mini-Checkliste

#

• Periodic Snapshot Task mit eindeutigem Naming Schema
• Replication Task: Hold pending + (optional) Delete stale aktivieren
• Advanced: Large blocks + Embedded + Compressed send an; Dedup send aus
• Properties/ACLs bei Bedarf mitreplizieren
• Bandwidth limit/Parallelisierung passend setzen
• SSH nur mit Keys; PasswordAuth nach Setup aus
• Netcat nur im vertrauenswürdigen LAN; Active side + Ports freigeben

Weiterführende Links

#

• TrueNAS SCALE Docs – Data Protection (Replikation, Snapshots, SSH)
• Zettarepl (TrueNAS Replikations‑Engine)
• OpenZFS – Konzepte zu Snapshots/Clones/Send‑Receive
• Microsoft – Volume Shadow Copy (Vorgängerversionen)

Fazit

#

ZFS Snapshot-Replikation in TrueNAS SCALE ist ein mächtiges Werkzeug für Disaster Recovery und Datensicherung. Der Hauptvorteil liegt in der block-basierten, inkrementellen Übertragung von konsistenten Snapshots über SSH.

Wichtige Erkenntnisse:

• Push vs. Pull: Wahl abhängig von Netzwerk-Topologie und Security-Anforderungen
• Verschlüsselung: Möglich ohne Key-Offenlegung am Zielort
• Kein automatisches Failover: Replikation ist für DR, nicht für HA gedacht
• SSH-Setup entscheidend: Semi-automatic vereinfacht Konfiguration erheblich

Für wen geeignet:

• Kleine bis mittlere Unternehmen mit TrueNAS-Infrastruktur
• Offsite-Backup-Strategien
• Compliance-Anforderungen mit Langzeit-Archivierung

Die GUI macht die Konfiguration auch ohne tiefe ZFS-CLI-Kenntnisse zugänglich, während fortgeschrittene Nutzer über Custom-Scripts und zfs send/receive noch mehr Kontrolle haben.

Ausblick:

In einem kommenden Artikel wird das Setup ohne Root-User behandelt – inklusive der Konfiguration eines dedizierten Backup-Users mit eingeschränkten ZFS-Rechten und Sudo-Delegation. Dies ist besonders wichtig für produktive Umgebungen mit strengen Security-Anforderungen.

Wim Bonis ist CTO bei Stylite AG und beschäftigt sich schwerpunktmäßig mit Storage-Lösungen und Rechenzentrumsinfrastruktur.