So I have a base image for a linux vmdk I snapshotted as I went along.
Now when I was going through and deleting things to free up some disk space I accidentally deleted that original vmdk, thinking that vbox would have stored the base in its own directory, not so.
Luckily I had the original vmdk backed up so I simply put it back in the directory from whence I obliterated it and thought that would be fine... not so.
I then had a hell of a time recovering it, as the <GUID> of the snapshot didnt match, I used some script to manually apply a <GUID> to the original vmdk for which the snapshot wanted. and it booted! hoorah!
heres where it gets weird - the snapshot will operate correctly for about 20 minutes, afterwhich the guest filesystem starts to apparently become read-only and thus corrupt and unusable - cant reboot successfully, if I force it off then try to boot it gives me an error "init: error.c:219: Assertion failed in _nih_error_raise_system: errno > 0"
So my question is - surely If I have in my possession - the original vmdk and all relevant snapshot files in the vbox folder, SURELY, there is a way to recreate a functioning vbox appliance???
help?
Details -
Virtualisation = virtualbox 5
Host = Win7x64
Guest = Ubuntu x64 14.04.1 krnl=3.16.0-33 generic
Recover vbox snapshot of recovered ubuntu vmdk
-
mpack
- Site Moderator
- Posts: 39134
- Joined: 4. Sep 2008, 17:09
- Primary OS: MS Windows 10
- VBox Version: VirtualBox+Oracle ExtPack
- Guest OSses: Mostly XP
Re: Recover vbox snapshot of recovered ubuntu vmdk
People continue to find new and inventive disaster scenarios involving snapshots. And, the appeal this feature has for newbies continues to mystefy me.
Time to copy off any files you would rather not lose, and delete this VM. I would suggest avoiding snapshots in future: proper backups are not only more effective in disasters, they also don't require any storage space on your host - a shortage of which is presumably behind your decision to delete important files.
Actually, that should have done it, had the VMDK been a proper backup. Presumably then the VMDK you deleted was not a copy, but a clone. Incidentally - you made a clone but didn't locate it inside the VM folder? Not recommended: a tidy folder layout is best if you want to avoid future confusions such as this.conma293 wrote: Luckily I had the original vmdk backed up so I simply put it back in the directory from whence I obliterated it and thought that would be fine... not so.
The first sentence voids your warranty, unless you have a certificate from the Guild of Disk Hackers. Yes, from those symptoms I'd guess you used the clone for a while before creating a first snapshot, hence the contents were no longer an exact copy of the "original". The snapshot is a difference state derived from an altered base state. Change the base state and you get a corrupted current snapshot state, and there's no telling how extensive the damage is.conma293 wrote: I used some script to manually apply a <GUID> to the original vmdk for which the snapshot wanted. and it booted! hoorah!
heres where it gets weird - the snapshot will operate correctly for about 20 minutes, afterwhich the guest filesystem starts to apparently become read-only and thus corrupt and unusable
Time to copy off any files you would rather not lose, and delete this VM. I would suggest avoiding snapshots in future: proper backups are not only more effective in disasters, they also don't require any storage space on your host - a shortage of which is presumably behind your decision to delete important files.