RESTORE WITH MOVE

RESTORE WITH MOVE pozwala odtworzyć bazę pod inną ścieżką plików niż ta zapisana w kopii zapasowej.

Mechanika translacji ścieżek fizycznych w strukturach relacyjnych

Zrozumienie działania modyfikatora odtwarzania w relacyjnych bazach danych, zwłaszcza w architekturze Microsoft SQL Server, wymaga w pierwszej kolejności analizy logiki przechowywania plików. Każda baza danych zarządzana przez ten silnik składa się z określonych struktur fizycznych na dysku. Podstawowymi jednostkami są główny plik danych (Master Data File, rozszerzenie .mdf) oraz plik dziennika transakcji (Log Data File, rozszerzenie .ldf). Rozbudowane środowiska mogą posiadać również wiele pomocniczych plików danych (Secondary Data Files, rozszerzenie .ndf), służących do rozpraszania obciążenia wejścia/wyjścia na różne macierze. Kiedy system wykonuje pełną kopię zapasową bazy, tworzony jest zunifikowany plik archiwum (najczęściej z rozszerzeniem .bak), który agreguje nie tylko tabele, indeksy, procedury składowane i surowe dane zapisane w ośmiokilobajtowych stronach alokacji, ale również wewnętrzne metadane. Metadane te przechowują dokładny zapis absolutnych ścieżek fizycznych katalogów serwera źródłowego w momencie generowania kopii. Standardowa procedura przywracania odczytuje ten nagłówek i instruuje usługę serwera bazy danych, aby utworzyła pliki dokładnie w tych samych lokalizacjach. W przypadku gdy docelowy serwer operuje na innej strukturze wolumenów, na przykład nie posiada partycji D: lub E: obecnych w środowisku produkcyjnym, żądanie alokacji kończy się krytycznym błędem systemu operacyjnego i przerwaniem operacji. Modyfikator zmiany ścieżki jest wbudowanym mechanizmem silnika, który przechwytuje żądanie alokacji przed wysłaniem go do kontrolera systemu plików. Funkcja ta pozwala administratorowi jawnie nadpisać metadane zaszyte w archiwum .bak i zdefiniować nowe, prawidłowe ścieżki fizyczne dostosowane do topologii sprzętowej serwera docelowego, na którym aktualnie wykonywana jest operacja odtwarzania.

Zarządzanie rozmieszczeniem wolumenów MDF i LDF podczas procesu odtwarzania

Techniczna implementacja zmiany ścieżek opiera się na zastosowaniu składni T-SQL, która wymaga precyzyjnego zmapowania stałych nazw logicznych na nowe nazwy fizyczne. Nazwa logiczna pliku to wewnętrzny identyfikator nadawany podczas tworzenia bazy danych, który pozostaje niezmienny bez względu na fizyczne przemieszczenia plików na dysku. Aby przygotować prawidłową kwerendę z modyfikatorem zmiany ścieżki, inżynier musi najpierw odczytać wewnętrzne identyfikatory z pliku archiwum, wykorzystując instrukcję odczytu samych nagłówków plików (RESTORE FILELISTONLY). Zapytanie to zwraca tabelę systemową, w której znajdują się kolumny określające nazwy logiczne, typ pliku (Dla danych – D, dla dziennika – L) oraz rozmiar zarezerwowany dla pliku w bajtach. Zależność między nazwami logicznymi a fizycznymi określa się w głównej kwerendzie za pomocą osobnych parametrów, oddzielonych przecinkami. Mechanizm ten jest rutynowo wykorzystywany podczas klonowania rozbudowanych środowisk produkcyjnych na uproszczone serwery deweloperskie i testowe. Produkcyjne klastry obliczeniowe najczęściej dystrybuują pliki .mdf, .ndf oraz .ldf na całkowicie oddzielne zasoby pamięci masowej o różnej charakterystyce wydajnościowej (np. szybkie dyski NVMe dla dzienników transakcyjnych i pojemne macierze RAID 6 dla archiwum danych). Deweloper odtwarzający bazę na lokalnej stacji roboczej, zazwyczaj wyposażonej tylko w pojedynczy wolumen systemowy C:, używa omawianego modyfikatora do skonsolidowania wszystkich tych plików w jednym katalogu testowym. Rozwiązanie to ma również kluczowe znaczenie podczas migracji serwerów między różnymi centrami danych, gdzie standardy nazewnictwa liter dysków logicznych ulegają zmianie w wyniku odrębnych polityk konfiguracyjnych sieci Storage Area Network (SAN).

Błędy alokacji i kolizje uprawnień na poziomie systemu plików

