Proxmox Vergleich der Storage-Varianten vs. ZFS zu Fuß

Vergleich der Storage-Varianten

Ceph RBD ist shared, thin-provisioned, redundant, selbstheilend und unterstützt Snapshots sowie Clones. Lokales ZFS unterstützt ebenfalls Snapshots und Clones, ist aber nicht shared. Reines iSCSI bietet selbst keine Speicherverwaltung; Proxmox empfiehlt deshalb normalerweise eine große LUN mit LVM darüber. Proxmox Storage-Dokumentation

Besonderheit bei iSCSI

Man muss drei Varianten auseinanderhalten:

1. Direktes iSCSI

   • Fertige LUN pro VM beziehungsweise bereits auf dem SAN angelegte LUNs
   • Shared Storage
   • Keine nativen Proxmox-Snapshots oder Clones

2. iSCSI + klassisches LVM („thick“)

   • Eine große gemeinsame LUN
   • Proxmox erzeugt darin Logical Volumes
   • Speicherplatz wird fest zugeteilt
   • Clusterweites Locking durch Proxmox
   • Seit Proxmox VE 9 sind VM-Snapshots als qcow2-Volume-Chain möglich; keine effizienten LVM-thin-SnapshotSnapshots

1. ZFS over iSCSI

   • ZFS läuft auf dem entfernten Storage-Server
   • Proxmox erzeugt dort per SSH ZVOLs und exportiert diese als iSCSI-LUNs
   • Shared und snapshotfähig
   • Nicht dasselbe wie gewöhnliches iSCSI+LVM
   • Der ZFS-Storage-Server kann ohne HA-Konzept zum Single Point of Failure werden

Populäre Proxmox-Funktionen und ihre Storage-Abhängigkeit

Proxmox-Funktion versus ZFS-Kommandozeile

ZFS bietet außerdem native Snapshots, Clones und inkrementelle Replikation mittels zfs send/zfs receive; ein Scrub prüft alle Blöcke per Prüfsumme und repariert Fehler bei vorhandener Redundanz automatisch. OpenZFS-Kommandoreferenz, OpenZFS Scrub

Wichtige Praxisregel

VM-Datenträger, die Proxmox gehören, sollte man normalerweise nicht direkt mit zfs snapshot, zfs clone, zfs rollback, zfs rename oder zfs destroy verändern. Proxmox weiß sonst nichts von diesen Änderungen:

Snapshots erscheinen nicht korrekt in der VM-Konfiguration. Mehrere VM-Festplatten werden möglicherweise nicht konsistent aufgenommen. Replikation und Löschvorgänge können durcheinandergeraten. Ein manuelles Rollback kann den Zustand der VM-Konfiguration und der Platten auseinanderlaufen lassen.

Für VM-Operationen deshalb bevorzugt qm, pct, pvesm, die API oder die Weboberfläche verwenden. Die ZFS-Kommandozeile ist ideal für Pool-Gesundheit, Scrubs, Plattentausch, Kompression, Kapazitätsanalyse und bewusst geplante externe Replikation.

Kurzempfehlung

1–2 Nodes, einfache und robuste Lösung: lokales ZFS. 3 oder mehr geeignete Nodes und echtes Storage-HA: Ceph RBD. Vorhandenes professionelles SAN: iSCSI + LVM thick. Thin Provisioning und schnelle Clones benötigt: Ceph oder ZFS. Maximal vorhersehbare Platzbelegung: iSCSI + LVM thick. ZFS per CLI vollständig selbst verwalten: gut für Storage-Administratoren, aber Proxmox-eigene VM-Volumes weiterhin über Proxmox bedienen.

Sendungsablauf: Proxmox GUI, ZFS und sichere Replikation

In der Sendung bauen wir eine mehrstufige Schutzstrategie für Proxmox-VE-Systeme auf:

ZFS erstellt engmaschige lokale Wiederherstellungspunkte.

