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 I found & deleted the Scheduled task that snapshots to Volume{f369330f-be43-11e2-b81d-001b21a9389c}.

Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

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.
cef_soothsayerAuthor Commented:
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...
cef_soothsayerAuthor Commented:
Nope, unfortunately that did't work.  :(  Any other ideas?
Protecting & Securing Your Critical Data

Considering 93 percent of companies file for bankruptcy within 12 months of a disaster that blocked access to their data for 10 days or more, planning for the worst is just smart business. Learn how Acronis Backup integrates security at every stage

Is there anything new on the VM that would be preventing the disk from quiesceing?
cef_soothsayerAuthor Commented:
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.

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.
cef_soothsayerAuthor Commented:
Let me try to shut down the guest VM before backing it up, and see if that gets me anywhere.
cef_soothsayerAuthor Commented:
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.
cef_soothsayerAuthor Commented:
Nope.  Crash consistent.  :(
cef_soothsayerAuthor Commented:
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...
My next advice is to call the backup vendor.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
cef_soothsayerAuthor Commented:
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.


Thanks for your assistance.
Glad you found the issue.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.