TrueNAS Snapshot-Strategien für VM-Storage

ZFS-Snapshots sind das vielleicht meistgepriesene Feature von TrueNAS — und zurecht. Sie sind atomar, kostenlos im Sinne der CPU-Last, und sie sind in Sekunden erstellt unabhängig von der Datenmenge. Für reine Datei-Freigaben (SMB-Akten, Backup-Targets) ist die Snapshot-Strategie gut beschrieben — wir haben das im Artikel TrueNAS Snapshot Schedule Best Practices abgehandelt.

Wenn aber VM-Disks auf einem TrueNAS-Dataset liegen (via NFS, iSCSI oder NVMe-oF/TCP angebunden an einen Hypervisor), wird die Snapshot-Frage komplexer. Eine Datei-Freigabe ist ein “Container voller Dateien”. Eine VM-Disk ist ein laufendes Betriebssystem mit Caches, offenen Datenbank-Transaktionen, Filesystem-Journal. Ein Snapshot zur falschen Sekunde liefert einen inkonsistenten Zustand — der Restore ist dann eine Rettungsoperation, kein sauberer Rollback.

Dieser Artikel ist die VM-Storage-spezifische Ergänzung zu den allgemeinen Best Practices. Wir behandeln Konsistenz, Quiesce, Dataset-Layout, Backup-Integration und Restore-Pfade.

VM-konsistent vs. Crash-consistent

Drei Konsistenz-Levels in der VM-Welt:

1. Crash-consistent

Das ist der Default-Modus für TrueNAS-Snapshots ohne Quiesce. Der Snapshot ist atomar auf Block-Ebene — alles, was zum Zeitpunkt des Snapshots auf der Disk stand, ist drin. Was noch im VM-RAM lag (geöffnete Datenbank-Schreibvorgänge, OS-Caches), ist nicht drin.

Effekt beim Restore: Die VM startet wie nach einem harten Power-Off. Das Filesystem-Journal kümmert sich um Konsistenz (modernes ext4, NTFS, ZFS-Guest, xfs). Datenbanken machen ihren Crash-Recovery. Das funktioniert in 95% der Fälle problemlos — Linux-Server, Windows-Server mit modernen Filesystemen sind dafür gebaut.

Risiko: Bei Datenbanken mit Memory-resident-Caches und großer Write-Last (Oracle, MS SQL mit Lazy Writer, große Postgres-Setups) können Daten verloren gehen, die zum Zeitpunkt des Snapshots noch nicht auf die Disk geschrieben waren.

2. File-system-consistent (Quiesced)

Hier wird vor dem Snapshot das Filesystem in einen Ruhezustand versetzt — alle Caches werden geflusht, neue Writes kurz pausiert, der Snapshot gemacht, dann normal weiter.

In VMware-Welt: VMware Tools Quiesce über VSS (Volume Shadow Copy Service) auf Windows-Guests, freezefs-Hooks auf Linux-Guests. In Proxmox: über den QEMU Guest Agent, der die fsfreeze-Operation auf dem Guest-OS triggert.

Das schützt vor Filesystem-Inkonsistenzen, aber Datenbanken auf Applikations-Ebene sind damit nicht garantiert konsistent — die DB-Prozesse müssten zusätzlich eigene Quiesce-Schritte unterstützen.

3. Application-consistent

Höchstes Level: Datenbank-Engine wird in einen sicheren Zustand gebracht, Transaktion-Logs werden geflusht, dann der Snapshot.

Konkrete Mechanismen:

• Microsoft VSS-Writer für SQL Server, Exchange, Active Directory
• Pre-/Post-Scripts für Postgres, MySQL (z.B. pg_start_backup / pg_stop_backup)
• Veeam-, Vembu-, Acronis-Backup-Agenten auf der VM, die das orchestrieren

Application-consistent-Snapshots sind das Goldstandard für DB-VMs. Sie kosten mehr Setup und etwas mehr Last (kurzzeitiger Wait), garantieren aber den sauberen Restore.

TrueNAS-Snapshot vs. Hypervisor-Snapshot

Es gibt zwei Snapshot-Welten, die sich ergänzen und nicht ersetzen:

TrueNAS-Snapshot

