RESTORE WITH REPLACE nadpisuje istniejącą bazę o tej samej nazwie, wymaga świadomej decyzji administratora.
Co oznacza opcja RESTORE WITH REPLACE w SQL Server
RESTORE WITH REPLACE jest opcją polecenia RESTORE w Microsoft SQL Server. Pozwala odtworzyć kopię zapasową na istniejącej bazie danych, nawet wtedy, gdy SQL Server wykrywa, że kopia nie pochodzi z tej samej bazy, którą wskazano jako cel. Bez tej opcji silnik zwykle zatrzymuje operację, gdy metadane kopii wskazują na inną bazę albo gdy odtworzenie mogłoby nadpisać istniejące dane. Opcja nie tworzy dodatkowej kopii i nie prowadzi do automatycznego połączenia zawartości obu baz. Odtwarzane pliki danych i dziennika zastępują stan zapisany w kopii zgodnie z pozostałymi parametrami polecenia.
Przykładowa składnia może mieć postać RESTORE DATABASE Sklep FROM DISK = 'D:\Backup\Sklep.bak' WITH REPLACE. Sama opcja REPLACE nie określa lokalizacji plików, trybu odzyskiwania ani momentu zakończenia procesu. Te elementy zależą między innymi od użycia MOVE, RECOVERY lub NORECOVERY oraz od rodzaju odtwarzanej kopii. W praktyce WITH REPLACE należy traktować jako świadome zezwolenie na zastąpienie istniejącej bazy, a nie jako zwykły przełącznik przyspieszający przywracanie.
Jak SQL Server zabezpiecza odtwarzanie przed pomyłką
SQL Server przechowuje w kopii zapasowej informacje pozwalające rozpoznać bazę źródłową, między innymi nazwę bazy, identyfikator bazy oraz charakter kopii. Podczas przywracania silnik porównuje te dane z bazą wskazaną jako cel. Ochrona ma zapobiec sytuacji, w której administrator przez pomyłkę odtwarza kopię produkcyjnej bazy na inną istniejącą bazę o podobnej nazwie. WITH REPLACE omija część tego ostrzeżenia, dlatego jego użycie nie powinno być uzasadniane samym faktem, że polecenie bez tej opcji zakończyło się błędem.
Przed wydaniem polecenia można sprawdzić zawartość pliku kopii za pomocą RESTORE HEADERONLY oraz listę plików logicznych i fizycznych za pomocą RESTORE FILELISTONLY. Te instrukcje nie odtwarzają danych, lecz pokazują informacje potrzebne do weryfikacji źródła kopii, numeru zestawu backupu oraz nazw plików. Przy odtwarzaniu na inną ścieżkę używa się klauzul MOVE, na przykład dla pliku danych i pliku dziennika. Jeżeli pliki docelowe mają zostać zastąpione, administrator powinien jednoznacznie potwierdzić ich lokalizację oraz bazę, której stan zostanie utracony.
Skutki użycia REPLACE dla istniejącej bazy
Przywrócenie pełnej kopii bazy z WITH REPLACE odtwarza dane, obiekty, uprawnienia zapisane w bazie oraz stan dziennika znajdujący się w kopii. Zmiany wykonane po utworzeniu tej kopii nie pojawią się w odtworzonej bazie, chyba że zostaną później odtworzone z odpowiednich kopii różnicowych lub dziennika transakcji. W przypadku sekwencji odzyskiwania kopię pełną można odtworzyć z NORECOVERY, następnie zastosować kopię różnicową i kolejne kopie dziennika, a dopiero na końcu użyć RECOVERY. WITH REPLACE nie zastępuje tej sekwencji i nie odzyskuje automatycznie operacji wykonanych po czasie utworzenia użytej kopii.
Opcja może być potrzebna podczas odtwarzania bazy na serwerze testowym, przy zmianie nazwy bazy docelowej albo po celowym odtworzeniu kopii na istniejące pliki. Nie naprawia jednak uszkodzonego backupu, nie zwiększa jego kompletności i nie gwarantuje zgodności wersji SQL Server. Po zakończeniu przywracania warto sprawdzić komunikaty z dziennika operacji, stan bazy w widoku sys.databases, dostępność wymaganych obiektów oraz poprawność aplikacji korzystającej z bazy. Szczególną uwagę należy zwrócić na połączenia aplikacyjne, zadania SQL Server Agent i konfigurację zależną od środowiska, ponieważ odtworzenie bazy nie odtwarza całej konfiguracji instancji.
Kontrola procedury przed i po przywróceniu
Bezpieczna procedura rozpoczyna się od ustalenia, czy celem jest zastąpienie istniejącej bazy, czy utworzenie jej obok obecnej. Jeżeli obecny stan może być jeszcze potrzebny, należy najpierw wykonać niezależną kopię zapasową bazy docelowej i zweryfikować możliwość jej odtworzenia. Następnie trzeba potwierdzić plik kopii, jego pochodzenie, datę utworzenia oraz kolejność zestawów backupu. W razie potrzeby można użyć RESTORE VERIFYONLY, pamiętając, że pozytywny wynik weryfikuje możliwość odczytu struktury kopii, lecz nie zastępuje pełnego testu odtworzenia na serwerze kontrolnym.
Po operacji należy sprawdzić, czy baza ma oczekiwany stan ONLINE, czy użytkownicy bazodanowi mogą się uwierzytelnić i czy aplikacja odczytuje właściwe dane. Przy odtwarzaniu kopii na inną nazwę lub inną instancję trzeba zweryfikować mapowanie plików przez RESTORE FILELISTONLY i odpowiednio zastosować WITH MOVE. W środowisku SQL Server każdorazowe użycie RESTORE WITH REPLACE powinno być odnotowane w procedurze administracyjnej wraz z nazwą kopii, bazą docelową i zakresem utraconych zmian. Dzięki temu można jednoznacznie ustalić, jaki stan danych został przywrócony i jakie kolejne kopie dziennika mogą być jeszcze użyte.
