ZFS Snapshots Tutorial

ZFS Snapshots Tutorial
Øyeblikksbilder er viktig om du kjører en enkel virtuell maskin på hjemmecomputeren din, eller om det er en bedriftsdatabase som stadig blir oppdatert og modifisert. Å ha øyeblikksbilder, det vil si en kopi av hele filsystemet slik det var i en gitt periode er viktig.

Folk mister ofte oversikten over hvor ting gikk galt, en fil ble slettet og ingen la merke til at den var borte. Flere sikkerhetskopier har gått, og nå innser du at en viktig fil mangler fra alle tilgjengelige sikkerhetskopiering av de siste 5 ukene. I denne opplæringen skal vi se hvordan du bruker ZFS -øyeblikksbilder og berører ulike øyeblikkelig politikk som vil fungere optimalt, både når det gjelder ressursutnyttelse og utvinnbarhet.

Copy-on-Write-mekanisme

ZFS har både den høye nivåoversikten over filer og kataloger og forstår hvordan data skrives på disken. Når du fysisk skriver data på en disk, gjøres det i diskrete blokker. Vanligvis kan blokkstørrelsen gå opp til 1 MB, men standard er vanligvis 128 kb. Nå betyr dette at enhver modifisering (les, skriv eller sletting) vil skje i de diskrete blokkene.

Kopieringsmekanismen sikrer at når en blokk blir endret, i stedet for å endre blokken direkte, lager den en kopi av blokken med de nødvendige modifikasjonene gjort på den nye blokken.

Dette er spesielt nyttig i tilfeller der, for eksempel, det er en strømbrudd og systemet ditt krasjer mens nye data ble skrevet på disken. Hvis det skjer i et tradisjonelt filsystem, vil filene dine bli ødelagte eller sitte igjen med hull i dem. Men hvis du bruker ZFS, kan du miste den pågående transaksjonen som det skjedde, men filenes siste gyldige tilstand vil fortsatt være uberørt.

Øyeblikksbilder er også avhengige av denne funksjonaliteten, og ganske tungt faktisk. Når du tar et øyeblikksbilde av et gitt datasett ('Datasett' er ZFS -betegnelsen for et filsystem), registrerer ZFS bare tidsstempelet når øyeblikksbildet ble laget. Det er det! Ingen data kopieres og ingen ekstra lagring konsumeres.

Bare når filsystemet endres, og dataene i det, avviker fra øyeblikksbildet, begynner øyeblikksbildet å konsumere ekstra lagring. Det som skjer under panseret er dette - i stedet for å resirkulere de gamle blokkene over tid, holder ZFS dem rundt. Dette forbedrer også lagringsutnyttelsen. Hvis du snapsbilde et 20 GB datasett og bare endrer noen få tekstfiler her og der, kan det bare ta noen få MB -er noen få MB.


Opprette øyeblikksbilder

For å demonstrere bruken av øyeblikksbilder, la oss starte med et datasett som har mange tekstfiler, bare for å holde saken enkel. Den virtuelle maskinen jeg bruker til demoen kjører FreeBSD 11.1-Release-P3 som er den siste stabile utgivelsen som er tilgjengelig på dette tidspunktet. Rotfilsystemet er montert på Zroot basseng som standard og mye av de kjente katalogene som /usr /src, /hjem, /etc er alle sine egne datasett montert på Zroot. Hvis du ikke vet hva et basseng (eller en zpool) betyr, i ZFS -språk, ville det være vel verdt å lese opp det før du fortsetter.

Et av de mange filsystemene, eller datasettene, som kommer som standard på FreeBSD er: Zroot/usr/src

For å se på Egenskaper, kjør følgende kommando.

root@testbsd: ~ $ zfs liste zroot/usr/src

Som du ser bruker den 633 MB lagring. Det inneholder hele kildetreet for operativsystemet.

La oss ta et øyeblikksbilde av Zroot/usr/src

root@testbsd: ~ $ zfs snapshot zroot/usr/src@snapshot1

@ -Symbolet fungerer som en avgrenser mellom datasettet og øyeblikksbildet, som i vårt tilfelle er Snapshot1.

La oss nå se på tilstanden til øyeblikksbildet slik det er opprettet.

Ved å kjøre kommandoen:

ZFS -liste -RT All Zroot/USR/SRC

Du kan se at øyeblikksbildet ikke bruker ekstra plass når den blir født. Det er ingen tilgjengelig plass heller, fordi det er et strengt lest datasett, selve øyeblikksbildet kan ikke vokse, endre eller krympe. Til slutt er den ikke montert noe sted som gjør det fullstendig isolert fra det gitte filsystemhierarkiet.

La oss nå fjerne sbin katalog i /usr/src/

root@testbsd: $ rm/usr/src/sbin

Ser du på øyeblikksbildet vil du nå se at det har vokst,

Dette forventes fordi kopieringsmekanismen er på jobb her og sletter (eller endrer) filene har ført til at mer av dataene bare er tilknyttet øyeblikksbildet og ikke datasettet som faktisk er i bruk.

Legg merke til referansen i outputten ovenfor. Det gir deg mengden tilgjengelige data på datasettet, mens den brukte kolonnen bare viser deg hvor mye plass som er okkupert på den fysiske disken.

ZFS 'kopieringsmekanisme gir ofte disse motintuitive resultatene der å slette en fil vil få den til å se ut som om mer plass nå brukes enn før. Men etter å ha lest så langt, vet du hva som faktisk skjer!

La oss gjenopprette sbin fra Snapshot1. Å gjøre det ganske enkelt å løpe:

root@testbsd:/usr/src $ zfs rollback zroot/usr/src@snapshot1

Snapshotting -policy

Det neste spørsmålet å stille er - hvor ofte du vil ta øyeblikksbildene? Selv om det kan variere fra en virksomhet til en annen, la oss ta eksemplet på en veldig dynamisk database som endres så ofte.

Til å begynne med vil du begynne å ta øyeblikksbilder hver 6. time, men fordi databasen endres så mye, vil det snart bli umulig å lagre alle de mange øyeblikksbildene som ble opprettet. Så neste trinn ville være å rense øyeblikksbilder som er eldre enn, for eksempel, 48 timer.

Nå vil problemet være å gjenopprette noe som har gått tapt for 49 timer siden. For å omgå dette problemet, kan du oppbevare ett eller to øyeblikksbilder fra den 48 timers historien og holde dem rundt i en uke. Rens dem når de blir eldre enn det.

Og hvis du kan fortsette denne veien, kan du stappe øyeblikksbilder opp til selve genesen av systemet, bare i synkende frekvensrekkefølge. Til slutt vil jeg påpeke at disse øyeblikksbilder er skrivebeskyttet, noe som betyr at hvis du blir smittet av en ransomware og får alle dataene dine kryptert (modifisert). Disse øyeblikksbildene vil, mest sannsynlig, fortsatt være intakte.