RESTORE DATABASE

RESTORE DATABASE odtwarza bazę z kopii zapasowej, przywracając dane, obiekty i uprawnienia z chwili jej wykonania.

Operacja RESTORE DATABASE w SQL Server

RESTORE DATABASE to instrukcja języka Transact-SQL używana w Microsoft SQL Server do odtworzenia całej bazy danych z kopii zapasowej. Operacja może odtworzyć strukturę bazy, dane, indeksy, procedury składowane, widoki, wyzwalacze oraz inne obiekty zapisane w kopii. Przywracany jest stan wynikający z momentu wykonania konkretnej kopii, a nie bieżąca zawartość uszkodzonej lub utraconej bazy. Polecenie nie „naprawia” logicznie danych według uznania administratora, tylko zapisuje na serwerze zawartość pochodzącą z określonego zestawu backupów.

Najprostsza forma operacji korzysta z kopii pełnej, na przykład RESTORE DATABASE NazwaBazy FROM DISK = 'D:\backup\NazwaBazy.bak' WITH RECOVERY;. Nazwa bazy oraz ścieżka muszą odpowiadać rzeczywistym zasobom dostępnym dla usługi SQL Server. W systemie Windows konto usługi silnika musi mieć prawo odczytu pliku kopii. Sam użytkownik uruchamiający polecenie powinien mieć uprawnienia pozwalające na wykonanie przywracania, zwykle związane z rolą administracyjną instancji lub odpowiednimi uprawnieniami do bazy.

Łańcuch kopii i kolejność odtwarzania

SQL Server rozróżnia między innymi kopie pełne, różnicowe oraz dziennika transakcji. Kopia różnicowa zawiera zmiany od ostatniej kopii pełnej, dlatego przy jej użyciu najpierw odtwarza się właściwą kopię pełną, a następnie najnowszą odpowiednią kopię różnicową. Przywracanie dzienników transakcji wymaga zachowania ciągłości łańcucha: każdy kolejny plik log backupu musi obejmować następny zakres zapisów po poprzednim. Pominięcie fragmentu dziennika uniemożliwia odtworzenie późniejszych punktów w ramach tego samego łańcucha.

Znaczenie ma również opcja zakończenia procesu. WITH NORECOVERY pozostawia bazę w stanie, w którym można zastosować następną kopię, na przykład różnicową albo dziennika transakcji. WITH RECOVERY kończy sekwencję i udostępnia bazę do normalnego użycia. Po przejściu do stanu odzyskiwania nie można bezpośrednio dołączyć kolejnego backupu z tego samego ciągu. W scenariuszu odtwarzania do określonej chwili można użyć STOPAT, ale tylko wtedy, gdy dostępne są odpowiednie kopie dziennika obejmujące wymagany moment.

Pliki bazy, nadpisanie i weryfikacja kopii

Kopia SQL Server zawiera informacje o logicznych nazwach plików bazy oraz ich pierwotnych lokalizacjach. Jeżeli baza ma zostać odtworzona na innym dysku, używa się klauzuli WITH MOVE, wskazując nowe ścieżki dla pliku danych i pliku dziennika, przykładowo WITH MOVE 'NazwaBazy' TO 'E:\SQLData\NazwaBazy.mdf', MOVE 'NazwaBazy_log' TO 'F:\SQLLogs\NazwaBazy_log.ldf'. Rzeczywiste nazwy logiczne należy wcześniej odczytać z nagłówka lub zawartości kopii, ponieważ nie muszą być identyczne z nazwami plików widocznymi w systemie Windows.

Przed odtworzeniem warto sprawdzić metadane kopii poleceniami RESTORE HEADERONLY oraz RESTORE FILELISTONLY. Pierwsze zwraca informacje o zestawach backupu zapisanych w pliku, między innymi typ kopii, czas jej wykonania i numer zestawu. Drugie pokazuje logiczne nazwy plików oraz ich typy. Do sprawdzenia integralności nośnika służy RESTORE VERIFYONLY, jednak pozytywny wynik nie zastępuje próbnego odtworzenia i kontroli danych. Po przywróceniu można dodatkowo uruchomić DBCC CHECKDB, aby sprawdzić spójność logiczną i fizyczną struktur bazy w zakresie obsługiwanym przez to polecenie.

Skutki nieprawidłowo przygotowanego przywracania

RESTORE DATABASE może wymagać odłączenia użytkowników od bazy. Jeżeli istnieją połączenia blokujące operację, administrator może użyć odpowiednio dobranej opcji WITH REPLACE lub WITH ROLLBACK IMMEDIATE, ale każda z nich może doprowadzić do utraty niezapisanych zmian albo nadpisania aktualnej zawartości. WITH REPLACE omija część zabezpieczeń przed przywróceniem kopii na niewłaściwą bazę, dlatego jej użycie powinno być poprzedzone identyfikacją bazy docelowej, kopii oraz wymaganej ścieżki odtworzenia.

W praktyce diagnostyka problemu obejmuje odczyt komunikatu SQL Server, sprawdzenie dostępności pliku backupu, uprawnień konta usługi, wolnego miejsca, zgodności wersji silnika oraz stanu plików docelowych. Kopia wykonana w nowszej wersji SQL Server nie może być zwykle przywrócona do starszej wersji tego silnika. Po zakończeniu operacji należy potwierdzić stan bazy w widoku katalogowym, sprawdzić dostęp aplikacji, wykonać kontrolę spójności i zweryfikować, czy przywrócono właściwy punkt w czasie. W przypadku sprzętowej awarii komputera lub lokalnej utraty środowiska SQL Server Warszawskie Pogotowie Komputerowe wykonuje profesjonalną naprawę laptopów, komputerów PC i ich podzespołów.