VDI dla SQL Server: kopia zapasowa bez plików .bak | Przewodnik

# Integracja VDI: jak utworzyć kopię zapasową MS SQL bez plików .bak

Standardowe polecenia BACKUP DATABASE w MS SQL Server są ograniczone do lokalnego zapisywania na dysk. Do integracji z zewnętrznymi systemami tworzenia kopii zapasowych niezbędny jest VDI — interfejs umożliwiający przechwytywanie strumienia danych bezpośrednio z SQL Server. Omawiamy implementację klienta VDI w projekcie „Beresta”, który zapewnia pełny cykl tworzenia kopii zapasowych i przywracania bez pośrednich plików .bak.

Po co VDI w nowoczesnych systemach tworzenia kopii zapasowych

Standardowe mechanizmy tworzenia kopii zapasowych SQL Server za pomocą TO DISK nie rozwiązują zadań zewnętrznych systemów ochrony danych. Gdy potrzebne jest zarządzanie cyklem życia zadań, kierowanie danych, równoległość lub integracja z object storage, pojawia się potrzeba warstwy pośredniej. VDI (Virtual Device Interface) pełni rolę takiego mostu: SQL Server nadal wykonuje standardowe polecenia BACKUP i RESTORE, ale zamiast fizycznych plików pracuje z wirtualnymi urządzeniami zarządzanymi przez zewnętrzne aplikacje.

Kluczowe zalety podejścia VDI:

• Pełna kontrola nad strumieniem danych — zapis bezpośrednio do chmury lub serwera mediów
• Niezależność od systemu plików SQL Server
• Obsługa operacji striped dla zwiększenia przepustowości
• Jednolity punkt obsługi błędów i rejestrowania
• Zgodność z wymaganiami enterprise-systemów tworzenia kopii zapasowych w zakresie zarządzania politykami przechowywania

W odróżnieniu od uproszczonych rozwiązań, projekt „Beresta” implementuje VDI jako pełnoprawny adapter transportowy między SQL Server a backendem storage, zachowując kompatybilność z wersjami od 2008 do 2022.

Architektura klienta VDI: od przygotowania do wykonania

Implementacja jest podzielona na dwa logiczne etapy. W etapie przygotowania odbywa się walidacja parametrów, połączenie z SQL Server za pośrednictwem ODBC oraz formowanie zestawu zadań. Kluczowe jest to, że projekt obsługuje kilka sterowników ODBC (w tym aktualne Driver 17/18), co zwiększa kompatybilność w środowiskach heterogenicznych.

W procesie wykonania aktywowany jest strumień VDI:

• Inicjalizacja COM za pomocą CoInitializeEx
• Tworzenie obiektu IClientVirtualDeviceSet2
• Generowanie GUID dla wirtualnych urządzeń
• Konfiguracja parametrów VDConfig (rozmiar bloku, timeout, głębokość buforowania)
• Publikacja urządzeń za pomocą CreateEx
• Uruchomienie polecenia T-SQL z ukazaniem VIRTUAL_DEVICE
• Przetwarzanie danych w wątkach roboczych

Centralnym komponentem jest transferThreadProc, w którym zaimplementowana jest logika wymiany z SQL Server:

while (true) {
    VDC_Command* command;
    device->GetCommand(&command);
    
    switch (command->dwCommandCode) {
        case VDC_Write:
            WriteToFile(command->pvBuffer, command->dwByteCount);
            break;
        case VDC_Read:
            ReadFromFile(command->pvBuffer, command->dwByteCount);
            break;
        case VDC_Flush:
            FlushBuffer();
            break;
    }
    device->CompleteCommand(command, S_OK);
}

Ten cykl zapewnia synchroniczną interakcję: SQL Server działa jako producer bloków danych, a klient VDI jako consumer, przekierowujący dane do docelowego magazynu.

Równoległość i zarządzanie wydajnością

Jednowątkowe przetwarzanie to wąskie gardło dla obciążeń enterprise. Projekt rozwiązuje to za pomocą striped backup/restore, gdzie każdy stripe jest obsługiwany przez oddzielny wątek. Po podaniu parametru --stripes=N tworzone są pliki w formie:

db_full_20260412_101530_s0.bak
db_full_20260412_101530_s1.bak
...

Taki sposób daje potrójną przewagę:

• Rozłożenie obciążenia I/O między dyski lub kanały sieciowe
• Liniowe skalowanie przepustowości
• Zgodność z architekturą przemysłowych systemów tworzenia kopii zapasowych z wielowątkowością

Kluczowe parametry wpływające na wydajność:

• blockSize — optymalny rozmiar bloku dla docelowego storage
• maxTransferSize — maksymalny rozmiar przesyłanego pakietu
• buffersPerStripe — głębokość buforowania na wątek
• vdiTimeoutSec — timeout operacji wejścia-wyjścia

Eksperymenty z tymi parametrami pozwalają dostosować rozwiązanie do specyficznych cech infrastruktury — od lokalnych SSD po wolne magazyny sieciowe.

Przywracanie łańcuchów: od full do log

Projekt obsługuje pełny cykl przywracania, w tym różnicowe i transakcyjne logi. Kluczowe jest poprawne przetwarzanie łańcuchów:

• Dla differential backup automatycznie dobierany jest ostatni full backup z tym samym timestampem
• Przy restore full wykonywane jest z WITH NORECOVERY, następnie differential z WITH RECOVERY
• Log backup dozwolony tylko dla baz w modelach FULL/BULK_LOGGED
• Baza master jest wykluczona z operacji differential (ograniczenie SQL Server)

Mechanizm wyszukiwania zestawów wykorzystuje konwencję nazewnictwa:

{db}_{type}_{timestamp}_s{n}.bak

Funkcje skanowania katalogu budują łańcuchy przywracania na podstawie znaczników czasowych. Dla full restore wybierany jest ostatni zestaw, dla differential — tylko te, gdzie istnieją powiązane pliki full i diff. Liczba pasm jest określana na podstawie maksymalnego indeksu sN w nazwach plików.

Przed przywracaniem wykonywany jest obowiązkowy przejście bazy w tryb single-user:

ALTER DATABASE [db] SET SINGLE_USER WITH ROLLBACK IMMEDIATE

Zapobiega to konfliktom z aktywnymi połączeniami. Po udanym przywracaniu baza wraca do trybu MULTI_USER.

Co jest ważne

• VDI eliminuje zależność od systemu plików SQL Server, przekierowując strumień danych do dowolnego docelowego magazynu
• Obsługa scenariuszy full/diff/log z automatycznym budowaniem łańcuchów przywracania
• Równoległe przetwarzanie za pomocą architektury striped zapewnia liniowe skalowanie przepustowości
• Kompatybilność z SQL Server 2008-2022 bez wiązania z konkretnym sterownikiem ODBC
• Implementacja uwzględnia specyfikę SQL Server (np. ograniczenia dla bazy master)

Projekt „Beresta” pokazuje, jak nawet stosunkowo kompaktowa implementacja klienta VDI może spełnić kluczowe wymagania enterprise-systemów tworzenia kopii zapasowych. Nacisk na pełny cykl operacji (w tym obsługę błędów i zarządzanie stanem bazy) czyni rozwiązanie odpowiednim do środowisk produkcyjnych. Architektura pozostaje otwarta na integrację z dowolnymi backendami storage — od lokalnych dysków po chmurowe object storage, co jest szczególnie aktualne w hybrydowych krajobrazach IT.

— Editorial Team