A potential for data loss has been discovered involving NetBackup 6.5.4 for Windows when backing up DFSR (Distributed File System Replication) folders.

Introduction:
A potential for data loss has been discovered involving NetBackup 6.5.4 Windows clients backing up DFSR.   It is possible to have matching folder names in DFS if each matching folder name is in a different group.  If a DFSR folder name is identical to a DFSR folder name in another replication group, only one folder is backed up and the backup exits with Status 0 (Successful).


What is Affected:
The following versions of NetBackup are affected on all supported Windows platforms:
 

- NetBackup Server/Enterprise Server 6.5.4

How to Determine if Affected:
If ALL of the following conditions are met, data loss can occur:

- NetBackup 6.5.4 is running on a supported Windows client platform for DFSR.

- DFSR services are running.

- One or more replicated folders, in different groups, have the same name.

Duplicate DFS folder names in the same group will not exhibit this issue.  This issue is seen when the same DFS folder name is configured on 2 or more different groups.  When this occurs, the Backup, Archive and Restore selection screen will show duplicate folder entries, but only one will be expandable (see Example 2).


Example 1:
Consider the following folder configuration.
 
This is a potentially affected DFSR folder configuration because two DFS Groups contain a folder called " projects".  If a NetBackup client attempts to back up the "projects" folder in both groups ("Group A" and "Group B"), only one " projects" folder will be backed up.

This same issue would occur with matching folders in 3 or more groups..  Only one of the matching folders will be backed up.


Example 2:
The folder name "DFSR_Set_1" is configured in more than one replication group and occurs more than once in the NetBackup client's Shadow Copy Components.  Notice that the second occurrence of "DFSR_Set_1" lists the GUID and is not expandable.  This is an indication that it will not be backed up properly.
 


Workaround:
The following two seperate workarounds are available for this issue:

Workaround A: Avoid duplicate folder names among different DFS replication groups.  

Workaround B: Use the flat file method of backing up DFS.  To do this, a registry key needs to be created and configured, and the DFS Replication service prior must be stopped prior to starting a backup:

1. Disable the DFSR writer in the registry by doing the following:

a. Launch the registry editor

b. Navigate to the HKEY_LOCAL_MACHINE\SOFTWARE\Veritas\veritas\BEDS\Engine\Shadow Copy Components

c. Add a new registry key called "Additional Not Authorized Writers"

d. Inside this new key, create a REG_SZ value named "DFSR" and give it the value "{2707761b-2324-473d-88eb-eb007a359533}"

Note: Disabling the DFSR writer in the registry only affects NetBackup.  It has no impact on the normal behavior of the server.

2. Once the registry key and value are created, stop the "DFS Replication" service before the backup starts.  Restart this service when backups are complete to ensure replication functions resume. See the NetBackup Administration guide (under Related Documents below) for use of bpstart_notify.bat and bpend_notify.bat to automate this process.  Similarly, when performing a restore of DFS data, this service must be stopped as well.  
 

Note: By stopping the DFSR service, the backup succeeds, but when the data is restored, it is an AUTHORITATIVE restore at the system where the restore is done.  Therefore, items restored become the "master" copies.  This may be correct for most cases but may prompt for replication when services are started.

If neither of the above workarounds are feasible, please contact Technical Services, referencing this issue and Etrack 1825306 for further instructions.


Formal Resolution:
The formal resolution to this issue (Etrack 1826648) is currently being researched so it may be included in a forthcoming NetBackup Release Update.  This document will be updated as further information is available.

Please note that when a fix is available and applied, it will prevent this issue from initially occurring but cannot recover data that was skipped due to this issue.

As new product updates are released, please visit the following link for download and readme information:
  https://www.veritas.com/business/support/overview.jsp?pid=15143


Best Practices:
Veritas strongly recommends the following best practices:

1. Always perform a full backup prior to and after any changes to your environment.

2. Always make sure that your environment is running the latest version and patch level.

3. Perform periodic "test" restores.