Microsoft SQL Server auf Proxmox sichern: Guest Agent, VSS und der richtige Backup-Modus

Datenbanken sind die anspruchsvollsten Gäste im Backup. Eine Windows-VM mit Microsoft SQL Server lässt sich unter Proxmox bequem per über die Backupfunktionalität sichern – der Job läuft, alles ist in Ordnung. Und trotzdem kann genau dieses Backup mit den Standardeinstellungen die Datenbanksicherung sabotieren, die innerhalb der VM läuft. Dieser Artikel erklärt, was beim Backup einer SQL-Server-VM wirklich passiert, welche Rolle der QEMU Guest Agent und der Gast-Freeze spielen – und warum eine unscheinbare Einstellung über die Wiederherstellbarkeit Ihrer Datenbanken entscheidet.

Crash-konsistent reicht einer Datenbank nicht

Ein Snapshot-Backup ohne weitere Vorkehrungen friert die VM in einem beliebigen Moment ein - Ohne die korrekten Vorkehrungen sieht die Wiederherstellung für die Datenbank dann aus wie ein Stromausfall: SQL Server startet, fährt die Crash-Recovery, rollt offene Transaktionen zurück. Das funktioniert in der Regel – aber ein Restrisko bleibt: Schwebende Schreibvorgänge, gefüllte Caches und offene Transaktionen werden zum Snapshot-Zeitpunkt existieren und können Probleme und Datenverlust verursachen.

Das Ziel ist ein applikationskonsistentes Backup: Die Datenbank weiß, dass gesichert wird, schreibt ihre Puffer weg und bringt die Dateien in einen sauberen Zustand, bevor der Snapshot entsteht. Genau dafür gibt es unter Windows den Volume Shadow Copy Service (VSS) – und die Brücke dorthin schlägt bei der Verwendung von Proxmox und anderen KVM-basierten Virtualisierungslösungen der QEMU Guest Agent.

Was der Guest Agent beim Backup wirklich tut

Ist der Guest Agent in der VM installiert und in den Proxmox-VM-Optionen aktiviert (inklusive der Option „Freeze/thaw guest filesystems on backup“), passiert beim Backup Folgendes: Proxmox weist den Agent an, die Gast-Dateisysteme einzufrieren. Unter Windows löst der Agent dabei keinen simplen Dateisystem-Freeze aus, sondern einen vollwertigen VSS-Vorgang. Alle registrierten VSS-Writer werden benachrichtigt – darunter der SQL Writer, der die Datenbanken kurz anhält, Puffer flusht und die Dateien konsistent auf die Platte bringt. Dann entsteht der Snapshot, danach taut der Agent den Gast wieder auf. Die Unterbrechung dauert im Normalfall Sekundenbruchteile bis wenige Sekunden.

So weit, so gut: Ohne Guest Agent gibt es nur Crash-Konsistenz, mit ihm applikationskonsistente Backups. Der Agent gehört deshalb auf jede (Windows-)VM. Aber genau hier beginnt die Feinheit, die viele Setups übersehen.

Die Falle: Der Freeze meldet sich als vollwertiges Backup

Der VSS unterstützt unterschiedliche Modi beim Einfrieren des Dateisystems. Der QEMU-Guest-Agent nutzt standardmäßig VSS_BT_FULL (Eine Übersicht über die VSS-Modi gibt es bei Microsoft: Link). Der SQL Server geht hierbei davon aus, dass ein vollständiges Backup des Systems erstellt wird und setzt damit die Basis für seine Differenzsicherungen neu und schneidet seine Transaktionsprotokolle ab.

Die Folge trifft jede Umgebung, in der zusätzlich eine native Datenbanksicherung läuft – Wartungspläne, SQL-Server-Agent-Jobs, Backup-Agenten von Drittherstellern: Deren Sicherungskette bricht. Die nächste Differenzsicherung bezieht sich auf eine „Vollsicherung“, die im Backup-Bestand des DBA gar nicht existiert, weil sie ein Proxmox-Snapshot war. Im Restore-Fall fällt das dann auf – also im schlechtesten Moment. Das Tückische: Beide Backups laufen fehlerfrei durch, das Problem ist im Monitoring unsichtbar.

Die Lösung: Copy statt Full

Seit Version 0.1.262 lässt sich der VSS-Backup-Typ des Guest Agents per Registry umstellen. Der Schlüssel:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\QEMU Guest Agent VSS Provider

