DFS and DFSR: Backing up your distributed file system with Backup Exec
Updated: 29 Apr 2009 | 9 comments
The following guide is intended to provide you with procedures for backing up your DFS and DFSR File Servers:
- Which DFS File Server To Backup? -
You'll want to compare your file servers that participate in DFS or DFSR and select the one that has the following attributes:
- Fastest network link to the Backup Exec server (Gigabit vs 10/100)
- Fastest disk hardware (SCSI vs IDE)
- Fastest Processor(s)
- Installing the Remote Agent for Windows Servers (RAWS) -
- From within Symantec Backup Exec, Select the Tools menu, then choose "Install Agents and Media Servers on Other Servers"
- Choose Next in the Installation window
- Select Windows Remote Agents from the list, and select Add.
- Enter the file server's Computer Name, and the domain name it belongs to. Click OK
- Next, you'll need to provide credentials that will allow you to run a program installation on the file server. Enter them and choose OK.
- Select the features that you'd like to install on the file server, in this case, the "Remote Agent for Windows Systems", then click Finish.
- The Remote Installation Status window will indicate that the installation has installation has completed successfully.
- Backing up your DFS and DFSR Folders -
- From within Backup Exec, select New Job from the Backup Tasks left-hand menu.
- Now in the Backup Job Properties screen, Under Selections, expand "Windows Servers" from the Favorite Resources tree. Now that you've installed the Remote Agent on your file server, it will be listed in this tree.
- Expand your file server's tree further and further expand the "Shadow Copy Components" tree, followed by the "User Data" tree.
- Next, you'll see the "Distributed File System Replication" tree, expand that, followed by the "DfsrReplicatedFolders" tree.
- Finally, you'll see all of your existing replicated folders, select the checkbox next to any of them to mark them for backup.
- Once you've made all of your selections, you may run or schedule your backup job as usual.
article Filed Under:
Comments
Yes, but...
This is the "by the book" process for backing up DFS shares - however - you will see some very significant performance issues doing this.
For more info, see:
http://www.backupexecfaq.com/articles/problems/dfs-backup-and-performance-issues.html
http://www.backupexecfaq.com/articles/real-world/backing-up-dfs-data.html
Mark this post as the solution, and have good luck for 7 years.
Forget to mark this as the solution, and tomorrow your server will crash.
I registered on backupexecfaq
I registered on backupexecfaq today and neither on Internet Explorer nor Firefox I get any content after logging in. Was the FAQ site closed?
RE: Yes, but...
Excellent point Mitch,
If you do experience significant slow-downs using the Shadow-Copy Components to back up DFS shares, you can try backing up the shares directly using the methods described in the articles listed above.
DFS Backup Methods
I've actually been researching this issue a lot lately, in an effort to figure out the best/most practical way of backing up DFS replicated data.
A big disadvantage of backing up DFS data via the Shadow copy components, if you are running Backup Exec 11 or 10 is that you CANNOT redirect data during restores. In v. 12 and above you can according to the tech docs.
If you back up DFS user data through the shares as Mitch pointed out you can redirect. The only drawback to this method is that you lose security attributes for files and folders. You are also bypassing the remote backup agent, which would probably result in a reduction in performance (compared to backing up files normally via the agent).
A third option is to stop the DFS service on the remote server via the Pre/Post job configuration page. Basically you issue a pre command of “NET STOP DFSR” followed by a “NET START DFSR” as a post command when the job finishes. This will allow you backup the replicated data directly via the normal volume level backup resulting in quicker backups, retention of security information, and allows for restore redirects. The downside is that stopping the DFS service results in loss of DFS data used for calculating which files to replicate and to which sites. Basically it will slow down the replication process. A Microsoft tech support agent recommended against this option.
We’re currently investigating a fourth option, where we disable communication between the DFS replicating hosts. In theory this should allow us to backup the data at the volume level without the problems of the other methods. But we have not had a chance to test this out yet.
For more details see: http://seer.entsupport.symantec.com/docs/304981.htm, http://seer.entsupport.symantec.com/docs/296168.htm, and http://seer.entsupport.symantec.com/docs/309537.htm
This really isn't cricket
This really is a bit of a show stopper for using Backup Exec with DFS, which is a technology we're using for disaster recovery.
I find it rather ironic that each year, we seem to move to new technologies that are making products like Backup Exec redundant. Our very expensive Quantum Tape Loader is pretty much redundant as tape just doesn't work very well. We replicate our data to our USA site for main DR. We want to use Backup Exec as the "Oops, I've just deleted a file" but it doesn't play very well with DFS put in for aforementioned reasons.
Seriously, our expensive BE support contract is up for renewal and I'm going to put that on hold whilst we look around for alternatives.
Cheers, Rob.
And...
Any, why does DFS have to use shadow copy? Why isn't there a plain vanilla file copy? I can use Robocopy to suck data off way faster than BE...
Cheers, Rob.
I guess this is because DFSR
I guess this is because DFSR is something were files enter and leave the system through the DFSR staging area while replicating with other members. There is also a special DFSR database keeping track of things. So only VSS can guarantee that you are backing up a consistent state of files.
Backing up DFSR Clusters the "Best Practice" way - IMPOSSIBLE
Yesterday I found some relatively new article from Symantec, dealing with the problem not being able to:
a) Backup DFSR Data by selecting the Shadow Copy Components
AND at the same time
b) Backup a Cluster via its Cluster Resource Name
Here's the Article: http://www.symantec.com/business/support/index?page=content&id=TECH164777
Problem
a) DFSR data should be backed up via the Shadow Copy Components.
b) Clustered servers should be backed up via their Cluster Resource Name.
Conclusion: Since the clustered resource name does not show shadow copy components, both of these best practices can not be followed.
Solution
There is an alternate way to backup the DFSR data and that is using the share name. The DFS shares will show under the cluster name. Selecting the shares will allow for the data to be backed up, however the security information on the folders will not be obtained. This should not be considered a disaster recovery solution. For disaster recovery, run an occasional backup of the shadow copy components on the active node in the cluster.
So the funny stuff is, the "Solution" is to back up DFSR Data by using the share names and lose every ACL and "from time to time" run some REAL backup, which isn't the supported way, because maybe you try to backup the wrong node.
I try to keep my anger down, but I have to admit that Symantec seems not to be able to provide working, supported and best practice solutions for Products which are more than 8 years old (DFSR).
What's your preferred method of backing up a DFSR Cluster?
I try to keep my anger down,
I learnt to keep an anger down as BE wasn't doing my blood pressure much good either! That said, after many hours of battling I've managed to get our BE environment stable...
Rob.
Would you like to reply?
Login or Register to post your comment.