RESTORE FILELISTONLY zwraca listę plików zapisanych w kopii zapasowej bez wykonywania samego przywracania.
Co zwraca polecenie RESTORE FILELISTONLY
RESTORE FILELISTONLY jest instrukcją języka Transact-SQL przeznaczoną dla aparatu kopii zapasowych programu Microsoft SQL Server. Polecenie odczytuje nagłówki i metadane zapisane w kopii zapasowej bazy danych, a następnie zwraca zestaw wierszy opisujących pliki znajdujące się w tej kopii. Nie odtwarza bazy, nie tworzy plików na dysku i nie zmienia zawartości istniejącej bazy. Jego zadaniem jest rozpoznanie zawartości backupu przed wykonaniem właściwej operacji RESTORE DATABASE.
Najczęściej używana postać polecenia wygląda następująco: RESTORE FILELISTONLY FROM DISK = N'C:\Backup\Baza.bak';. Wartość po DISK wskazuje plik kopii zapasowej, który musi być dostępny dla procesu SQL Server. Jeżeli kopia została zapisana na urządzeniu taśmowym, można wskazać również urządzenie typu TAPE, ale w typowych wdrożeniach spotyka się pliki dyskowe. Polecenie można wykonać z poziomu SQL Server Management Studio, sqlcmd albo innego klienta korzystającego z połączenia z odpowiednią instancją SQL Server.
Identyfikacja plików logicznych i fizycznych
Wynik RESTORE FILELISTONLY zawiera między innymi kolumny LogicalName, PhysicalName, Type, FileGroupName, Size, MaxSize, FileId oraz CreateLSN. LogicalName to nazwa logiczna pliku zapisana w bazie danych, używana później w klauzuli MOVE. PhysicalName wskazuje pierwotną ścieżkę pliku w systemie, czyli lokalizację, w której plik znajdował się na serwerze wykonującym kopię. Te dwie wartości mogą być zupełnie różne, dlatego nie należy traktować nazwy logicznej jako ścieżki systemowej.
Kolumna Type określa rodzaj pliku. Wartość D oznacza plik danych, a L plik dziennika transakcji. Informacja o grupie plików jest dostępna w FileGroupName dla plików danych. Rozmiary są raportowane w bajtach, co pozwala oszacować wymagane miejsce przed rozpoczęciem przywracania. Wiersz wynikowy może zawierać także informacje o numerze pliku, identyfikatorach LSN, rozmiarze sektora oraz innych właściwościach związanych z układem plików w backupie. Liczba zwróconych wierszy zależy od liczby plików danych i dziennika uwzględnionych w konkretnej kopii.
Planowanie RESTORE DATABASE z użyciem FILELISTONLY
Praktycznym zastosowaniem tego polecenia jest przygotowanie bezpiecznej klauzuli WITH MOVE. Jeżeli backup pochodzi z innego serwera, zapisane w nim ścieżki z kolumny PhysicalName mogą nie istnieć w środowisku docelowym. Najpierw można odczytać listę plików, a następnie przypisać każdej nazwie logicznej nową ścieżkę, na przykład: RESTORE DATABASE BazaTestowa FROM DISK = N'C:\Backup\Baza.bak' WITH MOVE N'Baza_Data' TO N'D:\SQLData\BazaTestowa.mdf', MOVE N'Baza_Log' TO N'E:\SQLLog\BazaTestowa.ldf';. Nazwy użyte w MOVE muszą odpowiadać wartościom LogicalName zwróconym przez RESTORE FILELISTONLY.
Odczyt listy plików nie zastępuje sprawdzenia całego łańcucha kopii. Przed przywróceniem należy ustalić, czy analizowany backup jest pełną kopią bazy, kopią różnicową czy kopią dziennika, a także czy jest zgodny z pozostałymi elementami planowanej sekwencji odtwarzania. Do odczytu zawartości kopii można użyć również RESTORE HEADERONLY, które zwraca informacje o zestawie backupu, jego typie, czasie wykonania i pozycji w nośniku. RESTORE FILELISTONLY odpowiada natomiast przede wszystkim na pytanie, jakie pliki logiczne i fizyczne zawiera wskazana kopia.
Kontrola ścieżek i warunków przed przywróceniem
Podczas diagnostyki problemów z odtwarzaniem wynik polecenia pomaga wykryć niezgodność między układem backupu a systemem docelowym. Jeżeli w kopii występuje kilka plików danych, każdy z nich powinien otrzymać właściwe przypisanie w WITH MOVE. Pominięcie jednego z plików albo użycie błędnej nazwy logicznej może zakończyć operację komunikatem o nieprawidłowym pliku lub niemożliwej do użycia ścieżce. Przed wykonaniem przywracania warto także sprawdzić, czy wskazane katalogi istnieją, SQL Server ma do nich uprawnienia oraz czy dostępna przestrzeń dyskowa jest wystarczająca dla rozmiarów zapisanych w metadanych.
Wynik RESTORE FILELISTONLY należy interpretować w kontekście konkretnej instancji SQL Server i konkretnego pliku kopii. Samo odczytanie listy nie potwierdza, że backup jest kompletny, nie sprawdza całego procesu odzyskiwania i nie gwarantuje poprawności danych użytkowych. Do dodatkowej kontroli można użyć RESTORE VERIFYONLY, pamiętając, że również ono nie jest pełnym testem odtworzenia aplikacji. W środowisku laptopa lub komputera używanego do pracy z narzędziami administracyjnymi istotne jest zachowanie oryginalnego pliku backupu, poprawne wskazanie instancji SQL Server oraz dokładne rozróżnienie nazw logicznych od fizycznych ścieżek plików.
