Backup Exec Persistent Errors-SQL Server-Sharepoint

[yurisend]

I have symantec backup exec setup with 6 different hard drive, one for everyday of the week and two for friday. Each removable USB harddrive is setup as its own non-removable device, each one with a different B2D folder on it, and they are all placed into the same device pool. Symantec is setup to run with partial overwrite protection, without prompting. Everywhere it is possible, I have allowed for overwriting. 

I am backing up domain controllers, exchange server, as well as a sharepoint server, and a SQL database on the same machine. I am having many problems with the SQL/Sharepoint backups. I am consistently getting error messages that the resource (i.e. the Sharepoint server with SQL) does not support the option to enable the restore of individual items. I realize this has to do with granular recovery. I have the granular recovery option checked in the SQL server/sharepoint settings in Symantec, AND I have the option of a FULL backp enabled both in Symantec and in each of the SQL databases, yet I still get this error.

Also, I am getting errors for each of the databases (all that have a FULL backup enabled) that: so and so database is config’ed to maintain transaction logs. Transaction logs are not being performed. This will result in the log growing to fill all available disk space. Regular log backups should be schedules or the database should be changed to “simple” recovery mode.

Now, if I change the SQL databases to simple, then wont this conflict with the granular recovery? (even though it doesn’t seem to be working anyway, this is how I understand it).

Any help would be greatly appreciated

[CraigV]

Hi,

For your first error, check the TN below...

http://www.symantec.com/business/support/index?page=content&id=TECH60504

For your second error, check the TN below:

http://www.symantec.com/business/support/index?page=content&id=TECH126063

Thanks!

[VJware]

Are you using the Sharepoint agent to backup Sharepoint ?

Recovery models such as simple, full does not affect GRT...Check with your SQL admin to see what sort of recovery model suits your environment & based on that, transaction logs backups need to be configured ...

[pkh]

GRT is the ability to restore an individual object from a backup, e.g. restoring a SQL database from a backup of the vmdk/vhd backup.  This is different from point-in-time restores which requires you to use transaction logs.

A Sharepoint farm is normally spread over a couple of SQL databases.  If you enable full recovery mode for the databases, i.e. maintain transaction logs, you can do point-in-time restores of the individual databases, but you would probably end up with a logically inconsistent Sharepoint farm.  This is because it is very difficult to synchronise a couple of SQL databases.  Hence the recommendation to switch to Simple Recovery Mode, i.e. don't maintain a transaction log and loose the ability to do point-in-time restores.  Once to switch to Simple Recovery Mode, you would not get the transaction log error message.  Before you switch to Simple Recovery Mode, do check with your Sharepoint admin.

[Russ_Perry]

The error related to GRT being unsupported for Sharepoint: This error commonly comes up if the Sharepoint content DBs being backed up have any compression or encryption enabled which is unsupported with Sharepoint agent GRT. The error also might come up if there is a problem with the Remote Agent service loading up the Sharepoint agent (very uncommon).

The Sharepoint and SQL agent work the same way using traditional SQL full/diff/inc methods. If you want to do incremental backups with either agent the DBs must be in full recovery model.  With Sharepoint, while the agent will support incremental backups, a point in time restore isnn't recommended because of the synchronization among the Sharepoint DBs.  If you have DBs in full recovery model and don't do incremental backups you'll start getting warnings that log backups aren't being performed.  You can either change the DB recovery model or do log backups to truncate the logs.

Russ