DFS backup errors (Access is Denied) in fully patched 11D

[Ken_Wallewein]

I'm getting errors trying to backup DFS roots configured on my BE 11D media server:

Access denied to directory DFSRoots\Main\K&M\.
V-79-57344-33928 - Access is denied.

I have two DFS roots on this server, with multiple shares on each.  Every one of them gets this same error. 

This is my only server with DFS -- I'm using it primarily to virtualize my UNCs so I won't have to redirect clients in case of future server changes.  All of the shares are actually local, and I'm already backing them directly.  The main reason I'm trying to back up the DFS is to record the configuration.  Maybe that's redundant and unnecessary (sic). 

My research indicates that this was a known issue with 10D, especially with multiple DFS roots, but it was apparently resolved with a hotfix, and this is 11D, so it shouldn't be an issue, should it? 

Other details:  I'm using Advanced Open File in automatic mode, backup following junction points, single instance backup is not selected.  The OS is Windows Server 2003 R2 Standard x64, fully current on updates.  It's a DC.

Oh, and Live Update says I'm fully up to date.

Any ideas?

/kenw

[Ben_L_]

Are you backing up the DFS folders via shadow copy or from the drive level?  If you are backing them up through the drive level are you stopping the DFS folders before you run the backup?

[Ken_Wallewein]

> Are you backing up the DFS folders via shadow copy or from the drive level? 

Not sure I understand the question properly.  I'm using AOFO with "Automatically select..."  and "Process logical volumes one at a time".  Your question seems to imply there's another way I should perhaps be aware of.  If so, could you provide more detail please?

The local directory structures, including those that are being shared via Windows SMB/CIFS file sharing and DFS, are being backed up directly without error.

The DFS roots are defined as subdirectories on separate local drive (E:\DFSRoots\...). These are also selected for direct backup.   They are strictly logical directory structures -- there is no local data in them.  I'm trying to back them up in order to accurately record the server configuration to allow complete restoration.  This is what is failing with errors like:

    Access denied to directory DFSRoots\Main\BulkStorage\.

    V-79-57344-33928 - Access is denied.

> If you are backing them up through the drive level are you stopping the DFS folders before you run the backup?

I am not stopping anything prior to backup, and would prefer not to.  Is there documentations somewhere that says I should?  The error messages I'm getting, and the references on the web site, make no hint of this.

FWIW, one thing I am NOT doing is trying to back up DFS structures or data via the network.  There's no need to, as all the data is local.  I just want to record the DFS structure so that if I do a full restore, my DFS configuration is properly restored.

It sounds as though you may be implying that locally defined DFS roots should be manually excluded from normal local drive backup selections.

/kenw

[Ben_L_]

AOFO doesn't matter with this backup.

DFS data can be backed up in two ways using Backup Exec.

1. Through shadow copy
2. By stopping the DFS services and then backing up the data through the drive level selections.

If you attempt to backup the DFS data via the drive letter with the service selections, it will only backup the folder structure and not any of the data.

I would suggest attempt to just backup your Shadow Copy Components of this server to make sure you can backup the DFS data correctly.  When you check your restore selections after the backup is completed just expand out the shadow copy components down to the DFS data.

[Ken_Wallewein]

I think we're getting somewhere, but there's some confusion.

I think we need to distinguish between the DFS root folders and the DFS data folders.  I may be being confused by your terminology, e.g., when you refer to "service selections".

> DFS data can be backed up in two ways using Backup Exec.

I'm not having any problem backing up DFS _data_.  I'm backing it up through drive level selection.  And since this is the only server hosting the data, there's no synchronization taking place, so using shadow copy or stopping DFS should be unnecessary.  But I take your point as to why and when it would be; thank you for that.

>If you attempt to backup the DFS data via the drive letter with the service selections, it

> will only backup the folder structure and not any of the data.

That's the problem: it doesn't.  I'm just trying to back up the DFS root folders to record the DFS share structure, not the data, and I get errors when I try.  As I said before, "I just want to record the DFS structure so that if I do a full restore, my DFS configuration is properly restored."  In other words, when I get the errors, I'm not trying to back up the data, I'm trying to back up the DFS root structure so that if I do a complete restore, my DFS share definitions would be recreated. 

Am I misunderstanding that?  I.e., are those definitions actually part of the System State?  Given that the roots are actual directory structures within Windows, it would seem necessary to back them up.

Interestingly, if I check the restore points, the DFS shares do show up despite the error messages on backup, although there's no indication as to which normal shares they link to. Not having used DFS with BE before, I don't know whether that's normal or not.  Is it? 

By the way, checking out your suggestions, I realized that I didn't have shadow copy running on any normal drives at all (this is a new server build mounting old volumes).   I'll be correcting that immediately; maybe it'll affect the problem.  Would it have any connection to the fact that my restore points all seem to say "Snapshot Full"?

[Ben_L_]

I used the wrong phrase for that, instead of "service selections" I should of said "service running".

Even if you want to just record the folder structure, you really need to stop the DFS service on that server before backing up DFS data (this includes folders, structure, anything that is on the disk that is controlled by DFS) via the drive letter or you are going to have problems.

The definitions are stored in the Shadow Copy portion of the backup as well, so If you backup Shadow Copy you will get the folder structure.

The shadow copy service should not be running all the time, the service is called Volume Shadow Copy.  This is something different from the backup.  If you look in your backup selections, you will see a section called Shadow Cop Components.  This is what I am refering to when I mention Shadow Copy, when you Select Shadow Copy Components, this backups up the DFS data correctly without having to shutdown the DFS service.

[Garen_Keshishia]

I wouldn't bother with Symantec's workarounds for backuping R2 DFS folders.

Stoping services is unacceptable and using Shadow Copies does not work.

Instead I just backup the DFS folders at the Share level.

[Ken_Wallewein]

After giving it some thought, I think I agree with you. 

All that's causing me a problem is having the backup job record the DFS configuration, not the data.  I can record the configuration manually, and if I have to recreate it manually, so be it.   Not why I got BE, but I don't see another reasonable option.  Would have been nice to have it better documented.

Does make me want to look around, though...

/kenw

[Chris_Herbert_2]

Just implemented DFS and last night BE 11d did not back up any of my data. The job didn't fail, it just backed nothing up.

Backing up at share level as opposed to selecting the local disk on the file server worked fine for me. No stopping DFS services required.

Thanks