ZFS-Funktionen ermöglichen Datei-Restore, Rollback und Klone.

Der Pool wird durch sinnvolle Geräteklassen und schnelle Reparatur robust gehalten.

zsync holt die Daten vom Proxmox-Server auf ein getrenntes Ziel.

checkzfs.py kontrolliert anhand der Snapshot-GUIDs, ob das Replikat wirklich angekommen ist.

Der Miyagi-Workflow verbindet ZFS-Replikation, Proxmox Backup Server, Monitoring und einen zeitweise ausgeschalteten Sicherungsserver.

Der entscheidende Unterschied:

Ein Snapshot schützt kurzfristig vor Fehlbedienung und unerwünschten Änderungen.

Ein Replikat schützt zusätzlich vor dem Ausfall des Quellservers.

Ein Backup liefert eine unabhängige, längerfristige Wiederherstellungshistorie.

Monitoring kontrolliert, ob diese Mechanismen tatsächlich funktioniert haben.

1. Automatische ZFS-Snapshots

Wir richten für die relevanten ZFS-Datasets und ZVOLs folgende Aufbewahrung ein:

Intervall Aufbewahrung Anzahl Alle 15 Minuten 3 Stunden 12 Stündlich 96 Stunden 96 Täglich 14 Tage 14 Wöchentlich 6 Wochen 6 Monatlich 3 Monate 3

Damit existieren maximal ungefähr 131 automatische Snapshots pro Dataset oder ZVOL. Je nach Snapshot-Engine und zeitlicher Überschneidung kann die tatsächliche Zahl etwas abweichen.

Warum diese Staffelung?

Die 15-Minuten-Snapshots helfen bei gerade eben gelöschten Dateien, Fehlkonfigurationen oder einem frisch gestarteten Angriff.

Die 96 Stunden überbrücken lange Wochenenden, Feiertage und Situationen, in denen ein Problem nicht sofort bemerkt wird.

Die 14 Tagessnapshots bieten ein gröberes Raster für die letzten zwei Wochen.

Die sechs Wochensnapshots reichen deutlich weiter zurück.

Die drei Monatssnapshots helfen bei langsam oder spät erkannten Fehlern.

Für längere Zeiträume verwenden wir Proxmox Backup Server. Snapshots auf demselben Pool sind ausdrücklich kein vollständiges Backup.

Platzbedarf

Ein Snapshot ist keine vollständige Kopie des Datasets. Beim Erstellen wird zunächst praktisch kein zusätzlicher Datenbestand kopiert. ZFS hält anschließend nur die alten Blöcke fest, die durch neue Schreibvorgänge ersetzt oder im Live-Dataset gelöscht werden.

Deshalb bedeuten 131 Snapshots nicht den 131-fachen Speicherverbrauch. Der Bedarf hängt von der Änderungsrate ab:

Wenig veränderte Daten benötigen wenig zusätzlichen Platz.

Datenbanken, VM-Disks und häufig überschriebene große Dateien können viel Snapshot-Speicher erzeugen.

Eine im Live-System gelöschte Datei gibt keinen Platz frei, solange ein Snapshot sie noch referenziert.

Wichtige Kontrollen:

zfs list -o name,used,available,usedbysnapshots
zfs list -t snapshot -o name,creation,used
zpool list

Der Pool sollte nicht dauerhaft bis an seine Grenze gefüllt werden. Bei knappem Platz verkürzt man zuerst die Aufbewahrung und untersucht die Änderungsrate.

2. Snapshots, Rollbacks, Clones und Snapdirs

ZFS-Snapshot

Ein Snapshot ist ein unveränderlicher Zeitpunkt eines Datasets oder ZVOLs:

zfs snapshot rpool/data@vor-update

Für eine Hierarchie kann rekursiv gearbeitet werden:

zfs snapshot -r rpool/data@vor-update

