Nie tylko backup, ale także odtworzenie

Przy planowaniu ochrony przed awarią wiele firm rozważa i testuje tylko proces kopiowania danych do innych nośników lub lokalizacji. Pomijanie procesów odtwarzania kopii to poważny błąd.

Podstawowym zadaniem, które musi zrealizować system backupowy, jest skopiowanie danych z systemu produkcyjnego do innego zasobu, nośnika lub nawet lokalizacji. Sama technologia ewoluowała - od prostego przenoszenia informacji na taśmę za pomocą prostych narzędzi, przez systemy realizujące backup przyrostowy i różnicowy, do radykalnie redukujących objętość składowanych finalnie danych za pomocą deduplikacji i kompresji. Zmieniało się także źródło backupu - od dużych maszyn klasy mainframe i potężnych serwerów typu UNIX, przez rozległe środowiska rozproszonego przetwarzania danych w systemach serwerowych Linux i Windows, aż do środowisk wirtualizowanych, w których wiele systemów pracuje na jednym komputerze, a zestaw takich komputerów tworzy klaster wirtualizacyjny. Mimo tak dużych zmian modelu przetwarzania danych przy backupie nadal koncentrowano się na kopiowaniu i przywracaniu funkcjonalności systemu do tej samej struktury przetwarzania danych. Wirtualizacja zmieniła obraz pracy IT, gdyż radykalnie przyspiesza wdrażanie systemów. Za procesem nie nadąża stary model backupowy, nie dorównuje mu szybkością i elastycznością.

Najważniejszy nie jest "backup", ale "restore"

Sprawność systemu backupowego można sprawdzić tylko w jeden sposób: przywracając dane w taki sposób, do jakiego system był zaprojektowany. W bardzo wielu wdrożeniach przy pierwszych testach okazuje się, że proces przywracania danych trwa o wiele dłużej, niż zaplanowano. Niekiedy pojawiają się problemy, nie tylko wydajnościowe, ale związane ze zgodnością ze stosowanym oprogramowaniem lub nośnikami. W pewnych przypadkach zdarzają się krytyczne błędy, wynikające stąd, że sporządzona kopia nie była kompletna lub była w inny sposób uszkodzona i nie można było tego sprawdzić inaczej niż przy odtworzeniu jej do testowego środowiska. Problemy mogą być także związane z wydajnością łączy między serwerami backupowymi a produkcyjnymi, co wpłynie na prędkość odtwarzania danych, a także z samym procesem odzyskiwania informacji z napędów taśmowych. Te ostatnie są sprawdzone przez lata, ale mają jedną istotną wadę: nie umożliwiają szybkiego odtworzenia informacji, która jest rozproszona wzdłuż nośnika, a najlepiej pracują z maksymalną prędkością, zapisując i odtwarzając komplet danych. Kopia realizowana na dyski nie ma tych wad, ale wymaga oprogramowania, które potrafi radykalnie zredukować ilość danych, a także współpracuje ze środowiskiem wirtualizowanym, "rozumiejąc" sposób odtwarzania i przywracania danych w takich instalacjach.

Backup, który zrozumie wirtualizację

Wirtualizacja, a zatem także praca w wysoko konsolidowanym środowisku, różni się znacząco od instalacji działającej bezpośrednio na sprzęcie. Wszystkie operacje wejścia/wyjścia z maszyn wirtualnych na jednym serwerze są obsługiwane przez jedną magistralę, a całe obciążenie obsługuje jeden zestaw procesorów, wykonując wielokrotnie to samo zadanie. Przy tak zmasowanym obciążeniu należy wziąć pod uwagę wpływ zadań backupowych na wydajność produkcyjnego środowiska. Jeśli obciążenie będzie bardzo wysokie, można oczekiwać zakłóceń w pracy zadań produkcyjnych. Przypisywanie maszyn wirtualnych oraz ograniczanie jednoczesnych kopii jest sprzeczne z automatyzacją i elastycznością środowiska wirtualizowanego.

Agenci nie mają przyszłości

W modelu pracującym bezpośrednio na sprzęcie w każdej instancji systemu operacyjnego na każdym z komputerów niezbędne jest oprogramowanie agenta. Przeniesienie modelu backupu do środowiska wirtualizowanego jest możliwe i backup nadal technicznie da się wykonać, ale nie będzie to rozwiązanie optymalne i wydajne. Jeśli w każdej maszynie wirtualnej musi być zainstalowany agent backupowy, to znaczy, że na jednym fizycznym serwerze będzie zainstalowanych tyle kopii tego samego oprogramowania, ile jest maszyn wirtualnych. To marnotrawstwo pamięci operacyjnej.

