How to recover a virtual machine without losing your data

Learn what causes data loss in virtual machines, how to restore a VM from backup, recover orphaned VMs and back up your VMs safely.

A virtual machine (VM) is a valuable solution for companies to expand their ability to manage different operating systems, overcoming physical limitations. In fact, when combined with RAID (Redundant Array of Independent Disks) systems, it becomes a highly efficient tool.

VMs are capable of turning a single physical server into several virtual servers, which makes them crucial components of modern IT.

However, this efficiency has attracted the attention of hacker groups who have developed ransomware specialized in encrypting virtual machines and their files.

After all, they know that data is now essential for any company, so keeping it available and accessible is vital. Losing it can be devastating.

In addition, various problems can result in the loss of data in VMs, as we’ll cover in this article.

Fortunately, there are methods available for recovering virtual machines – although they are complex and require advanced technical knowledge to avoid complications.

This blog post also walks you through safe methods for recovering data from your VMs. Read on to find out what these methods are, how to back up virtual machines and much more!

Problems that cause data loss in virtual machines

Several issues can lead to data loss in virtual machines. Some of the main reasons include:

Deleting data

Users can accidentally delete important files within VMs, resulting in data loss.

Formatting partitions

Formatting partitions in VMs can cause data loss because it removes the structures the file system uses to manage files and directories.

When a partition is formatted, the information about where files are located, their metadata and the directory structure is erased, so the data that was there becomes inaccessible.

Corruption of information

File system failures within the VM can occur due to incorrect shutdowns, power failures or other types of interruptions. This leads to file corruption and data loss.

Overwriting information

Overwriting can cause data loss in virtual machines because existing data is replaced or corrupted.

This happens when new data is written to areas that previously held other information.

This problem can occur in various scenarios, such as:

  • Shared file system
  • Access conflicts
  • Simultaneous backup and restore
  • Asynchronous synchronization
  • Failures in writing processes.

Formatting followed by reinstalling systems

Formatting a disk, virtual disk, array, LUN, vDisk, volume, etc., and then reinstalling the system, is another common cause of data loss in virtualized environments.

With VMs specifically, the reformatting can happen at the guest level or at the host level.

Corruption can also be caused by faulty patches and updates applied without an offline backup, as well as by poorly planned software rollouts, integration problems and database corruption.

These problems can also corrupt files on the host and damage the guest’s file system.

It is also important to consider the risk of data loss with thin provisioning.

Instead of allocating all the space the VM needs up front and placing the file system structures in fixed physical locations, thin (dynamic) provisioning allocates only the space needed right now, adding extra blocks as the virtual disk grows.

This can result in a more complex and fragmented layout of the virtual disk on the physical storage.

If the metadata pointers to the data are missing or damaged, it will be a challenge to locate the various fragments and rebuild the virtual disk.

The mapping layer inside the virtual disk can also be damaged or overwritten, making reassembly extremely difficult.

Hardware malfunction

The hardware problems faced by virtual systems are basically the same as those faced by physical systems. For example, failed drives, controllers and server components, as well as power problems.

However, RAID corruption is a much bigger challenge with VMs because of the nature of virtualization. Unfortunately, data loss is not uncommon with this type of storage.

Modern hardware and software RAID is already complex, and deduplication and compression add to that complexity. The extra virtualization layer further increases the likelihood of failure.

This is because RAID controllers keep track of where all the information is stored across the disks in the array.

If a RAID configuration is corrupted, the files may become inaccessible, and you will need a lab that specializes in RAID recovery.

When this happens, the interdependence of several systems can lead to significant data loss and downtime.

Simultaneous failure of several disks in a storage system

This kind of failure can cause data loss in VMs because of the way these systems are configured for redundancy and data protection.

Storage systems normally use techniques such as RAID to distribute and protect data. However, if more disks fail at the same time than the RAID level can tolerate, data integrity is compromised.

How do I recover data from a virtual machine?

Arcserve UDP allows you to use the “Recover VM” option to restore a virtual machine that was previously backed up using host-based agentless backup.

