Przywracanie danych z pliku .bak to odtworzenie bazy poleceniem RESTORE DATABASE na podstawie kopii zapasowej.
Plik .bak jako kopia zapasowa bazy SQL Server
Plik z rozszerzeniem .bak jest najczęściej kopią zapasową utworzoną przez Microsoft SQL Server. Samo rozszerzenie nie określa jednak zawartości pliku w sposób absolutny, dlatego przed rozpoczęciem odtwarzania trzeba ustalić, z jakiego silnika pochodzi kopia oraz jakim typem operacji została utworzona. W przypadku SQL Server kopia pełna bazy danych jest odtwarzana poleceniem RESTORE DATABASE. Taki plik może zawierać strukturę bazy, tabele, indeksy, procedury składowane oraz dane istniejące w chwili wykonania kopii.
Odtwarzanie nie polega na zwykłym rozpakowaniu pliku w Eksploratorze Windows. SQL Server odczytuje wewnętrzny format kopii, sprawdza jej nagłówki i zapisuje odtworzone pliki bazy, zwykle plik danych .mdf oraz pliki dziennika transakcji .ldf. Jeżeli kopia zawiera dodatkowe pliki danych, ich położenie również musi zostać prawidłowo określone. Próba otwarcia pliku .bak jako dokumentu albo zmiana jego rozszerzenia nie przywróci zawartości bazy.
Odczyt nagłówka i zawartości kopii
Przed właściwym odtworzeniem warto odczytać metadane kopii poleceniem RESTORE HEADERONLY. Wynik pozwala sprawdzić między innymi nazwę bazy źródłowej, typ kopii, czas jej wykonania, identyfikator zestawu kopii oraz informację, czy plik zawiera jeden czy kilka zestawów backupu. Gdy plik .bak jest kontenerem z wieloma kopiami, właściwy zestaw wybiera się za pomocą parametru FILE w poleceniu RESTORE DATABASE.
Drugim użytecznym poleceniem jest RESTORE FILELISTONLY. Zwraca ono logiczne i fizyczne nazwy plików bazy zapisanych w kopii. Te informacje są potrzebne, gdy pliki mają zostać zapisane w innej lokalizacji niż w systemie, z którego wykonano backup. W takim przypadku stosuje się klauzulę WITH MOVE, wskazując osobno docelowe ścieżki dla plików danych i dziennika. Pominięcie tego kroku może spowodować błąd, jeżeli oryginalne katalogi nie istnieją albo nie są dostępne na komputerze docelowym.
Przed rozpoczęciem operacji można sprawdzić, czy zestaw kopii jest możliwy do odczytania, używając RESTORE VERIFYONLY. Polecenie weryfikuje strukturę backupu w zakresie obsługiwanym przez SQL Server, ale nie zastępuje pełnego testowego odtworzenia. Kopia może być formalnie poprawna, a jednocześnie nie zawierać oczekiwanych danych, pochodzić z innej bazy lub być nieprzydatna bez wcześniejszych kopii wymaganych przez określony łańcuch backupów.
Przebieg polecenia RESTORE DATABASE
Najprostszy scenariusz dotyczy odtworzenia pełnej kopii do nowej bazy albo zastąpienia istniejącej bazy. Przykładowa forma polecenia wygląda następująco: RESTORE DATABASE NazwaBazy FROM DISK = 'D:\Backup\baza.bak' WITH RECOVERY. W praktyce nazwy, ścieżki i opcje trzeba dopasować do wyniku RESTORE FILELISTONLY. Jeżeli baza o tej samej nazwie jest używana przez inne połączenia, odtworzenie może wymagać zamknięcia aktywnych sesji.
Opcja WITH REPLACE pozwala zastąpić istniejącą bazę, ale jej użycie wymaga szczególnej ostrożności, ponieważ może nadpisać aktualne dane. Opcja WITH RECOVERY kończy sekwencję odtwarzania i udostępnia bazę użytkownikom. Jeżeli po pełnej kopii mają być odtwarzane kolejne kopie różnicowe lub dziennika transakcji, wcześniejsze operacje wykonuje się z WITH NORECOVERY. Dopiero ostatnie odtworzenie kończy się przez WITH RECOVERY. Błędne zakończenie zbyt wczesnym odzyskaniem może uniemożliwić zastosowanie kolejnych elementów łańcucha.
Po odtworzeniu należy sprawdzić stan bazy w SQL Server Management Studio albo innym narzędziu administracyjnym zgodnym z SQL Server. Kontroli wymagają między innymi dostępność tabel, aktualność danych, ścieżki plików, status dziennika transakcji oraz uprawnienia użytkowników. Loginy serwera nie są tym samym co użytkownicy zapisani wewnątrz bazy, dlatego po przeniesieniu bazy może wystąpić problem z niedopasowanymi identyfikatorami użytkowników i loginów. Sama obecność bazy w panelu SQL Server nie oznacza jeszcze, że aplikacja będzie mogła się z nią poprawnie połączyć.
Najczęstsze przyczyny nieudanego odtworzenia
Odtwarzanie pliku .bak może zakończyć się błędem, gdy kopia pochodzi z nowszej wersji SQL Server niż instancja docelowa. SQL Server nie obsługuje przywracania bazy do starszej wersji silnika. Problemem bywa również brak uprawnień konta usługi SQL Server do katalogu zawierającego plik kopii lub do folderów, w których mają powstać pliki .mdf i .ldf. Warto odróżnić uprawnienia osoby uruchamiającej narzędzie od uprawnień konta, pod którym działa usługa silnika.
Inne przyczyny to uszkodzenie pliku, niepełny transfer kopii, blokada istniejącej bazy, zajęte pliki danych, niezgodna ścieżka zapisu albo próba odtworzenia niepełnego zestawu backupów. Komunikaty SQL Server należy analizować razem z informacjami z RESTORE HEADERONLY i RESTORE FILELISTONLY, a nie wyłącznie na podstawie rozszerzenia pliku. W przypadku komputera używanego do pracy z lokalną bazą ważne jest wykonanie kopii obecnego stanu przed operacją zastępowania oraz potwierdzenie, że odtwarzany plik rzeczywiście odpowiada właściwej bazie. Warszawskie Pogotowie Komputerowe wykonuje profesjonalną naprawę laptopów, komputerów PC i ich podzespołów, w tym diagnostykę problemów z oprogramowaniem uruchamianym na komputerze użytkownika.
