Keeping same MorefID upon re-registering

[Moebius]

Greetings,
I need to replicate some VMs from a VMware 6.0 to a 5.5 environment (both managed by vcenters). The VMs on 6.0 are on virtual hw 11, so I get an error when trying to replicate saying that virtual hw 11 is not compatible with VMware 5.5, which is expected.
Downgrading the VMs to virtual hw 10 is easily done by de-registering, editing the vmx files, and re-registering them in the same location. After that the replication goes without problems.

Now the problem is that re-registering the VMs they get a new MorefID and Veeam sees them as new VMs. The 6.0 environment is a cloud infrastructure where I have backup chains already going on and limited storage space; there is no way to accomodate new full backups for all the VMs. I need to continue the existing chains.

Any solutions?

[HannesK]

Hello,
there is no officially supported way for this scenario. I heard from customers that they successfully manually edited moRefID in the Veeam database and for migrated from one VCenter to three VCenters.

So technically it is possible, but you need SQL skills.

Best regards,
Hannes

[Moebius]

I searched the db and found that in my case the moRefIDs are referenced as 'object_id' in table dbo.BObjects, and only as a substring within the 'inside_dir' column in table dbo.Backup.Models.OIBs.
So editing these two tables (or maybe only dbo.BObjects) and changing the old moRefID to the new one would be enough to do the job?

[foggy]

Hi Lucio, you've identified moref's location correctly, though, please keep in mind, that we do not recommend direct interaction with the database.

[Moebius]

