VMDK Handbook - Snapshots
by
Ulli Hankeln
In emergencies visit
back to Table of Content
This chapter is about snapshots and how to manage them.
For a list of the content see
Can I recover data from an orphaned snapshot ?
YES
Most of the times you will hear a NO when you ask if you can recover
data when all that is left is a *-delta.vmdk.
But this is not the full story.
You can actually recover data if you
- recreate a basedisk from scratch
- attach your orphaned snapshot to the new basedisk
- mount the disk and use recovery tools
This is pretty advanced work and requires very detailed information
about
the way the original - now missing - basedisk was setup.
The involved procedures are very time consuming and it is easy to
do it wrong.
Anyway - this is too advanced to be explained here in a few words.
If you want me look into your special case contact me
<<<
Translating VMware-Snapshotmanager button-names
to common sense ...
What happens when you take a snapshot ?
You already know the term: snapshot - it usually means something like:
take a photo in the middle of an action ...
Imagine you watch your little daughter climbing up a ladder - on step
5 she falls down - and in the precise moment she falls you take a
photo. Wow - you now have a photo that shows your little daughter
flying in the air.
You can show this snapshot to all her aunts and uncles ;-)
Lets get serious again. Does the photo matter ?
Nope - the moment of the snapshot is the breakpoint between to actions:
- climb up the ladder
- fall down.
In VMware-reality you can go back to the snapshot.
Actually you can go back to the end of the "climb ladder action"
and have a second trial for the "fall down action".
This time dont stare at her - run ...
With VMware these actions are just files.
A virtual machine writes into a vmdk.
So what does "take a snapshot" mean ?
Very simple: finish the current vmdk and write into a new one.
Full stop - that's all.
finish current vmdk/redo-log |
keep current REDO-log |
keep |
discard current REDO-log |
discard |
merge current REDO-log with
parent |
merge |
start to write into a new vmdk/redo-log |
start new REDO-log |
append |
start new REDO-log
(append to selected parent) |
append to selected |
We got three ways to finalize the current vmdk and two ways to start
a new one.
This adds up to some nice variants of combining our options.
See your self
VMware button label |
fileoperation |
simplified description
(imagine you are an author
and write a book) |
|
|
|
Take Snapshot |
close and keep current REDO-log
start new REDO-log |
finish current chapter
start a new chapter |
Revert to Snapshot
(special case of Goto) |
discard current REDO-log
start new REDO-log |
restart last chapter |
Delete |
merge current REDO-log with
parent
start new REDO-log |
define last chapter as good and keep it
start a new chapter |
Goto |
discard current REDO-log
start new REDO-log
(append to selected parent) |
discard last chapter
start over from chapter X
keep all different versions |
|
|
|
Linked Clone |
start new REDO-log
(append to selected parent) use
with a new VM (vmx-file) |
start a different version of the book using
the first X chapters of the main version |
Full Clone |
merge current branch into a
copy in a new dir use with a new
VM (vmx-file) |
copy the complete book and work on the copy
keep the original as it is |
|
|
|
a disk in
non-persistent mode |
start new REDO-log
discard it at next exit |
doesn't matter what you write
you will discard this chapter anyway |
<<<
How to create a monolithicSparse - snapshot from scratch
You can create a makeshift snapshot yourself with very simple tools.
Workstation will complain - it tells you that the snapshot must be
repaired.
But in this case it does not matter because it is absolutely blank.
At first usage the makeshift file will be transformed in a "correct"
snapshot vmdk.
Create a blank file - size does not really matter - it just should
be large enough.
(need to make a list of recommended size - related to the nominal
size of the parent)
fsz blabla-000001.vmdk 3000000
Next inject the "magic" first sector - you can download
a copy here : monolithicSparse-snapshot-magic.bin
dsfi blabla-000001.vmdk 0 512 monolithicSparse-snapshot-magic.bin
Finally create a description - use the example
and adjust parentfilename hint and the extent description.
Fill the end of the file with some spaces - so that the file is at
least 1024 bytes long - then store it as description.txt
Then inject it with
dsfi blabla-000001.vmdk 512 1024 description.txt
<<<
How do I check if a snapshot is an orphan ?
Orphaned snapshots are snapshots that are not part of an existing
snapshot-chain.
This should never happen - but in some cases ....
- unwise user action some time ago
- Workstation or ESX crash
- host OS crash or power-failure
- running out of diskspace during a snapshot action
- misconfigured or buggy behaviour of VMware tools like VCB or VDR
- misconfigured or buggy behaviour of third party backup tools - especially
for ESX and ESXi
It is not trivial to check if a snapshot is orphaned for several reasons
- looking at the snapshot number in the filename is unreliable
- looking at the vmsd file is unreliable
- looking at the filename hint in the vmx-file only references the
last used one at the end of the chain
- a snapshot maybe used by a VM in a different directory
- a snapshot maybe part of a linked clone in a different directory
- a snapshot may be the only part of a a separete branch in the snapshot-tree
To be absolutely sure if this snapshot is orphaned and so can be deleted
we have to check if it is referenced
by any of the other vmdk-descriptions found in the same directory.
In case any other vmdk references the snapshot it may be part of one
branch of the tree.
In case the snapshot is a direct child of the basedisk it may be a
valid separate branch all by itself.
In case the CID or parentCID of the snapshot are referenced by any
other vmdk it may be a required snapshot even if the parentfile name
hints don't match.
What is the size of the snapshot file ?
The larger it is the longer it has been in use - the more valuable
data may be stored in it.
Even If it is very small it may have never been used but it also may
contain a single file - maybe just THE important one.
Long story short: you have to make an educated guess after analysing
the other vmdks in the same directory.
Automated scripts that check for orphaned snapshots are only trustworthy
if you can rule out user-mistakes.
-
<<<
Can I use ESX-snapshots in Workstation ?
YES
On recent Workstation like 6.5.3 you can use native ESX 4 snapshots
in a Workstation VM without having to edit
the description first.
It is also possible to copy that snapshot back to ESX and continue
to use it there.
Practical use:
patch ESX VMs "offline" on Workstation without the need
to transfer large files
It is easy to do this wrong so I recommend this for experienced users
only
<<<
Snapshots and linked clones ...
Taking a snapshot means adding a new redolog to an existing regular
vmdk or snapshot-chain.
In the vmx-file the added snapshot will then be referenced as
scsi0:0.filename = "myVM-00000*.vmdk"
and a new vmdk named "myVM-00000*.vmdk" will appear in the
VM's directory.
To create a linked clone all we have to do is make a copy of the new
snapshot, put it into a new directory
and create a new vmx-file for this vmdk.
Here are some older howtos I wrote for this:
very
old guide showing how to do this with Ken Katos vdk.exe
this one
is written in german - deutsch sprachige Anleitung
how to create linked clones on
ESX4i without VirtualCenter
<<<
|