Kopie zapasowe w środowisku LVM: najlepsze praktyki

Większość serwerowych dystrybucji Linuksa wdraża przestrzeń dyskową przez Logical Volume Manager (LVM). LVM abstrahuje dyski fizyczne w elastyczne wirtualne partycje, ale ta abstrakcja zmienia to, co agent kopii zapasowych musi odczytać, aby utworzyć spójny, możliwy do przywrócenia obraz. Wybór niewłaściwej warstwy skutkuje kopiami zapasowymi, których nie da się przywrócić.

Ten przewodnik wyjaśnia, którą warstwę LVM chroni StateWarden, jak zachowują się spójne migawki i śledzenie zmian na woluminach LVM oraz co należy wziąć pod uwagę przy przywracaniu lub odbudowie systemu od zera.

1. Warstwy LVM i zasada woluminu logicznego

LVM organizuje przestrzeń dyskową w trzy warstwy:

1. Woluminy fizyczne (PV): dyski lub partycje bazowe przejęte przez LVM (na przykład /dev/sda2, widoczne w narzędziach takich jak lsblk z typem LVM2_member).
2. Grupy woluminów (VG): pula pojemności zagregowana z jednego lub kilku PV.
3. Woluminy logiczne (LV): wirtualne partycje wydzielone z VG, w których faktycznie żyją systemy plików i dane (na przykład /dev/vg0/root lub /dev/mapper/vg0-data).

Jako źródło kopii zapasowej zawsze wybieraj wolumin logiczny. LV jest zwykłym urządzeniem blokowym o stabilnych granicach: ma system plików, określony rozmiar i można wykonać jego migawkę. W widoku przestrzeni dyskowej urządzenia w panelu PV pojawiają się jako wytłumione pozycje członków puli i nie są oferowane jako samodzielne cele kopii zapasowych; urządzeniami do wyboru są nakładające się na nie LV.

Kopia zapasowa pojedynczego LV (na przykład data) pozwala też przywrócić go niezależnie, bez dotykania innych LV (na przykład root) w tej samej VG.

2. Dlaczego woluminy fizyczne nie są poprawnym celem kopii zapasowych

Bezpośredni odczyt PV (na przykład obrazowanie /dev/sda2) nie daje użytecznej kopii zapasowej:

• Brak spójnego punktu w czasie. Surowy odczyt PV przechwytuje sektory w trakcie, gdy system do nich zapisuje. Nagłówki metadanych LVM i dane systemu plików mogą zostać złapane w połowie aktualizacji, a wynik może być nieodwracalny. Nie da się wykonać migawki samego PV.
• Niekompletne dane w grupach wielodyskowych. Jeśli VG obejmuje kilka PV (spanning) lub rozdziela dane między nie (striping), pojedynczy PV przechowuje tylko fragmenty każdego LV. Odtworzenie VG wymagałoby przechwycenia wszystkich PV w dokładnie tej samej chwili, co w działającym systemie jest niemożliwe.
• Brak przywracania na poziomie woluminu. Obraz PV miesza ekstenty wszystkich LV w VG, więc poszczególnych woluminów nie da się przywracać selektywnie.

3. Spójne kopie zapasowe z migawkami LVM

StateWarden korzysta z natywnego mechanizmu migawek LVM, aby tworzyć spójne awaryjnie (crash-consistent) kopie zapasowe woluminów logicznych:

1. Przed odczytem woluminu Agent tworzy tymczasową migawkę LVM źródłowego LV. Migawka prezentuje zamrożony, punktowy w czasie obraz woluminu; LVM przekierowuje kolejne zapisy na woluminie źródłowym za pomocą copy-on-write, więc zawartość migawki nie zmienia się w trakcie wykonywania kopii.
2. Agent odczytuje dane kopii zapasowej z urządzenia migawki zamiast z aktywnego woluminu źródłowego. Bazy danych i pliki są przechwytywane dokładnie tak, jak wyglądały w chwili migawki, nawet jeśli sama kopia wykonuje się długo.
3. Po zakończeniu zadania tymczasowa migawka jest usuwana.

Uwagi operacyjne:

• Klasyczne migawki LVM zużywają miejsce w VG w miarę zmian na woluminie źródłowym w oknie wykonywania kopii. Utrzymuj w VG wystarczającą liczbę wolnych ekstentów, aby pomieścić oczekiwany wolumen zapisów na czas wykonywania kopii; migawka, której zabraknie miejsca, staje się nieważna i kopia zapasowa kończy się niepowodzeniem.
• Spójność na poziomie aplikacji to odrębne zagadnienie. W przypadku baz danych stosuj ich natywne mechanizmy opróżniania buforów (flush) lub wyciszania (quiesce), o ile są dostępne; migawka LVM gwarantuje obraz spójny awaryjnie, a nie wyciszony na poziomie aplikacji.

4. Zachowanie CBT na woluminach LVM

