cancel
Showing results for 
Search instead for 
Did you mean: 

Backup Exec - MSSQL 2008R2 - Complains about "Last Backup not done with BE"

Thomas_Zangl
Level 3

Hi,

we are using BE 2012 for backing up our SQL2008R2 instances. Environment: VMWare 5.0U1, DBServer are Windows2008R2 running SQL2008 (all updates&patches). We are doing a weekly fullbackup and a logfile backup every 15 minutes. Every couple days (I dont see a pattern yet) the backup jobs start to fail. The error message is (sorry its German):

"Auftrag beendet am Tuesday, August 14, 2012 um 1:42:29 AM
Abschlussstatus: Fehlgeschlagen
Endgültiger Fehler: 0xe0000363 - Der Backup Exec SQL Agent wurde nicht für die Erstellung des letzten vollständigen, Differenzial- oder Protokoll-Backup dieser Datenbank verwendet. Sie müssen die SQL Agent verwenden, um ein vollständiges Backup zu erstellen, ehe Sie ein Differenzial- oder ein Transaktionsprotokoll-Backup ausführen können."

English:

"Differential/Log backup of SQL database fails with the error The Backup Exec SQL Agent was not used ..."

More information on this error can be found here: http://entced.symantec.com/entt?product=BE&version=14.0.1798&module=eng-no_fs-backup&error=V-79-57344-867&language=DE&build=Retail&os=Windows_V-6.1.7601_SP-1.0_PL-0x2_SU-0x110_PT-0x3

Funny, we dont use any other backup product and I dont see any other backups done by somebody else. However, if I look at the msdb..backupset table, I see that the DB Backup was done by BE and shortly after (or better: shortly before the next failed log backup) I see another fullbackup which is likely the source of my problem. But: it looks like its BE! But under a different username (NT AUTHORITY\SYSTEM instead of our BACKUP user):

It seems BE is somehow schizophrenic ;)

In order to "fix" the log file backup, I need to manually run the fullbackup job. Which is kind anyoing :)

Any ideas whats the cause?
Thanks,

Tom

14 REPLIES 14

Thomas_Zangl
Level 3

I want to add something after I read this article: http://www.symantec.com/business/support/index?page=content&id=TECH58674

It is true, that *nearly all* databases on the affected servers are "restored or detached/attached in the past." We P2V'd them using that way.

VJware
Level 6
Employee Accredited Certified

Have you looked at this KB as well - http://www.symantec.com/business/support/index?page=content&id=TECH137587

Thomas_Zangl
Level 3

Hi,

yes - but I dont see anything related to us. VMs are backup'd using VMWare Data Recovery, and for testing, I disabled the backup of the DBServer. Anyway, I would have only backup'd the OS disks and not the DB disks :)

So no, I dont think this article helps me :(

Thanks! Tom

VJware
Level 6
Employee Accredited Certified

Is this SQL server also hosting the BE database ? If yes, exlcude it from the SQL database backups..

Else, the problem could be due to the fact which you already know about the attaching/detaching of the db's...Were the backups created afresh after the servers were P2Ved ?

Thomas_Zangl
Level 3

Hi,

the BE database is on a seperate server which is not part of this SQL Server farm.

The server itself were *not* P2V'd. The old ones were SQL 2005 based (32 Bit OS) and we moved only the DBs to the new ones. This was done by: creating (an empty) DB on the destination server, make a full backup of the DB on the old server, restore this full backup to the previous created DB, put the DB on the old server into readonly mode and make a log file backup, restore this log file backup on the new server and put it into r/w mode again. So basically its a less disruptive method of "attach/detach" - using the basic backup/restore mechanism.

So, what can I do to fix this problem?

Thanks, Tom

VJware
Level 6
Employee Accredited Certified

from the above screenshot, it shows other log backups being fine (looks like 15 mins intervals) & the then one occurence fails...and it shows NULL as the last backup requestor & this usually implies others and not BE...i guess, the inbuilt SQL backup has been disabled as well...if you are sure that there isn't any other backup or imaging software on this server, would recommend to contact tech support for further assistance...

Thomas_Zangl
Level 3

:) Inbuilt SQL backup *is* disabled (puh, I think I checked that already 5 times). Two things that disturb me: it happens at random time somwhere during the evening (19:00 to midnight) and second, the software major/minor/build version which identifies the backup software used, is the same as BE. Also the backup destination is a virtual file (type 7)...

I may open a ticket through the my.symantec.com website citing this thread?

Tom

Thomas_Zangl
Level 3

Update: thats cool, I cant create a support case because:

MySupport-Anwendungsfehler

 

In der MySupport-Anwendung ist ein Programmfehler aufgetreten. Wiederholen Sie den Vorgang, oder wenden Sie sich an  Symantec Technical Services

Vielen Dank für Ihre Geduld.

German - reads like "The MySupport-Application experienced a programm error... bla "

We better re-think our purchase of 10k+ EUR for this software...

VJware
Level 6
Employee Accredited Certified

Would suggest to contact Support via the phone & have a case logged...the case logger can assist you with the MySupport issue as well & fix it such that you can submit a case online via the portal..

Thomas_Zangl
Level 3

Yea, I will do that. Thanks.

Colin_Weaver
Moderator
Moderator
Employee Accredited Certified

If you are runniing a VMware backup as well as a SQL Backup then the VSS request made by the VMware backup process does get recorded as a SQL backup and will mean that you have to follow the VMware backup with a Full SQL backup before you can run further Log Backups.

It is possible that changing the VMware VSS snapshot setting to run as a copy backup may make a difference.

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

Note: The only concern I have over this is that you have indicated that the problem occurs  at unpredicatble times. If it was a VMware backup job affecting the SQL backup sequence I would expect it to have a predicatble timing.

Thomas_Zangl
Level 3

Hi,

I've disabled all Datarecovery jobs for the database servers. I already thought that it could influence it but its strange that it happens randomly and that there is no pattern :\

Maybe I will just shutdown datarecovery completly and have a look if it happens again.

Tom

ArulPrasad
Level 6
Employee

Hello,

 

Adding to What Colin Said,

 

If You choose to do a snapshot of the VM that will in turn use the Vmware Tools to do a application quisce. so After the Remote agent Full backup , then run the differential (No Snapshot of the Vm should take place By any means during this process)

 

Regards

Apr

Thomas_Zangl
Level 3

As I already said, I suspected that also BUT we stopped VMWare Datarecovery Backup for all DB servers on 08/14th and the error happened again since then (on 08/15th to be specific).

But I checked VMWare events and there was a Task caled "Create virtual machine snapshot" about 10 seconds before the offending full backup - maybe there's something else triggering those snapshots. Going to investigate some more :)

Thanks for the hint!