SAN Snapshots Aren’t Backups

Denny Cherry explains why SAN snapshots aren’t a good backup policy:

SAN snapshots, and I don’t care who your vendor is, by definition depend on the production LUN. We’ll that’s the production data.

That’s it. That’s all I’ve got. If that production LUN fails for some reason, or becomes corrupt (which sort of happens a lot) then the snapshot is also corrupt. And if the snapshot is corrupt, then your backup is corrupt. Then it’s game over.

SAN snapshots are a good part of an infrastructure-side recovery plan, but databases have their own recovery time and recovery point objectives.  Conflating these two can lead to sadness.

Related Posts

SQL Server Backup Restoration With LOADHISTORY

Kenneth Fisher explains what the LOADHISTORY option means when you run a RESTORE VERIFYONLY command: So, first of all, it only works with RESTORE VERIFYONLY. RESTORE VERIFYONLY does some basic checking on a backup to make sure that it can be read and understood by SQL. Please note, it does not mean that the backup can be restored. It will […]

Read More

Cross-Server Database Restoration With Minion Backup

Jen McCown walks us through how to restore a database on a different server with Minion Backup: Today we’ll look at configuring a common, repeatable scenario: take the latest backup of MyDB from ProdServer1 and restore it to DevServer1. There are four basic steps to the setup and execution: Configure Minion Backup and let it run on […]

Read More

Categories

April 2016
MTWTFSS
« Mar May »
 123
45678910
11121314151617
18192021222324
252627282930