Snapshots zijn belangrijk of u nu een eenvoudige virtuele machine op uw thuiscomputer draait of dat het een bedrijfsdatabase is die voortdurend wordt bijgewerkt en gewijzigd. Het is belangrijk om snapshots te hebben, d.w.z. een kopie van het volledige bestandssysteem zoals dat er op een bepaald moment uitzag.
Mensen weten vaak niet meer waar het fout is gegaan, een bestand is verwijderd en niemand heeft gemerkt dat het weg was. Verschillende back-ups zijn voorbijgegaan en nu realiseer je je dat een belangrijk bestand ontbreekt in alle beschikbare back-ups van de laatste 5 weken. In deze tutorial zullen we zien hoe we ZFS snapshots kunnen gebruiken en zullen we verschillende snapshotting policies bespreken die optimaal zouden werken, zowel in termen van resource gebruik als van herstelbaarheid.
ZFS heeft zowel het overzicht op hoog niveau van bestanden en directories als begrip van hoe gegevens op de schijf worden geschreven. Wanneer gegevens fysiek op een schijf worden geschreven, gebeurt dit in discrete blokken. Typisch kan de blokgrootte oplopen tot 1 MB, maar de standaard is meestal 128 KB. Dit betekent dat elke wijziging (lezen, schrijven of verwijderen) gebeurt in de discrete blokken.
Het copy-on-write mechanisme zorgt ervoor dat wanneer een blok wordt gewijzigd, in plaats van het blok direct te wijzigen, er een kopie van het blok wordt gemaakt met de vereiste wijzigingen op het nieuwe blok.
Dit is vooral handig in gevallen waar, laten we zeggen, er een stroomstoring is en uw systeem crasht terwijl er nieuwe gegevens op de schijf werden geschreven. Als dat gebeurt in een traditioneel bestandssysteem, zullen uw bestanden beschadigd raken of er zullen gaten in komen. Maar als u ZFS gebruikt, kunt u de lopende transactie verliezen terwijl dat gebeurde, maar de laatste geldige status van uw bestanden zal onaangetast blijven.
Snapshots vertrouwen ook op deze functionaliteit, en behoorlijk zwaar zelfs. Wanneer je een snapshot maakt van een gegeven dataset (‘dataset’ is de ZFS term voor een bestandssysteem), dan registreert ZFS alleen de tijdstempel waarop de snapshot is gemaakt. Dat is alles! Er worden geen gegevens gekopieerd en er wordt geen extra opslagruimte in beslag genomen.
Alleen wanneer het bestandssysteem verandert, en de gegevens daarin afwijken van de momentopname, begint de momentopname extra opslagruimte in beslag te nemen. Wat er onder de motorkap gebeurt is het volgende – In plaats van de oude blokken in de loop der tijd te recyclen, houdt ZFS ze in de buurt. Dit verbetert ook het opslaggebruik. Als je een snapshot maakt van een dataset van 20 GB en alleen hier en daar wat tekstbestanden wijzigt, neemt de snapshot misschien maar een paar MB ruimte in beslag.
Het maken van snapshots
Om het gebruik van snapshots te demonstreren, laten we beginnen met een dataset die veel tekstbestanden bevat, om de zaak eenvoudig te houden. De virtuele machine die ik zal gebruiken voor de demo draait FreeBSD 11.1-RELEASE-p3, wat de laatste stabiele release is die beschikbaar is op het moment van dit schrijven. Het root bestandssysteem is standaard aangekoppeld op de zroot pool en veel van de bekende directories zoals /usr/src, /home, /etc zijn allemaal hun eigen datasets die op zroot zijn aangekoppeld. Als u niet weet wat een pool (of een zpool) in de ZFS-taal betekent, is het de moeite waard om er eerst over te lezen voordat u verder gaat.
Een van de vele bestandssystemen, of datasets, die standaard op FreeBSD aanwezig zijn is: zroot/usr/src
Om de eigenschappen ervan te bekijken, voert u het volgende commando uit.
:~$ zfs list zroot/usr/src
Zoals u kunt zien gebruikt het 633 MB aan opslagruimte. Het bevat de volledige source tree van het besturingssysteem.
Laten we een snapshot maken van zroot/usr/src
:~$ zfs snapshot zroot/usr/
Het @ symbool fungeert als een scheidingsteken tussen de dataset en de snapshot naam, die in ons geval snapshot1 is.
Laten we nu eens kijken naar de toestand van het snapshot terwijl het wordt aangemaakt.
Door het commando uit te voeren:
zfs list -rt all zroot/usr/src
U kunt zien dat het snapshot geen extra ruimte gebruikt wanneer het wordt aangemaakt. Er is ook geen beschikbare ruimte, omdat het een strikt alleen-lezen dataset is, kan het snapshot zelf niet groeien, wijzigen of krimpen. Tenslotte is het nergens gemount, waardoor het volledig geïsoleerd is van de gegeven bestandssysteem hiërarchie.
Nu, laten we de sbin directory in /usr/src/ verwijderen
:$ rm /usr/src/sbin
Kijkend naar de momentopname zult u nu zien dat deze gegroeid is,
Dit is te verwachten omdat het copy-on-write mechanisme hier aan het werk is en het verwijderen (of wijzigen) van de bestanden heeft ertoe geleid dat meer van de gegevens alleen geassocieerd worden met de momentopname en niet met de dataset die daadwerkelijk in gebruik is.
Let op de REFER kolom in de bovenstaande uitvoer. Het geeft je de hoeveelheid toegankelijke gegevens op de dataset, terwijl de kolom GEBRUIKT je alleen laat zien hoeveel ruimte er op de fysieke schijf in beslag wordt genomen.
ZFS’ Copy-On-Write mechanisme geeft vaak deze tegen-intuïtieve resultaten, waarbij het verwijderen van een bestand het zou laten lijken alsof er nu meer ruimte wordt gebruikt dan voorheen. Maar als je tot zover gelezen hebt, weet je wat er werkelijk gebeurt!
Voordat we afsluiten, laten we de sbin van snapshot1 herstellen. Om dat te doen voert u eenvoudigweg uit:
:/usr/src$ zfs rollback zroot/usr/
Snapshotting Policy
De volgende vraag die gesteld moet worden is – Hoe vaak wilt u de snapshots maken? Hoewel dit per onderneming kan verschillen, nemen we het voorbeeld van een zeer dynamische database die om de zoveel tijd verandert.
Om te beginnen zou u om de 6 uur of zo snapshots nemen, maar omdat de database zo veel verandert, zou het al snel ondoenlijk worden om alle talrijke snapshots die zijn gemaakt op te slaan. De volgende stap zou dus zijn om snapshots te wissen die ouder zijn dan, zeg, 48 uur.
Nu zou het probleem zijn om iets terug te halen dat 49 uur geleden verloren is gegaan. Om dit probleem te omzeilen, kun je een of twee snapshots bewaren van die 48 uur historie en die een week lang bewaren. Zuiver ze als ze ouder worden dan dat.
En als je op deze manier door kunt gaan, zou je snapshots kunnen proppen tot aan het ontstaan van het systeem, gewoon in afnemende volgorde van frequentie. Tenslotte wil ik er op wijzen dat deze snapshots ALLEEN LEESbaar zijn, wat betekent dat als je geïnfecteerd wordt door ransomware en al je gegevens worden versleuteld (gewijzigd). Deze snapshots zouden, zeer waarschijnlijk, nog steeds intact zijn.