cancel
Showing results for 
Search instead for 
Did you mean: 

Backup Fails with error code 0xe0009574 for a VM not selected in the resource list

Allen_D
Level 3

Good afternoon BE2012 gurus,

 

Ran into an interesting and annoying problem with a VM (vSphere 5.5) backup to D2D.  We are running the latest build of BE2012 with all service packs, hot fixes and patches applied to the application.  The server (Windows 2008 Enterprise - 32 bit) is up to date as well with all MS updated installed and all HP updates installed as well.

 

The backup job is using the Agent for VMWare Virtual Infrastructure.  The backup job is a non-GRT type backup.

The specifics of the job are to backup, once a week, a select set of VMs that do not change often.

 User credentials are correct for the VMs and consistent with the user credentials used for individually backing up each VM individually.  In other words, the user credentials for the resource are confirmed correct.

When we run this job, we get the following error show up in the log during the Verify phase  of the backup:

Note: Resource: "VMVCB::\\VRSOMVCENTER\VCGuestVm\(DC)Veterinary Medicine(DC)\vm\ESX Shutdown vMA" is not snappable. Attempting to back up directly from the source volume.
V-79-57344-38260 - Unable to create a snapshot of the virtual machine. The virtual machine may be too busy to quiesc...

Note: Resource: "VMVCB::\\VRSOMVCENTER\VCGuestVm\(DC)Veterinary Medicine(DC)\vm\VRCMC" is not snappable. Attempting to back up directly from the source volume.

What is interesting about this error is the VM noted above is NOT selected in the list of resources to backup.  I have tried changing the job by adding this resource and saving the job followed by removing this resource from the list of VMs to backup and saving again.  Re-running the job results in the exact same failure.  I've even deleted the job and recreated a new job with the same VM resources to backup (excluding of course the VM that fails to be backed up) with the same name as the previous backup job and the job fails again with the exact same error message. Also note that all the other VMs backed up in this job succeed (no errors).

If I backup the ESX Shutdown vMA by itself as a non-GRT backup and as a one time backup, the backup runs successfully.  This gives me every indication that there is something wrong with the job that was created and recreated and points to a possible problem with the database.

Any pearls of wisdom to share on what might be the cause of this issue?  I think I'll try deleting and recreating the job with a different name and re-running the job to see if the problem goes away.  In the interim, I would be curious to hear what you believe this error points to.

Thanx!

 

Best,

 

Doug A.

1 ACCEPTED SOLUTION

Accepted Solutions

Allen_D
Level 3

So as it turns out, recreating the same job (exact same resources and settings) but naming it something else solved the problem.  The backup ran through without error.  So I'll be deleting the old job and no longer wondering why this problem occurred..... until the next time.

 

Doug A.

View solution in original post

3 REPLIES 3

lmosla
Level 6

In your job under Advanced Open File Backup Options set the settings to 

  • Use snapshot technology 
  • Automatically select snapshot technology
  • Process logical volumes for backups one at a time
  • make sure Enable checkpoint restart settings is unchecked

hope this helps

Allen_D
Level 3

Thank you for the return comment.  Those are the existing settings for this job as well as all the VM non-GRT jobs.

I've created a new job with a different name but with the same VMs to be backed up.  That job was started and currently in the Verify stage.  Should have an answer shortly if the problem recreates itself although I would highly doubt it will.  If this works, then I'll simply delete the old job.

Allen_D
Level 3

So as it turns out, recreating the same job (exact same resources and settings) but naming it something else solved the problem.  The backup ran through without error.  So I'll be deleting the old job and no longer wondering why this problem occurred..... until the next time.

 

Doug A.