Momentopnamen zijn belangrijk, of u nu een eenvoudige virtuele machine op uw thuiscomputer gebruikt of een bedrijfsdatabase is die voortdurend wordt bijgewerkt en gewijzigd. Het hebben van snapshots, dat wil zeggen een kopie van het volledige bestandssysteem zoals het was in een bepaalde periode, is belangrijk.

Mensen vergeten vaak waar het mis ging, een bestand werd verwijderd en niemand merkte dat het weg was. Er zijn verschillende back-ups gemaakt en nu realiseer je je dat er een belangrijk bestand ontbreekt in alle beschikbare back-ups van de afgelopen 5 weken. In deze zelfstudie zullen we zien hoe we ZFS-snapshots kunnen gebruiken en verschillende snapshotbeleidsregels bespreken die optimaal zouden werken, zowel in termen van resourcegebruik als herstelbaarheid.

Copy-On-Write-mechanisme

ZFS heeft zowel een overzicht op hoog niveau van bestanden en mappen en begrijpt hoe gegevens op de schijf worden geschreven. Wanneer gegevens fysiek naar een schijf worden geschreven, gebeurt dit in discrete blokken. Meestal kan de blokgrootte oplopen tot 1 MB, maar de standaardwaarde is meestal 128 KB. Dit betekent dat elke wijziging (lezen, schrijven of verwijderen) zal gebeuren in de discrete blokken.

Het copy-on-write-mechanisme zorgt ervoor dat wanneer een blok wordt gewijzigd, in plaats van het blok rechtstreeks te wijzigen, het een kopie van het blok maakt met de vereiste wijzigingen op het nieuwe blok.

Dit is vooral handig in gevallen waarin er bijvoorbeeld een stroomstoring is en uw systeem crasht terwijl nieuwe gegevens naar de schijf werden geschreven. Als dat gebeurt in een traditioneel bestandssysteem, raken je bestanden beschadigd of blijven er gaten in zitten. Maar als u ZFS gebruikt, kunt u de lopende transactie verliezen terwijl dat gebeurde, maar de laatste geldige status van uw bestanden blijft onaangetast.

Snapshots zijn ook afhankelijk van deze functionaliteit, en behoorlijk zwaar zelfs. Wanneer u een momentopname maakt van een bepaalde dataset ('dataset' is de ZFS-term voor een bestandssysteem), registreert ZFS alleen de tijdstempel waarop de momentopname is gemaakt. Dat is het! Er worden geen gegevens gekopieerd en er wordt geen extra opslagruimte verbruikt.

Alleen wanneer het bestandssysteem verandert en de gegevens erin afwijken van de snapshot, begint de snapshot extra opslagruimte te verbruiken. Wat er onder de motorkap gebeurt, is dit: in plaats van de oude blokken na verloop van tijd te recyclen, houdt ZFS ze in de buurt. Dit verbetert ook het opslaggebruik. Als u een momentopname maakt van een dataset van 20 GB en hier en daar slechts een paar tekstbestanden wijzigt, kan de momentopname slechts enkele MB's aan ruimte in beslag nemen.

Momentopnamen maken

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 voor de demo zal gebruiken, draait op FreeBSD 11.1-RELEASE-p3, de nieuwste stabiele release die beschikbaar is op het moment van schrijven. Het rootbestandssysteem is gemount op de zroot pool standaard en veel van de bekende mappen zoals /usr/src, /home, /etc zijn al hun eigen datasets gemonteerd op zroot. Als je niet weet wat een pool (of een zpool) betekent, in de ZFS-taal, zou het de moeite waard zijn om erover te lezen voordat je verder gaat.

Een van de vele bestandssystemen, of datasets, die standaard op FreeBSD aanwezig zijn, is: zroot/usr/src

Voer de volgende opdracht uit om de eigenschappen ervan te bekijken:.

[e-mail beveiligd]:~$ zfs lijst zroot/usr/src

Zoals je kunt zien, gebruikt het 633 MB opslagruimte. Het bevat de volledige bronstructuur voor het besturingssysteem.

Laten we een momentopname maken van zroot/usr/src

[email protected]:~$ zfs snapshot zroot/usr/[email protected]

Het @-symbool fungeert als scheidingsteken tussen de dataset en de snapshotnaam, wat in ons geval is case momentopname1.

Laten we nu eens kijken naar de staat van de snapshot zoals deze is gemaakt.

Door de opdracht uit te voeren:

zfs lijst -rt all zroot/usr/src

U kunt zien dat de momentopname geen extra ruimte in beslag neemt wanneer deze wordt geboren. Er is ook geen beschikbare ruimte, omdat het een strikt alleen-lezen dataset is, de snapshot zelf kan niet groeien, wijzigen of krimpen. Ten slotte wordt het nergens aangekoppeld, waardoor het volledig geïsoleerd is van de gegeven bestandssysteemhiërarchie.

Laten we nu de . verwijderen sbin map in /usr/src/

[e-mail beveiligd]:$ rm /usr/src/sbin

Als je naar de momentopname kijkt, zie je nu dat deze is gegroeid,

Dit wordt verwacht omdat het copy-on-write-mechanisme hier aan het werk is en het verwijderen (of wijzigen) van de bestanden ertoe heeft geleid dat meer gegevens alleen aan de momentopname zijn gekoppeld en niet aan de gegevensset die daadwerkelijk in gebruik is.

Let op de REFER-kolom in de bovenstaande uitvoer:. Het geeft u de hoeveelheid toegankelijke gegevens op de dataset, terwijl de kolom GEBRUIKT u alleen laat zien hoeveel ruimte er op de fysieke schijf is ingenomen.

Het Copy-On-Write-mechanisme van ZFS geeft vaak deze contra-intuïtieve resultaten, waarbij het verwijderen van een bestand het lijkt alsof er nu meer ruimte wordt gebruikt dan voorheen. Maar als je tot nu toe hebt gelezen, weet je wat er feitelijk gebeurt!

Laten we, voordat we eindigen, de . herstellen sbin van momentopname1. Om dat te doen, voert u eenvoudig het volgende uit:

[email protected]:/usr/src$ zfs rollback zroot/usr/[email protected]

Beleid voor snapshots

De volgende vraag die u moet stellen is: Hoe vaak wilt u de snapshots maken?? Hoewel het van onderneming tot onderneming kan verschillen, nemen we het voorbeeld van een zeer dynamische database die om de zoveel tijd verandert changes.

Om te beginnen zou je om de 6 uur snapshots gaan maken, maar omdat de database zo veel verandert, zou het al snel onhaalbaar worden om alle gemaakte snapshots op te slaan. Dus de volgende stap zou zijn om snapshots te wissen die ouder zijn dan bijvoorbeeld 48 uur.

Nu zou het probleem zijn om iets te herstellen dat 49 uur geleden verloren is gegaan. Om dit probleem te omzeilen, kun je een of twee snapshots van die 48-uursgeschiedenis bewaren en ze een week 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, alleen in afnemende volgorde van frequentie. Ten slotte wil ik erop wijzen dat deze snapshots ALLEEN LEZEN zijn, wat betekent dat als u geïnfecteerd raakt door een ransomware en al uw gegevens worden versleuteld (aangepast). Deze snapshots zouden hoogstwaarschijnlijk nog steeds intact zijn.