FILEGROUP Backup

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

FILEGROUP Backup w SQL Server

FILEGROUP Backup to kopia zapasowa wybranej grupy plików w bazie Microsoft SQL Server. Grupa plików, czyli filegroup, jest logicznym zbiorem plików danych typu .mdf lub .ndf. W przeciwieństwie do pełnej kopii zapasowej bazy taki backup nie obejmuje automatycznie wszystkich filegroupów. Administrator wskazuje konkretną grupę, której dane mają zostać zapisane w pliku kopii.

Przykładowe wykonanie kopii grupy plików może wyglądać tak: BACKUP DATABASE [Sklep] FILEGROUP = N'DaneArchiwalne' TO DISK = N'D:\Backup\Sklep_DaneArchiwalne.bak' WITH INIT, CHECKSUM, STATS = 10;. Nazwa DaneArchiwalne musi odpowiadać istniejącej grupie plików w bazie Sklep. Polecenie dotyczy SQL Server i nie jest składnią przeznaczoną dla PostgreSQL, MySQL ani Oracle.

Kiedy kopia pojedynczego filegroup ma zastosowanie

Backup filegroup jest użyteczny w bazach, których dane zostały rozdzielone na kilka grup plików, na przykład według okresu przechowywania, rodzaju tabel albo wymagań dotyczących nośników. Można w ten sposób ograniczyć zakres operacji kopiowania, gdy nie każda część bazy zmienia się z taką samą częstotliwością. Sama obecność wielu filegroupów nie oznacza jednak, że pojedyncza kopia wystarczy do odtworzenia całej bazy.

Podczas planowania backupu trzeba ustalić, czy wszystkie filegroupy będą objęte strategią kopii oraz jak zostanie zachowana spójność między nimi. Pełne odtworzenie bazy może wymagać kopii bazowej, kopii poszczególnych grup plików, a także kolejnych kopii różnicowych i dziennika transakcji. Filegroup zawierający tylko część tabel nadal może być zależny od obiektów lub danych znajdujących się w innych grupach, dlatego zakres backupu powinien wynikać z projektu bazy, a nie wyłącznie z rozmiaru pliku.

Wykonanie, kontrola i odtwarzanie kopii grupy plików

Przed wykonaniem kopii warto sprawdzić nazwy grup oraz przypisane do nich pliki za pomocą widoków katalogowych SQL Server, takich jak sys.filegroups i sys.database_files. Po utworzeniu backupu można użyć polecenia RESTORE VERIFYONLY, aby sprawdzić, czy zestaw kopii ma poprawny format i może zostać odczytany przez SQL Server. Taka kontrola nie zastępuje próbnego odtworzenia, ponieważ nie potwierdza kompletności całej procedury odzyskiwania ani poprawności danych aplikacyjnych.

Odtwarzanie wykonuje się poleceniami z rodziny RESTORE DATABASE lub RESTORE LOG, zależnie od rodzaju kopii i przyjętego scenariusza. Jeżeli baza jest odtwarzana etapami, administrator musi zachować właściwą kolejność kopii oraz stosować odpowiednie opcje NORECOVERY i RECOVERY. NORECOVERY pozostawia bazę w stanie oczekiwania na następne kopie, natomiast RECOVERY kończy sekwencję przywracania i udostępnia bazę do pracy. W przypadku dużych baz SQL Server może obsługiwać odtwarzanie wybranych grup plików, ale pozostała część bazy musi znajdować się w stanie zgodnym z wymaganiami konkretnego planu odzyskiwania.

W modelu odzyskiwania FULL lub BULK_LOGGED kopie dziennika transakcji mogą być potrzebne do odtworzenia zmian wykonanych po utworzeniu kopii filegroup. W modelu SIMPLE dziennik nie jest archiwizowany za pomocą backupów logu, więc dostępne możliwości odtwarzania do określonego momentu są ograniczone. Po zakończeniu procedury należy sprawdzić stan wszystkich filegroupów, dostępność tabel i indeksów oraz zgodność danych z wymaganiami aplikacji.

Znaczenie FILEGROUP Backup w diagnostyce środowiska SQL Server

Problemy z kopią grupy plików mogą wynikać z błędnej nazwy filegroup, braku dostępu konta usługi SQL Server do katalogu docelowego, niewystarczającego miejsca na dysku albo niespójnej sekwencji backupów. Komunikat o pominięciu pliku lub grupy plików należy interpretować razem z historią operacji w SQL Server. Przydatne są również informacje o rozmiarze plików, stanie bazy, modelu odzyskiwania i czasie wykonania ostatnich kopii.

Podczas analizy awarii nie należy usuwać istniejących plików .bak ani nadpisywać ich bez potwierdzenia, że zachowano wymaganą kopię bazową i kolejne elementy łańcucha odzyskiwania. Należy także zweryfikować, czy backup został zapisany lokalnie, na udziale sieciowym lub na innym urządzeniu oraz czy ścieżka będzie dostępna w czasie odtwarzania. Dobrą praktyką jest cykliczne odtwarzanie kopii na odizolowanej instancji testowej, sprawdzenie integralności bazy poleceniem DBCC CHECKDB oraz zmierzenie rzeczywistego czasu przywracania.

FILEGROUP Backup jest funkcją administracyjną SQL Server, dlatego jej poprawna obsługa wymaga znajomości struktury konkretnej bazy, zależności między filegroupami i obowiązującego planu odzyskiwania. W środowisku produkcyjnym każda kopia powinna mieć opis obejmujący nazwę bazy, nazwę grupy plików, czas wykonania oraz powiązane kopie dziennika transakcji. Dopiero taki zestaw informacji pozwala ocenić, czy backup można wykorzystać w rzeczywistym scenariuszu awarii.