Dort den DWORD-Wert VssOption auf 5 setzen – das entspricht VSS_BT_COPY. Ein Copy-Backup sagt den VSS-Writern: „Ich ziehe nur eine Kopie – verhaltet euch, als wäre nichts gewesen.“ SQL Server lässt die Differenzbasis unangetastet, es werden keine Logs abgeschnitten, die native Sicherungskette bleibt intakt. Nach der Änderung die VM (oder den VSS-Provider-Dienst) neu starten, damit sie greift.

Der Standardwert 1 (VSS_BT_FULL) ist nur dann unproblematisch, wenn das Proxmox-Backup die einzige Sicherung ist und innerhalb des Gasts keinerlei Datenbank- oder Backup-Jobs laufen. Auf jedem SQL-Server- oder Exchange-Gast mit eigener Sicherung gehört der Wert auf 5 – unsere Empfehlung ist, das bei Datenbank-VMs grundsätzlich zu tun und im Standard-Image zu verankern.

Das VM-Backup ersetzt die Log-Sicherung nicht

Die Umstellung auf Copy hat eine logische Konsequenz, die man bewusst tragen muss: Das Proxmox-Backup rührt die Transaktionsprotokolle nicht mehr an – und das ist richtig so, denn Log-Verwaltung ist Sache der Datenbanksicherung. Konkret heißt das: Steht eine Datenbank im Wiederherstellungsmodell „Vollständig“, braucht sie weiterhin regelmäßige Log-Sicherungen, sonst wächst das Transaktionsprotokoll unbegrenzt. Ein wachsendes Log trotz täglicher VM-Backups ist kein Fehler, sondern das erwartbare Ergebnis, wenn die Log-Sicherung fehlt.

Wer keine Punkt-in-Zeit-Wiederherstellung braucht, kann Datenbanken alternativ auf das einfache Wiederherstellungsmodell umstellen – dann verwaltet SQL Server sein Log selbst, und das Thema entfällt. Diese Entscheidung gehört aber zum Datenbank-Konzept, nicht zum Hypervisor.

Die richtige Arbeitsteilung

VM-Backup und Datenbanksicherung sind keine Konkurrenten, sondern zwei Ebenen mit klarer Aufgabenteilung:

• Das Proxmox-Backup (etwa auf einen Proxmox Backup Server) sichert die ganze VM: Betriebssystem, Konfiguration, Anwendung. Es ist die Antwort auf den Totalausfall – Host defekt, VM zerstört, Ransomware – und stellt den kompletten Server in einem Rutsch wieder her.
• Die native SQL-Sicherung (Voll-, Differenz- und Log-Backups) ist die Antwort auf Datenbank-Probleme: versehentlich gelöschte Daten, fehlerhafte Deployments, Punkt-in-Zeit-Wiederherstellung auf 14:32 Uhr, Wiederherstellung einzelner Datenbanken.

Damit die Arbeitsteilung aufgeht, sollten die SQL-Backupdateien selbst mitgesichert werden – etwa indem sie auf ein Ziel laufen, das vom VM-Backup oder einer eigenen Sicherung erfasst wird. Und beide Ebenen brauchen das, was jede Sicherung braucht: einen regelmäßigen Restore-Test.

Checkliste für SQL-Server-VMs unter Proxmox

• QEMU Guest Agent in der VM installiert und in den VM-Optionen aktiviert, inklusive Freeze/Thaw beim Backup.
• VssOption im Registry-Schlüssel des QEMU-VSS-Providers auf 5 (VSS_BT_COPY) gesetzt, danach VM neu gestartet.
• Native SQL-Sicherung eingerichtet: Vollsicherungen plus Log-Sicherungen bei vollständigem Wiederherstellungsmodell – oder bewusste Entscheidung für das einfache Modell.
• SQL-Backupdateien landen auf einem Ziel, das selbst gesichert wird.
• Restore beider Ebenen getestet: komplette VM aus dem Proxmox-Backup, einzelne Datenbank samt Point-in-time aus der SQL-Sicherung.
• Nach Guest-Agent-Updates prüfen, ob die VssOption-Einstellung erhalten geblieben ist.

Einordnung

Das Zusammenspiel aus Proxmox-Backup, Guest Agent und SQL Server ist kein Hexenwerk – aber es ist einer der Fälle, in denen die Standardeinstellung leise falsch ist und der Fehler erst im Restore-Fall sichtbar wird. Eine Registry-Einstellung, eine saubere Log-Strategie und ein Restore-Test trennen ein Backup, das gut aussieht, von einem, das im Ernstfall trägt.

Genau solche Details sind der Grund, warum wir Backups nicht nur einrichten, sondern betreiben. Wenn Sie SQL Server, Exchange oder andere Datenbanken unter Proxmox sichern – sprechen Sie uns an, wir schauen gemeinsam auf Ihre Backup-Kette.