Restore to new server


Hello GChen

First thank you for creating this nice piece of software.

Second my question. Two servers, old and new backing up to the same storage with different id’s.
The new server is completely empty and i would like to restore the vm’s from the old server on the new server.

I am using the command: vertical restore /newstoragepath/vmdirectory/ -f vm@old -r 1.
After first creating the vmdirectory this works but the vmx and vmxf files are put in the root of the vmdirectory while the vmdk file is put in the(relative to the new directory) old storage path.

Would it be possible to create some extra switch to the restore command which creates the new vmdirectory and puts all files in the root of the new vmdirectory or would this cause problems?

Best regards, Robert Jan


The recommended way is to create a vm with the same name on the new server and pass the name of the vm to the restore command. Then the restore command should preserve the original paths.

When you pass a destination directory to the restore command, it will try to preserve the original paths as much as possible, so when it sees the path contained in the backup it will try to restore files to that path. I guess the paths of those vmx and vmxf files do not matter, as long as they are referenced by the main vmx file of the vm.


Thanx for the response.

Tested it but sorry. After first creating a new vm the problem stays and the result is even messier.

Command used: vertical restore vm -f vm@old -r 1
Resulting in: The destination directory /oldstoragepath does not exist; use /newstoragepath/vm/oldstoragpath/vm instead.

Vmx & vmxf get copied to the /newstoragepath/vm directory but the vmdk isn’t.

Total result: one vm with two vmdk’s.
One new vmdk(empty) in the /newstoragepath/vm and one the on copied in /newstoragepath/vm/oldstoragpath/vm

In my humble opinion this is not my prefered way.
It’s also more work with possible typo’s because of first having to create the new vm’s.
Example, having esxi servers with about 20 desktops with long(explaining) names.

When copying the files you just have to rightclick the vmx and register the vm.
Ready you are.

So my question stays :slight_smile:

Best regards, Robert Jan


I encountered this issue as well.

In order to finalise the restore to a different ESXi host, I had to manually move the *.vmdk’s back into the proper location relative to the newly-created VMs root.

If it matters, the original host’s datastore name was datastore1 (lowercase) and the new host’s datastore was Datastore2 (capitalised), and thus Datastore1 exists, but not datastore1.

Not only that, I had to then remove the VM from the inventory and re-add it, since obviously the .vmx settings were no longer applicable.

I think it would be better for the restore process to handle restorations with or without the VM being in the inventory already. Perhaps it should temporarily remove the VM from the inventory and re-add it after the restore is complete anyway, since you never know, some of the VMs configuration may be different?

Incidentally, I didn’t have an empty new .vmdk as I just skipped the creation of the virtual disk, but this is all the more reason Vertical Backup should be able to deal with all situations. Without any extra manual intervention; to the same host or different host+datastore, create a new directory if needed, and obviously strip the pathname if necessary as well.


The destination directory /oldstoragepath does not exist; use /newstoragepath/vm/oldstoragpath/vm instead

Sorry I forgot about this: the vmdk files will be restored to the correct location only if the name of the vm is the same AND if the path of the datastore is the same.

If either of these is different, then you will need to manually edit the restored vmx/vmdk files to make it work. It is possible to make Vertical Backup smarter to make all these tweaks for you, but I haven’t figured out how to do this cleanly and reliably.