Snapshots entstehen sehr schnell, weil ZFS lediglich einen neuen Referenzpunkt im vorhandenen Blockbaum anlegt. Danach arbeitet das Live-Dataset weiter, während die alten Blöcke für den Snapshot erhalten bleiben.

Wichtig bei Proxmox:

Automatische ZFS-Snapshots sind Proxmox normalerweise nicht als VM-Snapshot bekannt.

Ein ZFS-Snapshot ist zunächst crash-konsistent, aber nicht automatisch applikationskonsistent.

Datenbanken und mehrere VM-Festplatten benötigen gegebenenfalls Guest Agent, Freeze/Thaw oder anwendungsspezifische Vorbereitung.

Proxmox-eigene Snapshots, Klone und Rollbacks sollten weiterhin über Proxmox durchgeführt werden.

Einzelne Dateien zurückholen

Bei einem ZFS-Dateisystem muss nicht gleich das gesamte Dataset zurückgerollt werden. Man kann eine Datei direkt aus einem Snapshot kopieren:

cp /daten/.zfs/snapshot/daily-2026-08-31/datei \
   /daten/datei

Das ist meist die sicherste Wiederherstellung: Nur die benötigte Datei wird zurückgeholt, während alle anderen aktuellen Daten erhalten bleiben.

Snapdir

Die Snapshot-Inhalte liegen unter:

.zfs/snapshot/

Die Eigenschaft snapdir steuert, ob dieses Verzeichnis sichtbar ist:

zfs set snapdir=visible pool/daten

Mögliche Zustände sind:

hidden: Verzeichnis ist vorhanden, erscheint aber nicht in einem normalen ls.

visible: Benutzer können .zfs/snapshot sehen und ältere Dateien selbst lesen.

disabled: Zugriff über die Snapshot-Verzeichnisse ist deaktiviert.

Die Snapdir-Funktion gilt für ZFS-Dateisysteme. VM-Disks sind in Proxmox normalerweise ZVOLs und besitzen kein durchsuchbares Verzeichnis. Für Snapshot-Geräte von ZVOLs existiert stattdessen die Eigenschaft snapdev. OpenZFS: Snapshots, Clones und Snapdir

Rollback

Ein Rollback setzt das komplette Dataset auf einen Snapshot zurück:

zfs rollback pool/daten@vor-update

Dabei werden alle Änderungen nach diesem Snapshot verworfen. Das ist wesentlich invasiver als das Kopieren einer einzelnen Datei.

Standardmäßig erlaubt ZFS nur den Rollback auf den neuesten Snapshot. Ältere Zeitpunkte benötigen zusätzliche Optionen, die neuere Snapshots und möglicherweise abhängige Klone löschen können:

zfs rollback -r pool/daten@alter-stand

Ein Rollback sollte daher erst erfolgen, nachdem der aktuelle Zustand zusätzlich gesichert wurde. Bei Proxmox-ZVOLs darf ein manueller Rollback nicht unüberlegt während des VM-Betriebs stattfinden.

Clone

Ein Clone ist eine beschreibbare Kopie eines Snapshots:

zfs clone pool/daten@vor-update pool/test

Der Clone wird sofort erstellt und benötigt anfangs nur sehr wenig zusätzlichen Platz. Snapshot und Clone teilen sich die unveränderten Blöcke. Neue Schreibvorgänge des Clones belegen zusätzlichen Platz.

Typische Anwendungen:

Updates in einer Testkopie prüfen

Daten aus einem alten Zustand untersuchen

schnell eine Entwicklungs- oder Testumgebung erzeugen

eine VM oder ein Dataset temporär isoliert starten

Der Clone bleibt zunächst von seinem Ursprungssnapshot abhängig. Mit zfs promote kann diese Beziehung umgekehrt werden. Für Proxmox-VMs sollte ein VM-Clone über die Proxmox-Oberfläche oder qm clone erstellt werden, damit Proxmox die Abhängigkeiten korrekt verwaltet.

3. Schneller Replace und RAIDZ-Expansion

