Netbackup and DFS-R "issues"

[gc_bus]

Hi to everyone,

After moving to Netbackup 6.5.4 the issue of not backing up Windows DFS-R folders is resolved to the extent that they backup and restore ok. However, the issues I have with this are

• Clients cannot have their DFS-R shares/drives multi-threaded in the same backup - i.e. they have to run serially via the Shadow Copy Component path. This means that large servers (.e.g 6TB!) can take so long to backup when single threaded that it is not viable to run full backups in the time-slots available.
• The Netbackup BAR screen shows up backed up files (as expected) under the Shadow Copy Components path but it gets difficult to identify which original Windows drive letter they came from especially if different drive letters have same named folders. The workaround puts in a hex string of numbers in front which can be a tad difficult to ensure the file/folder being restored is the correct one.
• It would appear that incrementals more or less run as full's for the DFS-R folders which also is not ideal when they are large

Had anyone got around these problems at all and is it any better in NBU 7.0.1?

Cheers

Glyn

[Nicolai]

Don't activate the TIR (True Image Restore) option in a policy containing Distributed File System Replication folders. The result will be incremental backup with same size as the full backup.

As the target is a subset of Shadow Copy Components, Microsoft DFSR writer is used to access the data (i.e. Netbackup tells DFSR writer what to backup and waits for it to return the data). However the DFSR VSS writer is TIR unaware.

TIR will however function at a file system level as designed, but for DFSR data this would require DFSR service to be stopped for correct functionality.

The TIR option will not be greyed out in the policy as the policy type for the backup is MS-Windows-NT which otherwise supports TIR.

[J_H_Is_gone]

You are so correct. It does it in the SCC backup job.

I do not do TIR, but every SCC job tires to do a full, as far as I could see.

I worked with support to see just how they thought DFSR was suppose to be backed up.

And the answer was in the SCC job, which they told me is always a full.

After by upgrade to 7.01 it took 2.5 days to backup just one of my DFSR servers.

.......

Solution  - turn it off.

I use the bpstart_notify script to turn DFSR off on the server.

Then I use the bpend_notify script to turn DFSR on on the server.

This allows me to backup by drive letter ( and also break it down into smaller jobs per job letter using the  a*  b* c* method of file selection)

Because I use the bpstart and bpend, it runs for every child

so it goes down down down down, and when each is done it goes up up up up.

I am looking at using the parent start/end (which only runs on the master) to see if I can can get it to go down only once, and up only once ( not sure if it will work as my master is unix)

-----

I spent 2 weeks after the upgrade trying to find a better way, I and support could not find one.  You either backup via SCC (which is too slow for big servers) or you turn it off - which I hate doing.    I don't know why it cannot work like it did in 5.x.

[gc_bus]

Would like to run Optimised Synthetic full backups but that, of course, requires that TIR is turned on in the policy so snookered there. Symantec have informed me that this is a problem and as yet don't have a further solution for these problems with DFS-R......

Of course turning on and off DFS-R via the bpstart_notify feature is ok but our backups take a while anyway on a particular 6TB server that then DFS-R replication gets out of step during that time so that's not an option either.

[Giroevolver]

You could always just disable the DFS VSS writer so that you can do a flat file level backup of DFS

http://www.symantec.com/business/support/index?page=content&id=TECH126944

[J_H_Is_gone]

that doc also says to stop dfsr using the notify scripts!

[Giroevolver]

Appologies! I miss read the doc! I thought it was a reg change and that was it. I didnt notice the Stop the service at the bottom.

[rshehab]

it is 2017 now and the issue is still unresolved? well done veritas!!

[Marianne]

MANY things have changed since 2010.

Herewith Best Practice doc: 

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

If you have issues with DFS-R backup using currently supported NBU versions, please start a new discussion.