DFS backup Configuration job getting fail most of the time.

Backup is taking long time to start and most of the time getting fail without taking any backup

So I need the proper configuration for the same

Server -win 2008 R2 cluster with DFS

Master srv-WIn 2008 R2(NBU 7.5.0.3) client  also same ver

selection type

Shadow Copy Components:\User Data\Distributed File System Replication\DfsrReplicatedFolders\userhome\...

4 Replies

DFS / DFSR is induced in

DFS / DFSR is induced in System State backup. It can not be backed up as normal files. Please check this TN.

Backup and Restore of Microsoft DFSR data using Symantec NetBackup
http://www.symantec.com/docs/HOWTO65638


Please check if "Volume Shadow Copy" service is disabled.  This happens when "Volume Shadow Copy" service is disabled - set to Automatic.

In the backup selection, just

In the backup selection, just mention "Shadow Copy Components:\" and run the backup.

 

This should backup your "Shadow Copy Components:\User Data\Distributed File System Replication\DfsrReplicatedFolders\* "

Highlighted

I feel your pain.  if you

I feel your pain.  if you have a server with a large DFSR you are stuck.

you can follow the doc and turn dfs off do the backup of the disk as a normal FS and then turn dfs back on.

this makes the backup faster and you can have more streams (like one per drive or break up the sub dirs into streams)

the draw back is that when you start dfs up again it starts from the beginning and may take a while to get all caught up again.

As stated above the files for that DFS dir will be located in the SCC backup stream - and it will only do 1 stream so it takes a long time.  It also can required a large vss space for the snapshot.

 

 

I've managed to achive really

I've managed to achive really slow but relatively sucessful backups (as long as you can tollerate a few "the file wasn't there anymore when NetBackup got around to it" errors) of Shadow Copies of DFS by disabling Client Side Dedup using the one checkmark in Policy Attributes.

The exact same policy, with that checkmark removed almost always fails out with either an error 13 or 14...

I do have an open ticket with Support but all they keep saying is "it's the fault of the network or other issues, it SHOULD work just fine with Client Side Dedup"...they even went so far as to suggest that I should set the timeout value in pd.conf to a value that translated to seven days!

I'm also experimenting with a small ( 1 TB ) Windows Media Server with a dedup pool (MSDP) at the same site as the suspect machine.  That removes WAN influences but still (so far) gives the same results.

So far the only sure-fire way to back up DFS is to find an idle time, turn off DFSR as described in one of the older KB's, and back it up as a normal backup.  But you must have a realatively idle server or the DFS logs will wrap around and changes will get lost.  And it can take forever to catch back up.

EDIT: And I should mention that my Windows Admin is refusing to use/setup the old method on any servers other than the one I've already got it working on.  So unless NetBackup comes up with a working method of backing up DFSR as regular files with working client side dedup, I'm sunk...