FILESTREAM a kopie zapasowe

FILESTREAM a kopie zapasowe opisuje specyfikę wykonywania backupu baz zawierających dane przechowywane w tym mechanizmie.

Jak FILESTREAM zmienia zakres kopii zapasowej bazy SQL Server

FILESTREAM jest mechanizmem SQL Server, który pozwala przechowywać zawartość obiektów typu varbinary(max) poza klasycznymi stronami danych, w specjalnym kontenerze systemu plików powiązanym z grupą plików FILESTREAM. Dla aplikacji dane nadal należą do bazy i są obsługiwane przez SQL Server, nawet jeżeli ich fizyczna zawartość znajduje się w katalogu kontenera FILESTREAM. Ta zależność ma zasadnicze znaczenie przy tworzeniu kopii zapasowej: backup bazy musi obejmować zarówno zwykłe pliki danych i dziennik transakcji, jak i grupy plików zawierające dane FILESTREAM.

Nie jest prawidłową kopią zapasową samo skopiowanie katalogu FILESTREAM w Eksploratorze Windows. Kontener jest zarządzany przez SQL Server, a jego zawartość musi pozostać zgodna z metadanymi bazy, strukturą grup plików oraz stanem transakcji. Niezależna kopia plików może nie zawierać zmian zatwierdzonych w dzienniku albo może obejmować pliki w stanie niespójnym względem bazy. Przy odtwarzaniu taki zestaw nie zastępuje kopii wykonanej poleceniem BACKUP DATABASE i odpowiednich kopii dziennika transakcji.

Pełny, różnicowy i dziennikowy backup danych FILESTREAM

Pełna kopia bazy SQL Server obejmuje wszystkie grupy plików należące do bazy, w tym FILESTREAM filegroup, o ile nie zastosowano szczególnego scenariusza backupu częściowego lub kopii wybranych grup plików. W typowym poleceniu BACKUP DATABASE nazwa_bazy TO DISK = ... dane FILESTREAM są zapisywane w strumieniu kopii razem z pozostałymi składnikami bazy. Podczas planowania miejsca na backup trzeba więc uwzględnić rzeczywisty rozmiar przechowywanych obiektów FILESTREAM, a nie tylko rozmiar plików MDF i NDF.

Kopia różnicowa zawiera zmiany wprowadzone od ostatniej pełnej kopii bazy, również w zakresie odpowiednich grup plików FILESTREAM. Jeżeli baza korzysta z modelu odzyskiwania pełnego albo bulk-logged, kopie dziennika transakcji rejestrują zmiany potrzebne do odtworzenia kolejnych operacji, natomiast w modelu simple backup dziennika nie jest dostępny. Sam backup dziennika nie stanowi niezależnej kopii początkowej: odtworzenie wymaga odpowiedniej pełnej kopii bazy, a w razie używania kopii różnicowej także zachowania właściwej kolejności i punktu odniesienia.

Warto rozdzielić ochronę danych od ochrony konfiguracji. Backup SQL Server obejmuje zawartość bazy, ale nie zastępuje kopii konfiguracji instancji, zadań SQL Server Agent, certyfikatów, kluczy szyfrujących ani ustawień aplikacji. Jeżeli FILESTREAM jest używany przez aplikację korzystającą z transakcyjnego dostępu do plików, odtworzenie bazy musi być połączone z poprawnym odtworzeniem środowiska SQL Server i konfiguracji wymaganej do ponownego dostępu do danych.

Spójność transakcyjna i kolejność odtwarzania

Najważniejszą cechą backupu wykonywanego przez SQL Server jest spójność względem transakcji. Mechanizm uwzględnia zależności pomiędzy metadanymi w bazie, stronami danych, dziennikiem oraz zawartością FILESTREAM. Oznacza to, że procedura powinna korzystać z poleceń SQL Server i z narzędzi rozumiejących format kopii, a nie z ręcznego kopiowania plików kontenera. Szczególnie istotne jest to przy równoczesnych zapisach dużych obiektów binarnych, zmianach metadanych i operacjach usuwania.

Przy pełnym odtwarzaniu najpierw przywraca się pełną kopię bazy z opcją NORECOVERY, następnie ewentualną kopię różnicową, a na końcu kolejne kopie dziennika transakcji. Ostatni etap wykonuje się z RECOVERY, gdy nie będzie już stosowany następny backup logu. SQL Server odtwarza wtedy również dane z grupy FILESTREAM. Przerwanie łańcucha kopii, użycie niepasującej kopii różnicowej albo pominięcie wymaganej kopii dziennika może uniemożliwić osiągnięcie oczekiwanego punktu odzyskiwania.

Po odtworzeniu należy sprawdzić stan bazy, dostęp aplikacji do obiektów FILESTREAM oraz możliwość odczytu i zapisu przykładowych danych. Polecenie RESTORE VERIFYONLY może pomóc ocenić, czy zestaw backupu ma poprawną strukturę i może zostać odczytany jako kopia, ale nie zastępuje testowego odtworzenia na osobnym środowisku. Dopiero próba przywrócenia bazy i odczytu rzeczywistych obiektów FILESTREAM potwierdza, że procedura odzyskiwania działa praktycznie.

Kontrola procedury backupu w środowisku SQL Server

W dokumentacji procedury warto zapisać, które grupy plików zawiera baza, gdzie są przechowywane kopie, jak długo zachowywany jest łańcuch backupów oraz jaki punkt w czasie ma być możliwy do odtworzenia. Trzeba także monitorować powodzenie zadań backupu, dostępne miejsce na urządzeniu docelowym i zgodność harmonogramu kopii pełnych, różnicowych oraz dziennika transakcji. Dla baz z dużą ilością danych FILESTREAM szczególne znaczenie ma kontrola wzrostu rozmiaru kopii i czasu jej wykonania.

Analiza kopii baz danych FILESTREAM wymaga pracy w środowisku SQL Server oraz dostępu do właściwej konfiguracji instancji. Przy diagnozie komputera można sprawdzić stan dysków, błędy systemu plików, dostępne miejsce i działanie nośnika, ponieważ awaria sprzętu może przerwać zadanie backupu lub uszkodzić lokalny cel zapisu. Sama ocena poprawności strategii tworzenia i odtwarzania kopii powinna jednak opierać się na logach SQL Server, historii zadań oraz kontrolowanym teście restore.