Mistake #80: treating a crash-consistent snapshot as a database recovery plan. A storage snapshot captures a point in time, but in-flight transactions may leave a restored SQL Server database inconsistent or corrupted. An application-consistent snapshot first quiesces the database and flushes pending data to disk, creating a coherent recovery point. section 12.3
Use application-consistent snapshots with these cautions:
- On Windows, use Volume Shadow Copy Service (VSS) to handle pending I/O before the storage snapshot. section 9.7 section 12.3
- Treat Linux support carefully: VMware requires manually written pre-freeze and post-thaw scripts, while Azure provides a template configuration that must be populated. section 12.3
- Use snapshots as a fast rollback or failed-deployment recovery mechanism, but supplement them with a proper database backup strategy. section 12.12 section 12.3
- Check storage-layout requirements before separating data, log, and TempDB volumes; some SAN software requires data and log files on the same volume for application-consistent snapshots. section 9.7
Rollback after a failed deployment
A team creates a storage snapshot before changing a database server. If the snapshot is crash-consistent, restoring the VM may restore a database with unfinished I/O and an inconsistent state. An application-consistent snapshot quiesces the databases and flushes memory first, making rollback a safer rapid-recovery option. section 12.3
