Het grote ZFS topic

[Videopac]

GioStyle schreef op maandag 9 maart 2026 @ 19:05:
De eerste snapshot is de volledige dataset?

Dat is wel de indruk die ik heb, maar je stelt een termijn in hoe lang de snapshots bewaard worden, daarna wordt de eerste snapshot toch verwijderd?

[dcm360]

@Videopac Bij het verwijderen van een snapshot, verdwijnt alleen de data die uniek was voor dat snapshot. Een snapshot bevat altijd alle data van dat moment, maar het is (vanwege hoe ZFS is opgezet) relatief makkelijk mogelijk om het verschil tussen snapshots vast te stellen, en daarmee kan ZFS voor het overzetten (of verwijderen van een snapshot wat dat bereft) snel vaststellen welke data er echt wijzigt.

[GioStyle]

Videopac schreef op maandag 9 maart 2026 @ 20:24:
[...]

Dat is wel de indruk die ik heb, maar je stelt een termijn in hoe lang de snapshots bewaard worden, daarna wordt de eerste snapshot toch verwijderd?

Ik vind het even lastig om te begrijpen wat jou niet precies duidelijk is.

Wat betreft snapshots, dat kan je allemaal zelf bepalen. Ik heb daar een bepaalde logica in, afhankelijk van de data. Een snapshot is een momentopname van de data. Als je de eerste snapshot heb verstuurd naar je backupserver, elke week stuur je één snapshot, en na 10 weken kom je tot de conclusie dat in die 10 weken niets is veranderd. Je verwijdert vervolgens de oudste snapshot, dan verandert er helemaal niets aan je data, want er zijn geen mutaties geweest?

[ph0t0nix]

@Videopac Als ik je goed begrijp, dan mis je een stukje conceptuele kennis over hoe een copy-on-write bestandssysteem werkt en, daar van afgeleid, hoe ZFS snapshots werken. Dat is dus nog voor je replicatie (bijvoorbeeld naar een ander systeem) doet.

Zie bijvoorbeeld het kopje "Copy-on-Write semantics" in https://arstechnica.com/i...-storage-and-performance/. Misschien is dit ook een verhelderend artikel, met praktische voorbeelden: https://klarasystems.com/...ace-accounting-explained/

Zoals hierboven al uitgelegd: elke snapshot bevat alle data. In tegenstelling tot andere backupmethoden zijn er geen full, incremental of differential backups. Maar, omdat ZFS weet welke blokken er in elk snapshot zitten, kan het bij replicatie alleen de verschillen sturen. Daar zit de winst bij replicatie (overdracht).

"Op disk" weet ZFS natuurlijk ook welke blokken voorkomen in meer dan een snapshot, dus ook die worden maar één keer opgeslagen. Daarom kost een snapshot niet meer ruimte dan het verschil tussen wat nu op disk staat en wat er veranderd is t.o.v. het snapshot.

[RobertMe]

ph0t0nix schreef op dinsdag 10 maart 2026 @ 09:36:
"Op disk" weet ZFS natuurlijk ook welke blokken voorkomen in meer dan een snapshot, dus ook die worden maar één keer opgeslagen. Daarom kost een snapshot niet meer ruimte dan het verschil tussen wat nu op disk staat en wat er veranderd is t.o.v. het snapshot.

En als aanvulling daarop: als je een bestand van 1TB hebt en vervolgens 1 byte wijzigt dan kost dat maar 1 block size aan opslag (wat volgens mij neerkomt op een paar KB).

En ten opzichte van andere (incrementele) backup oplossingen weet ZFS dus welke blokken gewijzigd zijn tussen twee snapshots en dus tussen twee sync momenten (want je synct van snapshot naar snapshot). Daar waar andere backup oplossingen of naïef zijn en zien "bestand is gewijzigd na die datum/tijd" en het volledig over de lijn sturen of aan beide kanten hashes/checksums berekenen over blokken van X grote en alleen bij verschillende hashes dat blok over de lijn sturen. Dus andere backup oplossingen gebruiken of veel meer bandbreedte (bij kleine wijzigingen in grote bestanden) of veel meer resources aan beide kanten (CPU en I/O om te lezen en hashen).

[CyBeR]

Videopac schreef op maandag 9 maart 2026 @ 19:03:
[...]

