Backup job Fails: Error e0008488 Access Is Denied

** EDIT **

Just to check what went on during the backup i tried and observed the following:

1. Created a new 'restore' job and navigated to the restore by Media option. Could see that the files were written to the Tape Drive, however, the ones which were listed as either 'skipped' or 'corrupt' came up with a red cross to the left of them.
2. Total Data written to the Tapes is around 1.6 TB out of 1.8 TB.
3. My point is if 1.6 TB is "good" i should probably retain these Tapes because atleast i would have more than 80% of the data backed up (ignore the math) for worst case scenario considering the NAS goes toast or something in the future before i can get a complete backup set.

The most important question is this - are the files listed as 'skipped' or 'corrupt' the only files that were not backed up (due to the error)  to the tapes ?

Or there's more files that i just don't know about at the moment ?

Thanks a Lot !

** EDIT 2 **

I went through the XML Log file generated for this job and observed the following:

1. The XML File has logged all the files which were marked as 'skipped' under set detail information - backup. It has also logged that the files which were skipped were 'in use' and resulted in an 'Access Denied' error. This piece of info was not straightaway available under the Job History in 'set detail information - backup' within the BE Console.
2. The info mentioned above atleast eliminates "Security Permissions" as a possibility for the Access Denied Error.
3. Now - I had enabled AOFO in the Backup Job properties. If its still unable to backup files that are open/in-use, what are my ways around it to get the Job done since enabling AOFO has'nt been enough. 

Thanks a Lot !

** EDIT 3 **

I just calculated the size of the Backup Target and the size of the Backed Up Data (per BE Console)

- Target Share = 1843.2 GB

- Backed Up Byte Count = 1670 GB

- There's still approx 170 GB unacccounted for.

- Looking at the total size of the files that were skipped and reported corrupt, which is far less than 170 GB, i should still have a hell of a lot more files that may have not been backed up at all apart from the ones that were reported as 'skipped' or 'corrupt'.

Not sure which way to go now ..

Any help would be highly appreciated.

Thanks !

Hi pkh

Thanks for your response.

1 - Is the BE SA differrent from the Domain account configured for Backups ? Where can i verify this ?

2 - The files (that were skipped) are all primarily excel files. After i enabled AOFO i did see a considerable increase in the total data being backed as compared to the last time it failed. If AOFO is not designed to work with a NAS device i am kind of struggling to understand how willl the backup ever work because some file or the other will inevitably be open considering the size of the NAS Server and the number of users who access it.

Thanks a lot !

The BESA is the account used to start most of the BE services.  It can be the BE logon account.  It can also be different.

Don't you run your backups after office hours when your users are not working?

Hi pkh

Thanks for your response.

The backup does run after office hours but am not sure if everybody in the office here religiously close all there running applications and log off/shutdown their PCs.

The Domain Admin account is the account under which all the services are configured. This Account also has "Full Control" priviledges over the Share which is being backed up.

Thanks a lot !

Unfortunately, there is no easy solution to your problem.  You would just have to remind your users to close their applications before they leave the office.

Thanks pkh

I have decided to create 2 new sets of backup jobs and divide the entire NAS Data between them just so i could get a seggregated view of what's going on.

I have run into issues while testing Resource Credentials during the Job Creation.

I have opened a new thread regarding it.

I shall comeback to this one once i have a new set of backup jobs running for the NAS Device.

Thanks a lot!

http://www.symantec.com/docs/TECH189560