Well, just for the records, I tried and edited the moRefID of just one vm in the job.
The vm had changed its moRefID after downgrading its virtual hw from 11 to 10. So I went on and edited all instances of the old moRefID substituting it with the new one. Then I ran an incremental backup.
The job is a forward incremental forever including a dozen VMs, and it does not use per-vm chains (the license doesn't allow).

Unfortunately, not only didn't it work, it even corrupted the whole backup chain. In the first run all the VMs seemed to complete without problems, but the merge phase failed with this message:
"There is no FIB [summary.xml] in the specified restore point. Failed to restore file from local backup. VFS link: [summary.xml]. Target file:[omissis]
Agent failed to process method {DataTransfer.RestoreText}."
The subsequent runs saw all VMs failing with a similar message.

I wasn't able to recover the existing chain and resorted to throwing it away and starting a new one.
I suspect that I should have changed the references to the old moRefID only in table dbo.Objects, but not in table dbo.Backup.Models.OIBs as it maybe references the existing restore points in the chain; or maybe there are references to the moRefIDs external to the database. Either way, I understand why direct interaction with the database is not recommended. But it was fun to try

[DGrinev]

You can ask our support team for assistance with the editing morefIDs DB, they can help you to figure out what was wrong with your scenario. Thanks!

[Moebius]

Thanks. But there was no time to wait for the support team, and I had to rebuild a backup system quickly.
Interestingly, something had gotten seriously wrong on the proxy server and I had to rebuild it from scratch, repository included. So maybe two issues got mixed together.

On a side note, in subsequent attempts I found that it wasn't necessary to de-register and re-register the VMs for downgrading from virtual hw ver.11 to 10, at least in my scenario. Just shutting down the VM, editing the vmx file and powering it on again did the job. This way there was not even a change in the moRefIDs.

[mcz]

Last week, I had the situation that one of our hosts (with direct attached storage) went down and I did an immediate failover using replicas created before. When the hardware issue was fixed and I had to re-register the VM's and therefore they all got new morefid's. I consulted veeam technical support and got a reference to the vcenter migration tool which of course wasn't applicable because the vcenter hasn't changed. I then asked for the logic that the tool uses to manually do the updates in the database and got the following answer:

I consulted with several senior engineers and the management, but I'm afraid I cannot provide requested query extracted from the script and list of the tables in the database.
Retrieving the script from unsupported utility is out of Veeam technical support scope and will most likely be not applicable as having old vCenter is essential for execution. As we discussed such database edits can seriously compromise backup consistency as well the Veeam instance functionality, therefore I was not authorized to share the database tables references.
I regret to tell you, but it will have to be space consuming full runs and VMs indeed will be treated as new ones.

Why does this tool only provide vcenter migration? I would like to have an option to to a "VM morefID migration" caused by re-registration (for whatever reason). Could that be implemented?

So I did a failback to the new (old) VM's to the original host and run a new backup job, expecting to see a lot of "new" VM's. To my big surprise I saw that many of the "new" VM's where mapped to the existing backup chain and so only increments were created - perfect. But why? Did the failback operation update several database entries?

Thanks for the clarification!

[Vitaliy S.]

Why does this tool only provide vcenter migration? I would like to have an option to to a "VM morefID migration" caused by re-registration (for whatever reason). Could that be implemented?

This tool was developed based on the most commonly used scenarios in addition to the required time by RnD team to implement it.

So I did a failback to the new (old) VM's to the original host and run a new backup job, expecting to see a lot of "new" VM's. To my big surprise I saw that many of the "new" VM's where mapped to the existing backup chain and so only increments were created - perfect. But why? Did the failback operation update several database entries?

Let me quickly check that with the RnD team, but before that can you please open the restore wizard and select the restore point after the failback operation for one of the VMs in question. Do you see two VMs with the same name there or just one?

[HannesK]

Hello,
it depends how you failback. If you failback to the original location and the old backup job (from the time before failover) is still in place, then your behavior is "works as expected".

Can you describe what you exactly did? Step by step in the order you did it.

Thanks,
Hannes

[mcz]

Let me quickly check that with the RnD team, but before that can you please open the restore wizard and select the restore point after the failback operation for one of the VMs in question. Do you see two VMs with the same name there or just one?

Vitaliy, are you talking about backups or replicas? In terms of backups: I just have two VM's in the backup chain with identical name - the one which wasn't replicated. All the other VM's in the chain got mapped to the new morefID.

Hannes, I've choosen the second option during failback and pointed to the (old) VM's with the new morefID: https://helpcenter.veeam.com/docs/backu ... l?ver=95u4. I suppose that this the reason why the mapping finally took place. Long story short:

Host A and B. VM's are replicated from A to B and B to A.

• Host A had a hardware failure

• Replication Failover on Host B was launched via Veeam Console

• Host A was repaired, VM's still existed but I had to re-register them in order to become online again

• Replication Failback was launched, option "Failback to the original VM restored in a different location" has been chosen

• Failback was successful, commited it

• Edited Backup Job (Added (old) VM's with new morefID's

• Started Backup Job and expected, that all VM's with new morefID's would become a new chain and would start with a VBK-file. It only happened to one VM which wasn't part of replica failover/failback

[Vitaliy S.]

I'm talking about backups. Backup does not map automatically anything if moref ID is different, that's why I wanted to see details of the job sessions where you see incremental pass in addition to the restore point wizard details.

Started Backup Job and expected, that all VM's with new morefID's would become a new chain and would start with a VBK-file. It only happened to one VM which wasn't part of replica failover/failback

A new backup chain is not always created, you can have a full VM pass stored in the vib file, that's why I wanted to check the size of the file and what VMs are stored there.

[mcz]

Really? Fulls could be part of a VIB? Quite confusing for me.... Anyway, I can confirm that no fulls (except for the one mentioned VM) have been created, this screenshot confirms my assumption:

[Vitaliy S.]

Really? Fulls could be part of a VIB? Quite confusing for me....

Yes, for example, if you back up a container with VMs and add a new VM to this container in the middle of the backup chain, then VMs that have already been backed up will do an incremental backup, while the newly added VM will obviously need a full backup created.

Can you open a restore wizard, select the restore point after that incremental job run and tell me if you have only one VM there or two with the same name?

[mcz]

Well as I said I'm having only one "duplicate" (the VM which hasn't been replicated). This is the view from the restore wizard:


If I'm still not delivering the information you need, please give me a short description how to fetch the requested data - thank you.

[Vitaliy S.]

I was referring to this step of the wizard. There should be two VMs available for restore (since moref IDs are different), if not, then I don't have other ideas on what happened. If you want to dig deeper, then failback logs review is required here. Our support team can help you with reading them.

[mcz]

OK Vitaliy, meanwhile the support team confirmed that replica failback automatically updates morefid's if you choose the second option here: https://helpcenter.veeam.com/docs/backu ... l?ver=95u4. Could someone please update the helpcenter so that this information can be found?

In general, it shouldn't cause any negative sideaffects (the morefid-change) but in my case it started a very unfortunate chainreaction. Long story short: If you remove such a chain from the configuration and rescan the repository, all offloaded restorepoints containing the old morefid will become unavailable and the offload writes into a complete new folder. I think this should be considered for the new v10. I've already contacted the teamleaders and the case is currently being investigated by RnD/QA. Case # 03620219

[foggy]

Could someone please update the helpcenter so that this information can be found?

Thanks, Michael. We will consider updating documentation with this information.