Gdy przychodzi „ten moment”, że trzeba odtwarzać dane i systemy z kopii zapasowych bardzo szybko przekonujemy się, że nasze dwugodzinne RTO nijak się ma do rzeczywistości. W dodatku, przyczyna powolnego odtwarzania z backupu rzadko leży tam, gdzie się jej intuicyjnie spodziewamy. Codzienna rutyna związana z wykonywaniem kopii zapasowych zostaje gwałtownie przerwana i mamy oto nowe wyzwanie, którym jest odtwarzanie. Co ciekawe dla wielu ta sytuacja jest pierwszą próbą całego procesu i nierzadko bardzo bolesną lekcją.
Odtwarzanie to proces, a nie pojedyncza operacja
Myśląc o szybkim odtwarzaniu z kopii zapasowych albo planując obniżenie RTO warto pamiętać, że odtwarzanie to nie jest tylko „kopiowanie pliku z repozytorium na serwer docelowy”. To łańcuch kilku następujących po sobie operacji, gdzie przepustowość całego procesu jest równa przepustowości najwolniejszego ogniwa. Aby zrozumieć złożoność odtwarzania z kopii zapasowej, przedstawię uproszczoną sekwencję procesu:
- Odczyt metadanych. Oprogramowanie backupowe (w tym przykładzie Veeam) odczytuje plik metadanych i identyfikuje, jakie pliki składają się na wybrany punkt przywracania: ostatni pełny backup plus wszystkie kolejne przyrostowe, które trzeba nałożyć, żeby dotrzeć do żądanego momentu w czasie.
- Rehydratacja. Dane w repozytorium nie są gotowym do skopiowania obrazem maszyny. Są skompresowanymi i zdeduplikowanymi blokami rozrzuconymi po wielu plikach. Żeby mogły wrócić w postaci maszyny wirtualnej (VM) na serwer produkcyjny, muszą zostać najpierw zdekompresowane i złożone w logiczny obraz. Ten etap to właśnie rehydratacja i to tutaj najczęściej chowa się wąskie gardło.
- Transfer przez „pośredników” (proxy). W przypadku technologii Veeam, do transferu używane są dwa procesy: jeden po stronie repozytorium (czyta i rehydratuje), drugi po stronie docelowej (zapisuje dane na produkcyjną pamięć masową poprzez silnik wirtualizacji). To, co mierzymy jako „prędkość odtwarzania w MB/s”, to efektywna prędkość tego strumienia, a nie odczyt z repozytorium backupu, ani nie przepustowość łącza.
- Zapis na docelowej pamięci masowej (target). Szybkość zapisu na macierzy produkcyjnej zależna jest od trybu transportu (Direct SAN, Hot-Add, NBD), bo każdy ma inną charakterystykę wydajnościową.
- Rejestracja i uruchomienie VM. Po zapisaniu wszystkich bloków maszyna jest rejestrowana w inwentarzu silnika wirtualizacji na klastrze produkcyjnym i może zostać uruchomiona.
Gdzie najczęściej jest wąskie gardło?
Skoro wiemy już jak wygląda proces odtwarzania, łatwo się domyśleć, że nie wystarczy mieć wysoko przepustową sieć, bo słaba wydajność repozytorium albo klastra wirtualizacji kompletnie zdegraduje szybkość odtwarzania, a to przecież nie wyczerpuje tematu.
Poniżej lista typowych wąskich gardeł procesu odtwarzania z backupu uszeregowana od najczęstszych.
1️⃣ Repozytorium (source). Odtwarzanie z backupu to operacja zarówno dyskowa jak i obliczeniowa, więc duże znaczenie ma I/O i CPU urządzenia. Repozytorium na wolnych dyskach SATA albo z niedowymiarowanym CPU potrafi dać stały sufit na poziomie 200–300 MB/s, niezależnie od tego, co będziemy mieli w innych miejscach.
2️⃣ Docelowa pamięć masowa (target). Macierz produkcyjna i klaster wirtualizacji pod obciążeniem odtwarzania często okazuje się wolniejsza, niż było to w ulotce produktowej producenta. Szczególnie gdy równolegle musi obsługiwać inne maszyny wirtualne lub kilka równoczesnych sesji odtwarzania.
3️⃣ Pośrednik (proxy). Serwer proxy Veeam odbiera dane ze źródła, przetwarza je i przekazuje do miejsca docelowego. W praktyce proxy staje się wąskim gardłem rzadziej niż repozytorium czy storage docelowy. Może się to jednak zdarzyć, gdy damy mu za mało mocy obliczeniowej przy wielu równoległych sesjach albo zbyt wiele zadań odtwarzania jednocześnie.
4️⃣ Sieć (network). Dopiero na tym etapie dochodzimy do limitów związanych z interfejsami sieciowymi i przepustowością sieci. Łącze staje się wąskim gardłem głównie, gdy odtwarzanie realizowane jest przez sieć rozległą (WAN), np. gdy źródłem jest off-site backup zlokalizowany w centrum danych. W przypadku sieci lokalnej (LAN) w większości przypadków przepustowość sieci nie jest problemem.
Warto też mieć na uwadze, że w przypadku backupu, a nie odtwarzania, źródłem jest pamięć masowa macierzy, a nośnik docelowy to repozytorium backupu, czyli odwrotnie niż w procesie odtwarzania.
Dlaczego repozytorium jest częstym winowajcą?
Przez rehydratację. Dane w repozytorium backupu nie są gotowym obrazem maszyny, to skompresowane i zdeduplikowane bloki danych. Rehydratacja to proces odwrotny: dekompresja i złożenie tych bloków z powrotem w pełny, logiczny obraz, który wirtualizator (target) potrafi uruchomić.
Żeby to zrobić, serwer repozytorium musi wykonać trzy rzeczy naraz:
- zdekompresować bloki – algorytm kompresji (LZ4, zlib lub inny wybrany przy tworzeniu zadania backupu) musi zostać odwrócony dla każdego bloku danych,
- odnaleźć fizyczne bloki – deduplikacja oznacza, że jeden blok fizyczny może być referencjonowany przez wiele maszyn lub wiele punktów przywracania, proces musi to „rozplątać”,
- złożyć łańcuch – zaczynając od ostatniego pełnego backupu, nakłada kolejne przyrostowe aż do wybranego punktu w czasie, blok po bloku.
Efektem jest strumień „gotowych” danych płynący do klastra produkcyjnego. I właśnie ten strumień jest tym, co mierzymy jako prędkość odtwarzania.
Jak więc widać, rehydratacja potrzebuje mocy obliczeniowej i sprawnego systemu dyskowego. Tymczasem, częstym błędem popełnianym przez zespoły jest budowa repozytorium backupu na starym gracie, który został wycofany z pracy w klastrze produkcyjnym.
Od czego zacząć szukanie wąskiego gardła?
Proponuje analizę w 3 krokach poprzez odpowiedzi na poniższe pytania.
1. Czy problem jest od początku, czy narasta? Jeśli odtwarzanie idzie wolno od pierwszej minuty, może to wskazywać na problem po stronie repozytorium lub proxy. Jeżeli start jest przyzwoity, ale proces zwalnia w trakcie, wówczas możliwe, że docelowa pamięć masowa nie wyrabia pod narastającym obciążeniem.
2. Ile zadań odtwarzania odbywa się równolegle? Każda równoległa sesja konkuruje o te same zasoby. Czasem uruchomienie mniejszej liczby sesji daje każdej więcej zasobów i łączny czas odtwarzania jest krótszy.
3. Jaki mamy najstarszy punkt przywracania? Im dalej wstecz sięgamy, tym więcej przyrostowych kopii Veeam musi złożyć w całość. To przekłada się bezpośrednio na obciążenie repozytorium i na czas odtwarzania.
Testowe odtwarzanie jako panaceum na niespodzianki
Rzadko kiedy sprawdzamy, czy coś działa, gdy nie jesteśmy do tego zmuszeni. W standardowych operacjach odtwarzanie z kopii zapasowych dotyczy zwykle przywracania określonych plików lub folderów, skrzynek pocztowych lub obiektów bazy danych. Sytuacja, gdy odtwarzamy większość systemów jest scenariuszem niezwykle rzadkim.
Jednak, gdy już dojdzie do odtwarzania całego systemu po incydencie bezpieczeństwa, a biznes stoi, wszyscy patrzą na ręce zespołu IT. Nie ma wówczas miejsca na tuning konfiguracji infrastruktury, bo każda godzina to realne straty finansowe. Dlatego, namawiam, testujcie odtwarzanie w miarę regularnie, chociaż raz na kwartał. Warto też użyć mechanizmów automatyzujących proces, w przypadku Veeam będzie to SureBackup. Da Wam to odpowiedzi, czy nadal mieścicie się w zakładanym RTO, co zmniejszy ciśnienie w już i tak stresującym procesie przywracania systemów. Pamiętajmy, że istotą systemu backup nie jest tworzenie kopii zapasowych, lecz odtwarzanie z kopii zapasowych!
