Understanding SnapManager backup set archival

The following topics provide background information about archiving SnapManager backup sets:

Why organizations archive data

Organizations archive data for many reasons, central of which is disaster recovery. Archiving data enables an organization to create a complete copy of a collection of data suitable for bringing back online at some future date. Whereas backup is concerned with users accidentally destroying files or individual hardware components failing, disaster recovery addresses recovery from events that might disable an entire building or geographical area.

Organizations also archive data for purposes other than disaster recovery. Space constraints often require that older data be archived. Reasons that organizations archive and restore data are as diverse as their businesses. Some organizations restore data for use in historical analysis, and some restore data for use in litigation.

Note
A complete disaster recovery backup strategy must also include system-level backups of the SQL Server.

Importance of archiving a complete backup set

Archived data might be used to completely re-create your SQL Server databases. For this reason, it is imperative that you archive an entire SnapManager backup set. A SnapManager backup set consists of the Snapshot copies of the LUNs that store the SQL Server databases and the SnapInfo directory that is created as part of the backup operation:

SQL Server database Snapshot copies
SQL Server transaction log Snapshot copies
SnapInfo directory Snapshot copy

All of the above components must be archived for you to successfully recover and implement a point-in-time restore.

Archiving individual databases is not recommended

Archiving individual databases from SnapManager backups that contains multiple databases is not recommended. This task requires a full understanding of the Snapshot copy naming conventions used by SnapManager for Microsoft SQL Server and should not be attempted without knowing which Snapshot copies contain the appropriate databases and transaction logs for a given point in time. Archiving complete SQL Server backup sets is recommended.

Scheduling SnapManager backups for archiving

Scheduling SnapManager backups for archiving must take into consideration many factors, including the following:

Archive method used
Service Level Agreements for disaster recovery
Number of SnapManager backups performed per day
SQL Server client activity schedules
Backup verification time

Guidelines for archiving SnapManager backup sets

Follow these guidelines when you archive SnapManager backup sets:

Dedicate your storage system volumes to individual hosts.
Archive only verified backups. If you are not sure whether a backup is verified, you can use the SnapManager Restore tab to check; a backup with a green check mark is verified.
Create an archive of the most recent backup. For detailed information, see SnapManager Snapshot naming conventions.
LUNs cannot be archived using the CIFS or NFS protocols. Use the storage system's dump command or an NDMP backup application to archive LUNs.