Modyfikacja ścieżek alokacji w locie wprowadza szereg zagrożeń na poziomie spójności konfiguracji i uprawnień systemu operacyjnego. Najczęściej rejestrowanym problemem jest błąd braku dostępu (Operating system error 5: Access is denied) w docelowej ścieżce. Wynika on z architektury zabezpieczeń, w której to nie użytkownik wykonujący skrypt T-SQL inicjuje zapis na dysku, lecz konto serwisowe, w kontekście którego działa sama usługa silnika bazy danych (często jest to wirtualne konto systemowe lub dedykowane konto domenowe bez uprawnień administratora lokalnego maszyny). Jeśli to konto nie posiada przynajmniej praw zapisu (Write) i modyfikacji (Modify) na poziomie list kontroli dostępu NTFS do nowego katalogu docelowego zdefiniowanego w parametrach, alokacja pliku w początkowym rozmiarze zostaje odrzucona. Kolejnym aspektem technicznym są blokady nakładane przez natychmiastową inicjalizację plików (Instant File Initialization). W celu oszczędzania czasu system unika zerowania alokowanej przestrzeni na dysku, ale operacja ta wymaga posiadania przez konto usługi specjalnego przywileju na poziomie polityk lokalnych systemu Windows (Perform volume maintenance tasks). Jeśli w nowej lokalizacji fizycznej istnieje już inna baza korzystająca z plików o identycznych nazwach docelowych, silnik bezpiecznie zablokuje wykonanie polecenia (błąd Msg 3156), informując, że wskazane pliki nie mogą zostać nadpisane. Wymaga to wtedy użycia dodatkowej flagi wymuszającej bezwarunkowe zastąpienie struktury danych. Po poprawnym odtworzeniu bazy za pomocą modyfikatora zmiany ścieżki, inżynier musi dodatkowo rozwiązać problem desynchronizacji identyfikatorów bezpieczeństwa SID. Loginy serwerowe pozostają bowiem w głównej bazie instancji, co sprawia, że wewnętrzni użytkownicy odzyskanej bazy stają się osieroceni (orphaned users) i wymagają ręcznego zmapowania przy użyciu dedykowanych procedur systemowych.

Odzysk sprzętowy nośników a granice kompetencji naprawczych

Zarządzanie serwerami relacyjnych baz danych, pisanie skryptów wymuszających relokację plików czy obsługa złożonych migracji to kompetencje właściwe inżynierom oprogramowania i administratorom systemów IT. Zadania te leżą całkowicie poza zakresem usług oferowanych przez podmioty zajmujące się naprawą i serwisowaniem sprzętu komputerowego. Zadaniem serwisu jest naprawa fizycznych uszkodzeń komputerów, diagnostyka zasilania płyt głównych, wymiana zużytych komponentów oraz ratowanie danych z nośników pamięci w ujęciu czysto sektorowym. Z bazami danych pracownicy serwisu stykają się jednak, gdy awarii ulega lokalna maszyna pełniąca funkcję hosta dla oprogramowania. Jeszcze kilkanaście lat temu małe firmy powszechnie instalowały programy księgowe czy magazynowe bezpośrednio na dyskach twardych komputerów biurowych, z wykorzystaniem darmowych wydań środowisk bazodanowych. W dobie powszechnej adaptacji rozwiązań w chmurze (SaaS), lokalna instalacja infrastruktury bazodanowej na komputerze konsumenckim to dziś rzadkość w serwisie. Sytuacje te wciąż się zdarzają w przypadku awarii starszych, nieaktualizowanych stacji roboczych, pracujących na przestarzałych systemach operacyjnych i starych, talerzowych dyskach HDD lub mocno wyeksploatowanych dyskach SSD. Gdy nośnik taki ulegnie mechanicznemu uszkodzeniu – na przykład z powodu zatarcia silnika, degradacji komórek NAND czy spięcia elektroniki – użytkownik traci dostęp do swoich archiwów bazy danych. Wówczas Warszawskie Pogotowie Komputerowe może przeprowadzić sprzętową diagnozę uszkodzonego dysku i podjąć próbę wykonania bezpośredniego klonu posektorowego. Proces ten ignoruje strukturę systemu operacyjnego, mając na celu wyodrębnienie i zapisanie na sprawnym nośniku nienaruszonych plików o rozszerzeniach .mdf, .ldf czy .bak. W tym miejscu sprzętowa część interwencji dobiega końca. Serwis dostarcza odzyskane ciągi bajtów na stabilnym nośniku fizycznym. Samodzielne podpięcie tych plików pod nową, działającą instalację systemu operacyjnego, przypisanie uprawnień usług systemowych i wykorzystanie omawianych modyfikatorów ścieżek do odbudowy logicznej spójności bazy pozostaje już obowiązkiem wykwalifikowanego zewnętrznego administratora oprogramowania.