BE 2012 Sharepoint Log Backups

[Peter_Sheridan]

Hello,

So I hear that Sharepoint transaction log backups are no longer supported in BE2012. What is the new solution for doing these now?

Cheers

Peter Sheridan

[pkh · Accepted solution]

See this recommendation to set the recovery mode to simple so that you do not back up the transaction log.

https://www-secure.symantec.com/connect/forums/sharepoint-server-recovery#comment-6978381

[Peter_Sheridan]

Hi Pkh,

Thanks for the reply.

I am no huge expert when it comes to sharepoint and transaction logs so was wondering what the disadvantage of doing this would be?

My understanding of transaction logs is that when a change is made to a database it also keeps a log so that you can see everything that has happened. Then you can do something like "replay transaction logs" and basically bring a database back to a certain point in time if needed. I belive thats the theory behind it anyway...

Wouldn't it be good to retain this option?

[pkh]

Not very elegant, but what you have described is how point-in-time restore works.  PIT restore is good for 1 database.   Sharepoint transaction can involve a couple of databases.  Suppose the transaction involes 5 databases.  When you restore 1 database, regardless of whether you just restore the database from your backup or a PIT restore, it willl be out of sync with the other databases.  You need the Sharepoint agent to restore your databases such that all 5 of them would be in sync after the restore.  Since you are not going to restore individual databases, there is no point in keeping transaction logs.  Hence the earlier recommendation not to use them.  I would recommend that you check with Microsoft whether it is o.k. not to use transaction logging with a Sharepoint farm.

[Russ_Perry]

The reason that log backups are not supported in Sharepoint any longer is as pkh discusses above - doing point in time restores can cause synchronization problems among Sharepoint DBs.  For this reason, in Backup Exec 10D, 11, 12, and 12.5 log backups weren't possible for Sharepoint but they were added in for 2010 R1/2/3 though mostly to truncate the logs.  With 2012, it's recommended to use simple recovery model for all DBs in Sharepoint since there is now the block level incremental and differential backups possible for backup space/time benefits.  The new block level incremental/differential backups, allow you to restore to the time that those backups were performed but nothing more granular.

Russ

[pkh]

I can understand your logic, but what I am not sure is whether setting the recovery mode to full is a Sharepoint requirement. (I am not a Sharepoint user.) There are some applications which require full recovery mode for whatever reason.

[Peter_Sheridan]

Thanks guys. I have changed the database recovery mode to simple on the effected databases and the errors in backup exec went away :)