Tworzenie kopii zapasowych oraz odzyskiwanie po awarii na potrzeby wirtualizacji serwera

Autor: Adam Fazio

Opublikowano: 7 listopada 2008

Zawartość strony

	Planowanie odzyskiwania po awarii
	Odzyskiwanie po awarii i wirtualizacja
	Konwersja systemów fizycznych na wirtualne
	Migawki maszyny wirtualnej
	Tworzenie kopii zapasowej Hyper-V
	Windows Server Backup
	Tworzenie kopii zapasowej maszyny wirtualnej za pomocą WSB
	Do rozważenia
	Przywracanie maszyny wirtualnej za pomocą WSB
	Data Protection Manager
	Kopie zapasowe w postaci skryptów

W miarę jak technologia wirtualizacji rozwija się i jest w coraz większym stopniu stosowana w przemyśle, organizacje dostrzegają jej korzyści sięgające poza najbardziej popularne powody użycia wirtualizacji: zmniejszenie kosztów infrastruktury oraz większa adaptacyjność technologii informacyjnej. Następny etap stanowi zastosowanie platformy wirtualizacji jako metody realizacji bądź wzmocnienia strategii odzyskiwania po awarii (ang. disaster recovery, DR).

Dlaczego gotowość do odzyskania po awarii jest stale jednym z najbardziej gorących tematów dla branży informatycznej? Badania wskazują, że w ciągu każdej godziny przestoju firmy tracą średnio 80 000 do 90 000 dolarów, a wśród firm, które ucierpiały z powodu katastroficznej utraty danych, bardzo mało jest w stanie przetrwać dłużej. Ten artykuł zawiera wprowadzenie do tematyki odzyskiwania po awarii (DR) przy użyciu platformy wirtualizacji firmy Microsoft, głębsze spojrzenie na opcje tworzenia kopii zapasowych oraz odzyskiwania, a także rozważania dotyczące Windows Server 2008 Hyper-V.

Planowanie odzyskiwania po awarii

Odzyskiwanie po awarii jest procesem przywracania krytycznych usług w przypadku przestoju i dla każdej firmy powinno być częścią planu zapewnienia ciągłości jej działania. Taki plan definiuje, jak firma będzie kontynuować funkcjonowania podczas takiej awarii oraz po niej. Te plany stanowią kamień węgielny każdej inicjatywy odzyskiwania po awarii.

Niektóry sprzedawcy zapewniają, że ich technologia automatyzacji odzyskiwania po awarii minimalizuje lub eliminuje potrzebę tworzenia szczegółowego i dobrze przygotowanego planu. Wprawdzie trzeba przyznać, że automatyzacja może skrócić czas odzyskiwania i zmniejszyć uzależnienie od interwencji człowieka, ale warto ogłosić publicznie, iż nie można z powodzeniem zminimalizować skutków katastrofy za pomocą samej technologii. Ludzie i stosowane procedury zawsze są równie ważni jak technologie.

W praktyce okazuje się, że wybranie właściwych technologii bez uprzedniego zrozumienia wszystkich ograniczeń i celi, które wynikają z procesu planowania odzyskiwania po awarii, jest prawie niemożliwe. Definiowanie całego planu odzyskiwania po awarii wykracza poza zakres tego artykułu, lecz chcę podkreślić te elementy, które są potrzebne do wybrania właściwych technologii i implementacji. Przedstawmy więc w skrócie niektóre krytyczne czynniki sterujące technologią w planie odzyskiwania po awarii.

Definicje i priorytety usług Co w rzeczywistości definiuje całą usługę, którą próbujemy ochronić i jak krytyczna jest ona dla organizacji? Rysunek 1 pokazuje przykłady usług firmy, które będą zapewne objęte planem odzyskiwania po awarii.

Rysunek 1: Przykład definicji i określania priorytetu usług.

Po zdefiniowaniu tych usług można rozpocząć określanie, które systemy i ograniczenia mają być celem strategii odzyskiwania po awarii oraz jakie rodzaje strategii przyjąć. Może się tak zdarzyć, że po przejrzeniu całego zestawu usług i zależności, okaże się, że musimy rozważyć kilka różnych poziomów możliwości odzyskiwania po awarii, ponieważ pojedyncze rozwiązanie dla wszystkich usług krytycznych dla firmy byłoby zbyt drogie i złożone.

Umowy SLA (Service Level Agreements) SLA jest umową lub kontraktem pomiędzy dostawcą usług informatycznych (IT) a klientem (organizacją), która definiuje możliwe cele danej usługi. Umowy SLA mogą być bardzo długie lub też całkiem krótkie i przyjemne; na przykład: „System e-mail będzie dostępny przez 99,95 procent czasu podczas ogólnych godzin pracy oraz 98 procent czasu w pozostałych godzinach, wyłączając zaplanowane okienka na konserwację, w skali miesiąca". Zwykle umowy SLA są rozbijane na warstwy, do których mogą być przypisane usługi IT, mierzone we wcześniej zdefiniowanym przedziale czasu.