Jeszcze gorzej wygląda odtwarzanie takiego środowiska, gdyż polega na uruchomieniu wzorca maszyny z zainstalowanym agentem, a następnie przywrócenie wszystkich danych do środka instalacji, korzystając z agenta. Proces ten jest długotrwały, wymaga dwukrotnego przetwarzania tej samej informacji - najpierw pozyskanie danych z nośników zapasowych przez oprogramowanie do backupu, a następnie odkładanie przez agenta do hostowanego systemu operacyjnego, którego obraz przechodzi do macierzy dyskowej przez hypervisor. Wykorzystanie narzędzia bezagentowego, które skomunikuje się z hypervisorem przez API, sprawia, że dane można odtworzyć wprost do bloków dyskowych na macierzy, co jest o wiele szybsze i mniej obciąża CPU i storage. Istotną wadą rozwiązania agentowego jest to, że backupu nie można sprawdzić, dopóki nie zostanie odtworzony do docelowego środowiska przy działającym systemie operacyjnym. Tymczasem rozwiązanie korzystające z API hypervisora umożliwia kontrolę spójności.

Deduplikacja i kompresja

Gdyby porównać pracę backupu na sprzęcie, korzystającego z agentów i wirtualizowanego, niektóre zagadnienia są podobne w obu środowiskach. Oba modele zakładają pomijanie zawartości niektórych obiektów, takich jak pliki lub partycje wymiany, gdyż obiekty będą odtworzone przy każdym starcie systemu. Deduplikacja i kompresja są podstawą sprawnego backupu w obu modelach, gdyż dział IT często standaryzuje swoje systemy operacyjne, niezależnie od tego, czy pracują na fizycznym sprzęcie czy w środowisku wirtualizowanym. To oznacza, że bardzo wiele bloków danych będzie się powtarzać między obrazami systemów operacyjnych i aplikacji, a także w obrębie jednego obrazu. Oba zagadnienia trzeba w obu modelach wykonać inaczej, uwzględniając specyfikę środowiska - zamiast odpytać system Windows o położenie plików wymiany, co może zrobić agent backupowy, należy te informacje pozyskać na podstawie detali obrazów dysków wirtualnych.

Mozolne odtwarzanie czy uruchomienie prawie od razu?

Każda kopia bezpieczeństwa jest warta tylko tyle, ile można z niej odzyskać w oczekiwanym przez IT czasie. Jeśli odtworzenie kopii wiąże się z koniecznością zaimportowania wielu terabajtów danych, to czas odtwarzania zasobów liczy się w godzinach. Niekiedy takie operacje i tak trzeba wykonać, co występuje przy poważnych zdarzeniach, wymagających odtworzenia kompletnego środowiska. Mimo wszystko większość zadań odtwarzania danych z kopii bezpieczeństwa dotyczy pojedynczych maszyn wirtualnych lub pojedynczych obiektów. Działania można radykalnie przyspieszyć, jeśli stosowane oprogramowanie umożliwi szybkie zamontowanie maszyny wprost z plików kopii bezpieczeństwa lub równie szybkie odtworzenie z deduplikowanych zasobów. Występuje tu istotna zależność związana ze sposobem, w jaki przeprowadzana jest deduplikacja.

Jeśli deduplikowana jest cała przestrzeń kopii, to proces wyciągnięcia danych do pierwotnej postaci, zwany nawodnieniem, bazuje na kompletnym archiwum, zawierającym wszystkie maszyny wirtualne. Przeprowadzona w ten sposób kopia pojedynczej maszyny nie może być przenoszona między instalacjami bez nawodnienia.

Deduplikacja przeprowadzana na poziomie zadania sprawia, że kopia nie należy do globalnego zasobu storage, a zatem jest przenośna. Ceną za to jest większe zapotrzebowanie na pamięć dyskową, gdyż globalna deduplikacja działa skuteczniej. Kopia wykonywana z deduplikacją realizowaną per zadanie umożliwia nie tylko szybkie odtworzenie pojedynczej maszyny, ale nawet możliwość zamontowania maszyny wirtualnej wprost z plików kopii bezpieczeństwa. Oprogramowanie backupowe może w locie dostarczyć odtworzoną zawartość maszyny jako obraz do hypervisora, uruchamiając maszynę bezpośrednio z danych zapisanych w kopii bezpieczeństwa. W ten sposób można testować funkcjonalność produkcyjnego oprogramowania w rezerwowym ośrodku.


TOP 200