Migawki LVM jako strategia tworzenia kopii zapasowych

Jak opłacalna jako strategia tworzenia kopii zapasowych byłyby okresowe migawki LVM xen domU? Plusy, minusy, jakieś problemy?

Wydaje mi się, że to idealne rozwiązanie do szybkiego, bezmózgiego przywracania. Każde dochodzenie może mieć miejsce na uszkodzonym woluminie logicznym, a domU z powodzeniem działa bez zakłóceń.

EDYTOWAĆ:

Oto gdzie jestem teraz, kiedy wykonuję pełne kopie zapasowe systemu.

• migawka lvm dysku domU
• nowy wolumin logiczny, którego rozmiar jest równy rozmiarowi migawki.
• dd if = / dev / snapshot of = / dev / new_lv
• pozbywanie się migawki za pomocą lvremove
• opcjonalna weryfikacja za pomocą kpartx / mount / ls

Teraz muszę to zautomatyzować.

Migawki LVM mają na celu przechwycenie systemu plików w stanie zawieszenia. Nie mają one stanowić kopii zapasowej same w sobie. Są one jednak przydatne do uzyskiwania spójnych obrazów kopii zapasowych, ponieważ zamrożony obraz nie może i nie zmieni się podczas procesu tworzenia kopii zapasowej. Chociaż nie będziesz ich używać bezpośrednio do tworzenia długoterminowych kopii zapasowych, będą one miały wielką wartość w każdym procesie tworzenia kopii zapasowej, którego zdecydujesz się użyć.

Istnieje kilka kroków do wdrożenia migawki. Po pierwsze, należy przydzielić nowy wolumin logiczny. Celem tego woluminu jest zapewnienie obszaru, w którym zapisywane są delty (zmiany) w systemie plików. Dzięki temu oryginalny wolumin może być kontynuowany bez zakłócania istniejącego dostępu do odczytu / zapisu. Wadą tego jest to, że obszar migawki ma skończony rozmiar, co oznacza, że ​​w systemie z zajętym zapisem może dość szybko się zapełnić. W przypadku woluminów, które mają znaczną aktywność zapisu, należy zwiększyć rozmiar migawki, aby zapewnić wystarczającą ilość miejsca do zarejestrowania wszystkich zmian. Jeśli twoja migawka przepełni się (zapełni), zarówno migawka zostanie zatrzymana i oznaczona jako nieużyteczna. W takim przypadku należy zwolnić migawkę, aby można było przywrócić oryginalny wolumin z powrotem do trybu online. Po zakończeniu wydania „

Drugą rzeczą, która się dzieje, jest to, że LVM „zamienia” prawdziwe cele omawianych tomów. Można by pomyśleć, że nowo przydzielona migawka będzie miejscem, w którym można szukać zmian w systemie plików, w końcu to tam będą wszystkie zapisy, prawda? Nie, jest na odwrót. Systemy plików są montowane do nazw woluminów LVM , więc zamiana nazwy spod reszty systemu byłaby nie-nie (ponieważ migawka używa innej nazwy). Więc rozwiązanie jest proste: Jeśli dostęp do oryginalnej nazwy głośności, będzie nadal odnosić się do żywego (odczyt / zapis) wersji objętości zrobiłeś migawkę. Utworzony wolumin migawki będzie odnosił się do zamrożonego(tylko do odczytu) wersja woluminu, którego kopię zapasową chcesz utworzyć. Na początku trochę mylące, ale będzie miało sens.

Wszystko to dzieje się w mniej niż 2 sekundy. Reszta systemu nawet tego nie zauważa. Chyba że oczywiście nie zwolnisz migawki przed jej przepełnieniem ...

W pewnym momencie będziesz chciał zwolnić migawkę, aby odzyskać zajmowane miejsce. Po zakończeniu wydania wolumin migawki jest zwalniany z powrotem do woluminu, a oryginał pozostaje.

