Before a major database engine upgrade, a DBA takes a storage snapshot of the database volumes so the team can roll back quickly if the upgrade fails. Which statement about this snapshot is accurate?
Select an answer to reveal the explanation.
Short Explanation
A snapshot is a bookmark in the same book, not a photocopy kept in another building. It's perfect for 'undo the upgrade,' but if the storage array dies, your bookmark dies with it. That's why you still want a real backup somewhere else.
Full Explanation
Storage snapshots capture the state of a volume at a moment in time, typically using copy-on-write or redirect-on-write techniques that record changed blocks rather than copying the whole volume. That makes them nearly instantaneous to take and quick to revert, which is ideal for rolling back a failed upgrade. Because most snapshots reference the original volume's blocks and live on the same array, they share its failure domain: if the array fails, is corrupted or is encrypted by ransomware, the snapshot is usually lost with it. A full backup stored off the array is therefore still required before risky changes. Describing a snapshot as an independent complete copy that survives array loss confuses it with a backup or a replicated copy. Treating snapshots as a replacement for backups ignores both the shared failure domain and that snapshots retained for long periods degrade performance and consume capacity as changed blocks accumulate. Saying a snapshot records only transaction log changes confuses storage-level snapshots with database log backups; a volume snapshot captures blocks for whatever files reside on the volume. Exam caveat: snapshots are fast restore points, not off-site protection. Operational check: confirm a verified full backup exists outside the array before the upgrade begins, and test the snapshot revert procedure in non-production.