Schneller Plattentausch

Beim Ausfall einer Platte wird sie ersetzt:

zpool replace tank alte-platte neue-platte
zpool status tank

ZFS kennt die tatsächlich belegten Blöcke und deren Prüfsummen. Beim Resilver werden die benötigten Daten aus den verbliebenen Platten rekonstruiert und auf die neue Platte geschrieben.

Wenn die alte Platte noch lesbar ist, ist es meist besser, die neue Platte zunächst zusätzlich anzuschließen und den Replace kontrolliert zu starten. Dadurch bleibt die vorhandene Redundanz möglichst lange erhalten.

Für Spiegel kann eine sequenzielle Rekonstruktion mit zpool replace -s die Redundanz schneller wiederherstellen. Diese Option ist für RAIDZ nicht verfügbar. Nach einem sequenziellen Mirror-Rebuild startet ZFS einen Scrub zur Prüfsummenkontrolle. OpenZFS: zpool replace

RAIDZ-Expansion

Aktuelle OpenZFS-Versionen können ein bestehendes RAIDZ-vdev um jeweils eine Platte verbreitern:

zpool attach tank raidz2-0 neue-platte

Dabei gilt:

RAIDZ1 bleibt RAIDZ1.

RAIDZ2 bleibt RAIDZ2.

RAIDZ3 bleibt RAIDZ3.

Die Anzahl tolerierbarer Plattenausfälle erhöht sich nicht.

Die neue Platte muss mindestens so groß wie die kleinste vorhandene Platte sein.

Die Pool-Feature-Flag raidz_expansion muss verfügbar und aktiviert sein.

Während der Expansion werden die belegten Daten gelesen und über die verbreiterte Gruppe neu verteilt.

Der Fortschritt erscheint in zpool status.

Bei einem Plattenausfall pausiert die Expansion, bis das RAIDZ wieder gesund ist.

Alte Blöcke behalten ihr ursprüngliches Verhältnis zwischen Nutz- und Paritätsdaten. Erst neu geschriebene Blöcke nutzen die breitere RAIDZ-Geometrie vollständig. Die gewonnene Kapazität kann deshalb zunächst etwas geringer erscheinen als rechnerisch erwartet. OpenZFS: RAIDZ-Expansion

4. Spares, Cache, Logs und Special Devices

Hot Spare

Ein Spare ist eine Reserveplatte:

zpool add tank spare /dev/disk/by-id/...

Bei einem Fehler kann sie automatisch für die ausgefallene Platte einspringen. Das verkürzt die Zeit, in der der Pool degradiert läuft.

Ein Spare erhöht aber nicht die normale Fehlertoleranz:

Ein RAIDZ1 bleibt ein RAIDZ1.

Ein RAIDZ2 bleibt ein RAIDZ2.

Das Spare ist kein zusätzliches Paritätslaufwerk.

Die defekte Platte muss trotzdem dauerhaft ersetzt werden.

Nach dem regulären Replace und Resilver kann das Spare wieder als Reserve verfügbar werden.

Cache beziehungsweise L2ARC

Ein Cache-vdev erweitert den Lesecache:

zpool add tank cache /dev/nvme0n1

Die erste Cache-Stufe ist immer der ARC im RAM. L2ARC auf SSD oder NVMe ist nur die zweite Stufe.

L2ARC hilft hauptsächlich, wenn:

der aktive Datenbestand größer als der RAM ist,

viele Daten wiederholt gelesen werden,

ausreichend RAM für die L2ARC-Metadaten vorhanden ist,

zufällige Lesezugriffe der Engpass sind.

L2ARC hilft nicht automatisch bei Schreibproblemen. Weil dort nur zusätzliche Kopien vorhandener Daten liegen, ist sein Verlust für den Pool ungefährlich. Mehr RAM ist häufig wirkungsvoller als vorschnell ein Cache-Gerät einzubauen.

Log beziehungsweise SLOG