This method restores the entire VM to its original location or to an alternative location on an ESX or Hyper-V server.

You can search for virtual machine recovery points from a calendar view and select the recovery point you want to restore.

Read on for a step-by-step guide to recovering a virtual machine.

Review the prerequisites and considerations for the restore

Before starting a restore, check the following prerequisites:

  • Valid recovery point: check that there is a valid recovery point for the restore
  • Accessible destination server: have an accessible and valid Virtual Center/ESX or Hyper-V server for the virtual machine recovery
  • Compatibility: consult the Compatibility Matrix to check supported browsers, databases and operating systems.

Then take the following points into account:

  1. Simultaneous restore: The Arcserve UDP Agent (Windows) allows only one restore task at a time. Arcserve UDP, on the other hand, supports multiple simultaneous restore tasks
  2. Restore in progress: if a restore job is already running and you try to start another one manually, you’ll get an alert asking you to try again later
  3. Destination compatibility: if the restore destination is Windows Server 2008 R2, the backed-up VM must not have VHDX disks, because Hyper-V on that system does not support them
  4. VM generation: for Windows Server 2008 R2 or Windows Server 2012 destinations, the backed-up VM cannot be a Generation 2 VM, because Hyper-V on those versions does not support Generation 2.
  5. Restoring to ESXi 5.5: you cannot restore VMs to an ESXi 5.5 host if the proxy server runs an x86 operating system. This is because it requires VMware VDDK 5.5.x, which is not supported on x86 operating systems.
  6. x86 proxy servers: if the proxy server is x86, the Arcserve UDP Agent (Windows) uses VDDK 5.1.2 instead, since VDDK 5.5.x does not support x86.

With this, you’ll have everything you need for a successful restore, ensuring compatibility and avoiding problems during recovery.

Specify the virtual machine to restore

You can recover an entire virtual machine from a recovery point.

The process for restoring a virtual machine is as follows:

Specify the virtual machine and the recovery point to restore

The “Restore VM” option is used to recover a virtual machine from a previous backup made with Arcserve UDP.

This method is ideal for quickly creating a virtual machine from a recovery point on the ESX or Hyper-V platform.

The restored VM can then simply be powered on to complete the recovery. To perform this restore, follow the steps below:

  1. Access the restore method selection dialog box:
    1. In Arcserve UDP:
      1. Log in to Arcserve UDP
      2. Go to the “Resources” tab and select “All nodes”
  • Choose the node you want and click on “Actions”, followed by “Restore”.
  1. In the Arcserve UDP Agent (Windows):
    1. Log in to the Arcserve UDP Agent
    2. On the home page, select “Restore” and then “Restore VM”.
  2. Defining the backup source:
    1. Click on “Change” to modify the backup location
    2. Choose the location of the backup images and provide the necessary credentials
    3. Select the recovery points folder.
  3. Selecting the recovery point:
    1. Specify the “Recovery point server” settings and click “Update”
    2. Select the desired node from the list displayed
    3. Choose the virtual machine to be recovered from the drop-down list
    4. In the calendar, dates with recovery points are highlighted.
  4. Choosing the recovery point:
    1. Select the date in the calendar for the virtual machine
    2. Choose an available recovery point.
  5. Restoration options:
    1. Click “Next” to access the “Restore Options” dialog box
    2. In this step, you configure the specific options for restoring the virtual machine from the chosen recovery point.

Set the restore options

Once you have identified the virtual machine and the recovery point, you need to configure the restore options for that virtual machine.

To do this, follow the steps below:

  1. Defining the destination of the restoration:
    1. In the “Restore options” dialog box, choose the restore destination
    2. The options available are “Restore to original location” and “Restore to an alternative location”
    3. The default option is to restore to the original location.
  2. Conflict resolution:
    1. Specify the “Resolving conflicts” options, which tell Arcserve UDP what to do if conflicts occur during the restore
    2. There is an option to overwrite the existing virtual machine. By default, it is not selected
    3. If it is selected, the restore will overwrite any existing images of that virtual machine at the restore destination
    4. If it is not selected, the restore job will fail if the VM already exists in the original location; in an alternative location, a separate VM will be created.
  3. After Recovery” option:
    1. Set the “After recovery” option, which determines whether the virtual machine is powered on once the restore is complete
    2. By default, this option is not selected.
  4. Selection of the Restoration Destination:
    1. When configuring the VM recovery process, it is important to select the restore destination
    2. The options available are “Restore to original location” and “Restore to an alternative location”.

