SQL Server & Exchange on Hyper-V

Write-ahead logging isn't luck — it's the design

SQL Server always writes changes to the transaction log (.ldf) before applying them to the data file — after a hard crash, the engine automatically replays redo/undo on the next start and reconstructs a consistent state. Exchange uses the same core idea with its ESE engine (JET Blue) — transaction logs before database changes, automatic recovery on the next start.

Both systems are explicitly built for the case of an unexpected crash. A single power outage where the underlying storage honestly reports what was actually physically written usually results in ordinary crash recovery on the next start — not data loss.

When storage lies

Write-ahead logging only works if a write confirmed as "done" is actually sitting on durable media. That's exactly where things go wrong in practice: a RAID controller in write-back mode without battery- or flash-backed cache confirms writes as soon as they hit volatile cache — they only land on disk later. If power cuts out in exactly that window, the confirmation SQL Server or Exchange relied on at restart is gone.

Another, often overlooked factor: Hyper-V's VSS integration (the backup integration service) quiesces SQL Server and Exchange through their respective VSS writers for consistent VM snapshots. That mainly concerns scheduled backups, not the shutdown sequence itself — but it's still worth making sure backup windows don't overlap with the start of a power outage.

A clean restart instead of crash recovery every time

If the engines already have crash safety built in, why bother shutting down gracefully at all? Because the practical difference isn't "data loss vs. no data loss" — it's restart time and predictability:

1. Graceful ACPI shutdown instead of a hard cut
   The UPS Hyper-V Shutdown Monitor defaults to a regular Stop-VM without -Force — that signals a normal ACPI shutdown to the guest OS, letting Windows stop its own services (SQL Server Agent, the database engine, Exchange services) in correct dependency order, instead of having power cut mid-operation. Only after a configurable timeout does a hard -TurnOff kick in as a fallback.
2. Faster, calmer restart
   A cleanly stopped SQL Server or Exchange service doesn't need to run redo/undo recovery on its next start — it starts directly from a consistent state. For critical databases that's often the difference between seconds and noticeably longer downtime after an outage.
3. No reason to improvise under pressure
   A predictable, logged shutdown removes exactly the time pressure under which the riskier decisions get made in practice (e.g. abruptly killing a database service mid backup because "it needs to happen fast").

Check before the next power outage

1. Check the RAID controller cache — write-back only with battery- or flash-backed cache, otherwise switch to write-through. That's the real safeguard, not the database engine.
2. Graceful shutdown instead of a hard TurnOff as the default — regular ACPI shutdown with a realistic timeout, hard power-off only as a last resort.
3. Give thresholds enough headroom for a clean service stop — SQL Server and Exchange take noticeably longer to stop gracefully than a plain web VM; the runtime reserve needs to account for that.
4. Don't let backup windows and UPS monitoring fight each other — a VSS snapshot mid-shutdown is avoidable extra stress in an already critical situation.
5. Run through test mode once — measure the actual shutdown order and restart time after a clean stop, before the first real power outage becomes the first test.