Umowy OLA (Operating Level Agreements) Umowy OLA są w zasadzie umowami pomiędzy różnymi grupami IT pracującymi nad obsługą SLA, obejmującymi czas procedur i reakcji związane z dostarczaniem usług. Załóżmy, że mamy krytyczną dla działalności witrynę Web z zakładanym poziomem SLA równym 99,99 procent, lecz baza danych, od której zależy jej zawartość ma założoną dostępność równą tylko 95 procent. OLA pomaga wyjaśnić te rozbieżności i wyrównać założony poziom w zespołach IT.

Docelowy punkt odzyskania (Recovery Point Objective, RPO) i docelowy czas odzyskania (Recovery Time Objective, RTO) RTO definiuje, jak długo usługa może być niedostępna, zanim nastąpi zerwanie ciągłości, natomiast RPO określa, co dla organizacji jest akceptowanym poziomem utraty danych. Dlatego też, jeśli usługa ma określone SLA jako 99 procent w skali miesiąca, to RTO jest równe 7 godzin i 18 minut. Jeśli połączymy to z RPO, równym, powiedzmy, 24 godziny, możemy dokładnie zdefiniować nasze techniki oraz harmonogramy tworzenia kopii zapasowych.

Zasady retencji danych Zasady organizacji dotyczące retencji danych ściśle określają, jak długo należy trzymać kopie zapasowe oraz gdzie je przechowywać. Są one zwykle wymuszane przez wymagania prawne i przypisy.

Kategoryzacja danych Trzeba również pomyśleć o naturze danych. Jeśli umieścimy dane w kategoriach, możemy szybko stwierdzić, że nie wszystkie dane wymagają takiego samego poziomu odtwarzania po awarii. Na przykład pojedyncza baza danych może mieć inne wymagania dotyczące dostępności niż Active Directory z wieloma kontrolerami domen, z których każdy zawiera replikę katalogu. Podobnie, dane serwera plików mogą mieć całkiem inne procedury odzyskiwania niż dane CRM.

Scenariusze katastrof Istotne jest zdefiniowanie wszystkich scenariuszy, dla których chcemy utworzyć plan, ponieważ każdy będzie miał inne procedury odtwarzania, inny wpływ na działalność oraz związane z tym koszty. Dobrze jest przejrzeć wszystkie możliwe scenariusze, a następnie zdecydować, który z nich chcemy wybrać, opracowując dla swojego środowiska plan odzyskiwania po awarii:

• Utrata całej lokalizacji
• Utrata pojedynczego centrum danych
• Utrata systemu (system operacyjny lub awaria sprzętu)
• Utrata danych (usunięcie danych lub ich lub uszkodzenie)
• Utrata krytycznych zależności

Oczywiście zasady postępowania dotyczące odzyskiwania po utracie całej lokalizacji bardzo się różnią od przypadku utraty pojedynczego systemu. Można także zdefiniować progi odzyskiwania na podstawie umów SLA. Powiedzmy, na przykład, że cała lokalizacja jest w trybie offline z powodu przestoju sieci głównego dostawcy internetu (ISP). Jeśli umowa SLA dla usługi, na którą ma to wpływ, mówi o ośmiu godzinach na przywrócenie usługi oraz o 48 godzinach na przywrócenie danych, to można by wykonać procedury awaryjne usługi na lokalizacji kopii zapasowej. W rzeczywistości jednak nie przeszlibyśmy przez proces odzyskiwania danych, ponieważ można by się spodziewać całkiem szybkiego powrotu do lokalizacji eksploatacyjnej.

Uff! Tyle pracy, a jeszcze nie porozmawialiśmy o technologii! Nie można niedocenić decydującego znaczenia planowania odzyskiwania po awarii. Implementacja odzyskiwania bez udokumentowanego planu jest tylko „nadzieją na odzyskiwanie po awarii”.

 Do początku strony

Odzyskiwanie po awarii i wirtualizacja

Gdy są gotowe podstawy planowania odzyskiwania po awarii, to co może dodać nam do tego obrazu wirtualizacja? Wiele firm podaje czas odtwarzania usług za pomocą wirtualizowanych serwerów w minutach, a nie w dniach lub tygodniach, tak jak w przypadku ich fizycznych odpowiedników. Ponieważ cały system operacyjny serwera jest teraz jedynie zbiorem plików, wyodrębnionych z podstawowego sprzętu fizycznego, przy rozważaniu możliwości odzyskiwania otwierają się nowe drzwi.

