Snapshots ä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. Det är viktigt att ha ögonblicksbilder, det vill säga en kopia av hela filsystemet som det såg ut vid en viss tidpunkt.
Människor tappar ofta bort minnet av var saker och ting 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 från de senaste fem veckorna. I den här handledningen ska vi se hur man använder ZFS-snapshots och beröra olika snapshotting-policies som skulle fungera optimalt, både när det gäller resursutnyttjande och återställbarhet.
ZFS har både överblick på hög nivå över filer och kataloger och förstår hur data skrivs på disken. När data skrivs fysiskt på en disk görs det i diskreta block. Typiskt sett kan blockstorleken gå upp till 1 MB, men standardvärdet är vanligtvis 128 KB. Detta innebär att varje ändring (läsning, skrivning eller radering) sker i de diskreta blocken.
Copy-on-write-mekanismen säkerställer att när ett block ändras, i stället för att ändra blocket direkt, görs en kopia av blocket med de nödvändiga ändringarna gjorda i det nya blocket.
Detta är särskilt användbart i de fall då, låt oss säga, det blir ett strömavbrott och systemet kraschar medan nya data skrivs på disken. Om detta händer i ett traditionellt filsystem kommer dina filer att skadas eller lämnas med hål i dem. Men om du använder ZFS kan du förlora den pågående transaktionen medan det hände, men dina filers senaste giltiga tillstånd kommer fortfarande att lämnas orört.
Snapshots förlitar sig också på den här funktionaliteten, och det i ganska hög grad faktiskt. När du tar en ögonblicksbild av ett givet dataset (”dataset” är ZFS-termen för ett filsystem) registrerar ZFS bara tidsstämpeln när ögonblicksbilden gjordes. Det är allt! Inga data kopieras och inget extra lagringsutrymme förbrukas.
Det är först när filsystemet ändras och data i det avviker från ögonblicksbilden som ögonblicksbilden börjar förbruka extra lagringsutrymme. Vad som händer under huven är följande – Istället för att återvinna de gamla blocken med tiden behåller ZFS dem. Detta förbättrar också lagringsutnyttjandet. Om du tar en ögonblicksbild av ett dataset på 20 GB och bara ändrar några textfiler här och där tar ögonblicksbilden kanske bara några MB utrymme i anspråk.
Skapa ögonblicksbilder
För att demonstrera användningen av ögonblicksbilder börjar vi med ett dataset som har många textfiler, bara för att hålla saken enkel. Den virtuella maskin som jag kommer att använda för demonstrationen kör FreeBSD 11.1-RELEASE-p3 som är den senaste stabila versionen som finns tillgänglig när detta skrivs. Rootfilesystemet är monterat på zroot-poolen som standard och många av de välkända katalogerna som /usr/src, /home, /etc är alla egna dataset som är monterade på zroot. Om du inte vet vad en pool (eller en zpool) betyder i ZFS-språket är det värt att läsa på innan du fortsätter.
Ett av de många filsystem, eller dataset, som är standard i FreeBSD är: zroot/usr/src
För att titta på dess egenskaper kör du följande kommando.
:~$ zfs list zroot/usr/src
Som du kan se använder det 633 MB lagringsplats. Den innehåller hela källkodsträdet för operativsystemet.
Låt oss ta en ögonblicksbild av zroot/usr/src
:~$ zfs snapshot zroot/usr/
Symbolen @ fungerar som en avgränsare mellan datasetet och ögonblicksbildsnamnet, som i vårt fall är snapshot1.
Nu ska vi titta på tillståndet för ögonblicksbilden när den skapas.
Du kan se att ögonblicksbilden inte använder något extra utrymme när den föds genom att köra kommandot:
zfs list -rt all zroot/usr/src
Du kan se att ögonblicksbilden inte använder något extra utrymme när den föds. Det finns inte heller något tillgängligt utrymme, eftersom det är ett strikt skrivskyddat dataset kan ögonblicksbilden själv inte växa, ändras eller krympa. Slutligen är den inte monterad någonstans vilket gör att den är helt isolerad från den givna filsystemshierarkin.
Nu tar vi bort sbin-katalogen i /usr/src/
:$ rm /usr/src/sbin
Om vi tittar på ögonblicksbilden ser vi nu att den har vuxit,
Detta är förväntat eftersom copy-on-write-mekanismen är verksam här och att radera (eller ändra) filerna har lett till att mer av datan endast är associerad med ögonblicksbilden och inte med den dataset som faktiskt används.
Lägg märke till kolumnen REFER i ovanstående utdata. Den ger dig mängden tillgängliga data på datasetet medan kolumnen USED bara visar hur mycket utrymme som upptas 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 används nu än tidigare. Men efter att ha läst så här långt vet du vad som faktiskt händer!
För att avsluta ska vi återställa sbin från snapshot1. För att göra det kör du helt enkelt:
:/usr/src$ zfs rollback zroot/usr/
Snapshotting Policy
Nästa fråga att ställa är – Hur ofta vill du ta ögonblicksbilderna? Det kan variera från ett företag till ett annat, men låt oss ta exemplet med en mycket dynamisk databas som ändras med jämna mellanrum.
I början skulle du börja med att ta ögonblicksbilder var sjätte timme eller så, men eftersom databasen ändras så mycket skulle det snart bli omöjligt att lagra alla de många ögonblicksbilder som skapades. Så nästa steg skulle vara att rensa bort ö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 en eller två ögonblicksbilder från den 48 timmar långa historiken och ha 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 proppa in ögonblicksbilder ända till systemets uppkomst, bara i fallande ordning i fråga om frekvens. Slutligen vill jag påpeka att dessa ögonblicksbilder är READ-ONLY vilket innebär att om du blir infekterad av ett utpressningstrojaner och får all din data krypterad (modifierad). Dessa ögonblicksbilder skulle med största sannolikhet fortfarande vara intakta.