SQL Server 2008 Log File

[J-Ake]

I get the following for each database on SQL Server 2008 R2 that is backed up;

V-79-40960-37914  Database Archives is configured to maintain transaction logs.  Transaction log backups are not being performed.  This will result in the log growing to fill all available disk space.  Regular log backups should be scheduled or the database should be changed to the simple recovery mode.

I did the following;

HKEY_LOCAL_MACHINE\SOFTWARE\Symantec\Backup Exec for Windows\Backup Exec\Engine\SQL Server\Number of Non-Log Backups Before Warning

The default value is a decimal value of 10
Increasing this value will increase the number of full database backups it will take to display the exception
Setting the value to 0 will disable this exception from ever occurring.  Symantec does not recommend setting this value to 0.

Where I set the registry key to zero to disable this, but Backup Exec 2010 R2 continues to complain about this in the log and flagging the backup as ended with exceptions. I've even restarted all the services just to ensure the key was picked up properly.

I also find it disappointing that given the cost of this product, this becomes an issue backing up the SQL databases. When doing a full backup of the systems and including the SQL databases, it should do what is required to handle the logs without having to create a sepaarte backup for this purpose.

So even though the registry key has been set to 0, why does is this not disabled and so eliminate this as a backup warning?

[Ken_Putnam]

When doing a full backup of the systems and including the SQL databases, it should do what is required to handle the logs without having to create a sepaarte backup for this purpose.

You would certainly think so, wouldn't you, but BackupExec has been this way since v7.0 and SQL 6.0

You could always add a thread to the "ideas" area (Grey menu bar\Forums\Ideas) and request this, but I wouldn't hold my breath waiting

[pkh]

To clear the logs, you need to run a separate job to backup the logs and truncate it.  Like Ken said, it has been this way forever.

[J-Ake]

Why does setting the registry setting I mentioned above, to what was in the KB note not work and disable this exception from happening as they documented?

[pkh]

If the registry setting had work, it is just postponing the inevitable, i.e. you still have to run a job to backup the logs and truncate them.  Why not schedule a log backup to run after your full backup?  The logs are of no use once you have a full backup so there is no point in accummulating them.  Depending on the activity of your database users, the log backup should be quite fast.  I backup my logs to disk to speed up things.

[Nimish_Patel · Accepted solution]

You can go througn following documents to find out more about SQL log backups.

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

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

If any of the above mentioned document help you in answering your question. Mark it as sollution.

[WJS-IT]

The registry fix does not work despite the fact the KB says it does. A person may use a different method to backup and truncate the logs than depending on Backup Exec to do this, so the registery hack should work, but doesn't appear to.

The second point, for the price of Backup Exec with the SQL addon, you would really think Symantec would handle this properly with a single back up action and not having to resort to a separate backup just for the logs.

There are solution out there that handle this properly and it make me wonder why Backup Exec doesn't. I'm not likely to renew our license and go for a different backup solution that actually works as a complete solution.

[J-Ake]

Thanks fo rthe pointers to the HowTo articles, I'll take a look at them and see how that goes.

RE: PKH - I backup the logs in other ways and the truncation, which is part of the reason I don't need Backup Exec telling every backup about the logs.

The registry key setting should have solved this and it appears that Backup Exec 2010 R2 ignores it and complains anyways.

But still in the grand scheme of things, Backup Exec should be able to do this in one complete backup without having to resort to two backups. If other backup solutions can do this, why not Backup Exec?

Jake