• ZFS-Snapshot des Datasets, auf dem die VM-Disks liegen
• Atomar auf Block-Ebene, sehr schnell
• Ohne Quiesce: crash-consistent
• Funktioniert für alle VMs auf dem Dataset gleichzeitig — ein Snapshot, viele VMs

Hypervisor-Snapshot

• VMware VMSnapshot oder Proxmox-Snapshot
• Erfasst auch den VM-State (RAM-Inhalt, Device-States) — optional bei laufender VM
• Mit Quiesce-Option: filesystem-consistent (Voraussetzung: VMware Tools / QEMU Guest Agent installiert)
• Sehr nützlich für kurzfristige Snapshots vor Wartung (“ich update jetzt das Patch-Level, falls was schiefgeht: snapshot revert”)

Empfehlung: Beides nutzen. Hypervisor-Snapshots für operative Sicherheit (kurzfristig, vor Eingriffen), TrueNAS-Snapshots als Storage-Layer-Safety-Net mit Retention für DR.

Vorsicht: VMware-VMSnapshots dürfen nicht lange leben

Ein VMware-VMSnapshot legt eine Redo-Log-Datei (.vmdk-delta) an, in die alle neuen Writes wandern. Solange der Snapshot existiert, wächst diese Datei. Bei einer aktiven VM in 24h können das problemlos viele GB sein. Best Practice: Hypervisor-Snapshots maximal 24-48 Stunden halten, danach commit oder revert.

TrueNAS-Snapshots haben dieses Problem nicht — sie sind kein Redo-Log, sondern Block-Level-References. Lange Retention auf der TrueNAS-Seite ist unproblematisch (bis auf den Footprint, siehe weiter unten).

Quiesce orchestrieren: vCenter / Proxmox-Hooks

Wer das volle Quiesce-Erlebnis will, kann TrueNAS-Snapshots aus dem Hypervisor orchestrieren:

VMware / vCenter

Über vSphere Storage APIs - Data Protection (VADP) lassen sich Storage-Snapshots vom Hypervisor aus auslösen. Backup-Software (Veeam, Vembu, Rubrik) macht das standardmäßig. Wer es manuell will:

1. Vor TrueNAS-Snapshot: VMware-VMSnapshot mit Quiesce-Flag
2. TrueNAS-Snapshot vom Dataset
3. VMware-VMSnapshot wieder entfernen

Das ist ein klassischer “freeze-and-clone”-Pattern.

Proxmox VE

Proxmox hat Pre/Post-Hook-Scripts für VM-Operationen. Ein Backup-Job kann vor dem Snapshot den QEMU Guest Agent triggern (qm guest fsfreeze-freeze 100), Snapshot machen, dann qm guest fsfreeze-thaw 100.

In der Praxis übernimmt das meist der Proxmox Backup Server automatisch — und das ist mit Abstand der einfachste Weg zu konsistenten VM-Backups.

Storage-orchestrierte Snapshots via iX-Plugin

Mit dem offiziellen TrueNAS-Proxmox-Plugin lassen sich ZFS-Snapshots aus dem Proxmox-UI heraus auslösen — inklusive Quiesce über den QEMU Guest Agent. Das ist die sauberste Variante für 2026.

Dataset-Layout: Pro VM oder pro Pool?

Eine der ersten Architektur-Entscheidungen. Drei Optionen:

Option A: Ein Dataset pro VM

tank/vms/vm-100/
tank/vms/vm-101/
tank/vms/vm-102/

Vorteile:

• Pro-VM-Snapshots mit individueller Retention (z.B. Datenbank-VM stündlich, Web-Server täglich)
• Pro-VM-Restore ohne andere VMs zu beeinflussen
• Pro-VM-Replikation zu Sekundär-Site (siehe Proxmox-Replication)
• Unterschiedliche Properties möglich (Komprimierung, Recordsize, Sync)

Nachteile:

• Bei vielen VMs (50+) wird die Dataset-Liste unübersichtlich
• Mehr Verwaltungsaufwand

Option B: Ein Dataset pro Workload-Klasse

tank/vms/production/
tank/vms/development/
tank/vms/dmz/

Vorteile:

• Klassenbasierte Retention-Policies
• Übersichtlicher

Nachteile:

• Restore betrifft eine ganze Klasse
• Snapshot-Footprint je nach Schreiblast schwer kalkulierbar

Option C: Ein Dataset für alle VMs

tank/vms/