Szeroko rozpowszechniona obecnie teoria jest taka, że niektóre lub wszystkie cele odzyskiwania po awarii mogą być spełnione za pomocą rozwiązań wysokiej dostępności (High Availability, HA). Idea za tym stojąca jest taka, że jeśli mamy węzły klastra w osobnych fizycznych lokacjach, dane w tych węzłach są ze sobą zsynchronizowane, to w przypadku awarii węzeł pasywny może przejąć działanie i przywrócenie pracy może nastąpić niemal w czasie rzeczywistym.

To prawda, lecz jeśli przypomnimy sobie wcześniej zdefiniowane scenariusze katastrof, to jasno z tego wynika, że nie jest to rozwiązanie dla nich wszystkich. Trzeba przygotować kombinację technologii dla wszystkich tych scenariuszy, a to na ogół obejmuje różne rodzaje regularnych kopii zapasowych. Wysoka dostępność (HA) nie chroni przed wszystkimi możliwymi przestojami i nie eliminuje całkowicie potrzeby stosowania jakiegoś rodzaju strategii tworzenia kopii zapasowych.

Wysoka dostępność z Hyper-V wymaga starannego zaplanowania warstwy pamięci, ponieważ jest to czynnik krytyczny dla możliwości odtwarzania. Na przykład w dwuwęzłowym klastrze Hyper-V ze wspólną pamięcią, podsystem pamięci i dane są nadal pojedynczym punktem awarii, nawet jeśli węzły klastra są osobnymi centrami danych.

Trzeba jednak wiedzieć, że taki sam dwuwęzłowy klaster Hyper-V z pamięcią, która nie jest współużytkowana, może przetrwać utratę pamięci lub danych na jednym bądź drugim węźle. Faktycznie wymaga to technologii replikacji do utrzymywania synchronizacji pamięci, a także wprowadza pewną złożoność (patrz rysunek 2).

Rysunek 2: Klaster Hyper-V z wieloma lokalizacjami.

Istnieje kilka bardzo interesujących nowości w obszarze w replikacji i synchronizacji danych, lecz nie są one jeszcze dostarczane przez Micro­soft. Na stronie internetowej na temat klastrowania Windows Server 2008 w wielu lokalizacjach, warto popatrzeć na pokazanych tam partnerów. Inną pomocą jest katalog Windows Server (patrz windowsservercatalog.com), który podaje listę sprzedawców pamięci z technologiami replikacji mającymi certyfikację Windows Server 2008.

Jak można się przekonać, do rozważenia jest wiele możliwych konfiguracji wysokiej dostępności (HA) oraz pamięci. Dlatego też i w tym przypadku trzeba mieć zdefiniowane wymagania biznesowe i pozwolić, aby one kierowały wymaganiami technicznymi, zamiast robić to inną, okrężną metodą.

 Do początku strony

Konwersja systemów fizycznych na wirtualne

Wirtualizacja oferuje oczywiście pewną niepowtarzalną sprawność odzyskiwania, lecz co zrobić z systemami fizycznymi, które nie są dobrymi kandydatami do wirtualizacji? System Center Virtual Machine Manager (SCVMM) zawiera możliwość dokonania przekształcenia uruchomionych, fizycznych serwerów Windows na serwery wirtualne (ang. physical-to-virtual, P2V), którego wynikiem jest możliwa do załadowania maszyna wirtualna Hyper-V, będąca dokładną repliką fizycznego serwera źródłowego. Teraz można replikować tę maszynę wirtualną tak jak jej zwirtualizowane odpowiedniki w całych kampusach lub w całym kraju i uzyskać podobne czasy odzyskiwania.

To podejście różni się od tradycyjnego odzyskiwania na najniższym poziomie (typu „bare-metal”) pod tym względem, iż lokalizacja odtwarzania nie wymaga już takiej samej liczby systemów fizycznych jak lokalizacja eksploatacyjna. Możemy więc przeciążyć nasz sprzęt do odzyskiwania i skalować go według potrzeb, zależnie od wielkości awarii.

Chociaż SCVMM nie obejmuje programu do tworzenia harmonogramów konwersji P2V, gdyż GUI działa w całości ponad Windows PowerShell, można całkiem prosto napisać jego skrypt przy użyciu polecenia New-P2V. W rzeczywistości wszystkie kreatory w SCVMM będą pokazywać kod, który jest używany przy wykonywaniu zadania. Ten kod można skopiować z testowego P2V do swojego środowiska i zmodyfikować go w celu przyszłego automatycznego wykorzystania. Rysunek 3 pokazuje fragment przykładowego kodu. Możemy w swoim środowisku uruchomić kreator SCVMM P2V, aby uzyskać unikatowy skrypt Windows PowerShell, który można przystosować do swoich potrzeb.