Ein Log-vdev verschiebt das ZFS Intent Log auf ein separates Gerät:

zpool add tank log mirror /dev/nvme0n1 /dev/nvme1n1

Ein SLOG ist kein allgemeiner Schreibcache. Er beschleunigt nur synchrone Schreibvorgänge, bei denen eine Anwendung die dauerhafte Speicherung bestätigt haben will.

Typische Nutznießer:

NFS

Datenbanken

VM-Storage mit vielen synchronen Schreibvorgängen

Anwendungen mit häufigem fsync()

Ein geeignetes SLOG braucht:

sehr geringe Latenz,

hohe Schreibhaltbarkeit,

Power-Loss-Protection,

bei wichtigen Systemen eine Spiegelung.

Asynchrone Schreibvorgänge werden dadurch nicht schneller. sync=disabled darf nicht als pauschaler Tuningtrick eingesetzt werden, weil damit die zugesagte Schreibsicherheit bei Stromausfall verloren geht.

Special Device

Ein Special vdev speichert dauerhaft:

ZFS-Metadaten,

indirekte Datenblöcke,

Dedup-Tabellen, falls kein separates Dedup-vdev existiert,

optional kleine Datenblöcke.

Beispiel:

zpool add tank special mirror /dev/nvme0n1 /dev/nvme1n1
zfs set special_small_blocks=32K tank/daten

Das kann einen HDD-Pool bei Verzeichniszugriffen, Scrubs, Resilvern und kleinen Dateien massiv beschleunigen.

Aber: Ein Special Device ist kein Cache. Die dort gespeicherten Blöcke existieren ausschließlich dort. Geht das komplette Special vdev verloren, ist der gesamte Pool verloren. Deshalb muss es mindestens dieselbe Redundanz wie der normale Pool besitzen. Bei einem RAIDZ-Pool ist das Hinzufügen praktisch eine dauerhafte Entscheidung. OpenZFS: Special vdev

Kurzform:

Gerätetyp Aufgabe Verlust Spare Ersatzplatte bereithalten Pool bleibt grundsätzlich intakt Cache/L2ARC Häufig gelesene Daten zwischenspeichern Unkritisch Log/SLOG Synchrone Schreibvorgänge bestätigen Risiko für jüngste Sync-Schreibvorgänge Special Metadaten und optional kleine Blöcke dauerhaft speichern Verlust kann den ganzen Pool zerstören

5. Pull-Replikation mit zsync

Die Replikation wird auf dem Zielserver gestartet:

ZFS-Quelle ── SSH/zfs send ──▶ ZFS-Ziel
                 ▲
                 │
          Ziel startet den Pull

Die Quelle schiebt ihre Daten nicht selbstständig auf das Ziel. Stattdessen verbindet sich der Zielserver mit der Quelle, ermittelt passende Datasets und holt die benötigten ZFS-Send-Streams ab.

Das ist sicherheitstechnisch wichtig: Ein kompromittierter Quellserver soll möglichst keine Berechtigung besitzen, das Ziel oder dessen ältere Stände zu löschen.

Auswahl über ZFS-Attribute

Auf der Quelle markieren wir, welche Datasets und ZVOLs repliziert werden:

zfs set bashclub:zsync=all rpool/data

Die Auswahl wird über die ZFS-Hierarchie vererbt. Mögliche Werte sind:

all: markiertes Dataset und darunterliegende Datasets replizieren

subvols: nur die untergeordneten Datasets und ZVOLs

exclude: diesen Zweig ausschließen

Der Attributname kann angepasst werden. Damit lassen sich unterschiedliche Ziele über unterschiedliche Tags steuern.

Ablauf einer Replikation

zsync läuft auf dem Ziel.

Das Ziel verbindet sich per SSH mit der Quelle.

Es liest die ZFS-Attribute und bestimmt die markierten Datasets.

Optional wird vor der Replikation ein neuer Snapshot erzeugt.