Vorteile:

• Einfachste Verwaltung
• Ein Snapshot deckt alle VMs

Nachteile:

• Restore eines einzelnen VM nicht möglich, ohne andere zu beeinflussen
• Bei vielen Writes: Snapshot wird “fett”

Empfehlung

Für KMU-Setups mit < 30 VMs: Option A (ein Dataset pro VM). Der Verwaltungsaufwand ist überschaubar, die Vorteile (Pro-VM-Restore, individuelle Retention) sind groß.

Für größere Setups mit > 100 VMs: Option B (pro Workload-Klasse) plus Hypervisor-Snapshots für individuelles Restore.

Auf der iSCSI-Seite ist das anders: Da ist eine LUN typischerweise ein Datastore mit vielen VMs darauf. Dann hilft nur Hypervisor-Snapshot oder ein TrueNAS-Plugin, das pro VM operiert.

VM-aware Backup vs. Storage-Snapshot

Wichtige Unterscheidung:

• VM-aware Backup (Veeam, PBS, Vembu): kennt das VM-Konzept, koordiniert Quiesce mit dem Guest, kann selektiv einzelne VMs oder Files restoren
• Storage-Snapshot (TrueNAS-Snapshot): block-level, ohne VM-Semantik

Beide haben ihren Platz:

• Schnelle Recovery (Sekunden bis Minuten): TrueNAS-Snapshot Rollback. Crash-consistent ist meistens ok.
• Granulare Recovery (einzelne Datei in der VM): VM-aware Backup mit File-Level-Restore.
• Cross-Site DR: TrueNAS-Replication + Hypervisor-Backup zum PBS.

Empfehlung: Beides parallel. TrueNAS-Snapshots als Sekunden-Restore-Layer, VM-aware Backup (PBS bei Proxmox, Veeam bei VMware) als längere Retention und granulare Recovery.

Siehe Proxmox Backup Server 4.0 Neuerungen und Backup-Strategie für KMU.

Restore-Pfade

Konkrete Wege, eine VM aus einem TrueNAS-Snapshot wiederherzustellen:

Pfad 1: Full Rollback (NFS-Dataset mit allen VMs aus)

Wenn alles korrupt ist, kann ein zfs rollback das Dataset komplett auf den Snapshot-Stand zurücksetzen. Voraussetzung: alle VMs auf dem Dataset sind gestoppt, sonst inkonsistent. Sehr schnell, sehr destruktiv für alle anderen VMs auf dem gleichen Dataset.

Pfad 2: Read-Only-Clone der Snapshot, einzelne Datei kopieren

# Auf TrueNAS:
zfs clone tank/vms/vm-100@daily-2026-07-15 tank/vms/vm-100-restore-clone
# Dann von Hypervisor aus mounten und VM-Datei kopieren

Vorteil: andere VMs unbeeinflusst, selektiver Restore möglich.

Pfad 3: Snapshot-Verzeichnis direkt nutzen (NFS)

Bei NFS-Datasets ist das versteckte .zfs/snapshot/<name>/-Verzeichnis aus dem Hypervisor heraus zugänglich. Dort liegt die VM-Disk im Snapshot-Zustand — einfach kopieren:

cp /mnt/nfs-tank/.zfs/snapshot/daily-2026-07-15/vm-100-disk-0.qcow2 \
   /mnt/nfs-tank/vm-100-disk-0-restored.qcow2

Voraussetzung: snapdir=visible auf dem Dataset oder Workaround via cd ins versteckte Verzeichnis.

Pfad 4: VM-Snapshot-Rollback (Hypervisor-Ebene)

Wenn ein Hypervisor-Snapshot existiert: einfach im UI oder CLI rollback. Schneller Weg ohne Storage-Eingriff.

Retention vs. Pool-Wachstum

Snapshots sind nicht “kostenlos”, sondern referenzieren alte Block-Versionen, die sonst freigegeben würden. Bei einer VM mit hoher Schreiblast wächst der Snapshot-Footprint schnell:

Beispielrechnung:

• VM mit 200 GB Disk
• 1 GB/Tag effektiver Daten-Change
• Hourly Snapshots, 24h Retention: 24 GB
• Daily Snapshots, 30 Tage: 30 GB
• Weekly Snapshots, 12 Wochen: 12 GB
• Monthly Snapshots, 24 Monate: 24 GB
• Gesamt: Snapshot-Footprint ca. 90 GB für 200-GB-VM = +45%

