TrueNAS Snapshot-Schedules: 5 Best Practices

ZFS-Snapshots gehören zu den stärksten Argumenten für TrueNAS in mittelständischen IT-Umgebungen: Sie sind atomar, kostenlos im Sinne von Storage-Overhead bei wenig Veränderung und lassen sich in Sekunden zurückrollen. Doch der Komfort hat eine Kehrseite. Eine schlecht geplante Snapshot-Strategie produziert in TrueNAS SCALE 25.10 oder TrueNAS CORE 13.3 schnell sechsstellige Snapshot-Mengen, treibt die Pool-Importzeit nach oben und belastet die ARC mit Metadaten.

In diesem Beitrag zeigen wir Ihnen fünf konkrete Best Practices, die wir in unseren Projekten beim Mittelstand und in Steuer- bzw. Anwaltskanzleien etabliert haben. Ziel ist eine Snapshot-Strategie, die Compliance-Anforderungen erfüllt, Ransomware-resilient ist und gleichzeitig die Storage-Performance nicht ruiniert.

1. GFS-Retention statt “alles behalten”

Der häufigste Fehler in TrueNAS-Installationen ist eine einzige Periodic Snapshot Task mit langer Retention — etwa “alle 15 Minuten, 90 Tage halten”. Das Ergebnis: rund 8.640 Snapshots pro Dataset. Bei 20 Datasets sind das schnell 170.000 Snapshots, deren Metadaten beim Pool-Import erst durchlaufen werden müssen.

Wir empfehlen stattdessen eine klassische Grandfather-Father-Son-Retention (GFS) mit vier gestaffelten Tasks:

Schedule	Intervall	Retention	Snapshots pro Dataset
Hourly	stündlich	24 Stunden	24
Daily	täglich 23:00	30 Tage	30
Weekly	sonntags 23:30	12 Wochen	12
Monthly	1. des Monats 23:45	12 Monate	12

Macht in Summe rund 78 Snapshots pro Dataset statt mehreren tausend. Bei 20 Datasets bleiben Sie unter 1.600 Snapshots — ein Wert, mit dem TrueNAS auch bei einem Reboot in unter 30 Sekunden wieder produktiv ist.

2. Rekursiv vs. dataset-spezifisch — bewusst entscheiden

In TrueNAS lässt sich pro Periodic Snapshot Task festlegen, ob Child-Datasets rekursiv mit eingeschlossen werden. Das ist bequem, kann aber teuer werden. Ein rekursiver Snapshot auf tank/data mit zehn Child-Datasets erzeugt elf Snapshots in derselben Sekunde — und elf Einträge im Replication-Log.

Unsere Faustregel:

• Rekursiv, wenn die Child-Datasets fachlich zusammengehören und konsistent rückrollbar sein müssen (z. B. eine Anwendungsgruppe mit app/db, app/files, app/logs).
• Dataset-spezifisch, wenn Retention-Anforderungen unterschiedlich sind oder einzelne Datasets gar nicht in das Backup gehören (z. B. tank/scratch oder tank/temp).

Setzen Sie für Datasets, die nicht gesichert werden sollen, zusätzlich die ZFS-Property com.sun:auto-snapshot=false — so vermeiden Sie, dass eine versehentlich rekursive Task später doch zugreift.

zfs set com.sun:auto-snapshot=false tank/scratch
zfs set com.sun:auto-snapshot=false tank/iscsi/swap

3. Naming-Konvention für nachvollziehbare Snapshots

TrueNAS bietet pro Task ein Naming-Schema an. Wir verwenden konsequent ein Format, das Intervall, Zeitstempel und Quelle ablesbar macht. Das spart bei Audits und Restore-Anfragen enorm Zeit.

Bewährt hat sich folgendes Muster:

auto-<intervall>-%Y-%m-%d_%H-%M

Konkrete Beispiele aus einer Produktionsumgebung:

auto-hourly-2026-06-14_09-00
auto-daily-2026-06-14_23-00
auto-weekly-2026-06-08_23-30
auto-monthly-2026-06-01_23-45
manual-pre-update-truenas-25.10

Manuelle Snapshots — etwa vor einem TrueNAS-Update oder einer Applikationsmigration — markieren wir explizit mit dem Präfix manual-. So greift keine automatische Retention versehentlich auf einen wichtigen Pre-Change-Stand zu.

4. Replikation: lokale vs. remote-gesicherte Datasets trennen

