Dziś ponownie z przyjemnością przedstawiam przydatne porady od mojego kolegi Jewgienija Iwanowa, lidera zespołu wsparcia technicznego Veeam. Tym razem Żenia podzielił się rekomendacjami dotyczącymi pracy z kopią zapasową i replikami. Mam nadzieję, że pomogą one uniknąć typowych błędów, a wasze repliki i kopie zapasowe nigdy nie będą "najsłabszym ogniwem" w procesie przywracania, gdyby zajdzie taka potrzeba.

Zatem, witamy pod spodem.

W moim poprzednim artykuł rozmawialiśmy o optymalizacji obciążenia komponentów infrastruktury kopii zapasowej oraz omawialiśmy typowe błędy konfiguracyjne. Przechodzimy do innego ważnego tematu – prawidłowego przygotowania i wykonania przywracania. I ten temat również omówimy na rzeczywistych przykładach, z którymi miały do czynienia zespoły wsparcia technicznego.

Kopia zapasowa bez testów – to pieniądze wyrzucone w błoto

Regularnie zwracają się do nas użytkownicy, którzy znaleźli się w podobnych kłopotliwych sytuacjach: konieczne jest przywrócenie z kopii zapasowej, ale przy próbie zrobienia tego napotykają na problem, który dla nich jest nie do rozwiązania. A problem ten wcale nie jest spowodowany brakiem kopii zapasowej, działaniem CryptoLockera ani niczym podobnym. To "tylko" brak wystarczającej uwagi poświęconej weryfikacji możliwości przywrócenia kopii zapasowych i replik. Wielu często koncentruje się wyłącznie na procesie tworzenia kopii zapasowej, zapominając, że sama obecność kopii zapasowej nie jest panaceum na możliwe nieszczęścia. Należy zrozumieć, że przywracanie to zupełnie inny proces, który ma swoje specyfiki i który należy kontrolować i testować przed wdrożeniem do produkcji. Oto kilka znakomitych przykładów:

U użytkownika wystąpiła awaria krytycznej maszyny wirtualnej o pojemności 20 TB. Przestoje są oczywiście niedopuszczalne, a administrator uruchamia proces błyskawicznego przywracania (VM instant recovery) – po 5 minutach maszyna jest gotowa. Ale pamiętamy, że taki stan maszyny może być używany tylko tymczasowo – należy ją na pewno przenieść z powrotem na produkcyjny datastore. A w tym przykładzie okazało się, że możliwości infrastruktury nie pozwalały na skopiowanie 20 TB danych w rozsądnym czasie. W ustawieniach procesu błyskawicznego przywracania wybrano opcję zapisywania zmian na dysku. Z: Serwery Veeam Backup & Replication (w przeciwieństwie do zrzutu vSphere) – w efekcie, oczywiście, miejsce na dysku szybko się skończyło. W momencie, gdy użytkownik skontaktował się z pomocą techniczną, na VM zaszły zmiany, których nie można było zignorować. Mamy więc sytuację, w której nie można szybko zakończyć procesu natychmiastowego przywracania krytycznej maszyny – jak w takim razie uratować dane?
Szczerze mówiąc, z upływem lat już nie przypomnę sobie wszystkich szczegółów zakończenia, ale pamiętam, że w końcu nie wymyśliliśmy nic genialnego. Klienci po swojej stronie, w miarę możliwości, rozwiązali ten problem, rozszerzając dysk C: z rezerw, skopiowali najważniejsze pliki, a dopiero potem wyłączyli VM i tak przeprowadzili migrację. Ogólnie rzecz biorąc, cudu nie było.
W infrastrukturze użytkownika działał jeden kontroler domeny, a wszystkie komponenty Veeam Backup & Replication były skonfigurowane z użyciem DNS. Tak, dobrze słyszycie. Było co najmniej sto możliwych scenariuszy, a rzeczywistość potoczyła się tak: ludzie zaplanowali konserwację i zdecydowali się przełączyć na replikę swojego kontrolera domeny. Wykorzystali zaplanowane przełączenie, co zresztą zaleca się w takich sytuacjach. Na pierwszym etapie wszystko szło dobrze, a na drugim pierwotną VM na chwilę wyłączono, aby przenieść pozostałe dane. Oczywiście zadanie przełączenia natychmiast zakończyło się błędem, ponieważ DNS przestał działać.
Na szczęście udało nam się poradzić sobie z sytuacją, uruchamiając replikę ręcznie z vSphere (w rzeczywistości tę operację zaleca się przeprowadzać ostrożnie, co zobaczycie w następnym przykładzie). Ale, jak rozumiecie, proces konserwacji został przerwany i odłożony. Dodatkowo musieliśmy ręcznie wprowadzić nazwy hostów do pliku C:WindowsSystem32driversetchosts na serwerze Veeam Backup & Replication, aby zapewnić poprawność podczas odwrotnego przełączania.
U innego klienta cała infrastruktura kopii zapasowej została zbudowana wokół nośników taśmowych, a na dysku przechowywane były jedynie krótkie ciągi plików. Kiedy jednak potrzebowali przywrócić szereg plików z dużego serwera plików, okazało się, że żadna maszyna nie może być użyta jako pomocnicze repozytorium przy przywracaniu z taśmy, ponieważ na żadnej z nich nie było wystarczająco dużo wolnego miejsca. (O przywracaniu z taśmy bezpośrednio i z użyciem pomocniczego repozytorium można przeczytać tutaj (na razie w języku angielskim)).

