backup exec 2010 SQL DB Exception

[Mat_Ashmore]

Hi,

Have just upgraded from 12.5 to 2010 & applied all the live updates.  Running Windows 2003 Storage Server 2003 R2 SP2 64Bit, SQL Server Standard 2005 SP3.

Since the upgrade to 2010 2 days ago, my backup jobs have gone up some size (no changes to the job selection & no changes in files on the disk).

After looking closer the extra 40GIG added to the job has come from the SQL backups of which I have a 2010 agent for.  It appears that BE is now backing up the log files for the 3 DBs that use one.  Obviously this was never the case in 12.5 & the method of restore would have been full db restore from tape & if logs available a roll forward etc...  Part of the upgrade has maintained the job selection lists so I no nothing has changed & everything has been selected...

I also now get these exceptions in the backup job log...

Backup- SERVER
V-79-40960-37914 - Database db1 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.

V-79-40960-37914 - Database db2 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.

V-79-40960-37914 - Database db3 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.

Is this something that they have introduced in the upgrade?  I understand about the default warn on 10 SQL backups but how comes all of a sudden the logs are backed up by default when in 12.5 they obviously wern't?

Please help, I just want to get a better understanding of things...

[RahulG]

this should resolve it  http://support.veritas.com/docs/345321

[RahulG]

Are you performing transcation log backup using Sql --if so it is not required ....
the above warnings can be ignored .
you need to check job log and compare the job log with some old job log to find why the size of the backup have increased.

[Mat_Ashmore]

Hi Rahul,

Thanks for the quick response.  The difference in size is almost definately the includsion now of x 3 log files.  However when the backup was running under 12.5 these were not being included...  Is there a reason as to why 2010 now includes these & 12.5 didn't?

When I look at the restore options against a backup from 12.5 with (SQL/Full) against its name the 3 DB's that are in full recovery mode have a size that relates just to its DB.

However when I look at a restore option against the backup taken after the 2010 upgrade with (Snapshot SQL/FULL) against its name the size of the 3 DB's which are in full recovery mode is the DB + the log file...

Many thanks in advance.

[RahulG · Accepted solution]

The the backup is performed using AOFO then it would have (Snapshot SQL/FULL) ...

[Mat_Ashmore]

excellent!!!  I understand now. its the aofo option thats adjusted the setup.  i have shrunk the trans log for now & will leave the backup job as is & setup a suitable sql server mant plan which backs up the logs so its will truncate them.  then ill back them up with symantec to tape.

many thanks Rahul for your help.

[RahulG]

Please mark it as resolution if that resolved the issue ....cheers !!!

[Mat_Ashmore]

one quick question.  i though the default behaviour of this exception as per symantec tech doc

http://seer.entsupport.symantec.com/docs/345321.htm

was to warn about this on every 12th full backup of the sql db?  mines warning me on every one!  I have check the registry & its set to the default 10...

also - is it clever enough that it knows you are backing up the trans with a maint plan?  ie does it read from the sql db statistics of when the last time the trans logs were backed up?  maybe this will dissapear that way?