Video Screencast Help
Symantec to Separate Into Two Focused, Industry-Leading Technology Companies. Learn more.

BE 2012 ADBO + DFS replication - options?

Created: 27 Mar 2012 | 5 comments

Hi,

We have BE 2012 with ADBO on a Win2008R2 server, backing a Win2008R2 file server with 600GB data stored on a SAN volume. The SAN is a Dell MD3200i, with hardware snapshots enabled. Approximately half the data is held in DFS replicated folders.

When I run a backup, using Shadow Copy Components for the DFS folders, the job fails with an error: 

" - Snapshot Technology: Initialization failure on: "\\YHRHPAFIL001.xxxxxxxx.xxx\Shadow?Copy?Components". Snapshot technology used: Microsoft Volume Shadow Copy Service (VSS).

Snapshot technology error (0x800423F8): 0x800423f8 (2147755000)

Check the Windows Event Viewer for details."

When I run an offhost backup, the data in the DFS replicated folders does not backup. The job fails with an error: 

"V-79-57344-65033 - Directory not found. Cannot backup directory #User?Data#Distributed File System Replication#DfsrReplicatedFolders#Accounts#Region#Accounts and its subdirectories."

It seems then that I cannot backup DFS replicated folders when using the off host backup option because they need the volume shadow copy provider, but I cannot back them up using shadow copy comonents either, as snapshots on that volume are now provided by the SAN hardware!

Can anyone suggest any options, short of separating DFS replicated folders and non-DFS replicated folders onto different volumes and running separate backups for each? This would render the off host backup option a bit pointless!

Thanks,

Richard

Comments 5 CommentsJump to latest comment

Colin Weaver's picture

Hmm well ADBO Offhost did not support DFSR in BE 2010 and I haven't seen any details of enhancements in this area for 2012. http://www.symantec.com/docs/TECH152591

And if the Hardware provider is not supported for a standard RAWS/VSS backup then I guess your only option is to put the DFSR data on separate volumes that are not managed by the hardware provider.

teiva-boy's picture

ADBO (Off-host Backup)was made for databases..  Exchange, SQL mainly.  It's support is pretty limited.  It's practical use is even less than that.  Dell hypes it up very hard in their lunch and learn events.  But hardly anyone implements it due to so many errors with Windows, VSS, hardware prodviders, SAN provisioning, etc...  Too many moving pieces.

In larger enterprise environments when talking Oracle, highend SAN's like XIV, VMAX, etc very few get snapshot integration to work with the backup application.  Instead products like RecoverPoint are used.  Or scripts are used to initiate the snaps.  Thousands of dollars are spent in getting it to work, only to have a service pack or hotfix break it all.  This is real-world experience with SAN snapshots....

There is an online portal, save yourself the long hold times. Create ticket online, then call in with ticket # in hand :-) http://mysupport.symantec.com "We backup data to restore, we don't backup data just to back it up."

rablack's picture

Well, that is interesting. Set up and running difficulties aside, the document linked to by Colin is the ONLY place I have found any reference to ADBO off-host not working with DFSR!

We would most likely not have bothered purchasing the add on and the SAN hardware snapshot licenses if that was the case.

If I am interpretting the errors correctly, then when the SAN snaps the volume on which the DFSR folders reside, the DFS DB is paused or otherwise unavailable on that volume, so the files are not accessible to the Agent. And because the Agent knows they are DFSR files, it won't back them up as normal files, because they would not be able to be restored. Does that sound right?

The data to be backed up is for archivepurposes only, since the DFSR takes care of disaster recovery and we also have shadow copies enabled (and working) on that volume too.

If that is the case, might it make sense for the SAN to do a snapshot independantly of the backup job, and for that snapshot to be mounted on the relevant server so that it is visible to the backup agent?  In my mind, that would present a (read-only) volume, with all my data, but no DFSR databases or shadowcopy stuff for the Agent to worry about. If I schedule the SAN snap to refresh itself periodically, then this could give me a solution. Colin, do you have any suggestions?

Richard

Colin Weaver's picture

If your SAN technolgy allows the snap to be mounted on Windows as a local drive (sort of like a split mirror) then that would probably work - although I suspect you would belimited to Full backups as it would kind of be a Read Only mount that is destroyed when the snap is removed so no option to archive bit monitor or journal.

Other than that and reconfiguring DFSR onto another volume, I don't really have any other options left

rablack's picture

Thanks Colin, I'm not entirely sure about your suggestion, as off host incremental backups was my main intentions behind this - quick, LAN free backup to disk during the day to allow for multiple backup sets per day.

I'm going to experiment with using AOFO with the hardware provider today to see where that gets me. Not LAN free backups obviously, but I'd still be able to do synthetic backups to tape from my incrementals.