Finally, after choosing the virtual machine and the recovery point, it is essential to configure the appropriate restore options.

This includes choosing the restore destination, setting conflict resolution and determining whether the VM will be powered on after recovery.

Choosing these options carefully helps ensure an accurate, successful restore of the virtual machine.

Set the options for restoring to the original location

To restore a virtual machine to its original location, follow the steps below:

  1. Restore options: in the “Restore options” dialog box, check the “Resolve conflicts” and “After recovery” options. Then select “Restore to original location” and click “Next”. The appropriate dialog box for VMware or Hyper-V will be displayed
  2. vCenter/ESX Server credentials: for VMware, the “Set credential for source vCenter/ESX Server” dialog box opens, where you enter the credentials needed to access the virtual machine:
    1. Then fill in the fields:
      1. vCenter/ESX Server: displays the host name/IP address of the target vCenter or ESX server
      2. VM name: displays the name of the virtual machine to be restored
      3. Protocol: offers a choice between HTTP and HTTPS for communication with the destination server
      4. Port number: sets the port used to transfer data between the servers
      5. Username: the name of a user with access to the vCenter/ESX server
      6. Password: the password for that username.
  3. Hyper-V Server/Hyper-V Cluster credentials: for Hyper-V, fill in the relevant fields:
    1. Hyper-V Server/Hyper-V Cluster: displays the host name or IP address of the target Hyper-V server or Hyper-V cluster
    2. VM name: displays the name of the virtual machine being restored
    3. Username: allows you to enter the name of the user with privileges for the Hyper-V server or Hyper-V cluster
    4. Password: enter the password for that username.
  4. Restore Summary: click “OK”. The “Restore Summary” dialog box appears, showing all the options for restoring to the original location.

Set the options for restoring to an alternative location

To restore a virtual machine to an alternative location or to a different datastore, you need to configure that alternative location.

Here are the detailed steps for VMware and for Hyper-V:

  1. Alternative Site Configuration:
    1. In the “Restore options” dialog box, check the “Resolve conflicts” and “After recovery” options
    2. Select “Restore to an alternative location”.
  2. Configuration for VMware:
    1. The “Restore options” dialog box expands to display the additional alternative restore options
    2. Fill in the fields for the vCenter/ESX server:
      1. vCenter/ESX Server: specify the hostname or IP address of the target vCenter or ESX server
      2. Username: enter the access credentials
      3. Password: enter the corresponding password
      4. Protocol: choose between HTTP and HTTPS for communication
      5. Port number: choose the port for data transfer.
  3. Configuration for Hyper-V:
    1. The “Restore options” dialog box expands to display the additional alternative restore options
    2. Fill in the fields for the Hyper-V server:
      1. Hyper-V server: specify the hostname or IP address of the target Hyper-V server
      2. Username: enter access credentials
      3. Password: enter the corresponding password
      4. Add virtual machine to cluster: select whether to add the restored virtual machine to the Hyper-V cluster.
Datastore configuration (VM → VMware / VM → Hyper-V)

To complete this step, you need to configure where the VM’s data will be stored, both for a VMware VM and for a Hyper-V VM.

Finally, review the restore summary.

