SQL Server & Exchange auf Hyper-V

Write-Ahead-Logging ist kein Zufallsschutz, sondern das Design

SQL Server schreibt Änderungen grundsätzlich zuerst ins Transaktionsprotokoll (.ldf), bevor sie in die Datendatei übernommen werden — nach einem harten Abbruch spielt die Engine beim nächsten Start automatisch Redo/Undo durch und stellt einen konsistenten Zustand her. Exchange nutzt mit der ESE-Engine (JET Blue) dieselbe Grundidee — Transaktionslogs vor Datenbankänderung, automatische Wiederherstellung beim nächsten Start.

Beide Systeme sind also explizit für den Fall eines unerwarteten Absturzes konstruiert. Ein einzelner Stromausfall, bei dem der darunterliegende Speicher ehrlich meldet, was tatsächlich physisch geschrieben wurde, führt in aller Regel zu einer normalen Crash-Recovery beim nächsten Start — keinem Datenverlust.

Wenn der Speicher lügt

Write-Ahead-Logging funktioniert nur, wenn ein als "geschrieben" bestätigter Schreibvorgang auch tatsächlich physisch auf dauerhaftem Medium liegt. Genau das ist der Punkt, an dem es in der Praxis schiefgeht: ein RAID-Controller im Write-Back-Modus ohne Battery- oder Flash-Backed Cache bestätigt Schreibvorgänge bereits, sobald sie im flüchtigen Cache angekommen sind — physisch auf der Platte stehen sie erst später. Reißt der Strom in genau diesem Fenster ab, geht die Bestätigung verloren, auf die sich SQL Server oder Exchange beim Wiederanlauf verlassen haben.

Ein weiterer, oft übersehener Faktor: Hyper-V-VSS-Integration (Backup-Integrationsdienst) quiesced SQL Server und Exchange über deren jeweilige VSS-Writer für konsistente VM-Snapshots. Das betrifft primär geplante Sicherungen, nicht die Abschalt-Sequenz selbst — trotzdem lohnt es sich, Backup-Zeitfenster nicht ausgerechnet in den Moment eines beginnenden Stromausfalls fallen zu lassen.

Sauberer Neustart statt Crash-Recovery bei jedem Ausfall

Wenn die Engines Absturzsicherheit ohnehin eingebaut haben, warum dann trotzdem geordnet herunterfahren? Weil der praktische Unterschied nicht "Datenverlust vs. kein Datenverlust" ist, sondern Wiederanlaufzeit und Vorhersehbarkeit:

1. Graceful ACPI-Shutdown statt hartem Trennen
   Der UPS Hyper-V Shutdown Monitor löst standardmäßig ein reguläres Stop-VM ohne -Force aus — das signalisiert dem Gast-Betriebssystem ein normales ACPI-Herunterfahren, wodurch Windows die dort laufenden Dienste (SQL Server Agent, Datenbank-Engine, Exchange-Dienste) in der korrekten Abhängigkeitsreihenfolge selbst sauber stoppt, statt dass ihnen der Strom mitten im Betrieb entzogen wird. Erst nach Ablauf eines konfigurierbaren Timeouts erfolgt notfalls ein harter -TurnOff.
2. Schnellerer, ruhigerer Wiederanlauf
   Ein sauber gestoppter SQL-Server- oder Exchange-Dienst muss beim nächsten Start keine Redo/Undo-Wiederherstellung durchlaufen — er startet direkt aus einem konsistenten Zustand. Bei kritischen Datenbanken macht das oft den Unterschied zwischen Sekunden und spürbar längerer Downtime nach dem Ausfall.
3. Kein Anlass, in der Krise zu improvisieren
   Ein vorhersehbarer, geloggter Abschaltvorgang nimmt genau den Zeitdruck heraus, unter dem in der Praxis die riskanteren Entscheidungen getroffen werden (z.B. ein Datenbankdienst wird während des laufenden Backups hart abgewürgt, weil "es schnell gehen muss").

Vor dem nächsten Stromausfall prüfen

1. RAID-Controller-Cache prüfen — Write-Back nur mit Battery- oder Flash-Backed Cache, sonst auf Write-Through umstellen. Das ist die eigentliche Absicherung, nicht die Datenbank-Engine.
2. Graceful Shutdown statt hartem TurnOff als Standardweg — reguläres ACPI-Herunterfahren mit realistischem Timeout, harte Trennung nur als letzter Ausweg.
3. Schwellwerte großzügig genug für sauberen Dienststopp — SQL Server und Exchange brauchen beim geordneten Stoppen spürbar länger als eine reine Web-VM; die Restlaufzeit-Reserve muss das einplanen.
4. Backup-Fenster und USV-Überwachung nicht gegeneinander laufen lassen — ein VSS-Snapshot mitten im Abschaltvorgang ist vermeidbarer Zusatzstress in einer ohnehin kritischen Situation.
5. Testmodus einmal durchspielen — Abschaltreihenfolge und tatsächliche Wiederanlaufzeit nach einem sauberen Stopp einmal messen, bevor der erste echte Stromausfall zum ersten Test wird.