Myślę, że w każdym z trzech przypadków użytkownicy, można powiedzieć, byli w pułapce iluzji – założyli, że jeśli kopia zapasowa została wykonana pomyślnie, to z przywracaniem nie będzie problemów. Ale, jak wszyscy rozumieją, wcale nie zawsze tak jest, i dlatego do przywracania należy się przygotować równie starannie, jak do tworzenia kopii zapasowej. Na początek warto zapoznać się z instrukcją obsługi, która zawiera dość szczegółowe informacje o różnych rodzajach przywracania. Na początku każdego rozdziału wymienione są wymagania, działania przygotowawcze i możliwe ograniczenia. Opis przywracania z taśm lub z migawek hardware'owych można znaleźć w sekcjach dokumentacji oraz naszych artykułach na Habrze. Ponadto działania przygotowawcze do przywracania obiektów aplikacji za pomocą narzędzi Veeam Explorers są opisane w rozdziale „Planowanie i przygotowanie” dla każdego z narzędzi. Polecam dokładne zapoznanie się z nimi – pomoże to prawidłowo przygotować system do przywracania w razie potrzeby. W języku rosyjskim instrukcje dla przywracania bazy danych SQL Server są przedstawione przewodniki Dlaczego nie należy pracować z replikami z poziomu konsoli vSphere? tutaj.

Teoretycznie, repliki Veeam są zwykłymi maszynami wirtualnymi, z którymi, wydawałoby się, logicznie jest pracować, korzystając z narzędzi vSphere, w szczególności klienta vSphere. Jednak nie zalecamy tego robić, i oto dlaczego: przełączenie na replikę w Veeam Backup & Replication to dość skomplikowany proces, wymagający ściśle uporządkowanego wykonania kroków (aby w razie czego można było cofnąć się o krok) oraz prawidłowych zakończeń działań – wystarczy spojrzeć na obrazek ilustrujący proces:

Teoretycznie replikacje Veeam są po prostu zwykłymi maszynami wirtualnymi, z którymi, wydaje się, logicznie byłoby pracować przy użyciu narzędzi vSphere, w szczególności klienta vSphere. Jednak nie zalecamy tego i oto dlaczego: przełączenie na replikę w Veeam Backup & Replication to proces dość skomplikowany, wymagający ściśle kolejnego wykonania kroków (aby w razie czego można było cofnąć się o krok) oraz poprawnych działań końcowych – wystarczy spojrzeć na obrazek ilustrujący ten proces:

Jeśli zdecydujecie się włączyć replikę z klienta vSphere, to z dużym prawdopodobieństwem będziecie mieli szereg problemów:

Mechanizm przełączania na replikę z Veeam Backup & Replication (pokazany na schemacie) dla tej maszyny nie będzie już działał.
Dane w bazie Veeam Backup nie będą odpowiadać rzeczywistemu stanowi VM. W najgorszym przypadku, aby to naprawić, trzeba będzie edytować bazę.
Możliwa jest nawet utrata danych, jak w tym przykładzie: użytkownik ręcznie włączył replikę w kliencie vSphere i postanowił kontynuować pracę z nią. Po pewnym czasie zauważył, że replika wciąż jest wyświetlana w konsoli Veeam Backup & Replication i postanowił ją usunąć, uznając za zbędną. Kliknął na nią prawym przyciskiem i wydał polecenie „Delete from disk”. Veeam Backup & Replication natychmiast usunął replikę z dysku, która, nawiasem mówiąc, była już wykorzystywana jako zwykła VM i zawierała potrzebne oraz przydatne dane.

Oczywiście zdarzają się sytuacje, kiedy jednak trzeba włączyć replikę z klienta vSphere – zazwyczaj są to przypadki, kiedy serwer Veeam jest wyłączony, a replikę należy włączyć z opóźnieniem. Ale jeśli z serwerem Veeam wszystko w porządku, to praca z replikami powinna odbywać się właśnie z jej konsoli.

Nie należy także usuwać replik, korzystając z klienta vSphere. Veeam Backup & Replication pozostanie w nieświadomości na temat takiej zmiany, a to grozi błędami i przestarzałymi danymi. Jeśli replika jest już niepotrzebna, usuń ją za pomocą konsoli Veeam, a nie jako VM z klienta vSphere. Dzięki temu zawsze będziesz mieć aktualną listę replik.

„O” – uwaga, aktualizacje!

Mamy tu na myśli, oczywiście, aktualizacje dla hypervisorów i różnorodnych aplikacji, które są backupowane za pomocą Veeam. Jeśli spojrzeć na nie z perspektywy pracy z Veeam Backup & Replication, to aktualizacje można umownie podzielić na 2 kategorie: duże, poważne, wprowadzające wiele zmian – i małe.

