Thursday, August 14, 2008

When backups aren't really backups

When is your backup not a backup? Apparently when you use BackupExec to back up data replicated using DFS-R.

My latest conundrum is that I have data that was replicated to a backup server using DFS-R, Microsoft's replication technology that comes as part of Windows Server 2003. DFS-R isn't the key component to this story, just that the data was part of a DFS tree and being replicated for backups. DFS is another Microsoft technology used to make mapping drives easier in an enterprise. In either case, these are fairly common things to find in a Windows shop.

Enter BackupExec. Since their 10d product (around hotfix 31) and continuing with their 11d and 12d disk backup products, any DFS data has to be backed up using a third Microsoft technology, Volume Shadow Services. This feature simply allows files and applications to be "snapshotted" or backed up while "hot", or during normal operations without impacting the live data. It is very useful. Well, we used it and backed up our data this way as it was required.

Only we had issues with the DFS replication and decided to transition to other methods to copy our file server local to the backup server. In that process we removed the DFS-R configuration, as expected, but now I need to restore some data from those previous backups only, I can't.


Apparently BackupExec requires that you restore shadow copied DFS data to the exact same replication group it originally came from.


So the scenario is that if you're using DFS and BackupExec you can never, ever...ever change your DFS replication groups because they are needed for restorations, even 2, 3, say 5 years down the line. And you know what their recommended fix is?

Restore your entire domain (user accounts, DFS configuration, email, whatever) back to before the change and then restore the data.


So the recommended recovery option for old DFSR data (let's say...a spreadsheet) is to restore my entire company domain back in time?


Needless to say, I'm opening a support ticket with Symantec but I'm not expecting much in the way of results. Meanwhile, I'm going to see if Arcserve can import my tape catalogs and restore my data to something less drastic than a previous version of my entire domain. If that fails, it looks like we're going to be building a time machine in a set of servers just to have them around to do restores.


BTW, the general recommendation in the community is either back up the files through the back door using a file share, avoiding the shadow copy service, or turn off DFS replication during the backup so BackupExec doesn't think it is DFS data anymore.


Update: After a somewhat heated discussion with Symantec on this issue, their senior technician had suggested we try running the restore with all DFS services turned off. I wasn't expecting much from this suggestion but sure enough, the restore was successful.

Now if only that had been mentioned in the technote. And the solution in the technote was the initial response from tech support and not until I complained excessively about this did they try to provide another workaround. Good thing I did, or else I still think I'd be left scratching my head over this "feature".


  1. Actually I ran accross this after having the SAME problem. But there's a better way than via the 'back door'. In your file selections, select the "Shadow Copy components" and everything in it. Then the user data of the DFS becomes through the same component when you want to restore.

  2. Unfortunately, digit-head, while you can select the data that way, my issue was that you cannot initially restore those selections if the original shadow copy location, in this case a replication group, no longer exists.

  3. Um... pooh... yeah that would be a problem (one that I need to remain MINDFUL of!). I learned that DFS backup is not as simple as one would think, the HARD way. Fortunately it was just ONE file I was trying to restore (one of my own) so it's not like it was the CEO breathing down my neck.

    Suffice it to say, had I NOT run accross your issue, I would have been on the phone with Symantec probably for DAYS.

  4. Yeah… guess I didn’t pay enough attention. I was looking for a solution to the “oh my GOD this is not backing up!” problem.
    Although I’ve been stuck using it for a good many years now, I’m still NOT real happy with Backup Exec at ALL.

  5. This comment has been removed by a blog administrator.

  6. I was wondering if you ever got a resolution with to issue with backing up /restoring DFS files whenusing Backup Exec? Or is the solution to move away from Backup Exec? I am in a current situation where by I am using DFS to replicate from our 4 remote sites to us and r Backup exec. But when it come to restoring a file from DFS all I get restored is the DFS Folders in the direct tree to the file I want restore but no file. Is there a secret to restoring a file in DFS? Thanks

  7. Actually yes there is a resolution to it. You have to connect to and backup the DFS shares THROUGH the DFS shares and not directly from the disk. If the server that's running Backup Exec has a copy of the DFS shares locally, it seems to have no impact on the length of time required to back them up. If you do not backup through the network shares, you will not be able to restore and data at all.

    I've actually put this to the test (and do so regulary) to make SURE I can restore DFS shared data and it does work quite well.

  8. This comment has been removed by a blog administrator.

  9. Thanks for the information, I am now not sure if the process we are running is the correct process. We are backing up the DFS shares through the Shadow Copy component due to one the backups running at night and two the replication of the DFS files from the remote sites run over night as well. Would you think this would create an issue? and or is this the reason why I am having issues with trying to restore a file from the DFS shares?

  10. Actually yes. This is exactly what this entire article was about. Using that method, you'd have to restore the entire System State of the machine in order to restore any of the DFS user data.

    As I stated earlier, if you instead backup the users' data through the share you will be able to restore any file back to the share without having to restore the entire System State of the machine. Just be sure and exclude the "DFSPrivate" folder in each of the shares. You DO however want to continue to backup the machine's System State so that in the event of a catostrophic failure you will still be able to recover from it.

    Does that help?