Here is the step-by-step process:

  1. MV Data Storage Configuration:
    1. Specify the datastore for the whole VM or for each of its virtual disks
    2. For each virtual disk, specify the datastore and the virtual disk type
    3. Click “Connect to this vCenter/ESX server” or “Connect to this Hyper-V server” to verify the credentials
    4. Once validated, the VM configuration fields will be activated.
  2. MV configurations for VMware:
    1. Fill in the VM settings, including the VM name, the target ESX server and the resource pool or vApp to use
    2. Specify the datastore for each virtual disk, including the virtual disk type
    3. Configure the network settings.
  3. MV configurations for Hyper-V:
    1. Fill in the VM settings, including the VM name and the destination path for the VM configuration file.
    2. For each virtual disk, specify the path on the Hyper-V server and the type of virtual disk
    3. Configure the network settings.
  4. Restore summary: click on “OK”. The “Restore Summary” dialog box will display the restore options for the alternative location.

Restore the virtual machine

The restore summary lets you review all the restore options you have set and change them if necessary.

To run the restore, follow these steps:

  1. In the “Restore Summary” dialog box, check that all the restore options and settings shown are correct.

Summary of a restore to the original location:

Restore the virtual machine

Summary of a restore to an alternative location (VMware):

Restore the virtual machine

Summary of a restore to an alternative location (Hyper-V):

Restore the virtual machine

  • If any of the summary information is wrong, click “Previous” and go back to the relevant dialog box to correct the setting
  • If the summary information is correct, click “Finish” to start the restore.

Once this is done, your virtual machine will be restored.

Check that the virtual machine has been restored

Once the restore is complete, you need to confirm that the virtual machine has actually been restored to the specified destination.

To do this, follow the procedure described below:

  1. Restore to the original location: if you chose to restore the virtual machine to its original location, log in to the vCenter/ESX or Hyper-V server and check that the virtual machine is there
  2. Restore to an alternative location: if you chose to restore the virtual machine to an alternative location, log in to the vCenter/ESX or Hyper-V server you specified in the restore options and confirm that the virtual machine has been restored correctly
  3. Confirm: thoroughly check that the virtual machine has been restored and is available for use.

This way, you can be sure the VM was restored successfully and is ready to use.

How to recover data from a virtual machine without risking it?

Recovering data from a virtual machine safely requires careful measures and a well-planned strategy.

Here are some steps to minimize risks when recovering data from a VM:

  1. First of all, isolate the affected VM to prevent problems or errors from spreading to other parts of the virtual environment
  2. Make sure you have a valid, recent backup of the VM before attempting any recovery, so you can return to a safe state if something goes wrong
  3. If possible, clone the affected VM or take a snapshot before attempting recovery, so you can test the recovery procedures without affecting the original VM
  4. Understand the cause of the data loss before proceeding with the recovery. That way, you can choose the best approach to recovering the lost data
  5. Use data recovery tools designed for virtual environments that are compatible with the VM’s file system and the virtualization platform
  6. During recovery, avoid unnecessary writes to the affected VM. Stick to read-only operations so you don’t make things worse
  7. If the recovery involves more complex or risky operations, make a complete backup of the current VM before proceeding. This provides an additional layer of security
  8. If possible, create an isolated test environment to carry out the recovery procedures. This allows you to evaluate the results without affecting the production environment
  9. Record all the steps you take during the recovery process. This is useful for future reference and can help identify possible problems
  10. If the recovery involves complex or risky situations, consult data recovery experts with experience in virtual environments.

How do you recover orphaned virtual machines?

In exceptional cases, virtual machines hosted on an ESXi server managed by vCenter Server can become orphaned.

In this scenario, the virtual machines are still registered in the vCenter Server database, but the ESXi host they reside on no longer recognizes them.

Although rare, it does happen, and it creates a disconnect between the central management layer (vCenter Server) and the execution nodes (ESXi hosts) in the virtualization environment.

Virtual machine orphaning can occur for a variety of reasons. For example, communication failures between vCenter Server and ESXi hosts, unexpected outages or even problems related to data corruption.

When a virtual machine becomes orphaned, it is still listed in the vCenter Server database, but the ESXi hosts cannot identify or manage its current state.

To resolve this situation, it is necessary to re-establish the connection between vCenter Server and the ESXi server on which the virtual machine is hosted.

This is done through diagnostic procedures, such as checking the network settings, analyzing the vCenter Server and ESXi logs, and trying to bring the virtual machine back into the virtual environment.

