Snapshots are not backups
a sufficient backup strategy needs to meet the following criteria:
•The backup needs to be atomic. That is to say, the backup cannot rely on anything else for its recovery.
•The backup needs to be separated from the system it is a backup of (out of band).
•The backup needs to be copied or transported to remote site (off site)
Snapshots are a very simple and elegant way to allow for simple routine restores, but they aren't reliable enough that they replace a real backup solution
They protect quite well from any non-netapp (systems accessing volumes) user or admin errors or problems.
They do not protect from catastrophic hardware failures of the netapp itself.
Snapshots are not application aware:
Just because you take a snapshot of the underlying storage volume does not mean the data on that volume is recoverable. MS SQL is a great example of this - you need to make sure your database is transaction-consistent before you snapshot the storage it is using. DBAs love to using different LUNs for different parts of SQL to better utilize the storage system, temp databases on fast storage, system databases on slower storage, read-only or archived data on bulk storage, and working data somewhere in between. If you are just snapshotting those volumes it is highly unlikely you will be able to recover your database.
Multiple storage types can have different snapshots schedules:
NetApp's ONTAP is a multi-protocol offering and it is very possible you are using more than one method or storage type for a particular server. In our shop some of our server's get their C:\ drive over an NFS-based datastore and their "storage" drives over Raw Device Mapped LUNs. We were taking snapshots of the RDM LUNs but not the NFS-based datastores. This made recovering the server, difficult.
Snapshots do not have a guaranteed retention policy:
It is possible to fill up your Snap Reserve in such a way where Snpashot Autodelete removes snapshots that have not naturally aged to deletion.
Snapshots are inline: last but most importent:
Your snapshots reside on the same platform you are backing up. If the volume or the Filer it is on disappears so does your backup
a sufficient backup strategy needs to meet the following criteria:
•The backup needs to be atomic. That is to say, the backup cannot rely on anything else for its recovery.
•The backup needs to be separated from the system it is a backup of (out of band).
•The backup needs to be copied or transported to remote site (off site)
Snapshots are a very simple and elegant way to allow for simple routine restores, but they aren't reliable enough that they replace a real backup solution
They protect quite well from any non-netapp (systems accessing volumes) user or admin errors or problems.
They do not protect from catastrophic hardware failures of the netapp itself.
Snapshots are not application aware:
Just because you take a snapshot of the underlying storage volume does not mean the data on that volume is recoverable. MS SQL is a great example of this - you need to make sure your database is transaction-consistent before you snapshot the storage it is using. DBAs love to using different LUNs for different parts of SQL to better utilize the storage system, temp databases on fast storage, system databases on slower storage, read-only or archived data on bulk storage, and working data somewhere in between. If you are just snapshotting those volumes it is highly unlikely you will be able to recover your database.
Multiple storage types can have different snapshots schedules:
NetApp's ONTAP is a multi-protocol offering and it is very possible you are using more than one method or storage type for a particular server. In our shop some of our server's get their C:\ drive over an NFS-based datastore and their "storage" drives over Raw Device Mapped LUNs. We were taking snapshots of the RDM LUNs but not the NFS-based datastores. This made recovering the server, difficult.
Snapshots do not have a guaranteed retention policy:
It is possible to fill up your Snap Reserve in such a way where Snpashot Autodelete removes snapshots that have not naturally aged to deletion.
Snapshots are inline: last but most importent:
Your snapshots reside on the same platform you are backing up. If the volume or the Filer it is on disappears so does your backup
No comments:
Post a Comment