Verlies van de laatste data is echt niet belangrijk, sorry dat ik dat niet duidelijk vermeldde. 1x per week updaten is echt wel voldoende. Het grootste deel van de data (enkele TB's) verandert niet. Ik snap niet hoe ik op een nette manier een volledige data-kopie maak; snapshots zijn alleen delta's sinds de vorige snapshot, maar als data nooit veranderd zit het ook niet in een snapshot (toch?).

Wat je misschien mist is dat je een ZFS snapshot moet syncen naar een ZFS pool. Dan heb je op je tweede plek een volledige kopie van het originele filesysteem ten tijde van de snapshot. De 1e snapshot die je maakt heeft dus álle data, daarna kun je op basis van voorgaande snapshots alleen het verschil sturen. Je destination ZFS pool wordt dan geüpdatet met wat er tussen de 1e en 2e snapshots gebeurd is, daarna de 2e en 3e, etc..

M.a.w. data die niet verandert zit inderdaad in die 1e snapshot en daarna niet meer. Vaker backuppen is dan ook voordelig want dan zijn (meestal) de verschillen kleiner en hoef je dus per keer minder te versturen.

Strict gezien kun je zfs send ook doen naar een file maar dan moet je dus idd wel al die files met de inhoud van de snapshots bijhouden, anders werkt het niet. Niet aan te raden dus.

[ocaj]

Je kunt ook op je primaire server elk uur een snapshot maken en dan 1 x per dag een snapshot naar de 2e server sturen. Je bent dus niet verplicht om ALLE snapshots over te zetten.

Wel belangrijk dat je het het laatste snapshot op de 2e nog niet weg gooit op de 1e server. Anders kun je de verschillen niet meer bepalen.

(overigens heeft zfs send ook een optie om alle tussenliggende snapshots wél mee te nemen, voor meer details -> man zfs send )

[RobertMe]

ocaj schreef op dinsdag 10 maart 2026 @ 22:11:
Wel belangrijk dat je het het laatste snapshot op de 2e nog niet weg gooit op de 1e server. Anders kun je de verschillen niet meer bepalen.

Volgens mij mag dat wel? Maar dan moet je bookmarks maken.

Als ik het goed begrepen heb werkt CoW en daarmee de snapshots? of snapshots an zich? met oplopende nummers? En met een bookmark is er een verwijzing naar het(zelfde) nummer als waar het snapshot naar verwijst. Als je vervolgens een send vanaf een bookmark doet weet die dat die alle blokken met de opvolgende / tussenliggende "nummers" moet sturen. Daarvoor hoeft het snapshot dan zelf dus niet meer te bestaan, Zolang ZFS maar kan bepalen van welke "nummers" die de data/blokken moet kopiëren, wat die dus ook weet op basis van bookmarks.
Immers weet je dat je het snapshot / de bookmark aan de ontvangende kant ("server 2") compleet hebt, die data / blokken zijn dus niet meer nodig en hoeven niet meer over de lijn te gaan. Zolang die maar weet welke blokken daarna veranderd zijn.

[ocaj]

Heel goed mogelijk. Ik moet eerlijk zeggen dat ik nog nooit van zfs bookmarks gehoord had.
Ik gebruik een collectie eigen scripts voor rotatie van dagelijkse/wekelijkse/maandelijkse snapshots.
Backups van snapshots doe ik met scripts die ik handmatig activeer en dan maak ik altijd een snapshot met een specifieke datum. (ik backup old-skool op losse externe HD's die ik roteer, dan is handmatig logischer dan geautomatiseerd naar een remote server. Principe hoe snaphots werken is niet zo heel veel anders)

Klinkt alsof een bookmark zoiets is als een snapshot dat je niet wil kwijtraken omdat je er nog naar wil verwijzen. Dat is waarschijnlijk wat overzichtelijker/handiger dan zelf bijhouden welke snapshots op de backup-targets de laatste zijn.

[ph0t0nix]

In plaats van eigen scripts zou ik kiezen voor de Sanoid/syncoid combinatie: https://github.com/jimsalterjrs/sanoid/

Met Sanoid geef je aan wanneer snapshots gemaakt moeten worden en hoeveel er daarvan bewaard moeten worden. Dat kan niet alleen op de bron server, maar ook op de doelserver (behalve dat je op de doelserver geen snapshots maakt, en alleen de retentie bepaald).

Syncoid is een Perl script dat het synchroniseren van snapshots eenvoudig maakt. Eventueel op basis van bookmarks.

Doel kan dezelfde server zijn, een andere machine, of een externe hdd (of een combinatie daarvan ).

[ Voor 9% gewijzigd door ph0t0nix op 11-03-2026 10:56 ]

[RobertMe]

Ik heb ooit, lang geleden, eens naar sanoid / syncoid gekeken, maar wat mij daaraan tegen stond was dat het geen config file heeft (/had?). Waardoor je alles in de CLI bij elkaar moet zoeken en dat weer in (bv) "lange" systemd services gooien.

Vervolgens naar Pyznap gegaan, die wel een ini style config file heeft waarbij je per dataset ("groep") vervolgens kunt aangeven hoeveel uurlijkse, dagelijkse, ... snapshots je wilt hebben (wat vervolgens automatisch op child datasets wordt toegepast). Alleen heeft die tool ook wel issues. Slechte rapportage over wel/geen succes bv (een echte error krijg je denk ik alleen als alles faalt, en misschien dat zelfs niet. Als een enkele dataset zou mislukken logt die alleen met een ERROR log line maar wel exit code 0). Daarnaast gebruikt die geen bookmarks of zo wat me incidenteel issues heeft gegeven (als ik lange tijd niet wist dat die niet gewerkt had en dus alweer de bron snapshot verwijderd was). En het heeft ook al jaren geen updates gehad.

Ook wel eens alternatieven bekeken. Laatste keer zrepl. Maar die faalt uberhaupt al in het snapshotten en opruimen. Weet niet meer precies hoe het zat maar die ruimde doodleuk zijn net gemaakte snapshots op omdat ze niet nodig zouden zijn volgens het "schema" .

[GioStyle]

Daar draai jij je hand toch niet voor om? Grappig om te zien dat iedereen er anders tegen aan kijkt. Ik vind sanoid/syncoid juist een verademing. Makkelijk in een config de templates vaststellen en de templates laten toepassen op de filesystems. Daarnaast een systemd optuigen met een simpel script om je snapshots geautomatiseerd naar je backupserver te sturen. En als het een keer faalt, krijg ik een mailtje, maar ik krijg zo weinig mail dat ik zelf af en toe kijk of het allemaal wel goed gaat.

[RobertMe]

GioStyle schreef op woensdag 11 maart 2026 @ 13:48:
Ik vind sanoid/syncoid juist een verademing. Makkelijk in een config de templates vaststellen en de templates laten toepassen op de filesystems.

Leest alsof er wat veranderd is (of ik heb toen niet goed gekeken). Binnenkort nog maar eens naar kijken.

[Jerie]

RobertMe schreef op woensdag 11 maart 2026 @ 15:19:
[...]

Leest alsof er wat veranderd is (of ik heb toen niet goed gekeken). Binnenkort nog maar eens naar kijken.

Dat is zeker zo, mijn config staat gewoon in /etc/sanoid/sanoid.conf daarnaast kun je een klein .sh scriptje maken met de flags erin, en dan een alias. Werkelijk een non-issue als de software verder goed voor jou werkt. Waarvan akte en als je huidige software prima werkt, why bother?

Ik gebruik naast sanoid ook syncoid, en daar heb ik geen aparte config voor. Ik draai deze dagelijks naar een remote locatie, en ook nog eens wekelijks naar een oude (backup) NAS. Overigens gebruik ik voor syncoid niet zo'n script, maar wel wat anders, namelijk cron. Tevreden over want met mbuffer over Wireguard is het retesnel ik geef toe dat het escapen soms wat lastig bleek (ook omdat ik nog eens Fish i.p.v. Bash/Zsh gebruikte), maar ben er niet uren mee bezig geweest.

Voor tape gebruik ik dan weer Duplicati omdat tape geen native versleuteling heeft (wel parity). Dit samen met LTFS over NFSv4 over IPv6 LL (fysiek zelfde hardware). Deze backup is maandelijks (maar niet een volledige).

[krijn1985]

Ik zal vast iets heel simpels over het hoofd zien, maar ik weet even niet wat. Dus hopelijk heeft iemand hier de gouden tip.

Ik heb een systeem met twee pools:

• lroot (mirror van 2 x 1,5T nvme (partitie)
• lpool (1 hdd + mirror van 0,5T nvme partitie als special device) (hierop staat een media en personal dataset met beide een eigen zfs encryptie wachtwoord)

Op lroot staat (zoals te verwachten) mijn debian bootstrap geinstalleerd met ZFS on root en systemd-boot. Ik heb aan mijn initramfs dropbear toegevoegd en een script om met clevis mijn lroot partitie te unlocken. Dit werkt prima. Nu wilde ik automatisch mijn andere twee datasets ook unlocken via clevis/tang combi maar deze heeft er toch moeite mee (zal wel aan mijn geschreven script etc liggen), waardoor die datasets te laat gemount zijn voordat mijn dockers opstarten of in ieder geval mijn dockers vertragen. Dus besloten om de passphrases in /etc/zfs in lpool.key en lpoolpersonal.key te plaatsen deze de locatie toe te voegen aan keylocation:

lpool keylocation file:///etc/zfs/lpool.key local
lpool/personal keylocation file:///etc/zfs/lpoolpersonal.key local

Hierbij hoopte ik dus dat na een reboot het zou werken, wat jammer genoeg niet zo was. Dus arch wiki er maar bij gepakt en gekeken naar zfs en systemd.

Dus gecontroleerd of zfs.target, zfs-import.target, zfs-import-cache.service en zfs-mount.service enabled zijn, zijn het ook allemaal. De zpool.cache bekeken en nog toegevoegd als cachefile aan de pools.

● zfs.target - ZFS startup target
Loaded: loaded (/usr/lib/systemd/system/zfs.target; enabled; preset: enabled)
Active: active since Wed 2026-07-29 21:23:35 CEST; 1 week 1 day ago
Invocation: c832d791ea0e4bdcb1df4ceb4ca26035

Jul 29 21:23:35 luiaard systemd[1]: Reached target zfs.target - ZFS startup target.

● zfs-import-cache.service - Import ZFS pools by cache file
Loaded: loaded (/usr/lib/systemd/system/zfs-import-cache.service; enabled; preset: enabled)
Active: active (exited) since Wed 2026-07-29 21:23:34 CEST; 1 week 1 day ago
Invocation: 28739bd6781640bb8363890def84597e
Docs: man:zpool(
Process: 2026 ExecStart=/usr/sbin/zpool import -c /etc/zfs/zpool.cache -aN $ZPOOL_IMPORT_OPTS (code=>
Main PID: 2026 (code=exited, status=0/SUCCESS)
Mem peak: 2.9M
CPU: 54ms

Jul 29 21:23:33 luiaard systemd[1]: Starting zfs-import-cache.service - Import ZFS pools by cache file...
Jul 29 21:23:34 luiaard systemd[1]: Finished zfs-import-cache.service - Import ZFS pools by cache file.

● zfs-mount.service - Mount ZFS filesystems
Loaded: loaded (/usr/lib/systemd/system/zfs-mount.service; enabled; preset: enabled)
Active: active (exited) since Wed 2026-07-29 21:23:34 CEST; 1 week 1 day ago
Invocation: 8a091d2cddbe445bad8db6322580fb4c
Docs: man:zfs(
Process: 2243 ExecStart=/usr/sbin/zfs mount -a (code=exited, status=0/SUCCESS)
Main PID: 2243 (code=exited, status=0/SUCCESS)
Mem peak: 9.1M
CPU: 123ms

Jul 29 21:23:34 luiaard systemd[1]: Starting zfs-mount.service - Mount ZFS filesystems...
Jul 29 21:23:34 luiaard systemd[1]: Finished zfs-mount.service - Mount ZFS filesystems.

● zfs-import.target - ZFS pool import target
Loaded: loaded (/usr/lib/systemd/system/zfs-import.target; enabled; preset: enabled)
Active: active since Wed 2026-07-29 21:23:34 CEST; 1 week 1 day ago
Invocation: 3450cccf568c46b18cc7d5078f9e87db

Jul 29 21:23:34 luiaard systemd[1]: Reached target zfs-import.target - ZFS pool import target.

Na reboot worden ze niet gemount. Ik zie niks bijzonders langs komen in journalctl dus ik weet gewoon even niet waar ik nu moet zoeken of wat ik eventueel vergeten.

Iemand tips?

[krijn1985]

Ik kan mijn bericht niet meer aanpassen. Maar bij deze een update:
Het was dus inderdaad iets stoms wat ik over het hoofd zag. Mijn keys werden niet ingeladen, dan mount hij het dus niet. In debian is zfs-load-keys.service gemasked omdat ze zelf bij default een andere manier gebruiken. Ik heb dus zelf een zfs-load-keys.service gemaakt ge-enabled en nu werkt het. Dus mocht iemand anders ook tegen dit probleem aanlopen, hopelijk kan ik je uren aan debuggen voorkomen.

P.s. Ik ben er niet bijna twee maanden mee bezig geweest, maar tijd om er even voor te gaan zitten was wat gelimiteerd.

[ Voor 11% gewijzigd door krijn1985 op 30-09-2026 21:55 ]

[RobertMe]

krijn1985 schreef op woensdag 30 september 2026 @ 21:55:
Ik kan mijn bericht niet meer aanpassen. Maar bij deze een update:
Het was dus inderdaad iets stoms wat ik over het hoofd zag. Mijn keys werden niet ingeladen, dan mount hij het dus niet. In debian is zfs-load-keys.service gemasked omdat ze zelf bij default een andere manier gebruiken. Ik heb dus zelf een zfs-load-keys.service gemaakt ge-enabled en nu werkt het. Dus mocht iemand anders ook tegen dit probleem aanlopen, hopelijk kan ik je uren aan debuggen voorkomen.

Wat ik zelf heb gedaan is mijn eigen service als dependency van de default zfs-load-key@.service gebruiken. Dus als die dataset X wilt mounten dan voert die [e-mail] uit, die een dependency op mijn eigen [e-mail]. Daardoor wordt mijn eigen service (/script) altijd uitgevoerd voor het build-in script / service. Waardoor het build in script "niks meer doet" (omdat die controleert of de key beschikbaar is, zo ja doet die niks meer).

Edit:
Voor de volledigheid. Mijn eigen service heeft dan:

code:

[Unit]
...
DefaultDependencies = no
Wants = network-online.target
After = network-online.target
Before = zfs-load-key@%i.service

[Service]
# This avoids a dependency loop involving systemd-journald.socket if this
# dataset is a parent of the root filesystem.
StandardOutput=null
StandardError=null
...

[Install]
WantedBy = zfs-load-key@%i.service

En waarschijnlijk (maar weet ik niet meer zeker ) heb ik die met het handje moeten enablen voor de datasets waarop het van toepassing is.

[ Voor 20% gewijzigd door RobertMe op 30-09-2026 22:33 ]

[krijn1985]

RobertMe schreef op woensdag 30 september 2026 @ 22:31:
[...]

Wat ik zelf heb gedaan is mijn eigen service als dependency van de default zfs-load-key@.service gebruiken. Dus als die dataset X wilt mounten dan voert die [e-mail] uit, die een dependency op mijn eigen [e-mail]. Daardoor wordt mijn eigen service (/script) altijd uitgevoerd voor het build-in script / service. Waardoor het build in script "niks meer doet" (omdat die controleert of de key beschikbaar is, zo ja doet die niks meer).

Edit:
Voor de volledigheid. Mijn eigen service heeft dan:

code:

[Unit]
...
DefaultDependencies = no
Wants = network-online.target
After = network-online.target
Before = zfs-load-key@%i.service

[Service]
# This avoids a dependency loop involving systemd-journald.socket if this
# dataset is a parent of the root filesystem.
StandardOutput=null
StandardError=null
...

[Install]
WantedBy = zfs-load-key@%i.service

En waarschijnlijk (maar weet ik niet meer zeker ) heb ik die met het handje moeten enablen voor de datasets waarop het van toepassing is.

Ja zoiets had ik deels eerst ook gedaan per dataset een service maar ik heb voor een dataset pool/dataset een aparte key en dan leek ik die service weer niet netjes op die naam te krijgen en toen heb ik de makkelijke weg gekozen en gewoon alle Keys laden.