Kopie zapasowe w środowisku ZFS: najlepsze praktyki

linux
zfs
backup

Kopie zapasowe w środowisku ZFS: najlepsze praktyki

ZFS łączy system plików, menedżera woluminów i RAID w jednym stosie przestrzeni dyskowej. Ponieważ StateWarden działa na poziomie bloków i urządzeń, ochrona systemu opartego na ZFS polega na wybraniu właściwego urządzenia blokowego jako źródła kopii zapasowej. Ten artykuł wyjaśnia, co zabezpieczać na hostach ZFS, co zawiera kopia zapasowa ZVOL i których błędów w wyborze unikać.


1. ZVOL a datasety

ZFS udostępnia dwa rodzaje obiektów przestrzeni dyskowej:

  • Datasets (zbiory danych) to obiekty na poziomie systemu plików, montowane do drzewa katalogów (na przykład /tank/home). Zawierają pliki i katalogi i nie mają reprezentacji w postaci urządzenia blokowego.
  • ZVOL (woluminy ZFS) to urządzenia blokowe tworzone poleceniem zfs create -V. ZVOL pełni zazwyczaj rolę dysku maszyny wirtualnej, urządzenia macierzystego dla LUN iSCSI albo surowego woluminu dla bazy danych.

W systemie Linux każdy ZVOL pojawia się pod dwiema ścieżkami urządzeń:

  • /dev/zvol/<pool>/<name> - stabilny, czytelny dla człowieka dowiązanie symboliczne (na przykład /dev/zvol/tank/vm-100).
  • /dev/zd<N> - bazowe urządzenie blokowe jądra (na przykład /dev/zd0).

Przy konfigurowaniu źródeł kopii zapasowych identyfikuj ZVOL po ścieżce /dev/zvol/.... Ścieżka koduje pulę i nazwę woluminu, więc pozostaje stabilna między restartami, podczas gdy numeracja zd może się zmieniać wraz z dodawaniem i usuwaniem urządzeń. W panelu ZVOL pojawiają się na liście woluminów w zakładce Dyski i kopie urządzenia, obok innych urządzeń blokowych.

StateWarden jest agentem kopii zapasowych na poziomie bloków. Chroni ZVOL bezpośrednio. Nie potrafi przechwycić zamontowanego datasetu (drzewa katalogów takiego jak /tank/home), ponieważ dataset nie jest urządzeniem blokowym. Jeśli dane wymagające ochrony znajdują się w datasecie, zmigruj je do systemu plików umieszczonego na ZVOL.

2. Zalecenie: zabezpieczaj ZVOL

Przy każdym wykonaniu kopii zapasowej ZVOL StateWarden korzysta z natywnych migawek ZFS, aby uzyskać spójne źródło. Copy-on-write w ZFS sprawia, że utworzenie migawki jest praktycznie natychmiastowe i nie wstrzymuje zapisów w warstwie przestrzeni dyskowej. Kopia zapasowa przechwytuje zatem dokładny, zamrożony obraz blokowy woluminu z pojedynczego punktu w czasie.

Co daje kopia zapasowa ZVOL:

  • Punktowy w czasie obraz zawartości woluminu, deduplikowany i kompresowany na węźle pamięci jak każda inna kopia na poziomie bloków.
  • Granularność przywracania na poziomie woluminu: można przywrócić pojedynczy ZVOL bez dotykania reszty puli.

Czego nie daje:

  • Semantyki plików na poziomie datasetów. Kopia zapasowa zawiera surowe bajty urządzenia blokowego - czyli system plików zapisany wewnątrz ZVOL przez system gościa lub aplikację. Nie zawiera hierarchii datasetów puli ani metadanych na poziomie ZFS.
  • Historii migawek ZFS. Lokalne migawki ZVOL nie są przenoszone na węzeł pamięci. Kopia zapasowa jest obrazem blokowym, a nie strumieniem replikacji ZFS. Przywracanie odtwarza wolumin według stanu z punktu kopii, a nie lokalny łańcuch migawek, klony ani właściwości ZFS, takie jak recordsize czy compression.

3. Nie zabezpieczaj dysków członkowskich puli

Nie dodawaj fizycznych dysków tworzących pulę ZFS (na przykład /dev/sdc) do polityki kopii zapasowych. To ta sama zasada, która obowiązuje dla woluminów fizycznych LVM i członków programowego RAID (zobacz Kopie zapasowe w środowisku LVM: najlepsze praktyki).

