VDI für SQL Server: Backup ohne .bak-Dateien | Anleitung

VDI-Integration: MS SQL-Backups ohne .bak-Dateien erstellen

Standardmäßige BACKUP DATABASE-Befehle in MS SQL Server sind auf lokale Festplattenspeicher beschränkt. Für die Integration mit externen Backup-Systemen ist VDI erforderlich – eine Schnittstelle, die es ermöglicht, den Datenstrom direkt aus SQL Server abzufangen. Wir zerlegen die Implementierung des VDI-Clients im „Beresta“-Projekt, das einen vollständigen Backup- und Wiederherstellungszyklus ohne Zwischendateien .bak bietet.

Warum VDI in modernen Backup-Systemen benötigt wird

Die serienmäßigen Backup-Mechanismen von SQL Server über TO DISK decken die Anforderungen externer Datenschutzsysteme nicht ab. Wenn Job-Lifecycle-Management, Datenrouting, Parallelität oder Integration mit Objektspeicher erforderlich sind, entsteht der Bedarf an einer Zwischenschicht. VDI (Virtual Device Interface) dient als solche Brücke: SQL Server führt standardmäßige BACKUP- und RESTORE-Befehle weiterhin aus, arbeitet aber statt mit physischen Dateien mit virtuellen Geräten, die von einer externen Anwendung verwaltet werden.

Wichtige Vorteile des VDI-Ansatzes:

• Vollständige Kontrolle über den Datenstrom – direktes Schreiben in Cloud-Speicher oder Medienserver
• Unabhängigkeit vom Dateisystem von SQL Server
• Unterstützung für gestreifte Operationen zur Steigerung des Durchsatzes
• Einziger Ansprechpartner für Fehlerbehandlung und Logging
• Einhaltung der Anforderungen von Enterprise-Backup-Systemen an das Management von Speicherrichtlinien

Im Gegensatz zu vereinfachten Lösungen implementiert das „Beresta“-Projekt VDI als vollwertigen Transportadapter zwischen SQL Server und dem Storage-Backend und gewährleistet Kompatibilität mit Versionen von 2008 bis 2022.

VDI-Client-Architektur: Von der Vorbereitung bis zur Ausführung

Die Implementierung ist in zwei logische Phasen unterteilt. In der Vorbereitungsphase werden Parameter validiert, die Verbindung zu SQL Server über ODBC hergestellt und ein Task-Set gebildet. Kritisch wichtig ist, dass das Projekt mehrere ODBC-Treiber unterstützt (einschließlich aktueller Driver 17/18), was die Kompatibilität in heterogenen Umgebungen erhöht.

Während der Ausführung wird der VDI-Strom aktiviert:

• COM-Initialisierung über CoInitializeEx
• Erstellung des IClientVirtualDeviceSet2-Objekts
• GUID-Generierung für virtuelle Geräte
• VDConfig-Parameterkonfiguration (Blockgröße, Timeout, Buffer-Tiefe)
• Geräteveröffentlichung über CreateEx
• Ausführung des T-SQL-Befehls mit Angabe von VIRTUAL_DEVICE
• Datenverarbeitung in Worker-Threads

Die zentrale Komponente ist transferThreadProc, die die Austauschlogik mit SQL Server implementiert:

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

Diese Schleife gewährleistet synchrone Interaktion: SQL Server tritt als Produzent von Blockdaten auf, während der VDI-Client als Konsument agiert und die Daten an den Zielspeicher umleitet.

Parallelität und Performance-Management

Einzelthread-Verarbeitung stellt einen Engpass für Enterprise-Workloads dar. Das Projekt behebt dies durch gestreifte Backup-/Wiederherstellungsoperationen, wobei jede Stripe von einem separaten Thread bearbeitet wird. Die Angabe des --stripes=N-Parameters erzeugt Dateien wie:

db_full_20260412_101530_s0.bak
db_full_20260412_101530_s1.bak
...

Dieser Ansatz bietet dreifachen Nutzen:

• Verteilung der I/O-Last auf Festplatten oder Netzwerkkanäle
• Lineare Skalierbarkeit des Durchsatzes
• Abstimmung auf die Architektur industrieller Backup-Systeme mit mehreren Streams

Wichtige Parameter, die die Performance beeinflussen:

• blockSize – optimale Blockgröße für den Zielspeicher
• maxTransferSize – maximale übertragbare Paketgröße
• buffersPerStripe – Buffer-Tiefe pro Stripe
• vdiTimeoutSec – Timeout für I/O-Operationen

Experimente mit diesen Parametern ermöglichen die Anpassung der Lösung an spezifische Infrastrukturcharakteristika – von lokalen SSDs bis zu langsamen Netzwerkspeichern.

Wiederherstellungsketten: Vom Voll- zum Log-Backup

Das Projekt unterstützt den vollständigen Wiederherstellungszyklus inklusive Differenzial- und Transaktionslogs. Die korrekte Behandlung von Ketten ist entscheidend wichtig:

• Bei Differenzial-Backups wird das letzte Vollbackup mit demselben Zeitstempel automatisch ausgewählt
• Vollwiederherstellung erfolgt mit WITH NORECOVERY, gefolgt vom Differenzial mit WITH RECOVERY
• Log-Backups sind nur für Datenbanken im FULL/BULK_LOGGED-Recovery-Modell zulässig
• Die master-Datenbank ist von Differenzialoperationen ausgeschlossen (SQL Server-Beschränkung)

Der Mechanismus zur Satz-Erkennung nutzt die Namenskonvention:

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

Verzeichnis-Scan-Funktionen erstellen Wiederherstellungsketten basierend auf Zeitstempeln. Für Vollwiederherstellungen wird der neueste Satz gewählt; für Differenzial nur solche mit passenden Voll- und Diff-Dateien. Die Stripe-Anzahl ergibt sich aus dem höchsten sN-Index in den Dateinamen.

Vor der Wiederherstellung wird die Datenbank zwingend in den Single-User-Modus versetzt:

ALTER DATABASE [db] SET SINGLE_USER WITH ROLLBACK IMMEDIATE

Dies verhindert Konflikte mit aktiven Verbindungen. Nach erfolgreicher Wiederherstellung wird die Datenbank in den MULTI_USER-Modus zurückversetzt.

Wichtige Erkenntnisse

• VDI beseitigt die Abhängigkeit vom Dateisystem von SQL Server und leitet den Datenstrom an beliebigen Zielspeicher um
• Unterstützung für Voll-/Diff-/Log-Szenarien mit automatischer Konstruktion von Wiederherstellungsketten
• Parallele Verarbeitung über gestreifte Architektur gewährleistet lineare Skalierbarkeit des Durchsatzes
• Kompatibilität mit SQL Server 2008–2022 ohne Bindung an einen bestimmten ODBC-Treiber
• Implementierung berücksichtigt SQL Server-Spezifika (z. B. master-Datenbank-Beschränkungen)

Das „Beresta“-Projekt demonstriert, wie eine relativ kompakte VDI-Client-Implementierung zentrale Anforderungen von Enterprise-Backup-Systemen erfüllen kann. Der Fokus auf den vollständigen Betriebszyklus (einschließlich Fehlerbehandlung und Datenbankzustandsmanagement) macht es produktionsreif. Die Architektur ist offen für die Integration mit jedem Storage-Backend – von lokalen Festplatten bis zu Cloud-Objektspeicher –, was in hybriden IT-Landschaften besonders relevant ist.

— Editorial Team