Nie polecam realizowania tego jako długoterminowej strategii tworzenia kopii zapasowych. Nadal przechowujesz dane na tym samym dysku fizycznym, który może ulec awarii, a odzyskiwanie systemu plików z dysku, który uległ awarii, w ogóle nie jest kopią zapasową.

Krótko mówiąc:

• Migawki są przydatne do tworzenia kopii zapasowych
• Migawki same w sobie nie stanowią formy kopii zapasowej
• Migawki nie trwają wiecznie
• Pełna migawka nie jest dobrą rzeczą
• Migawki muszą być w pewnym momencie udostępnione
• LVM jest twoim przyjacielem, jeśli używasz go mądrze.

Migawki LVM doskonale nadają się do tworzenia kopii zapasowych serwera bez przełączania go w tryb offline. Jak stwierdzono, migawki LVM są niemal natychmiastowymi kopiami. Tworzysz je za pomocą lvcreatepolecenia tak, jak chcesz stworzyć LV, tyle że dajesz mu --snapshotopcję i oryginalny LV zamiast VG. Na przykład:

lvcreate -L <LV size> -s -n <snapshot name> /dev/<VG name>/<LV name>

Spowoduje to utworzenie migawki danego LV z określoną nazwą migawki, którą można następnie zamontować i użyć tej migawki LV do wykonania kopii zapasowej bez obawy o aktywne używanie plików. Jest to szczególnie przydatne, jeśli próbujesz wykonać kopię zapasową aktywnego serwera bazy danych.

Po zakończeniu tworzenia kopii zapasowej z migawki należy ją usunąć, aby zmniejszyć wszelkie dodatkowe koszty we / wy lub inne problemy z wydajnością, o których wspominali inni:

lvremove /dev/<VG name>/<snapshot name>

Podczas gdy migawki LVM mogą być nieocenione przy tworzeniu niezawodnych kopii zapasowych systemów takich jak bazy danych i takie, że normalnie chcesz zamknąć kopię zapasową, aby uniknąć rywalizacji o pliki, nie są one idealne do długotrwałej pracy jako szybkie przywracanie.

To nie jest dobry pomysł, IMO.

Migawki są implementowane w sposób kopiowania przy zapisie, dzięki czemu każdy zapis staje się odczytem i dwoma zapisami (blok, który aktualizujesz, jest najpierw czytany z woluminu głównego i zapisywany w woluminie migawki przed umieszczeniem nowych danych w jego miejsce), więc zobaczysz pewien spadek wydajności, jeśli dużo pisania jest powszechne na maszynach wirtualnych.

Również IIRC, jeśli wolumin migawki zapełni się, jest po prostu bezceremonialnie upuszczany. Nie jest to dobre do celów tworzenia kopii zapasowych! Jeśli więc spróbujesz wykonać to jako metodę tworzenia kopii zapasowych, upewnij się, że wolumin migawki jest wystarczająco duży, aby obsłużyć wszystkie zmiany, które pojawią się w okresie użytkowania migawki. Oczywiście, jeśli zdajesz sobie sprawę i monitorujesz problem z rozmiarem, a problem z wydajnością nie stanowi dla ciebie problemu, to co sugerujesz, może być przydatnym dodatkiem do innych procesów tworzenia kopii zapasowych, które masz.

Migawki LVM są bardzo przydatne jako część procesu tworzenia kopii zapasowej (robienie migawki, tworzenie kopii zapasowej migawki w innym miejscu, aby zapewnić spójność kopii zapasowej bez konieczności wyłączania aktualizacji „rzeczywistego” wolumenu, upuszczanie migawki później), między innymi, ale same w sobie nie są przeznaczone do tworzenia kopii zapasowych.

Musisz upewnić się, że dane na dysku są w spójnym stanie przed utworzeniem migawki. np. mysql może mieć dane buforowane w pamięci, które należy wymusić na dysku, albo zrzucając bazę danych, albo zamykając ją. Szczegółowe informacje można znaleźć w instrukcjach aplikacji.