Rysunek 3: Kod wytworzony przez kreator SCVMM P2V.

$Credential = get-credential



New-MachineConfig -VMMServer <VMM SERVER> -SourceComputerName "<SOURCE P2V SERVER>" 

-Credential $Credential -RunAsynchronously 



$VMHost = Get-VMHost -VMMServer <VMM SERVER> | where {$_.Name -eq "<TARGET HYPER-V HOST>"}

$MachineConfig = Get-MachineConfig -VMMServer <VMM SERVER> | where {$_.Name -eq "<SOURCE P2V SERVER>"}



New-P2V -VMMServer <VMM SERVER> -VMHost $VMHost -RunAsynchronously -JobGroup 

e823f50d-dbc7-4a41-9087-fb01bb44dc26 -SourceNetworkConnectionID "00:14:D1:3C:66:2F" 

-PhysicalAddress "00:14:D1:3C:66:2F" -PhysicalAddressType Static -VirtualNetwork "External" 

-MachineConfig $MachineConfig 



$VMHost = Get-VMHost -VMMServer <VMM SERVER> | where {$_.Name -eq "<TARGET HYPER-V HOST>"}

$MachineConfig = Get-MachineConfig -VMMServer <VMM SERVER> | where {$_.Name -eq "<SOURCE P2V SERVER>"}



New-P2V -VMMServer <VMM SERVER> -VMHost $VMHost -RunAsynchronously -JobGroup 

e823f50d-dbc7-4a41-9087-fb01bb44dc26 -VolumeDeviceID "C" -Dynamic -IDE -Bus 0 -LUN 0 -MachineConfig $MachineConfig 



$Credential = get-credential

$VMHost = Get-VMHost -VMMServer <VMM SERVER> | where {$_.Name -eq "<TARGET HYPER-V HOST>"}

$MachineConfig = Get-MachineConfig -VMMServer <VMM SERVER> | where {$_.Name -eq "<SOURCE P2V SERVER>"}



New-P2V -Credential $Credential -VMMServer <VMM SERVER> -VMHost $VMHost -Path 

"C:\ProgramData\Microsoft\Windows\Hyper-V" -Owner "DOMAIN\username" -RunAsynchronously -JobGroup 

e823f50d-dbc7-4a41-9087-fb01bb44dc26 -Trigger -Name "<SOURCE P2V SERVER>" -MachineConfig 

$MachineConfig -CPUCount 1 -MemoryMB 512 -RunAsSystem -StartAction NeverAutoTurnOnVM 

-UseHardwareAssistedVirtualization $false -StopAction SaveVM

 Do początku strony

Migawki maszyny wirtualnej

Chociaż z technicznego punktu widzenia nie jest to kopia zapasowa, migawka maszyny wirtualnej zapisuje punkt czasu, do którego możemy powrócić przy użyciu dysków różnicowych i skopiować plik konfiguracji maszyny wirtualnej. Jeśli awaria obejmuje przypadkowe usunięcie danych w maszynie wirtualnej, można to traktować jako funkcję odzyskiwania po awarii, ponieważ maszynę wirtualną można cofnąć do migawki, co powoduje naprawienie uszkodzenia (migawkom VSS (Volume Shadow Copy Service) przyjrzymy się później).

 Do początku strony

Tworzenie kopii zapasowej Hyper-V

Kopie zapasowej oparte na hoście Jedną z niezwykłych korzyści wirtualizacji serwera jest perspektywa, iż nie trzeba dłużej tworzyć kopii zapasowych wirtualizowanych systemów. Teraz gdy te systemy są zwyczajnie plikami zawartymi w systemie plików hosta, można tylko zrobić kopię zapasową plików i nadać jej nazwę zawierającą dzień, prawda? Niezupełnie. Ponieważ są to „żywe” komputery, składające się z danych zawartych w pamięci, danych na dysku, konfiguracji systemu oraz otwartych plików, trzeba wziąć pod uwagę kilka spraw. Jak więc możemy zapewnić spójność danych kopii zapasowej, przy tych wszystkich ruchomych częściach?

Znaczące ulepszenie kopii zapasowej systemu Windows Server zaczęło sie od Windows Server 2003 oraz pojawieniem się usługi VSS. Został wtedy dostarczony standardowy zestaw rozszerzalnych interfejsów API, które są używane przez generatory VSS (punkty zaczepienia w aplikacjach i serwerach, które pozwalają dostarczać spójne kopie w tle) do tworzenia kopii zapasowych otwartych plików oraz aplikacji. Z pomocą usługi VSS, jej dostawców oraz generatorów, aplikacja kopii zapasowej może bardzo szybko, tworzyć kopię woluminu dla danego momentu, którą aplikacja rozpoznaje i może właściwie przetworzyć.