Mit zwei Dutzend VMs wird das schnell viel. Empfehlung:

1. Pool-Reserve einplanen — ZFS-Performance leidet ab ~80% Belegung
2. Retention nach Workload differenzieren — Datenbank-VMs brauchen vielleicht stündliche Snapshots, statische Webserver nicht
3. Komprimierung aktivieren (LZ4 ist Default — bei VM-Daten oft 1,5–2x)
4. Inline-Deduplikation vermeiden — RAM-hungrig, in VM-Storage selten lohnend

Workload-spezifische Empfehlungen

Datenbank-VMs (Postgres, MySQL, MSSQL)

• Application-consistent Snapshots über DB-eigene Mechanismen oder Veeam/PBS
• Häufige Snapshots (stündlich), kürzere Retention auf Storage-Ebene
• Zusätzlich: DB-Logical-Backups als zweite Schicht
• Recordsize an DB-Blocksize anpassen (8K für Postgres, 16K für MySQL InnoDB)

Web-Server / App-Server

• Crash-consistent reicht typisch
• Daily Snapshots, kürzere Retention
• VM-Image-Backup (PBS/Veeam) für Image-Restore

File-Server-VMs

• Crash-consistent reicht
• Stündliche Snapshots wenn aktiv genutzt, sonst täglich
• Lange Retention (30+ Tage) für Versionsschutz gegen Ransomware

Domain-Controller / AD-VMs

• Quiesced über VSS-Writer (Active Directory ist sehr empfindlich)
• Tägliche Snapshots reichen typischerweise
• Wichtig: System-State-Backup zusätzlich

Application-Server mit großem RAM-Cache (Java-Apps, etc.)

• Hypervisor-Snapshot mit Memory-State, wenn kurzfristig
• Sonst: App-graceful-shutdown vor TrueNAS-Snapshot

Praxis-Tipps aus DATAZONE-Projekten

1. Niemals Snapshot-Retention ohne Restore-Test. Ein Snapshot, der nie restored wurde, ist Hoffnung, kein Konzept. Mindestens einmal pro Quartal einen echten Restore üben.
2. Snapshot-Monitoring. Welche Snapshots sind ungewöhnlich groß? Welche VMs verursachen Snapshot-Wachstum? Mit Grafana und Prometheus messbar — siehe TrueNAS SMART Monitoring mit Grafana.
3. VMs nicht “irgendwo” platzieren. Bewusste Dataset-Zuordnung pro Workload. Erleichtert Retention und Restore.
4. Replikation nicht vergessen. Snapshots sind keine Backups, solange sie auf dem gleichen Pool liegen. ZFS-Replication zum Sekundär-Pool, idealerweise zweiter Standort.
5. Recordsize beachten. 128K Default ist für VM-Disks oft nicht optimal — bei NFS-vmdk/qcow2 funktioniert 64K oder 16K besser, je nach Workload.

Fazit

Snapshots auf TrueNAS sind ein hervorragendes Werkzeug für VM-Storage — aber sie ersetzen weder Hypervisor-Snapshots noch VM-aware Backup. Die richtige Strategie ist eine mehrschichtige: TrueNAS-Snapshots als schnelle Storage-Layer-Sicherung, Hypervisor-Snapshots für operative Sicherheit vor Eingriffen, VM-aware Backup für granulare Recovery und langfristige Retention.

Wer das versteht, hat einen Recovery-Stack statt nur eines Snapshot-Schedules. Und genau das ist es, was im Ernstfall den Unterschied macht zwischen “VM in 5 Minuten zurück” und “wir reden über Stunden Datenverlust”.

Quellen und weiterführende Artikel

• TrueNAS Snapshot Schedule Best Practices
• TrueNAS-Proxmox-Plugin (offiziell, NVMe/TCP)
• iSCSI vs. NFS für Hypervisor-Storage
• Proxmox Backup Server 4.0 Neuerungen
• Backup-Strategie für KMU (Proxmox + TrueNAS)
• Proxmox Replication zwischen zwei Standorten
• Vorteile von TrueNAS Snapshots
• TrueNAS Snapshots & Replikation erklärt
• TrueNAS SMART Monitoring mit Grafana