Pod sprytnie wyglądającymi rzeczami LVM to tak naprawdę „tylko” sztuczka mapowania urządzeń. Tworzenie migawki za pomocą programu lvcreate to niewiele więcej niż opakowanie niektórych rzeczy związanych z dmsetup. Opakowanie tworzy nowe urządzenie (wolumin migawki) z jednego starego woluminu (oryginalny lv) i nowego (wolumin kopiowania przy zapisie). Wraz z tym pierwotna nazwa LV zostaje przemianowana na -real (patrz poniżej, która jest wyjściem dmsetup ls --tree). Ten -real LV jest odwzorowany zarówno na wolumin migawki, jak i pierwotny wolumin, więc można go używać w obu miejscach. Wolumin kopiowania przy zapisie działa jako nakładka na -real LV. Opcja -snap LV pokazuje kombinację woluminu kopiowania przy zapisie i woluminu -real. To rzeczywiście powoduje pewne obciążenie wydajności.

Volume00-snap (253:11)
 |-Volume00-snap-cow (253:13)
 |  `- (104:2)
 `-Volume00-LogVol01-real (253:12)
    `- (104:2)

Volume00-LogVol01 (253:5)
 `-Volume00-LogVol01-real (253:12)
    `- (104:2)

Podczas usuwania migawki ponownie następuje zmiana nazwy i mapowanie. Potem sytuacja znów będzie wyglądać jak

Volume00-LogVol01 (253:5)
 `- (104:2)

Jeśli chodzi o to, w jaki sposób jest to dobra metoda tworzenia kopii zapasowych rzeczy: może być, jeśli weźmiesz pod uwagę, że (1) nie pomoże na pamięć RAM maszyn wirtualnych, (2) stworzy karę wydajności i (3) będziesz potrzebować do przechowywania obrazów migawki w innym miejscu.

VMware VCB działa również z migawkami, przy okazji, choć nie z LVM.

Nawet jeśli migawki nie miały żadnego wpływu na wydajność, musisz zrozumieć: Migawki nie stanowią więcej kopii zapasowej niż kopia do innego folderu na tym samym dysku.

Jeśli dysk ulegnie awarii, dane i kopia zapasowa zostaną utracone. Nawet jeśli przypiszesz obszar migawki do innego PE w VG, zawiera on tylko dane zmodyfikowane od czasu migawki.

Tworzenie kopii zapasowej oznacza co najmniej kopię na całkowicie oddzielny dysk.

używam takiej konfiguracji do tworzenia migawek maszyn serwerów vmware i baz danych mysql. jak dotąd działa dobrze. przywrócono kilka - wszystko bez problemów. jedna rzecz do rozważenia - podczas pracy z migawką lvm uzyskuje znaczący spadek wydajności dla operacji we / wy. spójrz tutaj . zignoruj ​​fakt, że mówią o mysql, operacje we / wy to operacje we / wy ... bez względu na to, jakie dane znajdują się na lvm.

Używam migawek lvm tylko do skopiowania DomU Lv kolejnej w osobnej Vg, gdzie każda domena ma do dyspozycji trzy zapasowe „węzły”.

Następnie migawka zostaje zniszczona, a zapasowe Lv pozostają do następnej rundy. Jeśli mam przywrócenie, muszę tylko wybrać źródło Lv z kopii zapasowej Vg i skopiować je do domeny Lv.

Raz na jakiś czas kopia zapasowa Lv jest zrzucana do pliku obrazu na oddzielnym serwerze.

Wszystko to jest zautomatyzowane za pomocą skryptu, z kopią zapasową co dwa dni i zrzutem co tydzień.

Miałem nawet na myśli tryb „paniki”, w którym Domena Lv zostanie przywrócona, ale będzie uruchamiana z migawki i resetowana co 2 godziny, aby utrzymać witrynę w trybie online w przypadku poważnych włamań, aż do zorganizowania odpowiedniej obrony .

Co stało się z ideą linii obrony w trybie paniki?