Eric Stewart: Running Off At The Mouth

Merry Christmas.  I’ve actually been doing work today.

So I’m now learning a bit about Symantec Backup Exec.  While not total crap software, it does have some idiosyncrasies that I’m beginning to dislike.

I inherited the current set up from someone who left the position probably three or four weeks before I got in, and their documentation was … well, lacking.  I found several jobs “on hold” for no apparent reason, and a couple of the BE media servers not doing any successful backups.

I’ve had a couple of cases where the BE Job Service would crash on the media servers for certain jobs.  In one case (a Linux box), I eventually managed to find a directory that, once excluded from the backups, was the culprit.  I haven’t had the opportunity to track down what file might have caused the issue.  Maybe some day I’ll open a case with Symantec …

In this most recent issue, a couple of shares were being backed up on a system (instead of being backed up directly from the drives).  “Okay,” I thought, “I don’t know why you’re not accessing the files directly, but fine – you should be able to back up the files via the share mounts instead of finding them on the drive/directory/folder where they’re being shared from.”  Thing is, for some (still unknown) reason, the BE Remote Agent service on the server being backed up would die off, causing a “connection to target system has been lost. Backup set canceled” issue.

After a late night session of reinstalling the BE Remote Agent (making an incorrect assumption that that’s where the problem lie), I finally decided to redo the selection list for the job (again, for like the fifth time), this time hitting the files directly from the drive instead of via shares.

Here’s the funny thing – the full backup) job would run, successfully, and would back up less than 2K of data for directories I know had well over 50 GB of data in them.

That kind of freaked me out.

After a search on the net (which I managed to find the solution at but without signing up to a site that has constantly plagued my search results, requesting/requiring me to sign up to see the solution), the solution I discovered was:

Directories that are managed/shared through DFS file shares should be backed up via “Shadow Copy Components”.  If the directory you’re backing up has a hidden “Dfsrprivate” folder in it, you should be able to find it via:

Shadow Copy Components\User Data\Distributed File System Replication\DfsrReplicatedFolders

And it will back up appropriately there.

The worst part of all this?

In the end, I discovered that a job on another server was successfully backing up those same files using the appropriate method.