Rozważmy najpierw pierwszą kategorię.

Najważniejsze aktualizacje to te, które są przeznaczone dla hypervisora. Przed zainstalowaniem takiej aktualizacji należy koniecznie upewnić się, że jest ona wspierana przez Veeam Backup & Replication. Takie aktualizacje wprowadzają wiele zmian w bibliotekach i interfejsach API używanych przez Veeam Backup & Replication, dlatego aby oficjalnie ogłosić ich wsparcie, konieczne jest zaktualizowanie kodu Veeam Backup & Replication oraz przeprowadzenie dokładnych testów.

Należy również pamiętać, że na przykład VMware nie udostępnia wcześniejszego dostępu do najnowszych wersji vSphere dla producentów oprogramowania, więc deweloperzy i testerzy Veeam otrzymują nową wersję w tym samym czasie, co cała postępowa ludność – dlatego między wydaniem VMware a oficjalnym ogłoszeniem wsparcia zazwyczaj upływa pewien czas. Liczba i różnorodność niezbędnych zmian jest na tyle duża, że w prosty hotfix trudno je pomieścić – a oficjalne wsparcie zazwyczaj ogłaszane jest razem z wydaniem wersji produkcyjnej Veeam Backup & Replication.

W efekcie pojawia się ten niezręczny moment, kiedy po wydaniu nowej wersji vSphere liczba zgłoszeń do pomocy technicznej gwałtownie rośnie, ponieważ użytkownicy bez namysłu rzucają się na instalację nowej wersji, a ich kopie zapasowe oczywiście natychmiast przestają działać. My – pomoc techniczna Veeam – musimy wyjaśniać użytkownikom, co dokładnie zrobili źle, prosząc ich o powrót (jeśli to możliwe) lub wymyślając złożone sposoby wyjścia z impasu. Dlatego przed zainstalowaniem poważnej aktualizacji koniecznie sprawdź jej kompatybilność z oprogramowaniem, które używasz, bardzo cię proszę!

Wszystko, co powiedziano powyżej, odnosi się również do aplikacji, które tworzysz kopie zapasowe i planujesz przywracać za pomocą Veeam. Linia narzędzi Veeam Explorers również ma listę wspieranych wersji odpowiednich aplikacji, która jest uzupełniana z każdym wydaniem Veeam Backup & Replication. Dlatego przed zainstalowaniem nowej wersji swojej aplikacji – czy to Exchange, Oracle czy SharePoint — koniecznie przestudiuj odpowiednią sekcję dokumentacji Veeam Explorers.

Do drugiej kategorii, czyli do niewielkich aktualizacji, zaliczam na przykład nowe wersje VMware Tools, aktualizacje kumulacyjne Exchange, aktualizacje bezpieczeństwa vSphere itd. Zazwyczaj nie niosą one ze sobą żadnych poważnych modyfikacji i w większości przypadków Veeam Backup & Replication nie ma z nimi problemów. (Dlatego nie ma publicznych ogłoszeń o oficjalnym wsparciu w produkcie.) Jednak w naszej praktyce spotykaliśmy przypadki, kiedy takie aktualizacje znacząco zmieniały dotychczasowy bieg wydarzeń, co prowadziło do błędów w działaniu Veeam Backup & Replication. W takich sytuacjach po potwierdzeniu problemu inżynierowie Veeam starają się szybko wydać hotfix.

Dla tych, którzy znają techniczny angielskiJeśli chcesz być na bieżąco z tym, nad czym pracują inżynierowie i z czym zmagają się architekci systemów oraz specjaliści wsparcia technicznego, polecam zapisać się na nasze forum. Co tydzień dla jego subskrybentów wychodzi newsletter „Word from Gostev” autorstwa TheRealGostev. W nim Anton Gostev, kierujący działem zarządzania produktem, opowiada o niedawno znalezionych problemach (nie tylko po stronie Veeam), planach na nowe wersje i nowinkach ze świata IT. Jeśli potrzebujesz więcej informacji, można przestudiować tematy na forum – jeśli któryś z klientów napotka problem z działaniem produktu po jakiejkolwiek aktualizacji, prawdopodobnie już napisał o tym na forum.

Jak rozumiesz, patche i aktualizacje mogą prowadzić do problemów nie tylko z kopiami zapasowymi, ale i z aplikacjami, dla których te kopie są tworzone. I tutaj pomogą wirtualne laboratoria – Veeam DataLabs. Na pewno słyszałeś o funkcjonalności SureBackup, przeznaczonej do weryfikacji kopii zapasowych. Opiera się ona właśnie na zastosowaniu DataLabs, z utworzeniem izolowanego środowiska, w którym można na przykład testować aktualizacje przed ich wprowadzeniem do produkcji. Gorąco to polecam – zaoszczędzisz sobie wiele nerwów. A jeśli ktoś jeszcze nie wie o SureBackup, polecam poczytać dokumentację.

Na dziś to wszystko, dziękuję za uwagę!