Odzyskiwanie danych z pliku strumieniowego (FILESTREAM)

Odzyskiwanie danych FILESTREAM wymaga przywrócenia zarówno bazy, jak i katalogu z powiązanymi plikami.

Jak działa FILESTREAM w SQL Server

FILESTREAM jest funkcją Microsoft SQL Server przeznaczoną do przechowywania dużych danych binarnych, takich jak dokumenty, obrazy, nagrania lub archiwa, poza klasycznymi stronami danych bazy, przy zachowaniu powiązania z rekordami tabeli. W tabeli znajduje się kolumna typu varbinary(max) FILESTREAM, a właściwe bajty są zapisywane w specjalnym kontenerze należącym do grupy plików FILESTREAM. Rekord zawiera identyfikator i metadane pozwalające silnikowi powiązać zawartość pliku z odpowiednim wierszem.

Odzyskiwanie danych nie polega więc na skopiowaniu pojedynczego pliku z katalogu systemu Windows. Kontener FILESTREAM jest zarządzany przez SQL Server i nie powinien być modyfikowany, przenoszony ani uzupełniany ręcznie. Zawartość musi pozostać zgodna ze stanem tabel, metadanymi bazy i dziennikiem transakcji. Samodzielne kopiowanie plików z kontenera może doprowadzić do niespójności, której zwykłe podłączenie katalogu do innej instancji nie naprawi.

Co obejmuje kopia zapasowa

Prawidłowo wykonana kopia zapasowa bazy SQL Server obejmuje także pliki należące do grupy plików FILESTREAM. Przy odtwarzaniu potrzebny jest zatem backup bazy oraz, jeżeli celem jest odzyskanie najnowszego możliwego stanu, odpowiedni łańcuch kopii dziennika transakcji. Kopia pełna ustanawia punkt bazowy, a kolejne backupy logu pozwalają odtworzyć zatwierdzone zmiany wykonane po tym punkcie. W przypadku kopii różnicowej można ją zastosować jako etap pośredni, o ile jest związana z właściwą kopią pełną.

Przed rozpoczęciem operacji należy ustalić, czy uszkodzeniu uległa sama baza, pliki danych, dziennik, wolumin zawierający kontener FILESTREAM, czy tylko system operacyjny. Istotne są również informacje o wersji SQL Server, nazwie bazy, lokalizacji plików oraz dostępnych zestawach backupów. Kopia bazy bez zawartości FILESTREAM, niekompletny zestaw plików albo backup wykonany po utracie części kontenera nie zapewni pełnego odzyskania. Weryfikacja kopii przez SQL Server, między innymi poleceniem RESTORE VERIFYONLY, może potwierdzić możliwość odczytu nośnika, ale nie zastępuje testowego odtworzenia i sprawdzenia danych.

Jeżeli organizacja używa backupu częściowego lub kopii poszczególnych grup plików, trzeba sprawdzić, czy obejmuje ona grupę FILESTREAM. Odtwarzanie wybranej grupy plików jest procedurą zależną od stanu całej bazy i wymaga zachowania zgodności z dziennikiem transakcji. Nie należy zakładać, że backup standardowych plików MDF i NDF wystarczy do odtworzenia obiektów przechowywanych przez FILESTREAM.

Przebieg odtwarzania i kontrola spójności

Odtwarzanie wykonuje się w SQL Server za pomocą instrukcji RESTORE DATABASE, a kolejne kopie dziennika przy użyciu RESTORE LOG. Podczas odtwarzania można użyć opcji WITH MOVE, aby wskazać nowe lokalizacje dla plików bazy oraz kontenera FILESTREAM, jeśli pierwotny wolumin jest niedostępny albo dane mają trafić na inny dysk. Mapowanie musi dotyczyć wszystkich elementów opisanych w zestawie backupu. Nazwa logiczna pliku FILESTREAM i jego fizyczna lokalizacja to odrębne informacje, dlatego przed odtwarzaniem warto odczytać listę plików z kopii poleceniem RESTORE FILELISTONLY.

Ostatni etap łańcucha backupów odtwarza się z opcją WITH RECOVERY, która udostępnia bazę użytkownikom. Jeżeli będą stosowane następne kopie logu, wcześniejsze operacje wykonuje się z WITH NORECOVERY. Przed uruchomieniem bazy produkcyjnej należy sprawdzić, czy wszystkie wymagane pliki zostały odtworzone, czy baza ma oczekiwany stan oraz czy aplikacja widzi zarówno rekordy, jak i powiązaną zawartość binarną. W przypadku korzystania z dostępu FILESTREAM przez interfejs Win32 aplikacja musi otrzymać prawidłowy kontekst transakcji i dostęp do właściwej instancji SQL Server.

Po odtworzeniu można wykonać kontrolę strukturalną za pomocą DBCC CHECKDB, zgodnie z procedurą właściwą dla używanej wersji SQL Server i polityką administratora. Należy także wykonać zapytania porównujące liczbę rekordów, wartości identyfikatorów FILESTREAM oraz rozmiary lub sumy kontrolne plików, jeżeli aplikacja je przechowuje. Test powinien obejmować otwarcie kilku rzeczywistych obiektów przez aplikację, odczyt danych binarnych i sprawdzenie, czy nowe zapisy działają po zakończeniu odzyskiwania. Opcje naprawcze DBCC, zwłaszcza naprawy mogące powodować utratę danych, nie powinny być używane jako pierwszy krok.

Diagnostyka problemów po odzyskaniu

Typowym objawem niepełnego odtworzenia jest obecność rekordów w tabeli przy jednoczesnym błędzie podczas pobierania zawartości FILESTREAM. Taka sytuacja może oznaczać brak właściwego kontenera, niezgodne ścieżki plików, uszkodzenie woluminu albo odtworzenie bazy z backupu, który nie obejmował aktualnego stanu danych FILESTREAM. Inny przypadek to brak rekordów połączony z poprawnie działającym odczytem starszych plików; wtedy problem może dotyczyć punktu odtworzenia, pominiętej kopii dziennika albo transakcji, która nie została jeszcze odtworzona.

Diagnostyka powinna opierać się na komunikatach SQL Server, historii operacji backupu i restore, stanie plików bazy oraz logach aplikacji. Nie należy naprawiać sytuacji przez ręczne zmiany nazw plików w kontenerze ani przez kopiowanie pojedynczych elementów między katalogami. Jeżeli backupy są dostępne, bezpiecznym sposobem potwierdzenia procedury jest odtworzenie kopii na odseparowanej instancji testowej, sprawdzenie tabel FILESTREAM i dopiero później zaplanowanie odtworzenia środowiska docelowego.

Po zakończeniu prac warto ustalić przyczynę awarii, czas utraty danych oraz punkt, do którego udało się odtworzyć bazę. Należy również sprawdzić, czy wykonano nową kopię zapasową już po odzyskaniu i czy procedura regularnie obejmuje grupę plików FILESTREAM oraz dziennik transakcji. W środowisku, w którym pliki binarne mają znaczenie operacyjne, test odtwarzania powinien być powtarzany, ponieważ sama obecność pliku backupu nie dowodzi, że pełna ścieżka odzyskiwania zadziała w praktyce.