Restore na nową instancję

Restore na nową instancję to typowy sposób sklonowania bazy do celów testowych bez ryzyka dla produkcji.

Na czym polega odtworzenie bazy jako nowej instancji

Restore na nową instancję oznacza odtworzenie kopii zapasowej bazy danych w oddzielnym środowisku, które nie korzysta z tej samej aktywnej instancji co baza produkcyjna. Nowa instancja może działać na tym samym komputerze, na innym serwerze albo w odizolowanym środowisku testowym, ale musi mieć własną konfigurację usług, własne pliki danych i niezależny punkt dostępu. Celem jest uzyskanie roboczej kopii bazy bez wykonywania operacji zapisu na oryginalnym systemie.

Do odtworzenia potrzebny jest zgodny zestaw kopii zapasowych oraz oprogramowanie silnika, który potrafi je odczytać. W zależności od przyjętej strategii może to być pełna kopia bazy, kopie różnicowe oraz kopie dziennika transakcji. Odtworzenie pełnej kopii tworzy stan z chwili wykonania backupu, natomiast zastosowanie kolejnych kopii różnicowych lub dzienników pozwala doprowadzić bazę do późniejszego punktu w czasie, jeżeli format i narzędzia danego silnika to obsługują.

Przygotowanie środowiska przed operacją restore

Nowa instancja powinna mieć parametry odpowiadające wymaganiom odtwarzanej bazy: zgodną wersję silnika lub wersję dopuszczoną przez jego mechanizm kompatybilności, wystarczającą ilość miejsca na pliki danych, pliki dziennika i pliki tymczasowe oraz uprawnienia do odczytu kopii zapasowych. Należy sprawdzić także system plików, dostępne zasoby pamięci i procesora oraz ograniczenia narzucone przez system operacyjny. Brak miejsca na pliki dziennika może przerwać odtwarzanie mimo poprawnej kopii pełnej.

Podczas restore często trzeba wskazać nowe lokalizacje plików, ponieważ ścieżki używane przez produkcyjną instancję mogą nie istnieć w środowisku testowym. Zmiana ścieżek nie powinna oznaczać ręcznego kopiowania pojedynczych plików bez wiedzy o ich roli. Silnik musi otrzymać spójną informację o wszystkich plikach należących do bazy, w tym o plikach danych, dziennika oraz ewentualnych plikach pomocniczych. Przed rozpoczęciem warto potwierdzić integralność archiwum, jego rozmiar, datę utworzenia i zakres obejmowanych obiektów.

Spójność danych i różnice względem produkcji

Poprawne zakończenie restore potwierdza, że silnik odczytał kopię i utworzył bazę, ale nie dowodzi jeszcze, że środowisko testowe działa tak samo jak produkcja. Po odtworzeniu należy sprawdzić możliwość otwarcia bazy, odczytu tabel, wykonania podstawowych zapytań oraz dostępność wymaganych indeksów, widoków, procedur i innych obiektów zapisanych w kopii. Warto porównać liczbę kluczowych rekordów z informacjami z momentu wykonania backupu, uwzględniając oczywiście różnicę czasu między kopią a bieżącym stanem produkcji.

Nowa instancja nie otrzymuje automatycznie wszystkich elementów otoczenia produkcyjnego. Poza samą bazą mogą być potrzebne osobne definicje logowania, użytkowników, ról, harmonogramów zadań, połączeń do innych systemów, certyfikatów oraz ustawień aplikacji. Ich odtworzenie wymaga sprawdzenia dokumentacji konkretnego silnika i aplikacji, ponieważ część konfiguracji jest przechowywana poza bazą. Należy również unikać przypadkowego uruchomienia zadań przeznaczonych dla produkcji, takich jak cykliczne importy, eksporty lub procesy modyfikujące dane.

Testowanie kopii po odtworzeniu

Po zakończeniu restore środowisko powinno przejść test techniczny obejmujący uruchomienie instancji, połączenie klienta bazodanowego oraz wykonanie kontrolnych operacji odczytu. Jeżeli kopia ma służyć do testów aplikacji, należy zweryfikować połączenie aplikacji z nowym adresem, portem lub nazwą instancji, a także sprawdzić, czy aplikacja nie zapisuje przypadkowo do produkcyjnego źródła danych. Szczególne znaczenie ma jednoznaczne rozdzielenie parametrów połączeniowych dla obu środowisk.

Restore na nową instancję jest użyteczny także jako próba odtworzeniowa. Pomiar czasu operacji, ilości zajętego miejsca i liczby wymaganych kroków pokazuje, czy procedura backupu może zostać wykorzystana po awarii. Błędy uprawnień, brakujące pliki, niezgodność wersji albo uszkodzenie archiwum powinny zostać zapisane w dokumentacji wraz z informacją, na którym etapie wystąpiły. Po zakończeniu testów kopię roboczą można pozostawić do dalszych prac albo usunąć zgodnie z przyjętą procedurą utrzymania środowiska, bez ingerencji w instancję produkcyjną.