virtualbox.org

After a standard shutdown backup and reboot of our server last night, I'm getting the following error:

Error: failed to start the machine. Error message: Could not open the medium 'E:\virtual drives\server1.vmdk'.
VMDK: inconsistency between grain table and backup grain table in 'E:\virtual drives\server1.vmdk' (VERR_VD_VMDK_INVALID_HEADER).
VD: error VERR_VD_VMDK_INVALID_HEADER opening image file 'E:\virtual drives\server1.vmdk' (VERR_VD_VMDK_INVALID HEADER)

This is running VirtualBox 3.2.12 r68302 on a Windows 7 host with a Windows 2003 guest.
Since everything was fine on shutdown, the backup completed as normal so my backup is corrupted as well.

Any help would be appreciated.

Does it get to a F8 stage? bartPE iso handy to run a chkdsk?

No, the guest doesn't even attempt to start. Even the Virtual Media Manager says "could not open... inconsistency between grain table and backup grain table..."

Hmm, can you delete it from the mediamanager (keep vmdk) and then re-add it to a newly created VM ? (dont start it), or try opening it in vmware only in order to see if it might run? does the backup from yesterday run?

Trying to readd it to the media manager says "Could not get the storage format of the medium...(VERR_NOT_SUPPORTED)."

Yesterday's backup is just a file copy and fails to run as well (even on a different host)

It'll take me a bit to try VMWare as our whole network is down with this server down. I'm posting via cell phone.

It sounds like something got hosed, why is a good question, failing drive, cache problems. Maybe this tool VDK can help: http://webcache.googleusercontent.com/s ... .google.nl

vmware-mount gives the error:
Unable to mount the virtual disk. The disk may be in use by a virtual machine or mounted under another drive letter. If not, verify that the disk is a virtual disk file, and that the disk file has not been corrupted.

The file is still the correct size so I'm assuming its at least mostly intact. Are there any tools to check and/or possibly repair corrupted vmdk images? Even if there is an "inconsistency" between the main and backup grain tables (whatever that is) can I basically pick one to use ignoring the other and try to boot it?

See link above, some old 2007 vmware tools. Other then that use google to search for what else is out there. I've had hozed VM's but they all remained accessable by vbox and repaired by your common tools.

Tried your link. When I run it I get "Invalid description entry." errors for encoding, ddb.uuid, ddb.uuid.image, ddb.uuid.modification, ddb.uuid.parent, ddb.uuid.parentmodification, ddb.geometry.bioscylinders, ddb.geometry.biodheads, ddb.geometry.biodsectors.

The vmdk image contains 2 drives, the first of which mounts fine and is usable, the 2nd drive (which has all my data) when I try to change to that drive I get "The file or directory is corrupted and unreadable."

So the problem drive does get a drive letter, maybe chkdsk can access it? also have a look at the clonevdi tool, it will convert it to a VDI but if it fixes some things who cares.

chkdsk reports ~100 index errors but can't fix them since the drive is opened in read only mode. Attempting to open the drive in read-write mode causes vdk to lock up. CloneVDI appears to be running, but its reporting 4.5 hours to complete.

I do have a month old backup of the entire working system, so if I can just get to the data, I'd be at least 90% there.

CloneVDI ran to 1 mbyte remaining, 0 min 0 sec remaining, and has been sitting here for the last 15 minutes frozen. Another issue is that the last ~50% pretty much flew compared to the first 50%. I'm hoping something will still come out of this, but its not looking promising.

CloneVDI left me with a vdi that was only half the size of the original vmdk. Windows would start to boot but quickly lock up and the files were mostly not there or corrupted

However, while that was running I had left vdk running in the background trying to mount the original corrupted vmdk image in read/write mode. After about 2 hours of looking frozen I was surprised to see it scroll on by saying it was done. With the vmdk mounted, I couldn't access the drive at first, but chkdsk ran, correcting a few 100 errors, and now I have access to the data files. I'm currently copying everything off to a spare drive and have yet to see anything particularly broken. My hope is that I can restore the majority of this data to my month old system backup and go from there.

As to the cause of the original problem - I still have no idea. All the physical hard drives are reporting no problems, raid drivers have no errors and there hasn't been any abnormal errors/crashes/power outages/etc for months. I had just finished setting up a system to make a spare weekly backup for offsite storage, but its first run was scheduled for tomorrow. Having that would have fixed all of this.

Anyhow, thank you very much for all the help. Its greatly appreciated.

Good to hear, glad those old 2007 tools are still useful though it took me an hour to find a very deeplink to the files, as to why the crash.... it might be worth to test everything like ram tests, raid tests, surface tests, etc...

I have come up with a theory as to why the crash happened, but testing/checking it is way beyond my ability.

The day before it went down, we closed out a job file which involves moving a folder from e:\Jobs\ to e:\Jobs 100% Complete\2300's\. Inside the folder was some really long named sub folders and so, by moving it, the path to some of those folders were now over 256 characters long. This ran me into errors when doing the restore (even managed to crash a command prompt - a new one for me). But I was wondering if this might have caused some corruption in the underlying filesystem and/or VirtualBox's handling of it.

Just throwing that out there - I wouldn't know where to start looking into that myself. And thanks again for all the help.