Quelle und Ziel suchen einen gemeinsamen Snapshot.

Beim ersten Lauf erfolgt ein vollständiges zfs send.

Danach werden nur die seit dem gemeinsamen Snapshot geänderten Blöcke übertragen.

Das Ziel legt automatisch den notwendigen Dataset-Pfad an.

Auf dem Ziel wird com.sun:auto-snapshot=false erzwungen.

Der Mountpoint wird übernommen, aber canmount=noauto verhindert ein versehentliches automatisches Einhängen.

Gewünschte vorhandene Snapshots werden anhand von snapshot_filter mitgenommen.

Die Replikation erfolgt als Raw Stream.

Raw Replikation ist insbesondere bei verschlüsselten ZFS-Datasets sinnvoll: Die verschlüsselten Blöcke können ohne Entschlüsselung auf dem Ziel übertragen und gespeichert werden.

Beispielhafte Zielkonfiguration:

source=root@pve01
target=backup/repl/pve01
tag=bashclub:zsync
snapshot_filter=hourly|daily|weekly|monthly
min_keep=3
zfs_auto_snapshot_keep=14
zfs_auto_snapshot_label=zsync

Die Dokumentation beschreibt zsync als Pull-Replikation und erklärt Tags, Snapshot-Filter sowie die Konfiguration auf dem Ziel. Das frühere GitHub-Repository verweist inzwischen auf GitLab. bashclub/zsync-Dokumentation

6. Kontrolle mit checkzfs.py

Eine erfolgreiche Script-Ausgabe allein beweist noch nicht, dass ein brauchbares Replikat vorhanden ist. Deshalb prüfen wir Quelle und Ziel zusätzlich mit checkzfs.py.

Der zentrale Punkt ist die ZFS-GUID eines Snapshots. Snapshot-Namen können gleich aussehen und trotzdem unterschiedliche Inhalte oder Ursprünge haben. Die GUID identifiziert den Snapshot innerhalb der ZFS-Replikationskette eindeutig.

Die Prüfung läuft sinngemäß so:

Snapshots auf Quelle und Ziel auflisten.

Datasets über Filter zuordnen.

Snapshot-GUIDs miteinander vergleichen.

Den neuesten gemeinsamen Snapshot bestimmen.

Alter und Anzahl der Snapshots bewerten.

Monitoringstatus OK, WARN oder CRIT ausgeben.

Das Script erkennt unter anderem:

kein Replikat gefunden,

letzter gemeinsamer Snapshot zu alt,

Snapshot auf dem Ziel fehlt,

Rollback auf einen älteren Snapshot,

zu viele Snapshots,

unerwünscht aktivierte Auto-Snapshots auf dem Replikationsziel,

SSH- oder Abfragefehler.

Das gewünschte Maximalalter wird über Schwellwerte in Minuten festgelegt:

threshold: 1500,2000

Damit kann beispielsweise nach 1.500 Minuten gewarnt und nach 2.000 Minuten ein kritischer Zustand gemeldet werden. Zusätzlich lassen sich maximale Snapshotzahlen, Dataset-Filter, Snapshotfilter, SSH-Key und ein eigener Servicename konfigurieren.

Beispiel:

source: pve01
remote: backup01
filter: rpool/data
replicafilter: backup/repl/pve01
snapshotfilter: zsync|daily|weekly|monthly
threshold: 1500,2000
maxsnapshots: 140,160
prefix: REPLICA

Die Ausgabe kann unter anderem als Tabelle, JSON, CSV, E-Mail oder lokaler Check für Checkmk erfolgen. Quellcode von checkzfs.py

Wichtig: Der GUID-Vergleich bestätigt, dass derselbe Snapshot auf beiden Seiten existiert. Er ersetzt keinen regelmäßigen ZFS-Scrub und keinen echten Wiederherstellungstest.

7. Miyagi-Workflow kompakt erklärt