Snapshots auf demselben Pool sind kein Backup. Sie überleben weder einen Pool-Totalausfall noch eine Ransomware-Attacke, die mit erhöhten Rechten direkt auf das Storage geht. Deshalb gehört zu jeder Snapshot-Strategie eine Replikation — typischerweise per zfs send | zfs recv auf ein zweites TrueNAS-System, idealerweise an einem anderen Standort.

Wir empfehlen, im Konzept klar zu trennen:

Dataset-Klasse	Lokale Snapshots	Replikation	Beispiel
Produktivdaten	GFS (78 Stk.)	täglich, 30 Tage	tank/fileserver, tank/vm
Compliance-relevant	GFS (78 Stk.)	täglich, 10 Jahre	tank/dms, tank/buchhaltung
Scratch / Cache	aus	aus	tank/scratch, tank/iscsi-swap
Test / Lab	hourly 24h	aus	tank/lab

Auf dem Replikationsziel verwenden wir eigene Snapshot-Tasks mit anderem Naming (backup-*), um Quelle und Ziel jederzeit unterscheiden zu können. Die Replikation selbst läuft per SSH+Netcat oder über einen dedizierten Replication-User. Wenn Sie mehr zu Architektur und Sizing wissen möchten, finden Sie auf unserer TrueNAS-Seite unsere typischen Setups — ergänzt durch unsere Backup-Beratung für 3-2-1-Konzepte.

5. Holds für Compliance und kritische Restore-Punkte

Snapshots können von einer Periodic Task gelöscht werden, sobald die Retention abläuft. Für Compliance-relevante Stände — etwa Jahresabschluss, GoBD-Stichtag oder ein bestätigter Pre-Migration-Snapshot — ist das nicht akzeptabel. Hier nutzen wir ZFS Holds.

Ein Hold verhindert, dass ein Snapshot gelöscht werden kann, solange der Hold gesetzt ist. Selbst ein zfs destroy schlägt fehl. In der CLI:

# Snapshot mit Hold versehen
zfs hold gobd-2026 tank/buchhaltung@manual-jahresende-2026-12-31

# Bestehende Holds anzeigen
zfs holds tank/buchhaltung@manual-jahresende-2026-12-31

# Hold entfernen (z. B. nach Ablauf der Aufbewahrungsfrist)
zfs release gobd-2026 tank/buchhaltung@manual-jahresende-2026-12-31

In der TrueNAS-WebUI lassen sich Holds unter “Datasets -> Snapshots” über das Aktionsmenü setzen. Wir kombinieren das mit einer dokumentierten Tabelle pro Mandant, in der jeder Hold mit Grund, Verantwortlichem und Ablaufdatum geführt wird. So bleibt der Pool revisionssicher, ohne dass die automatische Retention deaktiviert werden muss.

Auswirkung auf Metadaten und ARC

Ein Punkt, der in der Planung gerne untergeht: Jeder Snapshot belegt Metadaten. Bei 10.000+ Snapshots pro Pool steigt der Speicherbedarf für die ZFS-Metadaten spürbar — als Faustwert kalkulieren wir 0,5 bis 1 KB pro Snapshot in der ARC. Das klingt wenig, summiert sich aber. Auf einem TrueNAS mit 64 GB RAM und einer aggressiven Snapshot-Strategie haben wir schon Setups gesehen, in denen mehrere GB ARC allein durch Snapshot-Metadaten belegt waren — ARC, die für Read-Caching produktiver Daten fehlt.

Mit der oben skizzierten GFS-Strategie bleibt der Wert gut beherrschbar. Zusätzlich empfiehlt sich ein Monitoring der Snapshot-Anzahl, z. B. per Cron-Skript:

zfs list -H -t snapshot -o name | wc -l

Werte oberhalb von 5.000 sollten überprüft werden, oberhalb von 20.000 wird es Zeit für ein Konsolidieren der Retention.

Fazit

ZFS-Snapshots sind in TrueNAS extrem mächtig — aber nur, wenn die Schedule-Strategie zur tatsächlichen Datenklassifikation passt. GFS-Retention, bewusste Entscheidung zwischen rekursiv und dataset-spezifisch, klare Namensregeln, eine sauber getrennte Replikation und gezielte Holds für Compliance-Stände bilden zusammen ein robustes Backup-Konzept, das auch unter Ransomware-Druck trägt.

DATAZONE unterstützt Sie aus Neuburg an der Donau bei der Planung und dem Aufbau Ihrer TrueNAS-Snapshot- und Replikationsstrategie — von der Datenklassifikation über die Konzeption von TrueNAS und Backup-Architekturen bis hin zu Audit- und Compliance-Themen. Sprechen Sie uns an unter /kontakt/.