03-07-2011 09:05 AM
Recently added licenses for backup of MOSS (2007) Farm to our BE2010 solution. We have one volume for B2D (14TB) and it is configured for dedupe. All B2D jobs are Full Backups and then Duplicate to Tape, point to the same Media Sets and run fine except for MOSS. The job fails with a security error (see below) every time on the same SiteContent and causes the whole job to report as "Failed" even though it appears that the data is there. The account used to backup the Farm can login to all site content. The error for the SiteContent is "Error: e0008445 - The media operation was terminated by the user.". The job history shows Error Code E0001602.
There is a Duplicate job associated to the d2d job and it subsequently fails every time (approx. 50-60MB data copied) with the following error "Final error: 0xe00084e4 - The DC2000 cartridge has was formatted with an unrecognized format. Final error category: Backup Media Errors (job history shows Error Code E00084E4). I assume that the Duplicate job fails because it sees that there was a media error with the parent job.
We followed the best practices guide when setting up the job and I cannot see why it would be failing. The job log makes it look like the issue is related to the B2D media set. Perhaps I need to setup a different media set for MOSS? The settings are pretty generic so I cannot see a reason for failure. This is a new solution for us... a Dell PowerVault DL Backup to Disk DL2200 with an iSCSI attached MD1200 with 12 2TB drives (RAID5) so we may have something misconfigured.
Thanks in advance for any help.
Job name : SharePoint Farm1-SharePoint-Full Backup Job type : Backup Job status : Failed Job log : C:\Program Files\Symantec\Backup Exec\Data\BEX_IUBEXEC01_00084.xml Server name : IUBEXEC01 Selection list name : SharePoint Device name : B2D - Dedupe:6 Target name : B2D - Dedupe Media set name : Daily Media Set 1 All Media Used OST00000038-467AB5B0E2F9FE78 Error category : Security Errors Error : e0001602 - Access is denied (Share point backup). For additional information regarding this error refer to link V-79-57344-5634 |
AOFO: Started for resource: "Board Site\Content-DB 1 (Server1\BoardMemberSiteContent)". Advanced Open File Option used: Microsoft Volume Shadow Copy Service (VSS).
The following volumes are dependent on resource: "E:" .
The snapshot provider used by VSS for volume E: - Microsoft Software Shadow Copy provider 1.0 (Version 1.0.0.7).
Set Information - Board Site\Content-DB 1
(Server1\BoardMemberSiteContent)
Backup Set Information
Family Name: "Media created 3/4/2011 6:00:02 PM"
Backup of "Board Site\Content-DB 1 (Server1\BoardMemberSiteContent)"
Backup set #1 on storage media #1
Backup set description: "Daily full backup of SharePoint"
Backup Method: Full - Back up entire database
The option to enable the restore of individual items from the database backup was selected for this backup.
Backup started on 3/4/2011 at 6:25:43 PM.
Backup Set Detail Information
Media Label: IMG000145
GRT backup set folder: \\.pdvfs\BEXEC01\2\BEData\IMG000145
This operation is being coordinated through the server: Server0
Backup completed on 3/4/2011 at 6:28:01 PM.
Backup Set Summary
Processed 52,316,452 bytes in 2 minutes and 18 seconds.
Throughput rate: 21.7 MB/min
Compression Type: None
This backup set may not contain any data.
Solved! Go to Solution.
07-26-2011 12:22 PM
There are two known issues related to the access denied error during Sharepoint content DB backup with both being related to cataloging the backed up DB to allow GRT restore:
1) The backup is being run with VSS/AOFO enabled. See http://www.symantec.com/docs/TECH163882
Note that VSS/AOFO is normally no problem with Sharepoint backups. These backups will be larger since the backup process will snapshot all database files present rather than create a composite 'dump' of the DB.
2) The content DB showing the failure (you can identify which DB is failing by the line 'This backup set may not contain any data' at the end of the backup set) has more than the default single MDF/single LDF SQL database file. See http://www.symantec.com/docs/TECH153731
Russ
03-07-2011 05:19 PM
I ran the same MOSS backup directly to tape and it completed successfully. Backed up again to disk but first created a different Media Set... failed at the same point. Created a new B2D folder at root of local server's C:... job failed at same point. So, am I to understand that I cannot backup SharePoint to disk... only to tape?
04-05-2011 11:46 AM
I to am having issues backuping up Sharepoint to Disk. I need to find a solution to this problem asap.
Does anyone have an idea of how to resolve this issue?
Thank you
Brandon
04-05-2011 12:00 PM
Don't have a clue what is going on here, if the same job writes OK to tape, but I have set the Support Flag to draw the attention of the Symantec Techs
04-05-2011 01:38 PM
I can backup other sites on sharepoint to disk just not the default webite. It appears to have data in img folder but nothing shows up when you try restore
04-05-2011 03:45 PM
We have SharePoint 2010, but the same result. Tape works; disk does not. I need it to work on backup to disk.
04-12-2011 11:24 PM
Hi all
I also have this issue with an WSS Portal on W2k3.
The BEWS media server is also BEWS 2010R2, with SP1 installed.
Maybe the used media server OS has an impact?
I'm using W2k8 R2 Standard as media server.
I'll open a TAPP case at Symantec today. Hopefully they have already fixed it.
Kind regards
Chris
05-17-2011 08:12 AM
Any updates for this issue? We are using Sharepoint WSS 3.0.
05-24-2011 05:33 AM
I wish that there were an update. At this point I am resigned to backing up MOSS solely to tape... not exactly what I had in mind to do when I purchased our solution. I even went to the extreme of deleting our Dedupe volume and recreated everything. I again tried to backup to both B2D and deupe volumes... no joy. Tech support has been no help as they keep walking me through the same process, over and over.
05-24-2011 10:37 AM
I've seen this issue when backing up to disk with the Advanced Open File Option (AOFO) enabled. Is the AOFO option enabled on your SharePoint backups? If so does the backup still fail if you turn it off?
06-07-2011 05:20 AM
I have the same problem as those above, except I haven´t tested against tape, only B2D.
If I disable AOFO i don´t get any errors but my backup size is reduced to 20GB instead of 80GB, so I assume that I´m missing something in the backup to say the least.. ;)
My sharepoint server is also a Win2k3 and running MOSS 2007 in standalone mode(local SQLExpress).
So why is AOFO neccessary to use for the backup to be complete, and why does it produce this error?
My backupserver is a Win2k8R2 running Be2010R3 with latest patches to date.
Thanks
//Andreas..
06-07-2011 08:07 AM
It is recommended that you NOT use AOFO when backing up a database
You can use CATTOOLS to dump the catalog from one of you large backups and one of your small backups to see what is missing in the small one
06-07-2011 08:47 AM
Where do I find CATTOOLS? I will definately test this.
And do you have an explanation to why my SharePoint backup is 60% larger with AOFO?
When I run the backup without AOFO shouldn´t BE tell me that some files or something cannot be backed up without using AOFO?
Seems to be a strange behaviour, and a strange error message that don´t make any sense.
06-07-2011 09:28 AM
See http://www.symantec.com/docs/TECH136392
As to why AOFO backup is larger. Any files that would have been skipped because they were in use will be backed up in the AOFO run (except any database files skipped buy Active File Exclusion)
Anyway CatTools will tell you for sure
07-05-2011 07:01 AM
Has anyone got a fix for this yet? I am now experiencing the same issue as described, only I was working fine with Windows 2008 R2 running BE2010 R2, w/AOFO until I upgraded to BE2010 R3.
07-13-2011 07:34 AM
I also would like to know if there is a fix. I just upgraded our system from Backup Exec 2010 R2 to R3 and have started seeing this error. Everything was fine before. All I did was update the system.
07-14-2011 02:34 PM
When using the database agent to backup your resource it's going to make the data request and retrieve the actual data in the database.
When using AOFO it's going to ask for the 'open' files in use from the database, which will include any 'white space' that has been allocated for the database to grow into, so if you have 20gb of data and it can grow to 80gb, the 80gb is what will be 'open' to the database, and therefore will be seen as an open file for AOFO.
I hope that helps!
07-19-2011 08:45 PM
I encountered this same issue with Windows Small Business Server 2011 Standard and BackupExec 2010R3 for Windows Small Business Server.
To me, it looked like there was one piece of the backup that was failing, and all the rest was working, so I set out to figure out what the failing section was (the error messages weren't providing that data). In the initial backup, I had selected Microsoft SQL Server "SHAREPOINT" and Microsoft SharePoint Resources, and the backup failed (e10001602 - Access is Denied). I copied the job, and deselected Microsoft SharePoint Resources. I performed a "Test Run", which worked. After that, I enabled the items under Microsoft SharePoint Resources, one at a time, and performed a "Test Run". After I had all of the subordinate items selected, the "Test Run" still worked. I selected "Run Now", and it failed. I tried another "Test Run", and it worked. There appears to be a difference between a "Test Run" and a "Run Now".
I then ran through the exact same sequence, using "Run Now". The failure occured after I added the Microsoft SharePoint Foundation Web component of Microsoft SharePoint Resources. All other components of Microsoft SharePoint Resources worked.
I now have MOST of a SharePoint backup. This isn't as good as a complete SharePoint backup, but I have to hope that it's enough.
While this may not help any users here, I hope it helps Symantec find AND FIX this bug.
07-26-2011 12:22 PM
There are two known issues related to the access denied error during Sharepoint content DB backup with both being related to cataloging the backed up DB to allow GRT restore:
1) The backup is being run with VSS/AOFO enabled. See http://www.symantec.com/docs/TECH163882
Note that VSS/AOFO is normally no problem with Sharepoint backups. These backups will be larger since the backup process will snapshot all database files present rather than create a composite 'dump' of the DB.
2) The content DB showing the failure (you can identify which DB is failing by the line 'This backup set may not contain any data' at the end of the backup set) has more than the default single MDF/single LDF SQL database file. See http://www.symantec.com/docs/TECH153731
Russ