Find the datastore where the VM configuration file is located

In the virtual environment’s management console, start by locating the virtual machine’s .vmx file.

To do this, browse the inventory and select the virtual machine. Then open the “Datastores” tab.

In the Datastores tab, you will see the datastores where the virtual machine’s files are stored.

If more than one datastore is listed, you need to check each one. Select each datastore in turn and open the Files tab.

The interface will then show the files stored on the selected datastore.

The goal here is to find the .vmx file, which is essential for running the virtual machine. Browse through the datastore’s folders until you find the .vmx file for the virtual machine in question.

If several datastores are involved, repeat the search for the .vmx file on each one.

Once you have found the .vmx file on the right datastore, make a note of its location: you will need it to register the VM again.

Remove the virtual machine from the inventory

Go back to the virtual machine inventory, right-click the virtual machine and choose “Remove from Inventory”. This only removes it from the inventory; it does not delete its files from the datastore.

Confirm the removal of the virtual machine

Click “Yes” to confirm the removal of the VM.

Register the virtual machine again

Right-click the datastore where the virtual machine’s files are stored and choose “Register VM”.

Then browse to the .vmx file and confirm by clicking “OK”.

Next, choose where to place the virtual machine and click “Next”.

Choose the host that will run the virtual machine and click “Next” again.

Finally, click “Finish” to complete the process.

How do I back up and recover data from virtual machines?

Backing up virtual machines means creating backup copies of running virtual machines.

These backups protect applications and data in the event of failures or disasters, minimizing service interruptions and preventing the corruption or loss of information.

A virtual machine backup usually includes a complete image of the VM, including the operating system, applications and data.

These images should be stored in safe locations, such as external storage systems or cloud backup services, so they are ready to restore the environment in an emergency.

It’s important to note that backing up virtual machines is quite different from traditional file copies.

That’s because VM backups must ensure the continuity and integrity of services, especially in adverse situations or unexpected disasters.

With that in mind, to be able to recover information from a virtual machine, keep your backups up to date and follow these steps:

  1. Choose your software: use a backup solution such as the one described above or the tools built into your hypervisor (Hyper-V, VMware, VirtualBox, etc.)
  2. Configure VM protection: select the VM and set the backup options, such as frequency and destination
  3. Choose a destination: a local server, a storage system or NAS, or the cloud
  4. Start the backup: run the chosen software and wait for the process to complete
  5. Check the backup: make sure the VM backup completed successfully and can actually restore the environment.

Remember that the steps may vary depending on the backup or recovery software you choose, so read the vendor’s instructions before you start.

How can Bot help?

Has your virtual machine crashed, and none of the solutions in this article have managed to recover it?

Then it’s probably time to turn to a data recovery company and let professionals restore the drive and recover as much of your lost data as possible.

However, when choosing a data recovery company, check that it has:

  • Clean rooms and professional equipment: many companies offer data recovery services, but not all of them have the right facilities and equipment. These are essential to avoid further damaging the drive during the recovery process and making the problem worse
  • A proven track record: companies with long experience in the market offer greater security in the data recovery process
  • Positive reviews: it is wise to always check online reviews before selecting a data recovery company

Bot is a company that meets all these criteria, with highly qualified professionals, a Class 100 (ISO 5) cleanroom, more than two decades of experience in data recovery and a 96% success rate.

Don’t waste time: start your VM data recovery process with us right now and join the more than 200,000 cases we have handled!

About the author
Filipe BragaGestor de laboratório · Laboratório Bot

Filipe Braga is an engineer and runs the Bot lab. He works on the most complex data recovery cases, mainly RAID systems and servers, where every drive counts and the order of steps matters. Day to day, he organises the bench work so that each device follows the right procedure. On the blog, he writes about RAID and difficult cases. Outside the lab, he enjoys cycling and a good wine.

All articles by Filipe Braga →

Need to recover your files?

The diagnosis identifies the fault and whether recovery is technically viable. You receive a quote before any work begins.

Start diagnosis
Share