Virtual machines are like Russian dolls (nesting dolls): each layer depends upon the one below it. A guest file system is contained within a container file which itself resides within a datastore on top of a group of physical hard drives. The entire structure will fail if one "shell" fails, but you can't recover from that kind of disaster until you determine what layer caused the problem to occur, then fix just that layer, while protecting all the layers beneath it through imaging before starting any repairs.
The bottom-most layer is the data-store layer, which can be a VMFS datastore on a failed RAID, a Hyper-V volume that has lost its host, or an NFS storage system that was interrupted in the middle of writing to disk. At this layer we complete all array and filesystem recovery first, and then the VMs are simply recovered from the damaged filesystem. The next layer is the "container" layer, which could include a VMDK that has been deleted during a cleanup operation, a VHDX that has become corrupt after a host failure, or a qcow2 that has been shortened due to lack of disk space for the underlying file system. The top layer is the guest inside: the virtual Windows or Linux system whose own NTFS or ext4 took the damage.
Each level of the layers contains its own forms of failures and each level also provides its own means of repair. When you do it yourself and fail to properly diagnose which level your issue falls under you can turn a single problem into three.
The unobtrusive complication of snapshots. When each checkpoint creates a split machine with respect to its own new delta file, there is only one "current" VM, which can be seen only by reading all links in order. If you delete a link, if you consolidate at the wrong time, or if your hypervisor crashes midway through a merge, then the machine breaks down into parents and orphans (that none of the hypervisors will join again). We have to build the entire chain again manually using only the metadata in the delta files, and when a link is truly missing, we recover to the most recent point supported by the remaining chain and make it clear.
Don't try consolidating again if it currently can't be consolidated. Each failed consolidation rewrites deltas necessary for reconstruction.
VMs that were deleted exist in their own category. They may be removed from inventory with "delete from disk" checked, wiped clean by a storage maintenance process, or lost when a data store was reformatted to make room for the new cluster. In VMFS environments especially, deletion leaves the container's blocks recoverable until subsequent provisioning claims them, thus time becomes your adversary: freeze the data store; do not allow new provisioning onto the data store. Take an image of the data store to the bench. Deleted VMs can be recovered this way far more frequently than administrators would normally anticipate.
As all jobs have different shapes and sizes, the quote for each job is made separately and written down as soon as the free assessment has been completed prior to any paid work commencing. Each job starts with a free diagnostic, and finishes exactly how it was initially quoted. On most jobs, we do not charge for anything unless we recover your data. We never use an hourly rate, and we do not surprise you with an evaluation fee or take a percentage of the value of your recovered files.
Frequently not; the deletion simply removes the reference to the VM. The data blocks in the VMDK still exist and will remain there until they are provisioned for use by another VM. Immediately freeze all activity on this datastore: do not create new VMs, do not allow storage vMotion operations against this datastore, prevent the operation of any clean-up scripts. Using an image of the LUN we carve back the containers, then restore the guest and mount the original guest OS again.
In most cases. When there's a crash while still writing to the VHDX, the structure of the container will be broken. The hypervisor will refuse access to the entire VHDX due to fear of damaging its contents further. In this case we repair the VHDX structures against a copy, or bypass the VHDX completely and build the guest file system again from the raw data within. Do not use "inspect & repair" with retries, as these write to the VHDX.
The booting process is outdated because the hypervisor has fallen back to a parent disk and abandoned the deltas that contained your last few months' worth of changes. These deltas are the target for recovery. Do not delete them as "orphans". From the metadata within these deltas we can rebuild the chain and then roll your machine forward to the newest consistent point in time that the files allow.
Yes: it is often more intelligent to just deliver the files. Once we have opened up the recovered container, mounted the guest file system read-only and extracted the documents / databases / mail stores that you actually need, we can ignore the operating system completely. At assessment time you decide how much of the entire machine you want: whole machines, files only or both.
Before posting or dropping off your item please obtain a quote using either the form on this site or by calling us. There are then two genuine options. No vans will be used. To hand over your item, go to Tay House, 300 Bath Street (only two minutes from the M8) at Charing Cross, Monday to Friday, 9am–5:30pm. We do not require appointments. Or wrap your item securely and send it to us by insured, tracked post from Paisley, Ayrshire, the Highlands or anywhere else in the UK. Either way, the work is done in-house by our own engineers, with a documented chain of custody, and your data never leaves the UK.
Stop provisioning new VMs, stop consolidating existing ones, tell us which layer broke (the free assessment will take care of the rest). Virtual machine recovery pricing starts from £800 + VAT, fixed in writing before any work. Virtual machine recovery for Glasgow: VMware, Hyper-V, etc., rebuilt from the disks up, ready to go.