ZFS Snapshots Tutorial

ZFS Snapshots Tutorial
Migawki są ważne, niezależnie od tego, czy używasz prostej maszyny wirtualnej na komputerze domowym, czy też jest to baza danych korporacyjnych, która jest stale aktualizowana i modyfikowana. Migawki, to znaczy kopia całego systemu plików, tak jak w danym okresie czasu jest ważna.

Ludzie często tracą śledzenie tego, gdzie coś poszło nie tak, plik został usunięty i nikt nie zauważył, że zniknął. Minęło kilka kopii zapasowych, a teraz zdajesz sobie sprawę, że brakuje ważnego pliku na wszystkich dostępnych kopii zapasowych z ostatnich 5 tygodni. W tym samouczku zobaczymy, jak korzystać z migawek ZFS i dotknąć różnych zasad migawek, które działałyby optymalnie, zarówno pod względem wykorzystania zasobów, jak i możliwości odzyskiwania.

Mechanizm kopiowania na napis

ZFS ma zarówno wysokie przegląd plików i katalogów i rozumie, w jaki sposób dane są zapisywane na dysku. Podczas fizycznego zapisywania danych na dysku, odbywa się to w dyskretnych blokach. Zazwyczaj rozmiar bloku może wzrosnąć do 1 MB, ale domyślnie wynosi zwykle 128 kb. Oznacza to, że każda modyfikacja (odczyt, zapis lub usuwanie) nastąpi w dyskretnych blokach.

Mechanizm kopiowania na zapisanie zapewnia, że ​​za każdym razem, gdy blok jest modyfikowany, zamiast bezpośrednio modyfikować blok, tworzy kopię bloku z wymaganymi modyfikacjami wykonanymi w nowym bloku.

Jest to szczególnie pomocne w przypadkach, w których, powiedzmy, istnieje awaria zasilania, a system rozbija się, podczas gdy nowe dane były zapisywane na dysku. Jeśli zdarzy się to w tradycyjnym systemie plików, twoje pliki zostaną uszkodzone lub pozostawione z otworami. Ale jeśli używasz ZFS, możesz stracić trwającą transakcję, ponieważ tak się działo, ale ostatni prawidłowy stan plików nadal pozostanie nietknięty.

Migawki również opierają się na tej funkcjonalności i w rzeczywistości dość mocno. Kiedy zrobisz migawkę danego zestawu danych („Zestaw danych” to termin ZFS dla systemu plików), ZFS po prostu rejestruje znacznik czasu, gdy wykonano migawkę. To jest to! Żadne dane nie są kopiowane i nie jest zużywane żadne dodatkowe przechowywanie.

Tylko wtedy, gdy zmienia się system plików, a dane w nim rozchodzą się z migawki, migawka zaczyna zużywać dodatkową pamięć. To, co dzieje się pod maską - zamiast recyklingu starych bloków z czasem, ZFS trzyma je w pobliżu. Poprawia to również wykorzystanie przechowywania. Jeśli migawka jest zestaw danych 20 GB i zmodyfikujesz tylko kilka plików tekstowych tutaj i tam migawka może zabrać tylko kilka MB miejsca miejsca.


Tworzenie migawek

Aby zademonstrować użycie migawek, zacznijmy od zestawu danych, który ma wiele plików tekstowych, aby uprościć sprawę. Maszyna wirtualna, której będę używać do demo, działa FreeBSD 11.1-Rellease-P3, który jest najnowszą stabilną wersją dostępną w momencie tego pisania. Główny system plików jest zamontowany na Zroot Domyślnie basen i wiele znajomych katalogów, takich jak /usr /src, /dom, /itp czy wszystkie ich własne zestawy danych zamontowane Zroot. Jeśli nie wiesz, co oznacza basen (lub zpool), w języku zfs, warto go przeczytać przed kontynuowaniem.

Jednym z wielu systemów plików lub zestawów danych, które są domyślnie na FreeBSD, to: Zroot/usr/src

Aby spojrzeć na to właściwości, uruchom następujące polecenie.

root@testbsd: ~ $ zfs lista ZROOT/USR/SRC

Jak widać, używa 633 MB pamięci. Zawiera całe drzewo źródłowe dla systemu operacyjnego.

Zróbmy migawkę Zroot/usr/src

root@testbsd: ~ $ zfs migawka Zroot/usr/src@snapshot1

Symbol @ działa jako ogranicznik między zestawem danych a nazwą migawki, która w naszym przypadku jest Snapshot1.

Teraz spójrzmy na stan migawki podczas jego tworzenia.

Uruchamiając polecenie:

ZFS List -rt All ZROOT/USR/SRC

Widać, że migawka nie wykorzystuje dodatkowej przestrzeni, gdy się narodzi. Nie ma też dostępnego miejsca, ponieważ jest to ściśle odczytany zestaw danych, sama migawka nie może rosnąć, modyfikować ani kurczyć. Na koniec nie jest zamontowany nigdzie, co czyni go całkowicie odizolowanym od danej hierarchii systemu plików.

Teraz usuńmy sbin katalog w /usr/src/

root@testbsd: $ rm/usr/src/sbin

Patrząc na migawkę, zobaczysz teraz, że wyrosła,

Jest to oczekiwane, ponieważ mechanizm kopiowania na zapisie jest tutaj działa i usuwa (lub modyfikowanie) pliki doprowadziły do ​​tego, że więcej danych jest powiązane tylko z migawką, a nie z zestawem danych faktycznie używanych.

Zwróć uwagę na kolumnę Patrz powyższe wyjście. Daje ci ilość dostępnych danych na zestawie danych, podczas gdy używana kolumna pokazuje tylko, ile miejsca zajmuje na dysku fizycznym.

Mechanizm kopiowania kopii ZFS często daje te sprzeczne z intuicją wyniki, w których usunięcie pliku sprawiłoby, że wyglądałoby tak, jakby teraz używane jest więcej miejsca niż wcześniej. Jednak po przeczytaniu do tej pory wiesz, co się naprawdę dzieje!

Przed zakończeniem odzyskajmy sbin z Snapshot1. Aby to zrobić, po prostu uruchom:

root@testbsd:/usr/src $ ZFS Rollback Zroot/usr/src@snapshot1

Polityka migawek

Kolejne pytanie, które należy zadać, brzmi - jak często chcesz zrobić migawki? 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 zaczniesz robić migawki co około 6 godzin, ale ponieważ baza danych zmienia się tak bardzo, wkrótce stanie się niemożliwe do przechowywania wszystkich licznych utworzonych migawek. Następnym krokiem byłoby oczyszczenie 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ć jedną lub dwie migawki z tej 48 -godzinnej historii i zatrzymać je przez tydzień. Oczyść je, gdy się starzeją.

A jeśli potrafisz kontynuować w ten sposób, możesz wcisnąć migawki do samej genezy systemu, tylko w zmniejszającej się kolejności częstotliwości. Na koniec chciałbym zaznaczyć, że te migawki są tylko odczytane, co oznacza, że ​​jeśli zostaniesz zarażony przez oprogramowanie ransomware i otrzymasz zaszyfrowanie wszystkich danych (zmodyfikowanych). Te migawki najprawdopodobniej byłyby nienaruszone.