Pula rozdziela dane między swoje vdev-y w grupach transakcji (TXG). Kopia zapasowa poszczególnych dysków członkowskich działającej puli przechwytuje każdy dysk w stanie innej grupy transakcji. Przy przywracaniu dysków nie da się złożyć w spójną pulę, a wynikiem jest uszkodzenie danych. Należy pamiętać, że redundancja ZFS (mirror, RAIDZ) jest mechanizmem dostępności, a nie kopią zapasową: wybieraj ZVOL, a dyski członkowskie puli pozostaw nieprzypisane.

4. Obciążenia maszyn wirtualnych i baz danych na ZVOL

Kopia zapasowa ZVOL oparta na migawce jest spójna awaryjnie (crash-consistent): przechwycony obraz odpowiada stanowi, jaki widać po nieoczekiwanej utracie zasilania. Nowoczesne systemy plików i bazy danych odtwarzają się z tego stanu automatycznie, ale spójność awaryjna to nie to samo, co spójność na poziomie aplikacji. Bufory przechowywane w pamięci przez aplikację nie są częścią obrazu.

W przypadku obciążeń wymagających spójności na poziomie aplikacji wyciszaj je wokół okna wykonywania kopii:

  • Maszyny wirtualne: korzystaj z agenta gościa hipernadzorcy lub mechanizmu zamrażania systemu plików, aby system gościa opróżnił swoje systemy plików w chwili wykonywania kopii, i planuj kopie na okresy niskiego obciążenia I/O gościa.
  • Bazy danych: skoordynuj natywny mechanizm opróżniania buforów lub kopii gorącej bazy danych (na przykład flush z blokadą odczytu) z harmonogramem kopii zapasowych albo zaakceptuj spójność awaryjną i weryfikuj ją regularnymi testami przywracania.

Zasada ogólna: warstwa przestrzeni dyskowej zamraża bloki; zadbanie o czysty stan aplikacji w tym momencie należy do obciążenia.

5. Współdziałanie kompresji i deduplikacji

Kompresja ZFS (compression=lz4 i podobne) jest przezroczysta w warstwie blokowej. Odczyty ZVOL zwracają logiczną, zdekompresowaną zawartość, więc potok kopii zapasowej widzi te same bajty, które zapisał system gościa lub aplikacja. Dwie praktyczne konsekwencje:

  • Kompresja ZFS na ZVOL ani nie pomaga, ani nie szkodzi współczynnikom deduplikacji i kompresji po stronie kopii zapasowych. Szacuj oczekiwania przestrzenne na podstawie samych danych obciążenia, a nie wskaźników compressratio na poziomie puli.
  • Dane już skompresowane lub zaszyfrowane powyżej warstwy blokowej - archiwa, pliki multimedialne, bazy danych z wewnętrzną kompresją albo szyfrowanie dysków na poziomie gościa - obniżają współczynniki deduplikacji i kompresji, dokładnie tak samo jak na każdym innym typie woluminu.

6. Zastosowanie Smart CBT

Smart CBT w systemie Linux jest zbudowany na śledzeniu zmian dm-era i nie ma zastosowania do ZVOL. Woluminy ZVOL są migawkowane natywnie dla zachowania spójności i odczytywane w całości podczas kopii zapasowej; wydajność przestrzenna wynika z deduplikacji na poziomie bloków, a nie ze śledzenia zmienionych bloków. Panel raportuje stan CBT każdego woluminu; wskaźniki stanów i zachowanie awaryjne opisuje artykuł Smart CBT: przyrostowe kopie zapasowe.

7. Lista kontrolna

ObciążenieŹródło kopii zapasowejOcena
Dysk maszyny wirtualnej na ZFSZVOL, na przykład /dev/zvol/tank/vm-100Zalecane
LUN iSCSI oparty na ZVOLUrządzenie macierzyste /dev/zvol/... na hoście ZFSZalecane
Surowy wolumin bazy danychZVOL, z wyciszeniem zgodnie z sekcją 4Zalecane
Zamontowany dataset (na przykład /tank/home)Nie jest urządzeniem blokowym; zmigruj dane do systemu plików na ZVOLNieobsługiwane
Dysk członkowski puli (na przykład /dev/sdc)Brak; pozostaw nieprzypisanyNigdy nie zabezpieczaj pojedynczo

Czy ten artykuł był pomocny?