Restore na inną instancję

Restore na inną instancję pozwala odtworzyć bazę równolegle do środowiska produkcyjnego, bez wpływu na nie.

Restore na inną instancję a środowisko produkcyjne

Restore na inną instancję oznacza odtworzenie kopii zapasowej bazy danych w odrębnym środowisku uruchomieniowym. Instancja może działać na tym samym serwerze albo na innym komputerze, pod warunkiem że docelowy silnik bazy danych obsługuje format użytej kopii oraz ma dostęp do wymaganych plików. Odtworzona baza otrzymuje własne pliki danych, pliki dziennika transakcji i własną nazwę, dlatego operacje wykonywane na kopii nie zmieniają bezpośrednio bazy produkcyjnej.

Podczas przywracania system odczytuje informacje zapisane w kopii, tworzy strukturę bazy i odtwarza dane do punktu wynikającego z rodzaju backupu. Pełna kopia zawiera kompletny stan objętych nią danych w określonym momencie. Kopie różnicowe lub dzienniki transakcji mogą wymagać wcześniejszego odtworzenia pełnego backupu oraz zachowania właściwej kolejności. Jeżeli łańcuch kopii jest niekompletny, odtworzenie może zakończyć się błędem albo dać stan starszy niż oczekiwany.

Przygotowanie lokalizacji plików i parametrów odtworzenia

Instancja docelowa musi mieć wystarczającą ilość wolnego miejsca na pliki bazy, dziennika oraz pliki tymczasowe używane przez silnik. Trzeba również sprawdzić, czy konto procesu bazy danych może odczytać kopię zapasową i zapisać nowe pliki w wybranych katalogach. Samo skopiowanie backupu na serwer nie gwarantuje poprawnego restore, ponieważ uprawnienia systemu plików, ścieżki katalogów i dostępne zasoby mogą różnić się między środowiskami.

Jeżeli instancja źródłowa i docelowa używają innych lokalizacji plików, podczas restore należy wskazać mapowanie plików na nowe ścieżki. Jest to szczególnie ważne po przeniesieniu bazy między komputerami, gdy katalog używany na serwerze produkcyjnym nie istnieje na instancji testowej. Nie wolno bez sprawdzenia nadpisywać plików należących do innej bazy. Bezpieczniejszym rozwiązaniem jest użycie osobnej nazwy bazy i odrębnych katalogów, a następnie potwierdzenie, że lista plików z kopii odpowiada rzeczywistej konfiguracji środowiska.

Spójność danych po zakończeniu restore

Po odtworzeniu baza może być dostępna w trybie odzyskiwania, tylko do odczytu albo w stanie wymagającym zakończenia sekwencji restore. Wynika to z wybranego sposobu odtwarzania i z tego, czy planowane jest zastosowanie kolejnych kopii różnicowych lub dzienników. Dopiero po prawidłowym zakończeniu całego łańcucha można uznać bazę za gotową do normalnej pracy. Przerwanie sekwencji w niewłaściwym momencie może uniemożliwić zastosowanie następnych backupów.

Kontrola po restore powinna obejmować możliwość otwarcia bazy, obecność oczekiwanych tabel i indeksów, liczbę rekordów w kluczowych tabelach oraz działanie podstawowych zapytań. Warto sprawdzić również integralność logiczną danych, na przykład czy relacje między tabelami nie wskazują na brakujące rekordy. Sam komunikat o pomyślnym zakończeniu operacji potwierdza wykonanie procesu technicznego, ale nie dowodzi, że aplikacja będzie mogła się poprawnie połączyć i korzystać z odtworzonej bazy.

Połączenie aplikacji z odtworzoną instancją

Odtworzenie bazy na innej instancji nie przełącza automatycznie aplikacji na nowe środowisko. Program może nadal używać adresu serwera, nazwy instancji, portu, nazwy bazy lub danych uwierzytelniających zapisanych w konfiguracji. Przed uruchomieniem aplikacji na kopii trzeba jednoznacznie ustalić, do którego endpointu kierowane są połączenia. W przeciwnym razie testy wykonywane z założeniem pracy na kopii mogą faktycznie modyfikować środowisko produkcyjne.

W odtworzonej bazie mogą znajdować się identyfikatory, zadania cykliczne, kolejki lub konfiguracje wskazujące na produkcyjne usługi. Dlatego po restore należy wyłączyć procesy, które mogłyby wysyłać wiadomości, uruchamiać operacje automatyczne albo zapisywać dane poza środowiskiem testowym. Trzeba też zweryfikować mapowanie użytkowników bazodanowych na loginy instancji docelowej, ponieważ sam restore nie zawsze odtwarza zależności administracyjne znajdujące się poza plikami bazy. Diagnostyka problemów z takim środowiskiem obejmuje analizę logów aplikacji, konfiguracji połączeń, uprawnień oraz stanu plików bazy, aby potwierdzić, że kopia działa niezależnie od produkcji.