Hyper-V ma własny generator VSS, który pozwala twórcom oprogramowania tworzyć fascynujące rozwiązania tworzenia kopii zapasowych. Dzięki generatorowi aplikacje kopii zapasowych mogą tworzyć oparte na hostach kopie zapasowe VSS uruchomionych maszyn wirtualnych. Jeśli system operacyjny działający na maszynie wirtualnej ma zainstalowane komponenty integrujące Hyper-V, a także usługę VSS (dostępną w Windows XP SP1, Windows Server 2003 i wersjach późniejszych), oparta na hoście kopia zapasowa będzie wykonywana tak, jakby była uruchomiona na maszynie wirtualnej (jako gość). Kopia zapasowa będzie tworzona na uruchomionej maszynie wirtualnej, a dane będą spójne (patrz rysunek 4).

Rysunek 4: Kopia zapasowa VSS.

Jeśli jednak system operacyjny typu gość nie obsługuje komponentów integracyjnych lub usługi VSS, proces tworzenia kopi zapasowej wymaga, aby maszyna gość była ustawiona w zapisanym stanie i aby została utworzona, oparta na hoście, migawka VSS plików danych maszyny wirtualnej, która może być użyta do odtworzenia stanu z danej chwili. Migawki z zapisanym stanem będą wywoływać przestój niektórych maszyn wirtualnych (jest to zwykle ograniczone do 5-10 minut), a na kopii VSS danych są wykonywane procedury tworzenia pełnej kopii zapasowej na taśmie.

Kopie zapasowe oparte na gościach W środowisku fizycznym serwery i aplikacje muszą być archiwizowane indywidualnie, a takie kopie zapasowe mogą oczywiście być utrzymywane w wirtualizowanym centrum danych. W tej sytuacji trzeba wziąć pod uwagę takie same czynniki, jak przy tworzeniu kopi zapasowej maszyny wirtualnej, czyli wymagania dotyczące pojemności sieci dla kopii zapasowych opartych na sieciach oraz wpływ operacji wykonywania kopii zapasowej na wydajność systemu. Tworząc kopie zapasowe oparte na gościach, można wybrać opcję posiadania dedykowanej karty fizycznej NIC w hoście, powiązanej z siecią wirtualną używaną przez wszystkich gości.

 Do początku strony

Windows Server Backup

Windows Server 2008 zawiera program kopii zapasowej Windows Server Backup (WSB) z usługą VSS, który może służyć do wykonywania kopii zapasowych Hyper-V maszyn wirtualnych, opartych na systemie hosta lub gościa. Ponieważ WBS w pełni obsługuje VSS, można za jego pomocą wykonywać oparte na hoście kopie zapasowe uruchomionych maszyn wirtualnych, co oczywiście jest preferowane.

Jeśli jednak mamy maszyny wirtualne bez zainstalowanych komponentów integracyjnych (Integration Componnents), VSS nie będzie stosowane. W tym przypadku mamy kilka możliwości do wyboru. Możemy nadal używać WSB do archiwizacji maszyny wirtualnej, która nie ma zainstalowanych komponentów integrujących, co oznacza, że stan maszyny wirtualnej będzie zapisany, a następnie kopia zapasowa przechwyci dyski wirtualne oraz pliki konfiguracji maszyny wirtualnej.

Jednak może to nie być pożądane w przypadku takiej aplikacji, jak Exchange, ponieważ aplikacja nie będzie rozpoznawać, że kopia zapasowa została uruchomiona i dzienniki aplikacji nie będą obcinane. Ponadto, w maszynie wirtualnej pojawi się przestój, który będzie różny w zależności od tego, ile czasu zajmuje utworzenie kopii zapasowej.

Alternatywnie kopia zapasowa może być uruchamiana z maszyny wirtualnej, przy użyciu NTBackup lub WSB (zależnie od systemu operacyjnego maszyny wirtualnej), tak jakby była to maszyna fizyczna. Zobaczymy, jak użyć WSB dla obsługiwanych systemów gości, które mają zainstalowane komponenty integrujące.

 Do początku strony

Tworzenie kopii zapasowej maszyny wirtualnej za pomocą WSB

Hyper-V nie rejestruje automatycznie swojego generatora VSS do użytku z WSB. Trzeba ręcznie dodać klucz rejestru oraz wartość pokazaną na rysunku 5, zanim WSB będzie obsługiwać kopię zapasową Hyper-V. Można dodać je za pośrednictwem wiersza polecenia, tak jak poniżej:

reg add "HKLM\Software\Microsoft\windows nt\

  currentversion\WindowsServerBackup\Application

  Support\{66841CD4-6DED-4F4B-8F17-FD23F8DDC3DE}"

reg add "HKLM\Software\Microsoft\windows nt\

  currentversion\WindowsServerBackup\Application

  Support\{66841CD4-6DED-4F4B-8F17-FD23F8DDC3DE}" /v

  "Application Identifier" /t REG_SZ /d Hyper-v

Rysunek 5: Klucz i wartość do rejestrowania generatora VSS Hyper-V.

Nie wymaga to ponownego uruchamiania systemu, ponieważ WSB szuka tego klucza lub wartości w czasie tworzenia kopii zapasowej. Poniższe polecenie pokazuje, czy zapis został umieszczony:

reg query "HKLM\Software\Microsoft\windows nt\

  currentversion\WindowsServerBackup\Application

  Support\{66841CD4-6DED-4F4B-8F17-FD23F8DDC3DE}" /s

Oto jak należy zainstalować WSB. Klikamy Start | Server Manager. W lewym okienku klikamy Features (Funkcje), a następnie w prawym okienku klikamy Add Features (Dodaj funkcje). Na stronie Select Features (Wybierz funkcje), rozwijamy Windows Server Backup Features (Funkcje kopii zapasowej systemu Windows Server) i zaznaczamy pola wyboru dla Windows Server Backup (Kopia zapasowa systemu Windows Server) oraz Command-line Tools (Narzędzia wiersza polecenia). Teraz trzeba postępować zgodnie z poniższymi krokami, aby skonfigurować kopię zapasową:

1. Przechodzimy do Start | Administratine tools (Narzędzia administracyjne) | Windows Server Backup (Kopia zapasowa systemu Windows Server).
2. Jeśli tworzymy kopię zapasową zdalnego hosta, wybieramy Connect to Another Computer (Połącz z innym komputerem) i wpisujemy host Hyper-V.
3. Wybieramy Backup Once (Jednorazowa kopia zapasowa) lub Backup Schedule (Harmonogram tworzenia kopii zapasowej).
4. Wybieramy konfigurację kopii zapasowej Full Server (Cały serwer) lub Custom (Niestandardowa). Jeśli wybierzemy Custom, musimy się upewnić, że wzięliśmy wszystkie woluminy, które zawierają dane związane z maszyną wirtualną, której kopię zapasową tworzymy, łącznie z jej danymi konfiguracji, dyskami wirtualnymi oraz migawkami.
5. Wybieramy miejsce przechowywania kopii zapasowej.
6. Wybieramy VSS Full (Pełna kopia zapasowa VSS) lub Copy Backup (Kopia kopii zapasowej). Dla kopii zapasowych opartych na hostach, gdzie nie pojawiają się inne kopie zapasowe z maszynami wirtualnymi, wybieramy pełną kopię VSS.
7. Po potwierdzeniu wszystkich szczegółów wybieramy Backup (Twórz kopię zapasową).

 Do początku strony

Do rozważenia

• Trzeba robić kopię zapasową wszystkich woluminów związanych z maszyną wirtualną, łącznie z dyskami wirtualnymi (Virtual Hard Disks, VHD), plikami konfiguracyjnymi maszyny wirtualnej oraz migawkami.
• Jeśli tworzymy harmonogram kopii zapasowych, musimy użyć dedykowanego lokalnego woluminu, który będzie sformatowany i używany wyłącznie przez WSB. Jeśli natomiast wykonujemy zadanie Backup Once (Jednorazowa kopia zapasowa) możemy przechowywać kopię zapasową na niededykowanym woluminie lokalnym, urządzeniu wymiennym lub udziale sieciowym.
• Jeśli komponenty integrujące nie są zainstalowane w maszynie wirtualnej, której kopia zapasowa jest tworzona, WSB zapisze stan uruchomionej maszyny wirtualnej, aby zapewnić spójność danych kopii zapasowej.
• Po utworzeniu, zestaw kopii zapasowych jest przenośny i może być użyty z dowolnym hostem Hyper-V.

 Do początku strony

Przywracanie maszyny wirtualnej za pomocą WSB

Chociaż WSB ma możliwość odzyskiwania pojedynczych plików, funkcja ta nie używa VSS i dlatego może powodować niespójne odzyskanie, jeśli maszyna wirtualna była uruchomiona w czasie wykonywania kopii zapasowej. Aby przywrócić uruchomioną maszynę wirtualną, trzeba przywrócić cały wolumin (woluminy).

