Ögonblicksbilder är viktiga oavsett om du kör en enkel virtuell maskin på din hemdator eller om det är en företagsdatabas som ständigt uppdateras och ändras. Att ha ögonblicksbilder, det vill säga en kopia av hela filsystemet som det var vid en viss tidsperiod är viktigt.

Människor tappar ofta koll på var saker gick fel, en fil raderades och ingen märkte att den var borta. Flera säkerhetskopior har passerat och nu inser du att en viktig fil saknas i alla tillgängliga säkerhetskopior de senaste 5 veckorna. I den här handledningen ska vi se hur man använder ZFS-snapshots och berör olika snapshotting-policyer som skulle fungera optimalt, både när det gäller resursanvändning och återhämtningsförmåga.

Copy-On-Write-mekanism

ZFS har både hög nivå överblick över filer och kataloger och förstår hur data skrivs på disken. När du fysiskt skriver data på en skiva görs det i diskreta block. Vanligtvis kan blockstorleken gå upp till 1 MB men standard är vanligtvis 128 KB. Nu betyder det att varje modifiering (läs, skriv eller radering) kommer att ske i de separata blocken.

Copy-on-write-mekanismen säkerställer att när ett block modifieras, istället för att modifiera blocket direkt, gör det en kopia av blocket med nödvändiga modifieringar gjorda på det nya blocket.

Detta är särskilt användbart i fall där det till exempel är strömavbrott och ditt system kraschar medan nya data skrivs på disken. Om det händer i ett traditionellt filsystem blir dina filer skadade eller kvar med hål i dem. Men om du använder ZFS kan du förlora den pågående transaktionen som det hände, men dina filers senaste giltiga tillstånd kommer fortfarande att vara orörd.

Ögonblicksbilder är också beroende av denna funktionalitet, och faktiskt ganska tungt. När du tar en ögonblicksbild av en viss dataset ('dataset' är ZFS-termen för ett filsystem) registrerar ZFS bara tidsstämpeln när ögonblicksbilden gjordes. Nu räcker det! Ingen data kopieras och ingen extra lagring förbrukas.

Först när filsystemet ändras och data i det skiljer sig från ögonblicksbilden börjar ögonblicksbilden konsumera extra lagring. Vad som händer under huven är detta - Istället för att återvinna de gamla blocken över tid håller ZFS dem kvar. Detta förbättrar också lagringsutnyttjandet. Om du snapshot en 20 GB dataset och ändrar bara några textfiler här och där kan ögonblicksbilden bara ta några MB utrymme.

Skapa ögonblicksbilder

För att demonstrera användningen av ögonblicksbilder, låt oss börja med en dataset som har många textfiler, bara för att hålla saken enkel. Den virtuella maskinen som jag kommer att använda för demo kör FreeBSD 11.1-RELEASE-p3 som är den senaste stabila versionen som finns tillgänglig när detta skrivs. Rotsfilsystemet är monterat på zroot pool som standard och många bekanta kataloger som / usr / src, / home, / etc är alla sina egna datamängder monterade på zroot. Om du inte vet vad en pool (eller en zpool) betyder, i ZFS-folkspråket, skulle det vara värt att läsa om det innan du fortsätter.

Ett av de många filsystemen eller datauppsättningarna som finns som standard på FreeBSD är: zroot / usr / src

För att titta på egenskaperna, kör följande kommando.

[e-postskyddad]: ~ $ zfs lista zroot / usr / src

Som du ser använder den 633 MB lagringsutrymme. Den innehåller hela källträdet för operativsystemet.

Låt oss ta en ögonblicksbild av zroot / usr / src

[e-postskyddad: ~ $ zfs ögonblicksbild zroot / usr / [e-postskyddad]

Symbolen @ fungerar som en avgränsare mellan dataset och ögonblicksbildens namn, vilket i vårt fall är ögonblicksbild1.

Låt oss nu titta på tillståndet för ögonblicksbilden när den skapas.

Genom att köra kommandot:

zfs lista -rt alla zroot / usr / src

Du kan se att ögonblicksbilden inte tar något extra utrymme när den föddes. Det finns inget tillgängligt utrymme heller, eftersom det är en strikt skrivskyddad dataset, kan ögonblicksbilden inte växa, modifiera eller krympa. Slutligen är den inte monterad någonstans vilket gör den helt isolerad från den givna filsystemhierarkin.

Nu, låt oss ta bort sbin katalog i / usr / src /

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

Om du tittar på ögonblicksbilden ser du att den har vuxit,

Detta förväntas eftersom kopierings- och skrivmekanismen fungerar här och att ta bort (eller modifiera) filerna har lett till att mer av data endast associeras till ögonblicksbilden och inte den dataset som faktiskt används.

Lägg märke till kolumnen REFER i ovanstående utdata. Det ger dig mängden tillgänglig data i datasetet medan kolumnen USED bara visar hur mycket utrymme som är upptagen på den fysiska disken.

ZFS 'Copy-On-Write-mekanism ger ofta dessa kontraintuitiva resultat där radering av en fil skulle få det att se ut som om mer utrymme nu används än tidigare. Men efter att ha läst hittills vet du vad som faktiskt händer!

Låt oss återställa innan vi avslutar sbin från ögonblicksbild1. För att göra det, kör bara:

[e-postskyddad]: / usr / src $ zfs rollback zroot / usr / [e-postskyddad]

Politik för snapshotting

Nästa fråga att ställa är - Hur ofta du vill ta stillbilder? Även om det kan variera från ett företag till ett annat, låt oss ta exemplet på en mycket dynamisk databas som ändras så ofta.

Till att börja med skulle du börja ta snapshots var sjätte timme, men eftersom databasen ändras så mycket skulle det snart bli omöjligt att lagra alla de många snapshots som skapades. Så nästa steg skulle vara att rensa ögonblicksbilder som är äldre än, säg 48 timmar.

Nu skulle problemet vara att återställa något som har gått förlorat för 49 timmar sedan. För att kringgå detta problem kan du behålla ett eller två ögonblicksbilder från den 48-timmarshistoriken och hålla dem kvar i en vecka. Rensa dem när de blir äldre än så.

Och om du kan fortsätta på det här sättet kan du klämma ögonblicksbilder upp till systemets ursprung, bara i minskande frekvensordning. Slutligen vill jag påpeka att dessa ögonblicksbilder är LÄSA ENDAST vilket innebär att om du blir smittad av en ransomware och får alla dina data krypterade (modifierade). Dessa ögonblicksbilder skulle troligen fortfarande vara intakta.