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.