Last updated on Monday 28th of February 2022 08:52:48 PM

©XSIBackup Classic Restores

Restore your VMs | How to rebuild an ESXi VM disk layout

 Please note that this post is relative to old deprecated software ©XSIBackup-Classic. Some facts herein contained may still be applicable to more recent versions though.

For new instalations please use new ©XSIBackup which is far more advanced than ©XSIBackup-Classic.

UPDATE 2018-12-05:

Since XSIBackup-Pro 11.1.7 the restore module can resume partial transfers when restoring XSITools backups over IP. This is very convenient when restoring from unstable backup servers in the Internet.

UPDATE 2017-01-19:

Since XSIBackup-Pro 8.0.0 a restore module has been added to the advanced version.

UPDATE 2016-08-05:

Since XSIBackup-Pro 6.0.0 (jun 2016), VMs are startable in the very same backup location (Fast Start). For this to be possible paths are tweaked in such way that all disks are placed in the backup folder and all paths are changed to point to them. If you had your original VM with all disks placed in the default VM folder nothing will change. But if on the contrary your VM layout was more complicated and .vmdk disks were distributed across different datastores/ locations, then the backed up VM disk layout will be changed. To redistribute them to their original locations tweak your VM disk layout the same way you originally did.

To restore your backup to a different datastore simply copy the whole VM backup folder as it is.

If you use ©XSITools or Borg as the backup programs (--backup-prog argument), you will need XSIBackup-Pro's restore module to be able to restore those VMs.

In case of Borg, the VMs are stored tarred (packed with the tar binary), so you can restore them manually by extracting from the Borg repository and then un-tarring the just extracted file. The Pro restore module does this on the fly in just one step.

------------------------------------------------------------------------------------------------------------------------------------------

Many people have asked us to write an article about this topic. To tell the truth we have not dedicated much effort to this matter due to its simplicity. Let me explain why:

XSIBackup copies the .vmx and the .vmdk files "as they are" to their backup point, thus simply copying them back to their original location is enough to restore the contents of these files. In any case there are a few things to take on account about XSIBackup behaviour if you want to do a straight restore without any hassle.

XSIBackup will locate every .vmdk file where it is in the ESXi datastore map, many people like to place them in different datastores to gain I/O speed per instance or because they have organized their own system in such way. In any case XSIBackup will place them all in the same folder at the --backup-point defined in the argument list. This implies that if you want to restore the full VM including its .vmx file to a new location you will have to edit it to reflect the new path of the .vmdk disks in the new system. This is not that complicated and am sure most of the readers already know what i'm talking about. Let's get into the details and see how to do it practically.

Let's say that you have a Virtual Machine running on your VMWare ESXi hypervisor that has two disks attached to it, we will call it VM1 in sake of simplicity. One of the disks will be the system .vmdk file and will be stored in the same folder as the .vmx file. The second disk will be stored in a different datastore.

The original .vmx file would look like this, only in the part regarding the disks layout:

scsi0:0.present = "TRUE"
scsi0:0.fileName = "disk1.vmdk"
scsi0:0.deviceType = "scsi-hardDisk"
scsi0:0.ctkEnabled = "true"

scsi0:1.present = "TRUE"
scsi0:1.fileName = "/vmfs/volumes/datastore2/disk2.vmdk"
scsi0:1.deviceType = "scsi-hardDisk"
scsi0:1.ctkEnabled = "true"

As we can see, we have two .vmdk disks attached to this Virtual Machine. When we back it up with XSIBackup, all .vmdk and the .vmx file containing the above information will be copied during the backup to the --backup-point folder. So far so good, there's nothing too complicated in that behaviour. If we wanted to restore the Virtual Machine we would only need to keep the very same paths for the disks, as defined in the .vmx file, but; what if we wanted to restore the VM to a different location changing the relative paths of the disks in regards to the .vmx file?.

Let's imagine that our original server broke down and that we need to temporarily restore the VM to another system where the system disks are stored in /vmfs/volumes/sysdisks/[VM name] and the data disks are stored to /vmfs/volumes/datadisks/[VM name]. All the .vmx files will be stored to /vmfs/volumes/datastore1/[VM name]. If we copied all the contents of our backup folder located at --backup-point to .../datastore1/[VM name] and tried to switch it on it would find the system disk but would fail at the time of linking to the second disk at /vmfs/volumes/datastore2/disk2.vmdk. So, to make the VM work at its current server we should do the following: copy the .vmdk files to their definitive location (the first one to sysdisks and the other to datadisks), copy the .vmx file to its location at /vmfs/volumes/datastore1/[VM name] and edit it to reflect the new path of each disk, so that the VM is able to find them.

In the end all we have to do is change two lines at our .vmx file:

scsi0:0.present = "TRUE"
scsi0:0.fileName = "/vmfs/volumes/sysdisks/VM1/disk1.vmdk"
scsi0:0.deviceType = "scsi-hardDisk"
scsi0:0.ctkEnabled = "true"

scsi0:1.present = "TRUE"
scsi0:1.fileName = "/vmfs/volumes/datadisks/VM1/disk2.vmdk"
scsi0:1.deviceType = "scsi-hardDisk"
scsi0:1.ctkEnabled = "true"

And that's all, there is not much more to say in regards to restoring a VMWare ESXi Virtual Machine that was backed up using XSIBackup. In any case every maestro has his small book of secrets, so you might find it easier to create a new VM at the new server and attach the backed up .vmdk disks to the new VM. I prefer to use the manual method because I have more control on whats going on. The vSphere Client tends to do things its own way, so you may find things like new folders with sufixes being created to store the attached disks and messing up your intended organization.

Daniel J. García Fidalgo
33HOPS