Backup do pliku z rozszerzeniem .bak to standardowa forma zapisu kopii zapasowej bazy danych SQL Server.
Co oznacza plik .bak w SQL Server
Plik z rozszerzeniem .bak jest typowym plikiem kopii zapasowej utworzonej przez Microsoft SQL Server. Rozszerzenie nie jest jednak mechanizmem technicznym ani warunkiem rozpoznawania kopii przez silnik. O rodzaju pliku decyduje zawartość zapisana przez polecenie backupu, a nie sam przyrostek nazwy. Najczęściej plik .bak zawiera pełną kopię bazy danych wykonaną instrukcją BACKUP DATABASE. Taki backup obejmuje dane zapisane w plikach bazy oraz informacje potrzebne do odtworzenia struktury i stanu bazy w momencie wykonywania kopii.
SQL Server może zapisać w pliku .bak również kopię różnicową bazy albo kopię dziennika transakcji. Pełny backup stanowi punkt odniesienia dla późniejszych kopii różnicowych, natomiast backup dziennika jest elementem łańcucha logów i służy do odtwarzania zmian po wykonaniu pełnej kopii. Z tego powodu sama nazwa pliku, na przykład firma_2026-08-24.bak, nie wystarcza do określenia jego zawartości. Informacje o typie kopii można odczytać w SQL Server za pomocą polecenia RESTORE HEADERONLY.
Tworzenie kopii i elementy łańcucha odtwarzania
Pełną kopię bazy SQL Server tworzy się poleceniem BACKUP DATABASE z klauzulą TO DISK. Przykładowa instrukcja ma postać BACKUP DATABASE [Sklep] TO DISK = N'D:\Backup\Sklep_full.bak' WITH INIT, CHECKSUM, COMPRESSION. Opcja COMPRESSION powoduje kompresowanie kopii przez silnik, o ile konfiguracja i edycja SQL Server na to pozwalają. CHECKSUM umożliwia wykonywanie i weryfikowanie sum kontrolnych stron danych podczas operacji backupu. Opcja INIT nadpisuje istniejący zestaw kopii na wskazanym urządzeniu, dlatego jej użycie wymaga pewności, że wcześniejsze dane nie są już potrzebne.
Backup różnicowy zawiera zmiany od ostatniego pełnego backupu, a nie od poprzedniej kopii różnicowej. W instrukcji używa się wtedy BACKUP DATABASE [Sklep] TO DISK = N'D:\Backup\Sklep_diff.bak' WITH DIFFERENTIAL. Kopia dziennika transakcji jest wykonywana poleceniem BACKUP LOG, ale wymaga modelu odzyskiwania FULL albo BULK_LOGGED; w modelu SIMPLE regularne backupy dziennika nie tworzą ciągłego łańcucha do odtwarzania punktu w czasie. Aby odtworzyć bazę z pełnego backupu, kopii różnicowej i logów, należy zachować właściwą kolejność oraz wszystkie wymagane elementy łańcucha.
Sprawdzanie integralności przed przywróceniem
Przed użyciem pliku .bak warto sprawdzić, czy SQL Server może odczytać jego strukturę. Polecenie RESTORE VERIFYONLY FROM DISK = N'D:\Backup\Sklep_full.bak' wykonuje kontrolę kopii bez odtwarzania bazy. Nie jest to pełny dowód, że każdy zapisany fragment danych jest wolny od uszkodzeń, ale pozwala wykryć część problemów z formatem backupu i jego kompletnością. Jeżeli podczas tworzenia kopii użyto CHECKSUM, można dodatkowo zażądać weryfikacji sum kontrolnych podczas operacji przywracania.
Do ustalenia logicznych nazw plików znajdujących się w kopii służy RESTORE FILELISTONLY. Jest to istotne, gdy baza ma zostać odtworzona pod inną ścieżką albo na innym serwerze. Polecenie RESTORE HEADERONLY pokazuje między innymi typ backupu, czas rozpoczęcia i zakończenia, identyfikator bazy oraz informacje o zestawie nośnika. Przy odtwarzaniu można użyć RESTORE DATABASE z klauzulą WITH MOVE, aby wskazać nowe lokalizacje plików danych i dziennika. Jeżeli do jednego pliku dopisywano kilka kopii, konieczne może być wskazanie numeru zestawu za pomocą FILE.
Plik .bak a praktyczne odtwarzanie bazy
Przywracanie pełnej kopii zwykle rozpoczyna się od polecenia RESTORE DATABASE. Jeżeli po pełnym backupie ma zostać zastosowana kopia różnicowa lub kolejne backupy dziennika, pełny etap odtwarzania wykonuje się z opcją WITH NORECOVERY. Dzięki temu baza pozostaje w stanie oczekiwania na następne kopie. Ostatni etap kończy się poleceniem z WITH RECOVERY, które udostępnia bazę użytkownikom. Jeżeli kopia ma służyć wyłącznie do odczytu lub testu, można przywrócić ją pod inną nazwą i użyć odrębnych ścieżek plików.
Do jednorazowej kopii wykonywanej poza podstawowym harmonogramem służy opcja COPY_ONLY. Kopia pełna typu copy-only nie zmienia podstawy, od której liczone są późniejsze backupy różnicowe. Ma to znaczenie podczas doraźnego zabezpieczania bazy przed zmianą konfiguracji, migracją lub testowym odtworzeniem. Samo posiadanie pliku .bak nie gwarantuje możliwości odzyskania danych: trzeba znać wersję SQL Server, typ kopii, kolejność backupów, lokalizację plików oraz hasła lub uprawnienia wymagane do odczytu. W praktyce poprawność kopii potwierdza się przez okresowe odtworzenie jej na środowisku testowym i sprawdzenie, czy baza uruchamia się oraz zawiera oczekiwane dane.
