Backup Exec 2012: Backup ESXi VM with GRT and SQL Database

[nwickord]

Hello everyone

I have read across a lot of discussion threads and solution links, but somehow I just don't this szenario to work without error messages.

I have one back job that backs up about 8 VMs during the vCenter Server with GRT. On one of the VMs I have a MS SQL Server with databases configured to maintain transaction logs.

So the backup is running fine, but everytime I get the follwing exception:

V-79-57344-38728 - The SQL database 'DATABASE' on virtual machine '\(DC)ASM(DC)\vm\DB-Servers\db004' is configured to maintain transaction logs, but transaction log backups are not being performed. Not backing up the transaction log results in the log growing in size until it fills all available disk space. You should either schedule regular log backups or change the database to the simple recovery mode.

My Google searches brought up this article https://www-secure.symantec.com/connect/forums/backup-exec-2012-sql-transaction-log-backups.

So I created another job using the db-server directly (not via vCenter) just backing up the SQL database as recommended in the article above and also in this Tech Note http://www.symantec.com/business/support/index?page=content&id=TECH137587

When running this job (full backup) the first time I receive the same error as above:

V-79-57344-38728 - The SQL database 'DATABASE' on virtual machine '\(DC)ASM(DC)\vm\DB-Servers\db004' is configured to maintain transaction logs, but transaction log backups are not being performed. Not backing up the transaction log results in the log growing in size until it fills all available disk space. You should either schedule regular log backups or change the database to the simple recovery mode.

When I run the incremental backups I get this error:

V-79-57344-867 - The last Full backup of database DATABASE was not made by this application.  Run a new Full backup, then run this job again.

From what I understand, the error occurs, because after the full backup of the database only, the GRT-backup is run that makes another full backup of the database, and after that, the incremental job fails.

Can someone please tell me exactly:

How many jobs do I need?

How should they be configured?

How should they be scheduled? Which jobs runs first etc.

I really appreciate you help, since it seems that I just don't understand all the other related articles and tech notes.

Thanks a lot!

Nadine

[pkh · Accepted solution]

What probably happened is that you run a VM backup between your full SQL backup and your incremental SQL backup. This will disrupt the sequence and cause the second error message. If you want to do VM backups then do them just before the full SQL backups.

[nwickord]

Thanks for your reply. That is true, I ran the full SQL backup at 4.00 pm, than the VM backup at 11.00 pm and the SQL incremental backup at 4.00 pm the next day. So the VM backup was between the two SQL backups.

So should I run a full SQL backup at 4.00 pm and an incremental backup at let's say 6.00 pm EVERYDAY and the VM backup at 11.00pm or is it enough to run the SQL backups in that order only once a week?

[VJware]

At least 3 backups jobs would be required...

1) a backup of the SQL VM with GRT using the VMware agent

2) a backup of the SQL DBs (which have either the full or bulk-logged recovery model) using the Remote Agent

2.b) add a log backup (incremental) stage to the above backup which would backup the transaction logs...

You can schedule as per your convenience, just keeping one thing in mind (as pkh mentioned above), the chain of the Remote agent backups (full and log) should not be interrupted by the Vmware agent backup....so it actually does not matter whether you run the Vmware agent backup followed by the remote agent full + log backups or run the remote agent full + log backups followed by the Vmware agent as long as the remote agent backup sequence is maintained.

[pkh]

With your VM backup you actually don't need to run your full SQL backup, except that it is needed so that you can do a log backup to truncate the log. One advantage of having a full SQL backup is that the restore is faster than using the VM backup. If you don't want to do frequent full SQL backups then you can delay them until your logs are full, e.g. a weekly full followed by your log backup. There is no necessity to delay running the log backup after the full backup. You can run them back-to-back