W tym celu trzeba przejść do Start | Administrative Tools (Narzędzia administracyjne) | Windows Server Backup (Kopia zapasowa systemu Windows Server) i w okienku Actions (Akcje) wybrać Recover (Przywróć). Wybieramy serwer, z którego mają być odtwarzane dane (ten, na którym są umieszczone dane kopii zapasowej WSB), a następnie wybieramy datę, od której mamy odzyskać dane. Teraz możemy wybrać typ odzyskania.

Tutaj musimy podjąć decyzję. Jeśli potrzebujemy całej maszyny wirtualnej, łącznie z jej konfiguracją, migawkami oraz dyskami wirtualnymi (w przypadku na przykład całkowitej utraty danych) wybieramy Application Restore (Przywróć aplikację), a następnie Hyper‑V, jak pokazano na rysunku 6. W tym przypadku nie jest potrzebna opcja przywracania pojedynczych plików. Trzeba będzie przywrócić wszystko, co jest zawarte w zbiorze kopii zapasowych. Zwróćmy uwagę, że nie spowoduje to nadpisania istniejących danych konfiguracji Hyper-V oraz danych maszyny wirtualnej, które zmieniły się od utworzenia kopii zapasowej.

Rysunek 6: Przywracanie kopii zapasowej Hyper-V.

Jeśli potrzebujemy tylko samego wirtualnego dysku twardego (VHD), a dane konfiguracji oraz migawki dla wirtualnej maszyny są zdrowe, możemy wybrać opcję Files and foldes (Pliki i foldery), a następnie pojedynczy plik VHD, który jest nam potrzebny. Zwróćmy uwagę, że ten proces nie korzysta z generatora VSS; tworząc kopię zapasową maszyny wirtualnej trzeba brać to pod uwagę i najpierw zapisywać jej stan.

Jeśli cierpimy z powodu utraty całego systemu lub danych i musimy odzyskać sam host Hyper-V, łącznie z systemem operacyjnym Windows Server 2008 oraz wszystkie uruchomione na nim maszyny wirtualne, musimy uruchomić środowisko Windows Recovery i z niego wykonać nasze odtwarzanie. Można to zrobić z dysku instalacyjnego Windows Server 2008 lub wcześniej skonfigurowanej partycji dyskowej.

 Do początku strony

Data Protection Manager

Przyjrzeliśmy się etapom i czynnikom tworzenia kopi zapasowej i jej przywracania dla hostów i gości Hyper-V przy użyciu niezawodnego, bezpłatnego, wbudowanego WSB. WSB nie jest jednak rozwiązaniem chroniącym dane na poziomie przedsiębiorstwa. Po zakończeniu przez niego pracy, pojawia sie Data Protection Manager (DPM) 2007 SP1. DPM SP1, którego wydanie jest obecnie planowane na koniec 2008 r., będzie obsługiwać Hyper-V oraz oferować niektóre istotne funkcje:

• Pojedynczą konsolę zarządzania dla wszystkich hostów i gości Hyper-V.
• Ciągłą ochronę danych, tworzącą migawki oparte na VSS w odstępach do 15 minut, uwzględniając w tym procesie tylko zmienione bity.
• Rozpoznawanie klastra Hyper-V, co pozwala, aby kopia zapasowa podążała za maszyną wirtualną, gdy przenosi się pomiędzy węzłami klastra.
• Replikację serwera DPM na serwer DPM.
• Obsługę dla dysku oraz nośników taśmowych (dysk na dysk, dysk na taśmę lub dysk na dysk na taśmę).
• Możliwość tworzenia i przywracania kopii zapasowej w całym spectrum danych, które obejmują hosty i gości Hyper-V; kopie zapasowe VSS bez agentów dla uruchomionych systemów gości; obsługa odtwarzania pojedynczych maszyn wirtualnych; dane klastra awaryjnego oraz najlepsze w swojej klasie funkcje specyficzne dla aplikacji dla SQL Server, Exchange, SharePoint, Hyper-V oraz Virtual Server.
• Tworzenie skryptów wykonywanych przed i po utworzeniu kopii zapasowych.

Jeśli ktoś obecnie korzysta z rozwiązań innych firm do tworzenia kopii zapasowych, powinien śledzić aktualizacje aplikacji; większość producentów ciężko pracuje nad tym, aby dostarczyć na rynek oparte na hoście rozwiązania Hyper-V.

 Do początku strony

Kopie zapasowe w postaci skryptów

WSB obejmuje interfejs wiersza poleceń, WBadmin.exe, jak również zestaw poleceń Windows PowerShell do wykorzystania ze skryptami. W przypadku ich używania obowiązują takie same zasady tworzenia kopii zapasowych, jakie zostały wcześniej przedstawione, wraz z potrzebą ręcznej rejestracji generatora VSS Hyper-V poprzez rejestr.

