Forum Discussion

quaium's avatar
quaium
Level 3
9 years ago

Backup Exec VM Backup - Different Datastores

Hi,

Just wondering if someone could help with this issue.

We are carrying out backups of our VMWare Virtual Machines using Backup Exec 15. Some of the VM's have two drives on seperate datastores (for example, C:\ drive on Datastore01 and D:\ drive on Datastore02).

When Backup Exec backs up the VM's, it changes the name of one of the servers drives VMDK file buy adding a "(1)" to the end (for example, it will back up VM01.vmdk and VM01(1).vmdk).

Because of this restores via Backup Exec or VMWare Converter do not work. Both files are given the same name of the seperate datastores and this is why restores are failing.

What can I do to get around this problem? Is there an option within Backup Exec to not rename files?

Any help would be great.

Thanks in advance.

  • Ahh I am glad you said that - I am not sure if you will have the same issue if you redirect to a datastore

     

    If you restore to a local drive because we do not know where the VM will end up almost certainly all we do is recreate the VMX file as it was during the backup (so containing the old datastore GUID and the original VMDK name. )

     

    If however you redirect into a datastore it is possible we do correct the VMX content especially as the way a restore works is create an empty VM with the same number of vmdk files and same sizes (CPU, RAM etc) , snapshot the empty VM, restore the backed up VMDKs into the snapshot, merge the snapshots into the VM. It therefore may work for a true redirect into VMware and manually editing the VMX files for the redirection method you chose is probably expected.

     

    C.

     

     

6 Replies

  • We have to do that because Vmware does not create unique names for VMDK files when different datastores are invoved. However we should be able to restore (to original locations - I am not sure about redirects)

     

    You should log a formal support case for this to be looked at in more depth (although please make sure you are using BE 15 FP3 before doing this.)

  • It's the redirect option that we're trying to do. Trying to move VM's from an old vCenter to a new one. I have gotten around the issue by editing the VMX file but doing that for about 40 odd servers is going to be a pain.

  • Ah yes the redirect has no way to specify two different datastores and almost certainly does not correct the VMX file content so is likely to be an issue.

    After the redirected restore, have we amended the VMX file content and actual vmx file name to be unqiue (but match) but the characters we add into the names are not fully compatible with ESXi - or do we leave the original names and datastore paths even though it was a redirect?

     

    If you can please send me a private message with an example of the VMX file content (can be just the parts pertaining to the VMX file names and paths) after the redirected restore and your modified version for the same VM that allows you to use the VM. I would like to ask internally on what we intended and any limitaions but could do with just a little more detail when I start asking. ;)

     

    C.

     

  • Hi Colin,

    PM sent.

    Also, just so you are aware, at the monent we are using the "to a different path" restore and then importing the VM to the new vCenter. We are hoping to use the "to a different vCenter or ESX server" at a later date but I am assuming we will have the same issue.

  • Ahh I am glad you said that - I am not sure if you will have the same issue if you redirect to a datastore

     

    If you restore to a local drive because we do not know where the VM will end up almost certainly all we do is recreate the VMX file as it was during the backup (so containing the old datastore GUID and the original VMDK name. )

     

    If however you redirect into a datastore it is possible we do correct the VMX content especially as the way a restore works is create an empty VM with the same number of vmdk files and same sizes (CPU, RAM etc) , snapshot the empty VM, restore the backed up VMDKs into the snapshot, merge the snapshots into the VM. It therefore may work for a true redirect into VMware and manually editing the VMX files for the redirection method you chose is probably expected.

     

    C.

     

     

  • OK. I guess we are going to have to try the redirect option and see how that goes. Thank you for the help and advice anyway. If the redirect option fails I'll post back.