cancel
Showing results for 
Search instead for 
Did you mean: 

Exceptions on SBS 2011 Backup Jobs

Ian_Watts
Level 2

I keep getting this exception on my server's full/incremental job pair:

V-79-57344-33925 - Error: ShareWebDb.mdf is a component of a SharePoint server farm. It must be backed up using the ...

I have a Farm job, runs fine.
I do have a support case with Symantec Tech Support, but so far they are dodging the real issue and feeding me busy work.

Months ago when I installed this box, I moved the SharePoint databases and such using the SBS Console, to the "D:" data volume.. among other file shares and such.

Beginning 12/14, the Full job (on Fridays..) threw this exception.  That is thrown, as is every DB and log file for SharePoint for CompanyWeb.. which comes with SBS.

The first suggestion by support is to feed them version info and ensure my LiveUpdate is up to date.  It is.

The second suggestion was that I should exclude the SharePoint Resources and corresponding SQL instances/dbs from my main job's backup selections.. they already were.  Any SQL on this SBS box I don't care about.. my LoB server hosting an ERP product, I do care about.. not an issue to exclude all of it.

The third suggestion was that I should exclude the LDF/MDF pairs from the backup selection.

Okay.. but that turns off SDR.  YES, they are on D:, not C:.

As an MSP, I have multiple clients and multiple cases of this problem.  Some clients, I have gone so far as uninstall SP from SBS.. a different side-effect which makes SBS cry, but not Symantec's problem I guess.

 

First problem.. why aren't any of the kb articles current with Backup Exec 2012 issues? Every situation I encounter has articles about former versions.. including the "updated" articles.

Second problem.. As mentioned, this is one among at least six clients with this issue.  We using a monitoring/management system and agent.. I really want these backups to SUCCEED.. else I am looking at them daily.. so saying "meh, you know it's alright, deal with it" is not a solution.  We are looking at other backup solutions at this point.. we already abandoned Endpoint Protection about two years ago.

While I wait for the next busywork request from Support, anybody got the fix?

2 REPLIES 2

Sush---
Level 6
Employee Accredited Certified

Hello Ian,

    Please refer to the following technote which is about BE 2012.

http://www.symantec.com/docs/TECH196215 : SQL or File backup shows exceptions - Error: SPDBName is a component of a SharePoint server farm. It must be backed up using the Backup Exec Agent for Microsoft SharePoint Portal Server.

Please check if the workaround mentioned in this technnote helps.

 

Thanks,

-Sush...

Ian_Watts
Level 2
The workarounds are unacceptible. Here's why: Workarounds: 1) Confirm in the Sharepoint agent backups of the Sharepoint farm that all databases are properly protected with successful backups. The exceptions for those same databases can then be safely ignored in the SQL agent or file backup. 2) For SQL agent backup exceptions, in the backup job for the SQL server, the Sharepoint databases can be unchecked for backup. Note that in selecting only non-Sharepoint databases for backup in this way, if a new SQL database is created it won't be automatically added to the backup and must be manually checked in selections. 3) For File backup exceptions, an exclusion for SQL database file types (*.MDF) can be added. ===== 1) The Farm backup is properly protecting SharePoint. The selections are good, as are the backups. I'm an MSP and monitor backup jobs for multiple clients.. I cannot "ignore" an unsuccessful backup, I need a real solution. 2) The main job already has SQL instances (all.. I don't care about any of the instances or DBs..) unselected. 3) I cannot exclude the files.. on either C: or D:.. SDR will turn off. The last response on my case from Symantec is this: "You will have to move the database files to a different location If you want the backup to complete without exceptions and without turning the SDR off." Okay.. I already used SBS Console to move the DBs to D: way back when.. I cannot move them to some "other magical location which SDR will be happy about"... make it work.