Restore FILEGROUP

Restore FILEGROUP przywraca wybraną grupę plików bazy, przydatne przy odtwarzaniu wyłącznie jej fragmentu.

Rola FILEGROUP w strukturze bazy SQL Server

Restore FILEGROUP oznacza przywrócenie określonej grupy plików w bazie danych Microsoft SQL Server. Filegroup jest logicznym kontenerem dla jednego lub większej liczby plików danych, najczęściej plików typu .mdf i .ndf. Każda baza SQL Server ma podstawową grupę plików PRIMARY, a administrator może utworzyć kolejne grupy, aby rozdzielać dane według tabel, indeksów, działów aplikacji albo sposobu eksploatacji. Sama grupa nie jest pojedynczym plikiem systemu Windows; wskazuje zestaw plików danych zarządzanych przez silnik bazy.

Przywracanie filegroup służy do odtworzenia tylko wybranej części bazy, gdy pozostałe dane są dostępne i nie wymagają pełnego odtwarzania. Taki scenariusz może dotyczyć uszkodzenia dysku zawierającego pliki jednej grupy, przypadkowego usunięcia pliku danych albo planowego odtwarzania dużej bazy etapami. Operacja wymaga jednak wcześniejszego przygotowania kopii zapasowych filegroup oraz zachowania zgodności z pozostałą częścią bazy. Nie jest to mechanizm eksportu wybranych tabel do nowej bazy ani sposób na przywrócenie dowolnego fragmentu danych bez odtwarzania struktur zależnych.

Kopie zapasowe potrzebne do odtworzenia grupy plików

SQL Server tworzy kopie zapasowe filegroup za pomocą instrukcji BACKUP DATABASE z klauzulą FILEGROUP, na przykład BACKUP DATABASE [Baza] FILEGROUP = N'DaneArchiwalne' TO DISK = N'D:\Backup\DaneArchiwalne.bak'. Nazwa filegroup musi dokładnie odpowiadać nazwie z metadanych bazy. W praktyce przed odtwarzaniem należy ustalić układ plików poleceniem opartym na widoku sys.database_files oraz sprawdzić historię kopii w msdb, między innymi w tabelach backupset i backupfile.

Odtworzenie nie kończy się na wczytaniu jednej kopii filegroup. Zależnie od konfiguracji potrzebna jest także właściwa kopia pełna bazy, kopia różnicowa obejmująca dany plik lub filegroup oraz kolejne kopie dziennika transakcji. SQL Server musi odtworzyć zmiany zapisane w dzienniku od momentu wykonania kopii plików do określonego punktu w czasie. Dlatego kopie dziennika muszą tworzyć nieprzerwany łańcuch, a ich kolejność trzeba zachować. Przed rozpoczęciem pracy warto użyć RESTORE VERIFYONLY do sprawdzenia, czy plik kopii może zostać odczytany, ale polecenie to nie zastępuje testowego odtworzenia.

Możliwość użycia określonego scenariusza zależy między innymi od modelu odzyskiwania bazy. Pełne odtwarzanie z wykorzystaniem kopii dziennika wymaga modelu FULL albo BULK_LOGGED, natomiast model SIMPLE nie zapewnia kopii dziennika transakcji do odtwarzania punktowego. Zmiana modelu odzyskiwania nie tworzy wstecznie brakującego łańcucha logów. Po przełączeniu na pełny model trzeba wykonać pełną lub różnicową kopię bazy zgodnie z przyjętą procedurą, aby rozpocząć prawidłowe zarządzanie nowym łańcuchem kopii dziennika.

Przebieg RESTORE FILEGROUP i stan bazy

Podstawowa instrukcja ma postać RESTORE DATABASE [Baza] FILEGROUP = N'DaneArchiwalne' FROM DISK = N'D:\Backup\DaneArchiwalne.bak' WITH NORECOVERY. Klauzula NORECOVERY pozostawia bazę w stanie odtwarzania, dzięki czemu można zastosować następne kopie, w tym kolejne kopie filegroup lub dziennika transakcji. Na końcu sekwencji używa się WITH RECOVERY, które wykonuje fazę odzyskiwania i udostępnia bazę użytkownikom. Jeżeli pośrednie kopie nie są już potrzebne, zakończenie odtwarzania zbyt wcześnie może uniemożliwić zastosowanie wymaganych kopii dziennika.

W wielu procedurach przydatne są także opcje STANDBY, REPLACE i STOPAT, ale każda z nich ma określone zastosowanie. STOPAT pozwala wskazać punkt w czasie dla odtwarzania dziennika, pod warunkiem że żądany moment mieści się w dostępnych kopiach. STANDBY umożliwia czasowy dostęp tylko do odczytu między kolejnymi etapami przywracania, lecz wymaga pliku cofania zmian i nie jest zamiennikiem końcowego RECOVERY. REPLACE może nadpisać istniejące pliki i dlatego powinno być stosowane wyłącznie po sprawdzeniu ścieżek oraz tożsamości docelowej bazy.

Po przywróceniu filegroup baza może nadal pozostawać niedostępna, jeśli odtworzona grupa nie została doprowadzona do spójnego punktu razem z pozostałymi grupami. SQL Server obsługuje także piecemeal restore, czyli etapowe odtwarzanie bazy, w którym najpierw przywraca się grupę PRIMARY, a następnie pozostałe filegroup. Dotyczy to dużych baz i wymaga zaplanowania zależności pomiędzy obiektami. Tabele lub indeksy korzystające z niedostępnej grupy mogą nie być używalne do czasu zakończenia odpowiedniego etapu. Po odtworzeniu należy sprawdzić stan plików w widoku sys.master_files lub sys.database_files oraz wykonać kontrolę spójności poleceniem DBCC CHECKDB, gdy baza jest w stanie umożliwiającym jego uruchomienie.

Praktyczne znaczenie dla awarii nośnika i weryfikacji danych

Restore FILEGROUP ma sens wtedy, gdy zakres awarii został dokładnie określony, a pozostałe pliki bazy są dostępne i zgodne z planem odtwarzania. Przed wykonaniem operacji administrator powinien zidentyfikować nazwę uszkodzonej grupy, jej pliki fizyczne, ostatnią poprawną kopię filegroup oraz kompletny zestaw późniejszych kopii dziennika. Trzeba też upewnić się, że docelowe ścieżki istnieją i mają wystarczającą ilość miejsca. W przypadku zmiany lokalizacji plików można użyć klauzuli MOVE, na przykład WITH MOVE N'DaneArchiwalne' TO N'E:\SQLData\DaneArchiwalne.ndf', jeżeli logiczna nazwa pliku odpowiada rzeczywistej zawartości kopii.

Po zakończeniu odtwarzania warto zweryfikować dostęp do obiektów korzystających z przywróconej grupy, wykonać kontrolę spójności oraz porównać kluczowe dane z dokumentacją lub innym niezależnym źródłem. Należy również odtworzyć uprawnienia, zadania agenta SQL Server i konfigurację aplikacji tylko wtedy, gdy zostały objęte osobną procedurą — kopia filegroup przechowuje dane i struktury należące do tej grupy, ale nie zastępuje pełnej kopii konfiguracji instancji. W środowisku produkcyjnym procedurę powinno się najpierw przećwiczyć na kopii testowej, mierząc czas odtworzenia i potwierdzając, że aplikacja prawidłowo obsługuje czasową niedostępność wybranych obiektów.