VDI pro SQL Server: zálohování bez .bak souborů | Průvodce

# Integrace VDI: jak vytvořit zálohování MS SQL bez souborů .bak

Standardní příkazy BACKUP DATABASE v MS SQL Server jsou omezeny na lokální uložení na disk. Pro integraci s externími systémy zálohování je nezbytné VDI — rozhraní, které umožňuje zachytit datový proud přímo ze SQL Serveru. Probereme implementaci VDI klienta v projektu „Beresta“, který zajišťuje celý cyklus zálohování a obnovení bez mezičlánkových souborů .bak.

Proč je VDI potřebné v moderních systémech zálohování

Standardní mechanismy zálohování SQL Serveru přes TO DISK neřeší úkoly externích systémů ochrany dat. Když je potřeba správa životního cyklu úloh, směrování dat, paralelizmus nebo integrace s object storage, vzniká potřeba pro mezičlánek. VDI (Virtual Device Interface) slouží jako takový most: SQL Server nadále vykonává standardní příkazy BACKUP a RESTORE, ale místo fyzických souborů pracuje s virtuálními zařízeními, která řídí externí aplikace.

Klíčové výhody přístupu VDI:

• Plná kontrola nad datovým proudem — zápis přímo do cloudového úložiště nebo mediaserveru
• Nezávislost na souborovém systému SQL Serveru
• Podpora striped operací pro zvýšení propustnosti
• Jednotný bod zpracování chyb a logování
• Splnění požadavků enterprise systémů zálohování na správu politik úložiště

Na rozdíl od zjednodušených řešení projekt „Beresta“ implementuje VDI jako plnohodnotný transportní adaptér mezi SQL Serverem a storage backendem, přičemž zachovává kompatibilitu s verzemi od 2008 do 2022.

Architektura VDI klienta: od přípravy po provedení

Implementace je rozdělena do dvou logických fází. V fázi přípravy probíhá validace parametrů, připojení k SQL Serveru přes ODBC a vytvoření sady úloh. Kriticky důležité je, že projekt podporuje více ODBC ovladačů (včetně aktuálních Driver 17/18), což zvyšuje kompatibilitu v heterogenních prostředích.

Během provedení se aktivuje VDI proud:

• Inicializace COM přes CoInitializeEx
• Vytvoření objektu IClientVirtualDeviceSet2
• Generování GUID pro virtuální zařízení
• Nastavení parametrů VDConfig (velikost bloku, timeout, hloubka bufferování)
• Publikování zařízení přes CreateEx
• Spuštění T-SQL příkazu s uvedením VIRTUAL_DEVICE
• Zpracování dat v pracovních vláknech

Centrální komponenta — transferThreadProc, kde je implementována logika výměny se SQL Serverem:

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);
}

Tento cyklus zajišťuje synchronní interakci: SQL Server funguje jako producer blokových dat a VDI klient jako consumer, který přesměrovává data do cílového úložiště.

Paralelizmus a správa výkonu

Jednovláknové zpracování je úzkým hrdlem pro enterprise zátěže. Projekt to řeší pomocí striped backup/restore, kde každý stripe zpracovává samostatné vlákno. Při zadání parametru --stripes=N se vytvářejí soubory ve tvaru:

db_full_20260412_101530_s0.bak
db_full_20260412_101530_s1.bak
...

Takový přístup přináší trojnásobnou výhodu:

• Rozložení I/O zátěže mezi disky nebo síťové kanály
• Lineární škálování propustnosti
• Shoda s architekturou průmyslových systémů zálohování s vícenásobnými vlákny

Klíčové parametry ovlivňující výkon:

• blockSize — optimální velikost bloku pro cílové úložiště
• maxTransferSize — maximální velikost přenášeného balíku
• buffersPerStripe — hloubka bufferování na vlákno
• vdiTimeoutSec — timeout operací vstupu-výstupu

Experimenty s těmito parametry umožňují přizpůsobit řešení konkrétním charakteristikám infrastruktury — od lokálních SSD po pomalá síťová úložiště.

Obnovení řetězců: od full po log

Projekt podporuje celý cyklus obnovení včetně diferenciálních a transakčních logů. Kriticky důležitá je správná obsluha řetězců:

• Pro differential backup se automaticky vybere poslední full backup se stejným timestampem
• Při restore full se provádí s WITH NORECOVERY, poté differential s WITH RECOVERY
• Log backup je povolen pouze pro databáze v modelech FULL/BULK_LOGGED
• Databáze master je vyloučena z differential operací (omezení SQL Serveru)

Mechanismus hledání sad používá konvenci pojmenování:

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

Funkce pro skenování katalogu staví obnovovací řetězce podle časových značek. Pro full restore se vybírá poslední sada, pro differential pouze ty, kde existují související full a diff soubory. Počet pruhů se určuje podle maximálního indexu sN v názvech souborů.

Před obnovením probíhá povinný přechod databáze do single-user módu:

ALTER DATABASE [db] SET SINGLE_USER WITH ROLLBACK IMMEDIATE

To zabraňuje konfliktům s aktivními připojeními. Po úspěšném obnovení se databáze vrátí do MULTI_USER režimu.

Co je důležité

• VDI odstraňuje závislost na souborovém systému SQL Serveru a přesměrovává datový proud do libovolného cílového úložiště
• Podpora full/diff/log scénářů s automatickým sestavením řetězců obnovení
• Paralelní zpracování přes striped architekturu zajišťuje lineární škálování propustnosti
• Kompatibilita se SQL Server 2008-2022 bez vazby na konkrétní ODBC ovladač
• Implementace zohledňuje specifika SQL Serveru (např. omezení pro databázi master)

Projekt „Beresta“ demonstruje, jak i relativně kompaktní implementace VDI klienta může splnit klíčové požadavky enterprise systémů zálohování. Důraz na celý cyklus operací (včetně obsluhy chyb a správy stavu databáze) činí řešení vhodným pro produkční prostředí. Architektura zůstává otevřená pro integraci s jakýmkoli storage backendem — od lokálních disků po cloudové object storage, což je obzvláště aktuální v hybridních IT krajinách.

— Editorial Team