08-16-2012 12:59 AM
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:
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
08-16-2012 01:04 AM
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.
08-16-2012 01:14 AM
Have you looked at this KB as well - http://www.symantec.com/business/support/index?page=content&id=TECH137587
08-16-2012 01:18 AM
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
08-16-2012 01:23 AM
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 ?
08-16-2012 02:22 AM
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
08-16-2012 02:44 AM
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...
08-16-2012 03:22 AM
:) 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
08-16-2012 03:31 AM
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 |
German - reads like "The MySupport-Application experienced a programm error... bla "
We better re-think our purchase of 10k+ EUR for this software...
08-16-2012 03:36 AM
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..
08-16-2012 03:47 AM
Yea, I will do that. Thanks.
08-16-2012 04:55 AM
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.
08-16-2012 07:23 AM
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
08-16-2012 07:43 AM
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
08-16-2012 07:49 AM
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!