Øyeblikksbilder er viktige enten du kjører en enkel virtuell maskin på hjemme-datamaskinen din eller om det er en bedriftsdatabase som kontinuerlig oppdateres og endres. Å ha øyeblikksbilder, det vil si en kopi av hele filsystemet slik det var i en gitt tidsperiode 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å er du klar over at en viktig fil mangler fra alle tilgjengelige sikkerhetskopier de siste 5 ukene. I denne opplæringen skal vi se hvordan du bruker ZFS-øyeblikksbilder og berører forskjellige øyeblikksbilde-policyer som vil fungere optimalt, både når det gjelder ressursutnyttelse og utvinnbarhet.

Copy-On-Write-mekanisme

ZFS har både høyt nivå oversikt 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. Dette betyr at enhver modifikasjon (lese, skrive eller slette) vil skje i de diskrete blokkene.

Kopi-på-skriv-mekanismen sørger for at når en blokk modifiseres, i stedet for å modifisere blokken direkte, lager den en kopi av blokken med nødvendige modifikasjoner gjort på den nye blokken.

Dette er spesielt nyttig i tilfeller der det for eksempel er strømbrudd og systemet krasjer mens nye data ble skrevet på disken. Hvis det skjer i et tradisjonelt filsystem, vil filene dine bli ødelagt eller sitte igjen med hull i dem. Men hvis du bruker ZFS, kan du miste den pågående transaksjonen mens den skjedde, men filens siste gyldige tilstand vil fortsatt være urø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-begrepet for et filsystem), registrerer ZFS bare tidsstempelet når øyeblikksbildet ble laget. Det er det! Ingen data kopieres og ingen ekstra lagring forbrukes.

Først når filsystemet endres, og dataene i det skiller seg fra øyeblikksbildet, begynner øyeblikksbildet å forbruke ekstra lagringsplass. 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 tar et 20 GB datasett og endrer bare noen få tekstfiler her og der, kan øyeblikksbildet bare ta noen MBs plass.

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 skal bruke for demoen kjører FreeBSD 11.1-RELEASE-p3 som er den siste stabile utgivelsen som er tilgjengelig i skrivende stund. Rotfilsystemet er montert på zroot pool som standard og mange av de kjente katalogene som / usr / src, / home, / etc er alle sine egne datasett montert på zroot. Hvis du ikke vet hva et basseng (eller en zpool) betyr, i ZFS-folkespråket, ville det være verdt å lese om 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å egenskapene, kjør følgende kommando.

[e-postbeskyttet]: ~ $ zfs liste zroot / usr / src

Som du ser, bruker den 633 MB lagringsplass. Den inneholder hele kildetreet for operativsystemet.

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

[e-postbeskyttet]: ~ $ zfs øyeblikksbilde zroot / usr / [e-postbeskyttet]

@ -Symbolet fungerer som en avgrenser mellom datasettet og øyeblikksbilde-navnet, som i vårt tilfelle er øyeblikksbilde1.

La oss nå se på stillbildet til øyeblikksbildet når det er opprettet.

Ved å kjøre kommandoen:

zfs liste -rt alle zroot / usr / src

Du kan se at øyeblikksbildet ikke bruker ekstra plass når det blir født. Det er heller ikke ledig plass, fordi det er et strengt skrivebeskyttet datasett, øyeblikksbildet i seg selv kan ikke vokse, endre eller krympe. Til slutt er den ikke montert hvor som helst som gjør den fullstendig isolert fra det gitte filsystemhierarkiet.

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

[e-postbeskyttet]: $ rm / usr / src / sbin

Når du ser på øyeblikksbildet, vil du nå se at det har vokst,

Dette forventes fordi kopi-på-skriv-mekanismen er på jobb her og sletting (eller endring) av filene har ført til at mer av dataene bare er knyttet til øyeblikksbildet og ikke datasettet som faktisk er i bruk.

Legg merke til kolonnen REFER i utgangen ovenfor. Det gir deg mengden tilgjengelige data på datasettet, mens den BRUKTE kolonnen bare viser deg hvor mye plass som er opptatt på den fysiske disken.

ZFS 'Copy-On-Write-mekanisme gir ofte disse kontraintuitive resultatene der sletting av en fil vil få det til å se ut som om det blir brukt mer plass enn før. Etter å ha lest så langt vet du imidlertid hva som faktisk skjer!

La oss gjenopprette den før du er ferdig sbin fra øyeblikksbilde1. For å gjøre det bare løp:

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

Retningslinjer for snapshotting

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

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

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

Og hvis du kan fortsette på denne måten, kan du klemme øyeblikksbilder helt til systemets opprinnelse, bare i avtagende rekkefølge. Til slutt vil jeg påpeke at disse øyeblikksbildene KUN LESES, noe som betyr at hvis du blir smittet av en ransomware og får alle dataene dine kryptert (modifisert). Disse øyeblikksbildene vil sannsynligvis fortsatt være intakte.