Backup FILEGROUP

Backup FILEGROUP to kopia zapasowa obejmująca wyłącznie wybraną grupę plików bazy danych, a nie całą bazę.

Zakres kopii zapasowej FILEGROUP w SQL Server

Backup FILEGROUP w Microsoft SQL Server jest kopią zapasową określonej grupy plików należących do bazy danych. Filegroup może zawierać jeden lub wiele plików danych typu .mdf albo .ndf, natomiast plik dziennika transakcji .ldf nie należy do żadnej filegroup i jest zabezpieczany osobnym backupem logu. Kopia filegroup nie obejmuje automatycznie pozostałych grup plików, dlatego sama w sobie nie jest pełną kopią całej bazy.

Mechanizm wykorzystuje się przede wszystkim wtedy, gdy baza została logicznie podzielona na kilka obszarów danych. Przykładowo, osobna filegroup może przechowywać dane archiwalne, tabele o dużym rozmiarze albo indeksy. Administrator może wtedy wykonywać kopie wybranych grup plików, ograniczając zakres operacji do konkretnych danych. Taki podział wymaga jednak spójnego planu odtwarzania, ponieważ przywrócenie tylko jednej filegroup nie zastępuje zabezpieczenia pozostałych elementów bazy.

Tworzenie kopii filegroup poleceniem T-SQL

W SQL Server kopię określonej filegroup tworzy się poleceniem BACKUP DATABASE z klauzulą FILEGROUP. Przykładowe polecenie ma postać:

BACKUP DATABASE [Firma] FILEGROUP = N'DaneArchiwalne' TO DISK = N'D:\Backup\Firma_DaneArchiwalne.bak' WITH INIT, CHECKSUM, STATS = 10;

Nazwa podana po FILEGROUP = musi odpowiadać rzeczywistej nazwie grupy plików w danej bazie. Opcja CHECKSUM powoduje wykonywanie kontroli sum kontrolnych podczas tworzenia kopii, o ile środowisko i ustawienia SQL Server pozwalają na jej użycie. Parametr STATS = 10 wyświetla postęp co dziesięć procent, a INIT zastępuje zawartość wskazanego zestawu kopii na urządzeniu docelowym, dlatego powinien być stosowany tylko wtedy, gdy nadpisanie jest zamierzone. Przed wykonaniem kopii warto sprawdzić nazwy filegroup w widokach katalogowych, na przykład przez zapytanie do sys.filegroups.

Powiązanie backupu FILEGROUP z dziennikiem transakcji

Odtworzenie kopii filegroup wymaga zachowania właściwej kolejności kopii. SQL Server musi znać stan transakcji dotyczących przywracanej grupy plików, dlatego w typowym scenariuszu potrzebna jest odpowiednia pełna kopia bazy, kopia filegroup oraz ciąg kopii dziennika transakcji obejmujący okres od wykonania kopii danych do momentu, w którym baza ma zostać odtworzona. Przy modelu odzyskiwania FULL lub BULK_LOGGED backupy logu pozwalają odtworzyć zmiany z określonego przedziału czasu. W modelu SIMPLE dziennik nie jest archiwizowany poleceniem BACKUP LOG, więc nie można wykorzystać pełnego odtwarzania do dowolnego punktu w czasie w taki sam sposób.

Przywracanie grup plików może być wykonywane jako odtwarzanie częściowe, na przykład poleceniem RESTORE DATABASE z klauzulą FILEGROUP. Po przywróceniu kopii danych zwykle stosuje się kolejne operacje RESTORE LOG, aby doprowadzić przywracaną filegroup do zgodnego punktu w historii bazy. Jeżeli przywracana grupa jest oznaczona jako READ_ONLY, jej zawartość zmienia się rzadziej, co może ograniczyć częstotliwość wykonywania kolejnych kopii tej grupy. Nie oznacza to jednak, że można pominąć zabezpieczenie metadanych bazy, pozostałych filegroup ani dziennika transakcji.

Weryfikacja kopii i plan odtwarzania danych

Samo pomyślne zakończenie polecenia backupu nie dowodzi jeszcze, że cała procedura awaryjna działa. Kopię FILEGROUP należy okresowo sprawdzać poleceniem RESTORE VERIFYONLY, które weryfikuje możliwość odczytu struktury zestawu kopii, ale nie zastępuje pełnego testowego odtworzenia. Rzeczywisty test powinien obejmować przywrócenie kopii na odseparowanym środowisku, zastosowanie wymaganych kopii dziennika oraz sprawdzenie, czy baza i obiekty znajdujące się w danej filegroup są dostępne.

Ważne jest również udokumentowanie mapowania plików na filegroup, lokalizacji urządzeń backupu, haseł lub certyfikatów używanych do szyfrowania kopii oraz wymaganej sekwencji poleceń RESTORE. Przy odtwarzaniu należy zweryfikować, czy docelowe ścieżki plików istnieją i mają odpowiednie uprawnienia. W przypadku bazy podzielonej na wiele filegroup plan powinien wskazywać, które grupy są krytyczne dla uruchomienia aplikacji, a które mogą zostać odtworzone później. Backup FILEGROUP jest więc elementem strategii odzyskiwania SQL Server, a nie niezależnym zamiennikiem pełnej kopii bazy.