Link to home
Create AccountLog in
Avatar of cef_soothsayer
cef_soothsayer

asked on

Altaro reporting "Crash-consistent backup"

I've been backing up my 2 Hyper-V guest machines using Altaro for a while now.  Everything was working fine.  But now Altaro is reporting "Crash-consistent backup".  I've run a "vssadmin list writers" and none of the writers have any errors.

There is nothing odd in the Event log for the VM guest that is failing on backup.  However, in the Event logs for the VM host I found this:
"VssAdmin: Unable to create a shadow copy: Either the specified volume was not found or it is not a local volume. Command-line: 'C:\Windows\system32\vssadmin.exe Create Shadow /AutoRetry=15 /For=\\?\Volume{f369330f-be43-11e2-b81d-001b21a9389c}\'. "

Per the MS knowledgebase http://support.microsoft.com/kb/833779 I found & deleted the Scheduled task that snapshots to Volume{f369330f-be43-11e2-b81d-001b21a9389c}.


http://www.mcbsys.com/techblog/2012/02/delete-orphaned-vss-task/

https://social.technet.microsoft.com/Forums/windowsserver/en-US/64127ca1-06d5-4f6e-9f3d-98e629a038c7/vssadmin-unable-to-create-a-shadow-copy-failure-either-the-specified-volume-was-not-found-or-it-is?forum=winserverfiles


Help?
Avatar of asavener
asavener
Flag of United States of America image

Well, unless the backup software can quiesce the disk, you're always going to get a crash-consistent backup.  Even if you remove the VSS job that's throwing the error, you're still not quiesceing the disk (or, at least, your backup software doesn't detect that the disk is quiesced.)

I suggest setting up the job again in Altaro, and see if you start getting an application-consistent backup.
Avatar of cef_soothsayer
cef_soothsayer

ASKER

Ok, I don't see how that will allow the backup to access the VSS, but you might be right.  At this point, I'll try anything.  I detached the VM from the backup, removed the VM's old backups, reattached the VM, and rescheduled the backups.  Now waiting to see how the backup runs.  Stay tuned...
Nope, unfortunately that did't work.  :(  Any other ideas?
Is there anything new on the VM that would be preventing the disk from quiesceing?
Not that I know of.  I mean, It typically has an active RDP session, and a few apps and sometimes files left open, but nothing that is "changing" at the time of night that this backup runs.  I don't think that would be the issue because:  1.) That's never stopped the backup before.  2.) I've rebooted the VM and the backups still don't work.  3.) The backup is running on the VM host, not the VM guest.  The VM guest is unaware.  And the VM host isn't really running anything else.  Plus, it's been rebooted too.

Thanks.
Well, if you just take a snapshot of a running VM, and then back up that snapshot, it gives you a crash-consistent backup.

If you quiesce the applications in the VM prior to taking the snapshot, then you get an application-consistent backup.

So the hypervisor has to send a notice to the guest, and get it to (very briefly) stop disk access.
Let me try to shut down the guest VM before backing it up, and see if that gets me anywhere.
Ok, that did the trick.  Did two backups while the VM was offline and they were both successful.  Now I need to try again when the VM is running - as that is the ultimate goal.
Nope.  Crash consistent.  :(
Any other ideas?  Why wont this VM backup in a successful non-crash-consistent state when it is running anymore?  This worked just fine for months and months, and nothing was installed on the VM.  No changes prior to the problem starting...
ASKER CERTIFIED SOLUTION
Avatar of asavener
asavener
Flag of United States of America image

Link to home
membership
Create an account to see this answer
Signing up is free. No credit card required.
Create Account
NAILED IT.  Ok, this is definitely a facepalm moment.  But here's what happened.

A little while ago (about the time the backups started failing, but I didn't realize it) I was working on a P2V project and having trouble. (There is another Experts Exchange Question still open on that).  As part of the troubleshooting, I connected the VHD to this VM as a secondary drive in order to review the file contents.  Well, that VHD was on a USB connected Zalman drive, and when I was done, I downed the VM and removed the drive.  But I forgot to unmount the VHD in the VM config.  So after I unplugged the Zalman, and booted the VM back up, the secondary volume to the VHD was still mounted, but the drive could not be found.  Hence the Altaro backup errors.  It wasn't complaining about the C; drive at all.  It was complaining about the E: drive which was missing.  DOH!

So, problem solved.  Lesson learned.  My Bad.

But those error messages SURE COULD USE SOME MORE DESCRIPTIVE INFORMATION.  Sheesh...

Thanks for your assistance.
Glad you found the issue.