Richten Sie separate ZFS-Datasets für App-Daten, Backups und Downloads ein, indem Sie jeder Arbeitslast einen eigenen Mountpoint, eigene Eigenschaften, eine eigene Snapshot-Richtlinie und eine eigene Bereinigungsgrenze zuweisen.
Auf einem Heimserver beginnen diese Ordner oft in einer einzigen großen Freigabe, weil das zunächst einfach ist. Später benötigen sie jedoch unterschiedliche Aufbewahrungsfristen, Berechtigungen, Komprimierung, Recordsize-Werte, Quotas und Wiederherstellungsverfahren. Daher ist es sicherer, sie aufzuteilen, bevor eine besonders aktive Arbeitslast die Richtlinien für alles andere bestimmt.
Legen Sie fest, was jedes Dataset schützen muss
Beginnen Sie mit der Aufgabe jeder Arbeitslast. App-Daten benötigen in der Regel konsistente Snapshots und sorgfältige Wiederherstellungen, Backups benötigen Kapazitätskontrolle und Aufbewahrungsregeln, und Downloads müssen sich einfach bereinigen lassen, ohne Teil des langfristigen Schutzes zu werden.
ZFS-Datasets sind ebenso administrative Grenzen wie Ordner. Eigenschaften wie Komprimierung, Quotas und Reservierungen, Mountpoints und Snapshots können pro Dataset verwaltet werden. Genau deshalb ist die Trennung von Arbeitslasten sinnvoll, selbst wenn sie sich im selben Pool befinden.
Notieren Sie vor dem Erstellen die drei vorgesehenen Rollen: wiederherstellbarer App-Zustand, aufzubewahrende Backup-Daten sowie löschbare oder erneut herunterladbare Daten. Wenn zwei Ordner dieselben Wiederherstellungs- und Bereinigungsrichtlinien benötigen, müssen sie möglicherweise noch nicht in separate Datasets aufgeteilt werden.
Erstellen Sie klare Mountpoints, bevor Sie Daten verschieben
Wählen Sie Mountpoints, die die Trennung für Apps und Menschen offensichtlich machen. Ein einfaches Layout könnte einen übergeordneten Pfad wie /srv/storage und darunter die Mountpoints appdata, backups und downloads verwenden.
Die Dokumentation zu zfs-set beschreibt das Festlegen von Dataset-Eigenschaften mit zfs set, während die umfassendere Dokumentation zu den Eigenschaften das Verhalten von Mountpoints und die Vererbung von Eigenschaften behandelt. Dadurch können Sie ein übergeordnetes Dataset mit gemeinsamen Standardwerten erstellen und nur bei den untergeordneten Datasets abweichende Einstellungen festlegen.
Erstellen Sie zunächst leere Datasets, überprüfen Sie, ob sie erwartungsgemäß eingebunden werden, und verschieben Sie erst danach die Daten. Halten Sie an, wenn eine Anwendung noch in den alten Pfad schreibt. Migrieren Sie diese Anwendung während eines Wartungsfensters, damit Sie sauber zurückrollen können.
Geben Sie App-Daten die sorgfältigste Snapshot-Richtlinie
App-Daten ändern sich meist in kleinen, aber wichtigen Details: Datenbanken, Konfigurationsdateien, Benutzer-Uploads, Container-Volumes und Anwendungszustand. Der Verlust einer einzelnen Datei fällt möglicherweise weniger auf als der Verlust eines gesamten Backup-Ordners, doch die Wiederherstellung des falschen Zeitpunkts kann eine App beschädigen.
Die OpenZFS-Dokumentation zu Eigenschaften zeigt, dass Eigenschaften auf Dataset-Ebene vererbt oder überschrieben werden können. So kann das Dataset für App-Daten häufigere Snapshots oder eine andere Komprimierung verwenden, ohne diese Einstellungen auf Downloads zu übertragen.
Verwenden Sie für App-Daten möglichst häufige Snapshots, eine vorsichtige Bereinigung und einen Wiederherstellungstest für eine repräsentative Anwendung. Wenn eine App eine aktive Datenbank verwendet, stimmen Sie Snapshots mit der eigenen Backup- oder Quiesce-Methode der App ab, statt anzunehmen, dass der Dateisystem-Snapshot anwendungskonsistent ist.
Geben Sie Backups Kapazitätsgrenzen und Aufbewahrungsgrenzen
Backups verdienen ein eigenes Dataset, weil sie durch Aufbewahrungsfristen, Deduplizierungsmetadaten, synthetische Vollsicherungen, Replikation oder alte Client-Aufträge unbemerkt wachsen können. Ein Backup-Dataset ohne Begrenzung kann den Speicher belegen, den Apps oder aktive Freigaben benötigen.
Oracles Leitfaden zu ZFS-Eigenschaften erklärt Quotas und Reservierungen als Steuerelemente auf Dataset-Ebene. Dadurch eignen sie sich, um zu verhindern, dass das Wachstum von Backups unabhängige Arbeitslasten verdrängt.
Setzen Sie für das Backup-Dataset ein Quota oder zumindest einen Warnschwellenwert und stimmen Sie die Snapshot-Aufbewahrung mit der eigenen Aufbewahrungsregel des Backup-Tools ab. Bewahren Sie nicht dauerhaft Dateisystem-Snapshots rund um Backup-Dateien auf, die die Backup-Anwendung nach eigener Einschätzung bereits bereinigt hat.
Halten Sie Downloads einfach wiederherstellbar und löschbar
Downloads sind meist das am wenigsten wichtige Dataset, weil die meisten Dateien temporär, erneut herunterladbar oder nur zum Sortieren zwischengespeichert sind. Dennoch verdienen sie eine eigene Grenze, da sie einen Pool schnell füllen und Snapshots erben können, die sie nicht benötigen.
Ein separates Downloads-Dataset ermöglicht es Ihnen, die langfristige Aufbewahrung zu verkürzen oder zu deaktivieren, die Komprimierung an den Dateimix anzupassen und das Verzeichnis zu bereinigen, ohne den App-Zustand oder Backups zu berühren.
Verwenden Sie ein kleines Quota oder eine geplante Bereinigung, wenn Downloads regelmäßig den Speicher füllen. Wenn eine Datei wichtig wird, verschieben Sie sie in das Dataset, dessen Richtlinie zu ihrer neuen Rolle passt, anstatt langfristig benötigte Daten im löschbaren Bereich aufzubewahren.
Überprüfen Sie nach der Aufteilung Berechtigungen, Snapshots und Wiederherstellungen
Die Einrichtung ist nicht abgeschlossen, sobald die Datasets existieren. Sie ist erst abgeschlossen, wenn Apps korrekt starten, Backups im richtigen Dataset landen, Downloads sicher bereinigt werden können und Snapshots die erwarteten Grenzen zeigen.
Führen Sie pro Klasse eine Wiederherstellungsprüfung durch: Stellen Sie eine kleine App-Konfiguration wieder her, listen Sie einen Backup-Wiederherstellungspunkt auf und löschen oder bereinigen Sie eine Test-Download-Datei. So bestätigen Sie, dass die Dataset-Grenze mit der betrieblichen Grenze übereinstimmt.
Wenn ein Snapshot unerwartet Downloads enthält oder App-Daten fehlen, halten Sie an und korrigieren Sie den Mountpoint oder die Dataset-Zuordnung, bevor Sie weitere Automatisierung hinzufügen. Der saubere Endzustand ist unspektakulär: Für jede Arbeitslast gibt es eine Richtlinie, die Sie in einem Satz erklären können.
FAQ
Sollten App-Daten und Backups jemals dasselbe Dataset verwenden?
Nur wenn sie tatsächlich dieselben Anforderungen an Aufbewahrung, Quota, Snapshots und Wiederherstellung haben. Auf den meisten Heimservern benötigen App-Daten und Backups unterschiedliche Richtlinien.
Kann ich Datasets aufteilen, nachdem bereits Daten vorhanden sind?
Ja, behandeln Sie dies jedoch als Migration. Erstellen Sie die neuen Datasets, stoppen Sie die schreibenden Apps oder Aufträge, verschieben Sie die Daten, aktualisieren Sie die Pfade, testen Sie alles und behalten Sie die alte Kopie, bis die neuen Mountpoints überprüft wurden.
Als ergänzenden Planungsschritt sollten Sie prüfen, wie Dataset-Grenzen mit der Replikationskapazität zusammenspielen. ZimaSpaces Leitfaden zum Verhindern, dass Snapshot-Replikation einen Ziel-Pool füllt, zeigt, warum Aufbewahrung und Dataset-Umfang gemeinsam geplant werden sollten.
Support & Tipps
Mehr zum Lesen

Leitfaden zur Speicherkapazität, Aufbewahrung und Bereinigung von Live-TV-Aufnahmen
Messen Sie echte Aufzeichnungen, halten Sie Headroom frei, kombinieren Sie Alters- und Kapazitätslimits und weisen Sie nach, dass das älteste geeignete Programm entfernt wird,...

Workflow zur Wiederherstellung von Metadaten für Heimmedien nach der Wiederherstellung einer Datenbank
Schützen Sie den wiederhergestellten Zustand, überprüfen Sie die Medienidentität und die Pfade und reparieren Sie anschließend fehlende Grafiken oder Übereinstimmungen in einer Pilotbibliothek, bevor...

Jellyfin-Client-Kompatibilitätscheckliste für Audio, Video und Untertitel
Testen Sie repräsentative Dateien mit jeweils nur einer veränderten Variable und protokollieren Sie für jeden Client Direct Play, Remux, Audiokonvertierung, Videotranskodierung oder einen Fehler.