Rysunek 7 pokazuje niektóre polecenia WBAdmin. Pełną dokumentację WBAdmin można znaleźć na stronie go.microsoft.com/fwlink/?LinkId=124380. Jak widać, w WB​Admin nie zawiera nic do konfigurowania samej zasady tworzenia kopii zapasowych, ale do zarządzania tymi ustawieniami można stosować przystawkę Windows PowerShell. Aby zobaczyć, czy ta przystawka jest zarejestrowana, można wykonać test za pomocą poniższego polecenia:

Get-PSSnapin -Registered

Rysunek 7: Polecenia WBAdmin.

Do załadowania przystawki o nazwie Win­dows.Serv­erBackup można użyć następującego polecenia:

Add-PSSnapin windows.serverBackup

Po jej załadowaniu mamy dostęp do polecenia Windows PowerShell dla WSB, pokazanego na rysunku 8. Aby otrzymać szeroki opis każdego polecenia, trzeba uruchomić poniższe polecenie:

Get-Command -PSSnapin windows.serverBackup | select name | get-help –full

Rysunek 8: Polecenia Windows Server Backup.

Windows Server 2008 ma wbudowany jeszcze jeden program użytkowy, który może również korzystać z generatora VSS Hyper-V oraz dodaje nieco elastyczności do opcji tworzenia skryptów. DiskShadow.exe umożliwia tworzenie kopii w tle

oraz montowania jej jako dysku, co pozwala administratorom tworzyć bardziej selektywną kopię zapasową niż jest to możliwe przy użyciu WSB. Trzeba pamiętać, że DiskShadow nie akceptuje wejścia potokowego Windows PowerShell; zamiast tego trzeba przejść do niego poprzez polecenia w skrypcie, które mogą wyglądać podobnie jak poniższe:

Delete Shadows Volume C:

Set Context Persistent

Begin Backup 

Writer Verify {66841cd4-6ded-4f4b-8f17-fd23f8ddc3de}

Add Volume C: ALIAS MyShadow 

Create

End Backup

Expose %MyShadow% X: 

Exit

Ten skrypt najpierw usuwa wszelkie istniejące kopie w tle dysku C:, a następnie zapewnia, że kopia w tle będzie utrzymywana po uruchomieniu DiskShadow. Następnie tworzy blok transakcyjny — jeśli jakiś krok się nie uda, cały proces się nie powiedzie. W tym bloku DiskShadow sprawdza, czy jest załadowany generator dla Hyper-V i do listy dysków, których kopia zapasowa ma być utworzona dodaje dysk C:.

Dysk C: dostanie GUID w celu jego identyfikacji, a GUID ten będzie przechowywany w zmiennej środowiskowej, która nosi nazwę „MyShadow”. Po zakończeniu tego działania, powstaje kopia w tle.

Kopia zapasowa jest pokazywana jako dysk X: przy użyciu zmiennej środowiskowej. Na danych zawartych na X: można wykonywać różne operacje, a potem można ponownie uruchomić Disk­Shadow za pomocą polecenia Unexpose X:, aby usunąć ten dysk.

Zwróćmy uwagę, że przywracanie maszyn wirtualnych Hyper-V, które były archiwizowane za pośrednictwem DiskShadow jest obecnie procesem ręcznym (maszyna wirtualna musi być ponownie tworzona, migawki nie są zapisywane i tak dalej). Chociaż ma to oczywiste wady, dane są jednak chronione.

Odzyskiwanie po awarii może być żmudnym procesem, który na pozór nigdy się nie kończy. Lecz serwer wirtualizacji daje nowe możliwości, zarówno dzięki nowym technologiom, jak i wynikającym z niego obniżeniem kosztów punktu dostępowego. Microsoft zapewnia nie tylko wirtualizację, lecz cały ekosystem. Platforma wirtualizacji serwera wraz z rodziną System Center oferują bardziej holistyczne rozwiązania dla organizacji, która stają przez wciąż rosnącymi, złożonych wyzwaniami, takimi jak odzyskiwanie po awarii.

Dziękuję Jamesowi O'Neillowi za jego wkład do tego artykułu.

O autorze

Adam Fazio rozpoczął pracę w Microsoft Consulting Services ponad dwa lata temu i teraz zajmuje się sektorem publicznym USA. Ponad 10 lat służył branży IT, pracując przy różnych projektach infrastruktury oraz operacjach centrów danych dla firm z listy Fortune 100 i firm początkujących w Internecie. Obecnie jest liderem rozszerzania technik w globalnym programie szybkiego rozwoju wirtualizacji (Virtualization Rapid Deployment Program) firmy Microsoft.

Do początku strony