Snapshots er vigtige, uanset om du kører en simpel virtuel maskine på din hjemmecomputer, eller om det er en virksomhedsdatabase, der konstant opdateres og ændres. Det er vigtigt at have snapshots, dvs. en kopi af hele filsystemet, som det var på et givet tidspunkt.
Folk mister ofte overblikket over, hvor det gik galt, en fil blev slettet, og ingen bemærkede, at den var væk. Flere sikkerhedskopier er gået, og nu opdager man, at en vigtig fil mangler i alle de tilgængelige sikkerhedskopier fra de sidste 5 uger. I denne tutorial skal vi se, hvordan man bruger ZFS-snapshots og berøre forskellige snapshotting-politikker, der vil fungere optimalt, både med hensyn til ressourceudnyttelse og genoprettelsesmuligheder.
ZFS har både overblik på højt niveau over filer og mapper og forstår, hvordan data skrives på disken. Når der fysisk skrives data på en disk, sker det i diskrete blokke. Typisk kan blokstørrelsen gå op til 1 MB, men standardværdien er normalt 128 KB. Det betyder nu, at enhver ændring (læsning, skrivning eller sletning) vil ske i de diskrete blokke.
Mekanismen copy-on-write sikrer, at hver gang en blok ændres, i stedet for at ændre blokken direkte, laves der en kopi af blokken med de nødvendige ændringer udført på den nye blok.
Dette er især nyttigt i tilfælde, hvor der f.eks. er strømsvigt, og dit system går ned, mens der blev skrevet nye data på disken. Hvis det sker i et traditionelt filsystem, vil dine filer blive beskadiget eller efterlades med huller i dem. Men hvis du bruger ZFS, mister du måske den igangværende transaktion, mens det skete, men dine filers sidste gyldige tilstand vil stadig blive efterladt uberørt.
Snapshots er også afhængige af denne funktionalitet, og det i ret høj grad faktisk. Når du tager et snapshot af et givet datasæt (“datasæt” er ZFS’ betegnelse for et filsystem), registrerer ZFS blot det tidsstempel, hvor snapshotet blev taget. Det er det hele! Der kopieres ingen data, og der forbruges ikke ekstra lagerplads.
Det er kun, når filsystemet ændres, og dataene i det afviger fra snapshotet, at snapshotet begynder at forbruge ekstra lagerplads. Det, der sker under motorhjelmen, er følgende – I stedet for at genbruge de gamle blokke over tid, beholder ZFS dem. Dette forbedrer også udnyttelsen af lagerplads. Hvis du tager et snapshot af et datasæt på 20 GB og kun ændrer nogle få tekstfiler her og der, tager snapshotet måske kun nogle få MB plads.
Skabelse af snapshots
For at demonstrere brugen af snapshots starter vi med et datasæt, der har mange tekstfiler, bare for at holde sagen simpel. Den virtuelle maskine, som jeg vil bruge til demonstrationen, kører FreeBSD 11.1-RELEASE-p3, som er den seneste stabile udgave, der er tilgængelig i skrivende stund. Root-filsystemet er som standard monteret på zroot-puljen, og mange af de velkendte mapper som /usr/src, /home, /etc er alle deres egne datasæt monteret på zroot. Hvis du ikke ved, hvad en pool (eller en zpool) betyder i ZFS-sproget, er det værd at læse op på det, før du fortsætter.
Et af de mange filsystemer, eller datasæt, der følger med som standard i FreeBSD er: zroot/usr/src
For at se på dets egenskaber skal du køre følgende kommando.
:~$ zfs list zroot/usr/src
Som du kan se, bruger det 633 MB lagerplads. Den indeholder hele kildetræet for styresystemet.
Lad os tage et snapshot af zroot/usr/src
:~$ zfs snapshot zroot/usr/
Symbolet @ fungerer som en afgrænser mellem datasættet og snapshot-navnet, som i vores tilfælde er snapshot1.
Nu skal vi se på tilstanden af snapshotet, når det oprettes.
Ved at køre kommandoen:
zfs list -rt all zroot/usr/src
Du kan se, at snapshotet ikke bruger ekstra plads, når det er født. Der er heller ikke nogen ledig plads, da det er et strengt skrivebeskyttet datasæt, kan selve snapshotet ikke vokse, ændre eller krympe. Endelig er det ikke monteret nogen steder, hvilket gør det helt isoleret fra det givne filsystemhierarki.
Lad os nu fjerne sbin-mappen i /usr/src/
:$ rm /usr/src/sbin
Kigger man på snapshotet, vil man nu se, at det er vokset,
Dette er forventeligt, fordi copy-on-write-mekanismen er på spil her, og sletning (eller ændring) af filerne har ført til, at flere af dataene kun er knyttet til snapshotet og ikke til det datasæt, der faktisk er i brug.
Bemærk kolonnen REFER i ovenstående output. Den giver dig mængden af tilgængelige data på datasættet, mens kolonnen USED blot viser dig, hvor meget plads der er optaget på den fysiske disk.
ZFS’ Copy-On-Write-mekanisme giver ofte disse kontraintuitive resultater, hvor sletning af en fil ville få det til at se ud som om, at der nu bruges mere plads end før. Men når du har læst så langt, ved du, hvad der faktisk sker!
Hvor vi slutter, lad os gendanne sbin fra snapshot1. For at gøre det skal du blot køre:
:/usr/src$ zfs rollback zroot/usr/
Snapshotting Policy
Det næste spørgsmål, du skal stille, er – Hvor ofte vil du tage snapshotsene? Det kan variere fra virksomhed til virksomhed, men lad os tage eksemplet med en meget dynamisk database, der ændrer sig med jævne mellemrum.
Til at begynde med ville du begynde at tage snapshots hver 6. time eller deromkring, men fordi databasen ændrer sig så meget, ville det hurtigt blive uoverkommeligt at gemme alle de mange snapshots, der blev oprettet. Så det næste skridt ville være at rense snapshots, der er ældre end f.eks. 48 timer.
Nu ville problemet være at gendanne noget, der er blevet tabt for 49 timer siden. For at omgå dette problem kan du beholde et eller to snapshots fra denne 48 timers historik og opbevare dem i en uge. Rens dem, når de bliver ældre end det.
Og hvis du kan blive ved på denne måde, kan du proppe snapshots op til selve systemets tilblivelse, bare i faldende rækkefølge efter hyppighed. Til sidst vil jeg gerne påpege, at disse snapshots er READ-ONLY, hvilket betyder, at hvis du bliver inficeret af en ransomware og får alle dine data krypteret (ændret). Disse snapshots ville, højst sandsynligt, stadig være intakte.