### Urgent: My quest OS goes to a previous snapshot ###

[Tuncai]

Hello!

I'm using Virtual Box 4.1.18 r78361 for Windows. The guest OS is Oracle Linux 6.2.

I turned off the the guest OS without saving the current state. But, when I restarted the guest OS, it goes to a previous snapshot. My works before turning off the quest OS has lost.

But, when I create and edit a test file under the current snapshot, and then turn off the guest OS without saving the current state, my test file is ok after I reboot.

How can I turn back to my last state ?

Thanks in advance

[mpack]

I assume "quest OS" is guest OS.

Are you sure it was a snapshot? This sounds more like "immutable disk" behaviour - same technology, but put to a different use.

If it's an immutable disk then discarding the data on a next full boot is exactly what the feature is supposed to do.

On the other hand, it is NOT what snapshots are supposed to do - and as far as I know, snapshots do not do this.

If the data has been deleted then the only way to restore it is from a backup.

[Tuncai]

Thank you for the quick answer.

It's a default installation. I just checked it is "Type (Format): Normal (VDI)".

I've not deleted any data. may I think that it can be salvaged ?

I'm sure it goes to a previous state more than 1 year earlier. So, I think it's a snapshot. I have 2 snapshots.

Thanks in advance...

[Tuncai]

Hello!

After I deleted all snapshots, nothing has changed. When I reboot the guest OS, it goes to 3 years ago.

What is wrong ? I just turned off the guess OS without saving the state. But now, I can not see my latest works.

I've still guest OS backup. If there is no option to open with the latest time, is there a way/tool to salvage my data ?

[mpack]

I did not ask you to delete any snapshots. I hope you made a backup before you risked making things worse!

Your original post talked about the important event being that you fully shut down the VM (not saved state). That distinction would be important to immutable drives (where changes are discarded on every VM full start), but is completely unimportant to snapshots.

The only way I know of to end up in a past state using snapshots is if you manually select that past state: shutting down and starting the VM would not do it. If you "restored" to the past state then any data from later states is now lost. If you branched from an earlier state then the situation may be recoverable.

Please shut down the VM now, and show me a screenshot of the "Snapshots" pane from the VM settings.

It would also help if you zipped up the ".vbox" file from the VM and attached the zip here. Also, show me a directory listing of your Snapshots subfolder.


Did you do anything at all to the VM that you haven't told me? For example, copying it to a new host or a new folder. Or, creating a new VM using the old disk.

[Tuncai]

Hello!

No. There is nothing that I did not mention here. I don't know Virtual Box well. I just start and stop my guest OS.

I have a guest OS backup taken immediately after I encountered this problem. Snapshots were deleted later.

I've restrored this guest OS backup. The info you wanted attached below.

Thank you.

[Tuncai]

There is 512K limit in this forum. I'm uploading in multiple parts.

vb.part1.rar [418K] Deleted by mod.
vb.part2.rar [418K] Deleted by mod.
vb.part3.rar [418K] Deleted by mod.
vb.part4.rar [418K] Deleted by mod.

[mpack]

There is 512K limit in this forum. I'm uploading in multiple parts.

Uploading what in multiple parts? Nothing I asked you for should have taken more than a couple of hundred K before compression. And I see it's incomplete even after 1600K. Were you trying to upload the VDIs?

I'm deleting those rogue attachments.

[mpack]

Ok, I've had a look at the vbox file (the only thing I asked for that has been provided), and I see that you have a base VDI followed by two snapshots. Unfortunately I have no creation dates and no way to know if these are the only files present.

Please look again at what I asked for above. If you want help then please provide the information I need, and nothing else.

[Tuncai]

I sent what you wanted. They were screenshots, not VDI. But, they were deleted now.

Since, it was impossible to upload file bigger than 512K, I had uploaded in multipart WINRAR format. Some screenshots are bigger than 512K.

[mpack]

Trim the screenshot so that it only shows the part of the screen I asked for. Then save the remaining image using PNG format, or JPEG if you really must. Then zip and attach here. No one else has ever been prevented from doing this by the upload limits.

[Tuncai]

I've uploaded trimmed images. All other wanted data uploaded before.

[mpack]

Thanks. Now I can see that folder contents seem to match the .vbox data:

• In the main VM folder you have a base VDI which has not been modified since 2012. That's as it should be.
• In the snapshots folder I see two snapshot files, both apparantly created in late 2012, but only the "{3ecc-...." file has been modified recently. This snapshot looks quite small for one which has existed since 2012 (assuming regular use).
• You also have three orphaned saved saved states, which again seem to date from 2012.

Are you sure that you are not confusing this VM with another? I see no sign of errors or inconsistency that you might get following a crash, and I see no sign that this VM was used between 2012 and very recently. In any case there is no data present from any intermediate dates.

I can tell you that having the guest revert to a previous snapshot on its own is not a credible scenario in my view. Credible scenarios include (1) wrong VM selected, (2) that this VM folder has been restored from a 2012 backup, (3) you reverted to a 2012 snapshot state (though in that case I would expected to see some clues, e.g. sav files from intermediate dates). The four log files you provided are all very recent, hence tell us nothing about the missing years.

[Tuncai]

Thank you for the analysis.

I'm sure I use just this VM. Also, I'm sure I used this VM recently. I sent the lastest version of a project from this VM to the customers in 2015_01_26.

What I did:

- I was always closing the VM by "Save the machine state" for years.
- The last time, I closed the VM without saving the state. I might have used "send the shutdown signal" or "Power off the machine".

There is nothing I did.

[mpack]

Saving the machine state essentially dumps the contents of virtual RAM to a file. However disk writes are saved to virtual disk (i.e. the current snapshot VDI), not in the sav file. Powering off the machine might at worst cause the corruption of a few files which were open at the time, but it would not cause the VM to effectively travel back in time two years.

Having said all that: I instinctively avoid both snapshots and sav files. I regard both as representing unstable states, prone to error. But, I still can't think of a scenario (whether due to bugs or not) in which you committed no significant error (none of ones you mentioned would do it), and there is no sign of damage to disk files or config files, and yet two years of data is gone without leaving a trace.

The only scenario that would even get close - which I have seen here once before - is when a single application was left open the entire time, with the work never being saved to disk (never mind not backed up), with the VM always being "save stated" instead of shut down. One day the save state thing had a hickup and poof - months of work with that app was gone. That said, decent modern "work" apps usually these days have an autosave feature, so even then...