Restore z Snapshotu

Restore ze snapshotu to szybkie odtworzenie bazy z migawki, dostępne w wybranych środowiskach chmurowych.

Na czym polega restore z snapshotu

Restore ze snapshotu oznacza odtworzenie stanu danych zapisanych wcześniej w migawce. Snapshot jest punktem w czasie, który opisuje zawartość woluminu, systemu plików, maszyny wirtualnej albo usługi bazodanowej. W przypadku bazy danych przywracany jest stan obejmujący pliki danych, a czasem również pliki dziennika transakcji lub dodatkowe metadane wymagane przez konkretną usługę. Po wykonaniu operacji środowisko wraca do wersji zapisanej w chwili utworzenia migawki, dlatego zmiany wprowadzone później mogą zostać utracone.

Mechanizm przywracania zależy od platformy, na której utworzono snapshot. Niektóre systemy tworzą kopię bloków i przywracają je do tego samego woluminu, inne udostępniają odtworzone dane jako nowy wolumin, instancję lub bazę. Restore może oznaczać zarówno zastąpienie bieżącego zasobu, jak i utworzenie oddzielnej kopii do późniejszego przełączenia aplikacji. Przed rozpoczęciem trzeba więc sprawdzić, jaki obiekt zostanie zmieniony, czy operacja jest odwracalna oraz czy snapshot jest zgodny z wersją usługi używaną przez aplikację.

Spójność migawki i stan transakcji

Najważniejszą cechą snapshotu bazy danych jest spójność. Migawka wykonana na poziomie dysku nie zawsze gwarantuje, że wszystkie pliki bazy przedstawiają jeden logiczny moment pracy. Jeżeli w chwili wykonywania snapshotu trwa zapis, część danych może znajdować się jeszcze w pamięci podręcznej systemu lub silnika, a część w plikach na dysku. Dlatego usługi bazodanowe często oferują snapshoty wykonywane przez własny mechanizm albo wymagają krótkiego zamrożenia zapisu, zrzutu pamięci podręcznej i poprawnego zamknięcia plików.

Po przywróceniu silnik może uruchomić procedurę odzyskiwania, podczas której analizuje dziennik transakcji, ponawia zatwierdzone operacje i wycofuje te, które nie zostały zakończone. Taki etap jest normalny i może wydłużyć start bazy, zwłaszcza gdy snapshot wykonano podczas intensywnego obciążenia. Sam fakt, że pliki zostały odtworzone bez błędu, nie potwierdza jeszcze poprawności danych. Należy sprawdzić możliwość uruchomienia usługi, dostęp do tabel lub kolekcji, wykonanie kontrolnych odczytów oraz zgodność danych z momentem, który miał zostać odzyskany.

Przygotowanie operacji odtworzenia

Przed restore trzeba ustalić dokładny punkt przywracania, identyfikator migawki, zakres zasobu oraz zależności aplikacji. Warto zapisać bieżącą konfigurację, wykonać dodatkową kopię aktualnego stanu i zatrzymać procesy, które mogłyby zapisywać dane podczas odtwarzania. Jeżeli baza korzysta z kilku woluminów, snapshoty powinny pochodzić z tego samego, uzgodnionego momentu. Przywrócenie tylko jednego elementu może doprowadzić do rozbieżności między plikami danych, dziennikami i konfiguracją.

Istotne są także parametry RPO i RTO. RPO określa, jak dużo danych można utracić, licząc od awarii do ostatniego dostępnego punktu odtworzenia. RTO określa maksymalny akceptowany czas niedostępności usługi. Snapshot wykonywany raz dziennie może spełniać wymagania prostego środowiska testowego, ale nie zapewni małego RPO dla systemu, w którym dane zmieniają się co kilka minut. Po przywróceniu należy uwzględnić czas kopiowania bloków, odtwarzania dziennika, kontroli spójności oraz ponownego podłączenia aplikacji.

Kontrola po przywróceniu danych

Po zakończeniu restore należy potwierdzić, że baza działa na właściwym zasobie i korzysta z oczekiwanej konfiguracji. Trzeba sprawdzić status usługi, logi uruchomieniowe, stan mechanizmów odzyskiwania, dostępność indeksów oraz podstawowe operacje odczytu i zapisu. W przypadku aplikacji korzystającej z bazy należy wykonać kontrolny scenariusz obejmujący logowanie, odczyt rekordu, utworzenie testowej zmiany i jej wycofanie, o ile środowisko na to pozwala. Należy również zweryfikować, czy aplikacja nie wskazuje nadal starego adresu, woluminu lub identyfikatora instancji.

Snapshot nie powinien być jedyną metodą ochrony danych. Migawka może zostać usunięta razem z zasobem, zależeć od tej samej awarii infrastruktury albo nie obejmować ustawień i danych przechowywanych poza bazą. Dlatego w środowiskach wymagających odtwarzania stosuje się także niezależne kopie zapasowe, testy odtworzeniowe i dokumentację procedury. Jeżeli restore dotyczy komputera używanego lokalnie jako klienta, trzeba dodatkowo sprawdzić połączenie z odtworzoną usługą, aktualność sterownika oraz poprawność lokalnej konfiguracji. Warszawskie Pogotowie Komputerowe zajmuje się profesjonalną naprawą laptopów, komputerów PC i podzespołów, w tym diagnostyką problemów z dostępem do danych oraz konfiguracją oprogramowania klienckiego.