Backup File (.bak)

Backup File z rozszerzeniem .bak to plik zawierający zapisaną kopię zapasową bazy danych SQL Server.

Czym jest plik Backup File (.bak) w SQL Server

Plik z rozszerzeniem .bak jest najczęściej plikiem kopii zapasowej utworzonym przez Microsoft SQL Server. Rozszerzenie wskazuje zwyczajowo na backup, ale samo w sobie nie jest gwarancją zawartości, ponieważ SQL Server może zapisywać kopie także do plików o innych nazwach i rozszerzeniach. O tym, czy plik jest poprawnym backupem SQL Server, decyduje jego wewnętrzny format oraz możliwość odczytania nagłówka przez silnik bazy danych.

Kopia zapasowa nie jest zwykłym eksportem tabel do pliku tekstowego ani kopią pliku bazy danych MDF. Zawiera dane zapisane w formacie obsługiwanym przez mechanizm backupu i przywracania SQL Server. W zależności od rodzaju operacji może obejmować całą bazę, zmienione od czasu pełnej kopii extent'y danych albo fragment dziennika transakcji. Pliku .bak nie otwiera się więc bezpośrednio w edytorze tekstu i nie należy go traktować jak bazy gotowej do uruchomienia.

Rodzaje kopii zapisywanych w pliku

Pełna kopia bazy danych obejmuje jej dane oraz informacje potrzebne do odtworzenia struktury bazy. Taki backup stanowi podstawę wielu scenariuszy odzyskiwania. Kopia różnicowa zawiera zmiany wykonane od czasu ostatniej pełnej kopii. Do odtworzenia aktualnego stanu potrzebna jest najpierw odpowiednia pełna kopia, a następnie najnowsza kopia różnicowa oparta na tej samej bazie. SQL Server zapisuje w metadanych backupu informacje pozwalające rozpoznać typ kopii i jej zależności.

Kopia dziennika transakcji obejmuje rekordy logu potrzebne do odtworzenia zmian z określonego przedziału czasu. Przy prawidłowo utrzymanym modelu odzyskiwania może pozwolić na odtworzenie bazy do konkretnego momentu, ale wymaga zachowania ciągłości łańcucha logów. Nie każda kopia z rozszerzeniem .bak musi być pełnym backupem: rozszerzenie nie opisuje rodzaju kopii, dlatego przed użyciem trzeba sprawdzić jej nagłówki i zestaw backupów zapisanych w nośniku.

Sprawdzanie i przywracanie kopii SQL Server

Podstawowe informacje o pliku można odczytać za pomocą instrukcji RESTORE HEADERONLY. Pozwala ona sprawdzić między innymi typ backupu, nazwę bazy źródłowej, czas wykonania, identyfikator zestawu oraz informacje o nośniku. Instrukcja RESTORE FILELISTONLY pokazuje logiczne i fizyczne nazwy plików bazy zapisane w kopii. Dzięki temu można ustalić, jakie pliki zostaną odtworzone i przygotować ich docelowe ścieżki, zwłaszcza gdy kopia pochodzi z innego komputera.

Do wstępnej kontroli czytelności kopii służy RESTORE VERIFYONLY. Polecenie sprawdza, czy zestaw backupu jest kompletny i możliwy do odczytania przez SQL Server, ale nie zastępuje rzeczywistego testowego odtworzenia. Kopia może przejść weryfikację, a mimo to okazać się nieprzydatna w konkretnym środowisku z powodu braku kolejnych kopii różnicowych lub logów, niezgodnych ścieżek plików, braku miejsca albo problemów z uprawnieniami. Najbardziej wiarygodnym testem jest przywrócenie kopii do odrębnej bazy i sprawdzenie jej spójności oraz działania wymaganych obiektów.

Przywracanie pełnej kopii wykonuje się instrukcją RESTORE DATABASE, natomiast kopie dziennika odtwarza się za pomocą RESTORE LOG. Jeżeli po pełnym backupie ma zostać zastosowana kopia różnicowa lub kolejne logi, wcześniejsze etapy muszą zostać pozostawione w stanie umożliwiającym dalsze przywracanie. W praktyce oznacza to użycie opcji NORECOVERY do czasu zastosowania ostatniego elementu sekwencji, a następnie zakończenie procedury opcją RECOVERY. Zawsze należy zachować kolejność wynikającą z metadanych backupów, a nie tylko z nazw plików w katalogu.

Znaczenie pliku .bak podczas diagnostyki awarii

Plik .bak może być potrzebny po uszkodzeniu dysku, błędzie systemu plików, nieudanej aktualizacji aplikacji korzystającej z SQL Server albo przypadkowym usunięciu danych. Samo posiadanie pliku nie potwierdza jednak, że możliwe jest pełne odzyskanie informacji. Należy ustalić datę wykonania kopii, jej zakres, dostępność kopii różnicowych i dzienników transakcji oraz zgodność wersji i konfiguracji środowiska, w którym ma nastąpić odtworzenie. Istotne są również rozmiar pliku i wynik odczytu nagłówka, ponieważ bardzo mały lub przerwany plik może wskazywać na nieudaną operację.

Przy analizie problemu nie powinno się nadpisywać oryginalnego backupu ani wykonywać eksperymentów na jedynej dostępnej kopii. Bezpieczniej pracować na kopii pliku, a odtwarzanie prowadzić do osobnej lokalizacji z kontrolą wolnego miejsca i ścieżek plików. Jeżeli baza po przywróceniu zgłasza błędy, można uruchomić kontrolę spójności odpowiednią dla SQL Server, ale polecenia naprawcze wymagają szczególnej ostrożności, ponieważ mogą powodować utratę części danych. Najpierw należy zabezpieczyć kopię i ustalić, czy problem dotyczy backupu, nośnika, plików bazy czy samego środowiska SQL Server.

Dobrze prowadzona procedura obejmuje okresowe testy odtwarzania, przechowywanie kilku niezależnych punktów przywracania oraz dokumentowanie kolejności kopii. Warto także rozdzielić lokalizację działającej bazy od lokalizacji backupów, aby awaria jednego urządzenia nie usunęła obu źródeł. Plik .bak jest więc elementem procesu odzyskiwania, a nie samodzielnym zabezpieczeniem: jego użyteczność zależy od poprawnego wykonania, zachowania wymaganej sekwencji i potwierdzenia, że kopię można rzeczywiście odtworzyć.