New adventures in Disaster Recovery

[The_real_Alex_D]

Probably one of the most misunderstood aspects of some of the newer disk based backup technologies like OST and PDDO is exactly how you use them as part of your site DR strategy, particularly if your DR domain is separate from your production domain.

Sure, if you have one domain spanning multiple sites you can write your backups to deduplicating disk storage at one site and copy it to another site using optimized duplication but that second site needs to be part of the same NetBackup domain to do that and it’s not much use on its own if you lose the first site and that’s the only place you have a master server.

Of course you could be replicating your catalog to a standby master server at the second site but to do that Symantec says you need clustered master servers on both sites.

In NetBackup 6.5.4 Symantec allows you to write your catalog backups to these newer disk types.  You can even duplicate the catalog backup between sites with storage lifecycle policies (SLPs) and optimized duplication.  But there’s a catch – you can’t restore the whole catalog from that duplicated copy, you can only do a partial restore.

Of course if you’ve got an OST device you could just replicate the contents (including the catalog backup) to a DR site at the device level, outside of NetBackup control and connect a standby master server but what you’ll find then is that when you restore that catalog backup you still can’t restore the backups because the disk media IDs in the DR domain don’t match the ones in the catalog backup.

Maybe the answer is to do optimized duplication to the DR site and then import the contents of the copy at the DR site into a DR master server?   Well no, because Symantec tech note 337026 explicitly states that doing so is unsupported.

So there you have it.  Either you have a single domain that spans two sites with a complex clustered, replicating master server or you just use tape for off-site storage like you always have done.

Or do you?

Things have changed quite a lot in the last 12 months when it comes to disk based DR and they’re set to change even more in the next 12 months.

So what’s new?

First up that complex issue of catalog replication being limited to a single domain with clustered master servers.  Things have become a lot more flexible for users of NetBackup 6.5.4 and above – you can now replicate without clustering and replicate between domains.  Restrictions apply of course but there are a lot more options than there used to be.  Tech notes 345977, 345978 and 345979 cover the new options and it’s also discussed in the new NetBackup High Availability Guide that ships with NetBackup 7.0.1.

Recovering the catalog backup from that duplicate copy you made is also possible NetBackup 6.5.6  and NetBackup 7.  So if the whole idea of replicating catalogs puts you off you can just backup your catalog at one site, use optimized duplication to get it (and the rest of your backups) to your second site and then, if you ever lose the first site) just start a standby master at the second site and restore the catalog from the copy of the catalog backup you have there.

And if you’re interested in replicating things to a DR domain there’s a new command in NetBackup 6.5.6 and 7.0.1 called nbcatsync that specifically deals with the problem of disk media ID mismatches.  The nbcatsync command allows you to make a catalog backup to an OST device, replicate it, along with your regular backups, to a separate DR site with its own master server, recover the catalog backup, reconcile the disk media IDs and restore the replicated backups.      

So there you have it:

• Catalog replication – now simplified and expanded
• Catalog recovery – now possible from any copy of the catalog backup
• Disk media ID conflicts – now resolvable using nbcatsync

What’s in the works?

A new feature coming next year will extend the capabilities of SLPs to allow you to selectively duplicate disk based backups between domains.  The copy you create in your DR domain is automatically cataloged in that domain and can be duplicate on to other storage for longer tem retention.  This feature allows for ‘hub and spoke’ DR models with a single DR site being able to receive mission critical backups from multiple production sites.  Because the duplication occurs between domains it also allows backups to be selective duplicated to a site operated by a 3^rd party DR provider or to another production domain in your organization.