Der Miyagi-Workflow verbindet zwei unterschiedliche Sicherungsmethoden auf einem getrennten System:

Proxmox Backup Server für deduplizierte, längerfristige VM- und LXC-Backups

native ZFS-Replikation für unmittelbar verfügbare Datasets und ZVOLs

Das Ziel ist sinngemäß:

mindestens drei Datenkopien,

mindestens zwei Standorte,

zwei unterschiedliche Sicherungsmethoden,

automatische Kontrolle,

möglichst wenig Angriffszeit auf dem Sicherungsserver.

Typischer Ablauf

Miyagi-Server startet
        │
        ├─ Updates und Zustandsprüfung
        ├─ ZFS-Replikation per Pull
        ├─ PBS-Backup koordinieren
        ├─ Verify, Wartung und Monitoringdaten
        ├─ GUID und Alter der Replikate prüfen
        └─ Sicherungsserver herunterfahren

Das ZFS-Replikat ist für schnelle Wiederanlauf-Szenarien gedacht: ZVOLs und Datasets sind bereits vollständig auf dem Ziel vorhanden. Ein PBS-Backup bietet dagegen eine längerfristige und deduplizierte Historie, muss für die produktive Nutzung jedoch erst wiederhergestellt werden.

Der Sicherungsserver kann nach Abschluss heruntergefahren werden. Dadurch ist er nicht permanent über das Netzwerk erreichbar und die Angriffsfläche wird reduziert.

Wann ist das trojanerresistent?

„Trojanersicher“ ist kein Automatismus. Die Schutzwirkung entsteht nur, wenn die Berechtigungen sauber getrennt sind:

Das Ziel startet die ZFS-Replikation.

Die Quelle besitzt keine administrativen Schreib- oder Löschrechte auf dem Ziel.

SSH-Zugriffe werden auf die benötigten Befehle und Datasets begrenzt.

Der PBS-API-Key erhält nur die wirklich erforderlichen Rechte.

Passwortlogin per SSH wird deaktiviert.

Interaktive Konten werden mit 2FA geschützt.

Snapshot-Löschung und Retention werden vom Ziel kontrolliert.

Das Ziel ist außerhalb der Sicherungsfenster ausgeschaltet oder wirksam isoliert.

Scrubs, Verify-Jobs und Wiederherstellungstests werden regelmäßig ausgeführt.

Mindestens eine Kopie befindet sich an einem anderen Standort.

Der Miygiserver läuft oft nur mit Routen, nicht Gateway System ist meist ausgeschaltet

Der dokumentierte Workflow kombiniert Backups, startfähige ZFS-Replikate, Monitoring, Wartung und automatisches Herunterfahren. Die dort genannten Mindeststände sind Proxmox VE 8.4 und Proxmox Backup Server 3.4; bei neueren Installationen müssen Konfiguration und Scripts gegen die eingesetzten Versionen geprüft werden. Miyagi-Workflow-Dokumentation

Kernaussage der Sendung

Wir verlassen uns nicht auf einen einzelnen Sicherungsmechanismus:

Snapshots liefern schnelle lokale Zeitreisen.

Snapdirs erlauben unkomplizierten Datei-Restore.

Rollbacks setzen komplette Datenbestände zurück.

Clones schaffen sofort beschreibbare Teststände.

Replace und RAIDZ-Expansion halten den Pool wartbar.

Spares, L2ARC, SLOG und Special Devices lösen jeweils unterschiedliche Probleme.

zsync zieht native ZFS-Replikate auf ein getrenntes Ziel.

checkzfs.py beweist über Snapshot-GUID und Alter, dass die Replikation aktuell ist.

Miyagi kombiniert startfähige Replikate, PBS-Backups, Monitoring und zeitweise Offline-Sicherung.

So entsteht aus ZFS-Snapshots eine kontrollierte Wiederherstellungsstrategie – und aus einer bloßen Replikation ein überprüfbares Sicherheitskonzept.