cancel
Showing results for 
Search instead for 
Did you mean: 

Backup to Disk Issue for SharePoint 2007

greeck
Level 2

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.

1 ACCEPTED SOLUTION

Accepted Solutions

Russ_Perry
Level 6
Employee

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
 

View solution in original post

18 REPLIES 18

greeck
Level 2

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?

bozard
Not applicable
Partner

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

Ken_Putnam
Level 6

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

Wurzy
Not applicable
Partner

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

frizbian
Not applicable

We have SharePoint 2010, but the same result.  Tape works; disk does not.  I need it to work on backup to disk.

Infoniqa-webch
Level 3
Partner

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

cmeyer25
Not applicable

Any updates for this issue?  We are using Sharepoint WSS 3.0.

greeck
Level 2

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.

Michael-Tech
Level 2
Employee Accredited

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?

nackros
Level 4
Partner Accredited

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..

Ken_Putnam
Level 6

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

nackros
Level 4
Partner Accredited

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.

Ken_Putnam
Level 6

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

JeffinIT
Not applicable

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.

Marc_Sirois
Not applicable

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.

Ian_E
Not applicable
Employee Accredited

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!

Peter_A_
Not applicable

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.

Russ_Perry
Level 6
Employee

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