1 Copper

Recovery from a mtree replicated DD


DD01 on site1

DD02 on site 2

Backup application NetBackup or BackupExec

Backups are taken using DDBoost to a DDboost storage unit on DD01 using the backup application. In addition DDBoost for Microsoft Applications is utilised to enable the DBA's to backup the SQL servers from the SQL Server Management Studio to another DDBoost storage unit on DD01.

DD01 is replicated to DD02 using DD Replication Mtree replication method.


Site 1 is trashed by fire/Jumbo jet/Godzilla

How is recovery of the mtree replicated data stored on DD02 enacted? I don't believe that the backup application is aware of the replicated copy nor that SQL management studio would be aware.

This does not exist yet so any comments on this would be appreciated.

Tags (2)
0 Kudos
3 Replies

Re: Recovery from a mtree replicated DD

I have limited experience with Symantec software but have experience with the general process with other backup software.

1. make the mtree on replication target accessible

     * break mtree replication and enable ddboost, nfs or cifs as needed

     * possibly create a new mtree and us fast copy

     * Create users and assign access as needed.  mtree replication doesn't replicate users.

2. Restore application

     *If its a site outage you probably have to restore or reinstall MS SQL and Symantec.

3. Restore backup data

     * DBA can restore data from replication target either via management studio or command line.  They select the replication target as the source of the restore.

     * Most backup software has a process of scanning media and importing backups.  It may make the process easier to rename DD02 to DD01.  Depending on change rate, amount and type of data and bandwidth the mtree at the replication target might be several hours behind and I do not know how well Symantec software will handle it.

Also note collection replication might be used which will simplify the restore process but it would not be practical to test disaster recovery.

1 Copper

Re: Recovery from a mtree replicated DD

Ryan, Thanks for this. Any infomation is useful as I've never used mtree replication before. Maybe I'm over thinking this and it might be a lot easier than I imagine because this seems like a lot of faff to effect a DR.

If anybody has experience of testing, or the misfortune of a live DR using mtree replication please add your experience.

To make things easier let's assume that the backup application is configured on a cross site cluster and that the SQL servers are again on cross site clusters. Therefore when the disaster strikes it is only the DD mtree bit we need to sort out. The backup application and the SQL servers will know nothing about the DR DD because they were not involved in the replication of the data from source to target and it's this bit that's stumping me.

In installations I have setup before I've always configured the backup apps to manage and perform the replication/duplication of the backup images. Therefore they know about both copies of the data, in a DR it's only a case of telling the app to look for the data on the other site. Which it will do quite happily because it's catalog contains both references. With this scenario where the DD controls the replication I cannot see an easy way to effect a failover as the applications catalog only contains information of one site. As I've said I may be over thinking and missing a salient point about mtree replication.

Any thoughts greatly appreciated.

0 Kudos

Re: Recovery from a mtree replicated DD

Ideally when using data domain storage for backups you have software that supports managed file replication so the software knows about the 2nd copy like you describe.  In other use cases like archive data with retention lock license or sourceone mtree replication is a great solution.

DDboost for application with oracle does support managed file replication.  DDboost for mssql does not.  I'm guessing because maintenance plans don't have any catalog or copy intelligence built in.  It shouldn't be a big deal because it wont be much different from a DBA's perspective than pointing the maintenance plan to local or shared folder.

I only have limited experence with Symantec but I do believe there is some support for managed file replication.  I believe there is a data domain ost document somewhere that talks about it.  I believe managed file replication is called optimized deduplication by Symantec.

0 Kudos