Snapshoty są ważne niezależnie od tego czy uruchamiasz prostą maszynę wirtualną na swoim domowym komputerze, czy jest to baza danych przedsiębiorstwa, która jest ciągle aktualizowana i modyfikowana. Posiadanie snapshotów, czyli kopii całego systemu plików, jaki był w danym okresie czasu, jest ważne.
Ludzie często tracą orientację, gdzie coś poszło nie tak, plik został usunięty i nikt nie zauważył, że go nie ma. Minęło kilka kopii zapasowych i teraz zdajesz sobie sprawę, że brakuje ważnego pliku we wszystkich dostępnych kopiach zapasowych z ostatnich 5 tygodni. W tym poradniku zobaczymy jak używać migawek ZFS i dotkniemy różnych polityk migawkowych, które będą działać optymalnie, zarówno pod względem wykorzystania zasobów jak i możliwości odzyskania danych.
ZFS posiada zarówno wysokopoziomowy przegląd plików i katalogów, jak i rozumie jak dane są zapisywane na dysku. Kiedy fizycznie zapisujemy dane na dysku, jest to robione w dyskretnych blokach. Typowy rozmiar bloku może wynosić do 1 MB, ale domyślnie jest to zwykle 128 KB. Oznacza to, że każda modyfikacja (odczyt, zapis lub usunięcie) będzie miała miejsce w blokach dyskretnych.
Mechanizm copy-on-write zapewnia, że za każdym razem, gdy blok jest modyfikowany, zamiast modyfikować blok bezpośrednio, tworzy kopię bloku z wymaganymi modyfikacjami wykonanymi na nowym bloku.
Jest to szczególnie pomocne w przypadkach, gdy, powiedzmy, nastąpiła awaria zasilania i system zawiesił się, gdy nowe dane były zapisywane na dysku. Jeśli tak się stanie w tradycyjnym systemie plików, twoje pliki zostaną uszkodzone lub pozostaną w nich dziury. Ale jeśli używasz ZFS, możesz stracić trwającą transakcję, ale ostatni ważny stan twoich plików pozostanie nietknięty.
Snapshoty również polegają na tej funkcjonalności, i to dość mocno. Kiedy robisz snapshot danego zbioru danych (’zbiór danych’ to w ZFS określenie systemu plików), ZFS po prostu zapisuje znacznik czasu kiedy snapshot został zrobiony. To wszystko! Żadne dane nie są kopiowane i nie jest zużywany dodatkowy storage.
Tylko wtedy, gdy system plików się zmienia, a dane w nim odbiegają od zrzutu, zrzut zaczyna zużywać dodatkowy storage. To co dzieje się pod maską jest następujące – zamiast recyklingu starych bloków w czasie, ZFS zachowuje je. To również poprawia wykorzystanie pamięci masowej. Jeśli wykonasz migawkę zbioru danych 20GB i zmodyfikujesz tylko kilka plików tekstowych tu i tam, migawka może zająć tylko kilka MB miejsca.
Tworzenie migawek
Aby zademonstrować użycie migawek, zacznijmy od zbioru danych, który ma dużo plików tekstowych, aby zachować prostotę. Maszyna wirtualna, której będę używał do demonstracji, działa pod kontrolą FreeBSD 11.1-RELEASE-p3, które jest najnowszym stabilnym wydaniem dostępnym w momencie pisania tego tekstu. System plików root jest domyślnie zamontowany na puli zroot, a wiele znanych katalogów takich jak /usr/src, /home, /etc ma swoje własne zbiory danych zamontowane na zroot. Jeśli nie wiesz, co oznacza pula (lub zpool) w języku ZFS, warto się z tym zapoznać przed kontynuacją.
Jednym z wielu systemów plików, lub zbiorów danych, które są domyślnie montowane w FreeBSD jest: zroot/usr/src
Aby przyjrzeć się jego właściwościom, wykonaj następującą komendę.
:~$ zfs list zroot/usr/src
Jak widzisz, używa on 633 MB pamięci. Zawiera ono całe drzewo źródeł dla systemu operacyjnego.
Zróbmy migawkę zroot/usr/src
:~$ zfs snapshot zroot/usr/
Symbol @ działa jako ogranicznik między zbiorem danych a nazwą migawki, która w naszym przypadku to snapshot1.
Spójrzmy teraz na stan migawki w trakcie jej tworzenia.
Uruchamiając polecenie:
zfs list -rt all zroot/usr/src
Widzimy, że migawka nie używa żadnego dodatkowego miejsca, gdy się rodzi. Nie ma też dostępnego miejsca, ponieważ jest to zbiór danych tylko do odczytu, a sam snapshot nie może rosnąć, modyfikować się ani kurczyć. Wreszcie, nie jest nigdzie montowany, co czyni go całkowicie odizolowanym od hierarchii danego systemu plików.
Teraz usuńmy katalog sbin w /usr/src/
:$ rm /usr/src/sbin
Patrząc na migawkę zobaczysz, że się powiększyła,
To jest oczekiwane, ponieważ działa tu mechanizm copy-on-write i usuwanie (lub modyfikowanie) plików doprowadziło do tego, że więcej danych jest przypisanych tylko do migawki, a nie do zbioru danych faktycznie używanego.
Zwróć uwagę na kolumnę REFER w powyższym wyjściu. Podaje ona ilość dostępnych danych w zbiorze danych, podczas gdy kolumna UŻYWANE pokazuje, ile miejsca jest zajęte na dysku fizycznym.
Mechanizm Copy-On-Write systemu ZFS często daje sprzeczne z intuicją wyniki, gdzie usunięcie pliku sprawia, że wygląda na to, że więcej miejsca jest wykorzystywane niż wcześniej. Jednak czytając do tej pory, wiesz już, co tak naprawdę się dzieje!
Przed zakończeniem, odzyskajmy sbin ze snapshota1. Aby to zrobić po prostu uruchom:
:/usr/src$ zfs rollback zroot/usr/
Snapshotting Policy
Kolejne pytanie, które należy zadać to – Jak często chcesz robić snapshoty? Chociaż może się to różnić w zależności od przedsiębiorstwa, weźmy przykład bardzo dynamicznej bazy danych, która zmienia się co jakiś czas.
Na początek zacząłbyś robić zrzuty co 6 godzin lub tak, ale ponieważ baza danych zmienia się tak często, szybko stałoby się niewykonalne, aby przechowywać wszystkie liczne zrzuty, które zostały utworzone. Tak więc następnym krokiem byłoby usunięcie migawek, które są starsze niż, powiedzmy, 48 godzin.
Teraz problemem byłoby odzyskanie czegoś, co zostało utracone 49 godzin temu. Aby obejść ten problem, możesz zachować jeden lub dwa snapshoty z tej 48-godzinnej historii i trzymać je przez tydzień. Wyczyść je, gdy staną się starsze niż ten czas.
I jeśli możesz kontynuować w ten sposób, możesz upchać snapshoty aż do samej genezy systemu, tylko w kolejności malejącej częstotliwości. Na koniec chciałbym zaznaczyć, że te snapshoty są READ-ONLY, co oznacza, że jeśli zostaniesz zainfekowany przez ransomware i dostaniesz wszystkie swoje dane zaszyfrowane (zmodyfikowane). Te snapshoty, najprawdopodobniej, nadal będą nienaruszone.