BE2010 R3 & Sharepoint Trans Log Backup

[pdalte]

Hi. I am wondering if anyone can explain what I am seeing.

I am backing up a Sharepoint 2003 farm using the Sharepoint agent on Backup Exec 2010 R3.

I do fulls, incrementals and transaction log backups. All look fine except the transaction log one.

The result of the transaction log backup is 100% success, except that it says "the database is in full mode ... bla bla".

As far as I can see, the transaction log backup is fully copying the databases and the transaction logs, and not trunkating the logs.

So, the transaction log backup is even bigger than the full and not clearing the log content.

Thanks in advance. Best regards, Pedro.

[ZeRoC00L]

Did you configure the job with "Log - Back up and truncate transaction log"

And have you seen this technote:

http://www.symantec.com/docs/TECH125960

[pdalte]

Yes, I have a policy set with the three jobs. Full, Differential and Transaction log.

And yes, I saw the tech note, but it says:

"Currently there is no workaround for this issue as it is just a GUI (Graphical User Interface) issue"

This is not the case here, because I confirmed that the logs were not trunkated - not just a GUI issue.

And is it supposed to do a full backup on the databases as well when you select the Transaction Log option?!

Thanks again. Pedro.

[RSSilva]

Viva Pedro,

espero que esteja tudo bem contigo:)

How did you check that the Logs were not trunkated ? By the phisical size ? Because the Log Tuncation does not reduce the phisical size of the .ldf file, its is just cleared logically.

Abraço,

Rui Silva

[pdalte]

Olá Rui.

No, I generated a disk usage report in SQL Management Console.

The usage report shows that pretty much all the space within the transaction log file is allocated.

Obrigado, Pedro.

[Striker_303]

After performing "Log - Backup the size of the physical log file remains unchanged

Have a look at this: http://www.symantec.com/docs/TECH33654

Sharepoint also uses SQL in the backend and should apply the same.

[pdalte]

I appreciate your help, but the physical size of the files is not the problem here.

Issuing the shrink operation in SQL will not reduce the size of the physical file because it is full. I believe the transaction log backup was supposed to clear the file contents first in order to allow me to shrink the physical file – which is not happening. I have this working flawlessly with other SQL database backups, using the SQL agent.

And, as I said before, I also find it strange the size of the transaction log backup job. The total size of the data backed in this job is the sum of the databases and transaction log physical files – too big.

[Striker_303]

Well I would say - Go to policy - edit template and double check the backup method under sharepoint option  - "Log - Back up and truncate transaction log"

so my point is make sure Backup method is selected as log under sharepoint and not SQL option.

Also does the backup work using sharepoint internal utility.

[pdalte · Accepted solution]

Well, I think I've managed to fix it. I’ll post it here just in case someone finds the same.

I did have the option "Log - Back up and truncate transaction log" selected in the Sharepoint agent options. I had a look at the Backup reports from the SQL Manager console and saw that my Transaction Log Backups were actually showing up there as a “Database Backup”, as if it was a Full.

So, I went back to my job definition and changed from "Log - Back up and truncate transaction log" to Full, and saved the policy. Then, went back in and changed it back to "Log - Back up and truncate transaction log" again – just one of those tricks you usually use on dodgy software :).
Although it should not be necessary, I also went to the SQL agent definition and changed the option there from Full to Transaction Log as well. Recreated the jobs based on the policy and as far as I can see it is working (?!). It has backed up the transaction logs for two databases so far and those logs were emptied. One of these must have fixed it… weird huh?

Thanks for your help. Best regards, Pedro.