Minimizing your exposure to loss of data

The following topics discuss methods for minimizing the exposure to loss of data when using automatic SnapMirror updates of SnapManager backup sets:

• Goal: More frequent mirror updates with minimal Snapshot overhead
• Supplemental replication using rolling Snapshot copies
• Supplemental mirroring of the transaction logs

Goal: More frequent mirror updates with minimal Snapshot overhead  

As described in SnapMirror replication for SnapManager is asynchronous, changes to the database that occurred on the source volume after the most recent SnapMirror replication update would not be on the destination volume if the source volume were to be lost.

One way to trigger more frequent SnapMirror updates would be to simply use SnapManager to schedule more frequent Snapshot copies of the LUNs containing the transaction logs. Increasing the frequency of SnapManager backup operations, though, increases the difficulty of managing the number of online Snapshot backup sets that are stored online at your primary site. This is described in Maximum number of Snapshot copies per volume.

As an alternative to increasing the frequency of SnapManager backups, you can use SnapDrive to initiate additional, more frequent SnapMirror replication updates. When SnapMirror replication is initiated directly from the SnapDrive command-line, as opposed to using the SnapMirror replication schedule or using SnapManager backups to automatically trigger SnapMirror updates, you can better manage the overhead that is incurred by creating additional Snapshot copies on the primary site.

Supplemental replication using rolling Snapshot copies  

When you use SnapDrive to initiate SnapMirror replication, rolling Snapshot copies are used. These Snapshot copies are created for the sole purpose of SnapMirror replication. You can use SnapDrive rolling Snapshots to supplement the automatic mirroring of SnapManager backup Snapshot copies with additional, more frequent SnapMirror replication updates of just the transaction logs. Exposure to data loss is minimized by narrowing the window during which data can be lost (from the time of the most recently completed SnapManager backup and mirrored Snapshot copy to the time of failure).

Advantages of SnapDrive rolling Snapshots

Using SnapDrive rolling Snapshots to augment your SnapMirror replication schedule for SnapManager offers the following advantages over increasing SnapManager backup operations:

• Fewer Snapshot copies are retained.

  A maximum of two rolling Snapshots are retained at any time.

• Fewer SnapManager backups are required.

  NetApp recommends that you avoid taking SnapManager backups every few minutes, which can result in overlapping SnapManager operations, as well as increased difficulty in managing the large number of resulting backups.

For details about rolling Snapshot, see the SnapDrive Installation and Administration Guide for your version of SnapDrive.

Rolling Snapshots of all database files

When all the LUNs utilized by any database file are located in a single storage system volume, replicate all of the database files more frequently. This offers the following additional advantages:

• Combined with automatic SnapManager backup set replication, this narrows the window during which transactions can be lost.
• By replicating the entire database, you can quickly recover from site failure by attaching to the database on the remote site.
• When all database files are placed in a single volume, all files will be at the same consistency point. Therefore, when the database is attached, it will automatically recover the most recently committed transactions.

If you augment your SnapManager backup schedule with supplemental SnapMirror replications of all database files, be aware of the following data recovery consideration: if the disaster on the main site has created a suspect database, then the database must be restored from backup, but the transaction log must be backed up using SnapManager before it is restored.

Rolling Snapshots of only the transaction log

In situations where it is not always practical to replicate all database files, replicate only the transaction log more frequently (by replicating the LUN where the logs are stored). This offers the following advantages:

• By supplementing SnapMirror updates by using SnapDrive to initiate frequent updates to the transaction log, you can restore the databases up to the point of the most recent successful SnapMirror replication. First, you restore the databases from the replicated backup set on the SnapMirror destination volume. Then you can use the replicated LUN to replay any transaction logs that were generated or changed after that mirrored backup.
• Fewer changes are made to the SQL Server data between replications, as compared to increasing the frequency of mirrored SnapManager backups. This enables you to keep your destination volume effectively more current without running the risk of overlapping your SnapManager operations.

To increase the frequency of the transaction log updates, use the SnapDrive command-line interface tool sdcli to schedule the additional SnapMirror replication updates through Windows Scheduled Tasks, specifying supplemental replication of the LUN where the transaction logs are stored.

If you augment your SnapManager backup schedule with supplemental SnapMirror replications of only the transaction log, be aware of the following data recovery considerations:

• The databases must restored from a backup set.
• If the SQL Server on the primary site is available, then SnapManager will request that SQL Server instance to back up the transaction log.
• If the SQL Server on the primary site is not available, then the following activities must be completed before the databases can be restored:
  • The database must be attached.
  • The transaction log must be backed up.

Supplemental mirroring of the transaction logs  

If you plan to augment your SnapManager backup schedule with supplemental SnapMirror replications of the transaction logs, your backup schedule requires additional planning.

Allow time for the backup to finish

Design your backup schedule so that a SnapMirror replication is not scheduled to start until the SnapManager backup operation has finished. Note that all three types of SnapManager Backup operations can be configured to trigger SnapMirror updates:

• Full database backup, with or without transaction log backup or database verification
• Transaction log backup only
• Database verification only

At a minimum, be sure to allow enough time for the actual SnapManager backup operation to finish before the SnapMirror update is initiated.

Allow time for the previous replication to finish

Be sure that the interval between SnapMirror replications allows enough time for the previous replication to finish.

Example of a backup and replication schedule

The following table shows an example of a schedule documenting the additional intervals when the volume containing the transaction logs is replicated.

• SnapMirror replication is scheduled to occur 30 minutes after the SnapManager backup begins. You might need to adjust this delay in order to allow enough time for your specific backup configuration to finish.
• It is assumed that the 60-minute interval between each replication of the transaction logs allows enough time for the previous replication to finish.

Copyright © 1994-2006, Network Appliance, Inc. All rights reserved.
Part No. 215-01752_A0
File: mirrbkp3.htm
Last updated: 01-Sep-2006 07:41:21