Na zwykłych partycjach Smart CBT przyspiesza przyrostowe kopie zapasowe, śledząc zmienione bloki między kolejnymi wykonaniami. Woluminy logiczne LVM zachowują się inaczej: LVM udostępnia natywne mechanizmy migawkowe, z których Agent korzysta do identyfikacji zmienionych danych, więc nakładanie na LV osobnej warstwy CBT jest zbędne.

Zgodnie z tym przełącznik CBT w widoku przestrzeni dyskowej urządzenia w panelu raportuje dla woluminów LVM następującą podpowiedź:

LVM używa natywnych migawek. Warstwa CBT nie jest wymagana.

To informacja, a nie błąd. Przyrostowe kopie zapasowe woluminów LVM nadal są wykonywane; detekcję zmian zapewniają po prostu własne mechanizmy migawkowe LVM zamiast warstwy stosowanej dla zwykłych partycji. Tło działania Smart CBT na innych typach woluminów opisują artykuły Smart CBT: przyrostowe kopie zapasowe oraz Smart NTFS i kopie zapasowe na poziomie bloków.

5. Woluminy cienkie (thin-provisioned)

Cienka alokacja LVM przydziela pojemność na żądanie z puli cienkiej (thin pool) zamiast przypisywać ją z góry każdemu woluminowi. Cienkie LV są zabezpieczane jak każdy inny wolumin logiczny, ale należy pamiętać o następujących kwestiach:

• Miejsce na migawki pochodzi z puli cienkiej. Migawki woluminów cienkich zużywają pojemność puli w miarę napływania zapisów w oknie wykonywania kopii. Monitoruj wykorzystanie puli i utrzymuj zapas; wyczerpana pula cienka może wpłynąć na woluminy źródłowe, a nie tylko na migawkę.
• Rozmiar wirtualny a realne dane. Cienki LV może prezentować rozmiar wirtualny znacznie większy niż fizyczna pojemność puli. Cele przywracania są wymiarowane względem rozmiaru wirtualnego LV (zobacz sekcję 6), więc planując przeniesienie woluminu cienkiego na inny sprzęt, odpowiednio dobierz docelową przestrzeń dyskową.

6. Co wykluczyć

Nie każde urządzenie blokowe w systemie z LVM jest warte ochrony:

• Woluminy migawkowe. Nie dodawaj urządzeń migawek LVM (ani tymczasowych migawek StateWarden, ani tworzonych ręcznie) jako źródeł kopii zapasowych. Zawartość migawki oparta na copy-on-write jest przejściowa i zduplikowana; tworzenie kopii migawek migawek marnuje przestrzeń i daje obrazy bez samodzielnej wartości przywracania. Zabezpieczaj zamiast tego źródłowy LV.
• Woluminy wymiany (swap). Przestrzeń wymiany zawiera wyłącznie przejściowe strony pamięci, bez wartości po restarcie. Urządzenia wymiany są wyłączone ze śledzenia zmian i nie należy przypisywać ich do polityki kopii zapasowych. LV wymiany odtwarza się trywialnie podczas odbudowy systemu.

7. Uwagi dotyczące przywracania

Woluminy LVM są przywracane na poziomie bloków, co narzuca reguły wymiarowania celu:

• Ten sam rozmiar lub większy. Docelowy LV musi być co najmniej tak duży, jak źródłowy LV w chwili wykonania kopii. Przywrócenie obrazu blokowego na mniejszy LV nie jest możliwe; utwórz docelowy LV z wystarczającym rozmiarem przed rozpoczęciem przywracania.
• Powiększ system plików po przywróceniu. Przy przywracaniu na większy LV przywrócony system plików zachowuje swój pierwotny rozmiar. Powiększ go po przywróceniu, aby wykorzystać dodatkową przestrzeń (na przykład xfs_growfs dla XFS lub resize2fs dla ext4, zależnie od typu systemu plików).
• Odtwórz LVM przed przywróceniem na świeże instalacje. Jeśli maszyna docelowa nie ma jeszcze wymaganego układu VG i LV, utwórz go najpierw standardowymi narzędziami LVM (pvcreate, vgcreate, lvcreate), a następnie przywróć zawartość woluminów do nowych LV.

8. Bare Metal Recovery w systemach opartych na LVM

Ochrona woluminów logicznych zamiast dysków fizycznych nie przeszkadza w odzyskaniu całego systemu na czysty sprzęt. Smart BMR rejestruje układ przestrzeni dyskowej chronionego systemu razem z danymi woluminów. Podczas przywracania bare-metal środowisko odzyskiwania:

1. Uruchamia maszynę docelową z obrazu StateWarden Recovery ISO.
2. Prezentuje dostępne puste dyski fizyczne do wyboru.
3. Odtwarza strukturę LVM (woluminy fizyczne, grupy woluminów i woluminy logiczne) na podstawie informacji o układzie zapisanych z kopią zapasową.
4. Przywraca zabezpieczone dane do nowo utworzonych LV i stosuje poprawki bootloadera wymagane, aby system był rozruchowy.

Pełną procedurę, w tym przygotowanie nośnika odzyskiwania i generowanie tokenu, opisuje artykuł Bare Metal Recovery: przewodnik krok po kroku.

Lista kontrolna