A DBA scripted a nightly storage snapshot of a busy database server's data and log volumes. When the team reverted to one snapshot during a test, the database would not start cleanly and reported inconsistencies. Writes were active when the snapshot ran. What should the DBA change?
Select an answer to reveal the explanation.
Short Explanation
Snapping a busy database without warning is like photographing a juggler mid-throw; some balls are in the air and the picture doesn't add up. You want the database to flush and pause for a beat so the snapshot catches a clean, consistent moment. Taking more photos doesn't guarantee one of them is clean.
Full Explanation
A snapshot taken while a database is actively writing is at best crash-consistent: it resembles the disk state after a sudden power loss, with in-memory changes not yet flushed and, if data and log volumes are snapshotted at slightly different moments, files that disagree. Some engines can recover from a crash-consistent image, but the failed test shows this one could not. An application-consistent snapshot coordinates with the database: it flushes dirty pages, briefly freezes or quiesces I/O, and records a consistent point across all volumes, often through a backup integration the database supports, before the storage snapshot is taken and writes resume. Taking snapshots more frequently only produces more crash-consistent images and leaves consistency to chance. Excluding the log volume removes the information the engine needs to recover and makes the data volume less consistent, not more. Compressing the snapshot volume affects capacity and possibly speed but does nothing to coordinate the snapshot with in-flight transactions. Exam caveat: consistency groups across all database volumes are required when data and logs live on separate volumes. Operational check: after changing the method, revert a snapshot in a test environment, confirm the database starts without recovery errors, and run an integrity check.