How to repair replication jobs after renaming datastore?

[vfrolov]

While adding a standalone host with local datastore "disk array" to vCenter the vCenter renames the datastore to "disk array (1)" because other datastore "disk array" already exists for vCenter.

Aafter renaming all replication jobs targeted to the renamed datastore stop working with error.

Any ideas?

[Vitaliy S.]

The only idea I have so far is to try to change destination for your replication job in case you haven't done that already.

I have removed the logs you posted. For any technical issues requiring logs investigation you need to contact support directly with full log files, as explained when you click New Topic.

[jpaul]

Pretty sure Veeam doesnt care about what the datastore is called. It only cares about the unique id (UUID) of the datastore. It "shouldnt" matter if you just rename the datastore, but if you reformat the datastore or somehow resignature it with a new UUID then its time to reseed.

[vfrolov]

Pretty sure Veeam doesnt care about what the datastore is called. It only cares about the unique id (UUID) of the datastore. It "shouldnt" matter if you just rename the datastore, but if you reformat the datastore or somehow resignature it with a new UUID then its time to reseed.

The following scenario is 100% reproducible on my test system with Veeam Backup & Replication 5.0.2.230 (32 bit).

1. Create a job and start replication

replication result: Success

2. Rename destination datastore from "disk array" to "disk array (1)" and start replication

replication result: Fail

3. Rename destination datastore back from "disk array (1)" to "disk array" and start replication

replication result: Success

So Veeam is sensitive to destination datastore name changes.

[tsightler]

After you rename the datastore do you edit the replication job to reflect the new name? I think that's all you have to do.

[vfrolov]

Re-choosing the datastore in the job properties has no any effect.

[Gostev]

You may have to restart Veeam Backup service to clear cached infrastructure data before doing this though.

[vfrolov]

Restarting service and rebooting system do not help.

[vfrolov]

BTW: The following scenario (with using second datastore “iSCSI-XVS-NAS”) works fine on my test system:

1. ‘Remove from Inventory’ original replica VM (with vSphere Client)
2. Copy replica VM subfolder from '[disk array (1)] VeeamBackup' to '[iSCSI-XVS-NAS] VeeamBackup' (with vSphere Client)
3. ‘Add to Inventory’ copied replica VM (with vSphere Client)
4. re-choose the datastore ‘iSCSI-XVS-NAS’ in the job properties (with Veeam B&R)
5. ‘Delete from Disk’ copied replica VM and VM’s subfolder from '[iSCSI-XVS-NAS] VeeamBackup' (with vSphere Client)
6. ‘Add to Inventory’ original replica VM (with vSphere Client)
7. re-choose the datastore ‘[disk array (1)]’ in the job properties (with Veeam B&R)

But this scenario is too complicated, slow, ... and is not helpful for restoring big replicas

[Softeis]

[merged]

Hi,
VMware uses always the UUID from the Datastores. So, it is no problem at all to rename the alias.
In case of Veeam, it seems to be diffrent. No Backupjob works, after renaming a Datastore (alias) to which the job was pointing to.

Is this behavior by Design?
How can i fix it? Can i update the cache or DB? Is there an option to switch to UUID identification?

Any help, workaround or solution will be appreciated.

Thank you!

[cdf]

I opened a ticket with support and this is what they told me.

"I have gone over your ticket and have come to the conclusion that you will need to delete the replica from disk and retry the job. Please advise."

[vfrolov]

I opened a ticket with support too and this is what they told me.

that's the way the product works now

Yes, this issue is already in our "fix list", so it would be done in one of the future releases

Maybe another workaround would be to create a folder "VeeamBackup" on [iSCSI-XVS-NAS] datastore, create a subfolder "test VM(656)" and put empty files with the same name (e.g. 2011-06-01T162243.vbk) to that datastore

I've tested "another workaround" and it works fine on my test system.

Here is the scenario:

1. Create VM subfolder with empty files in '[iSCSI-XVS-NAS] VeeamBackup' (like VM subfolder of '[disk array (1)] VeeamBackup')
2. re-choose the datastore ‘iSCSI-XVS-NAS’ in the job properties (with Veeam B&R)
3. re-choose the datastore ‘[disk array (1)]’ in the job properties (with Veeam B&R)
4. Remove VM subfolder with empty files in '[iSCSI-XVS-NAS] VeeamBackup'

[vfrolov]

Here is a more simple workaround.

The ESX(i) host should be accessible from Veeam B&R via second IP address so second VMKernel should be created.

1. Add Server Standalone ESX(i) host "second IP address" to Veeam B&R.
2. Change job properties - choose Replica destination "second IP address"/"new datastore name".
3. Change job properties - choose Replica destination "first IP address"/"new datastore name".
4. Remove Server "second IP address".