Can't seed replication. Error message about vm not found.

[davidb1234]

Can someone please help me? I have a support case 5213437 and they are not being helpful at all. Support is telling me that seeding is not possible unless I copy every single .vrb file as well as the vbk and vbm file when importing. That is CRAZY talk....

We take reverse incremental backups so that the vbk file is the complete VM with the most recent data. So I copied only the vbk and vbm file. To copy every single vrb file would take an ENORMOUS amount of data.

What am I doing wrong with my seeding process and why is support telling me this?

1. Copy vbm and vbk file to USB drive from veeam backup server at main office.
2. Take USB drive from main office to DR hot site and plug in to DR Veeam server.
3. Create repository from USB drive and import backups. backups import successfully. I see all Vms I want to replicate in the imported media.
4. Create replication job and choose to seed from repository. select correct repository.
5. Run job and get error:


Cannot find VM in the backup file specified for seeding
Task failed unexpectedly

[foggy]

David, please specify the correct case ID, seems you missed one digit in its number.

Btw, the exact seeding procedure is described in this post, though you seem to follow it quite precisely.

EDIT: Updated the case number.

[davidb1234]

my case is in fact 5213437 and your support staff are telling me I am doing it wrong and have to peform all of these extra steps like take an extra backup or first restore the VMs to the DR site and then use the mapping features....

I am very confused now.... how do I get your support staff to help me?

EDIT: Still speaking to support. They don't want me to do it this way and are telling me I should restore all of the VMs first then seed by mapping. With a large jobs and lots of VMs this will make this process very time consuming and require double the space on the SAN to get these seeded.

I am concerned that nobody from Veeam support is concerned or wants to investigate this issue.

Since I am forced to do this the long way and restore all my VMs first and then using the mapping feature I would also like to point out that the detect button feature is also broken....

[foggy]

my case is in fact 5213437 and your support staff are telling me I am doing it wrong and have to peform all of these extra steps like take an extra backup or first restore the VMs to the DR site and then use the mapping features....

I am very confused now.... how do I get your support staff to help me?

As I can see from the case, support tech is referencing the same seeding procedure (which does not work for you, for some reason) and has suggested the possible workaround. However, you are free not to close the case until the actual cause of your initial problem is discovered.

[davidb1234]

Do you suggest I escalate this case to a manager? The support staff don't seem to want to help with this and are either telling me I am doing it wrong or that I should use a workaround.

[foggy]

Yes, if you are not satisfied with the level of support you are given, please escalate the issue to the support management team (I guess you've already noted the Talk to a Manager button on the customer support portal).

[asin@puleng.co.za]

Hi

Im experiencing the same problem with the replication seeding, has there been a resolution to this?

[foggy]

According to the OP's support case, this behavior was reproduced and confirmed to be a product issue. At the moment I cannot give the estimate of when it is supposed to be fixed, need to check. Currently you can restore the VMs from backup on target and then map the replicas as the workaround.

[Vitaliy S.]

Anyway, it's better to open support case to be notified once the resolution to this issue is available.

[Rumple]

thank god for forums, I just hit this exact same issue trying to do a seeing from repository
Least I know I was doing something correct and will try out the restore first and mapping.

[maupol]

Hi,
I'm in the exact same situation. No seeding from imported files. Issue still not solved?
Mauro

[foggy]

I have not heard anything about that since then, will try to check with devs/QC.

[foggy]

Mauro, the ball is still on the dev's side. Could you please open a case as well so we have more information to investigate the issue, as well as notify you when the fix is available?

[antspants77]

Just adding my voice to the "fix it ASAP" list.
So many times in forums, we get the "just reseed it" line on these kind of problems.
Problem is, this takes resources both in the copying to USB (hundreds of GBs to USB takes hours), the travel time (2 hours each way).
Then we do all this and you are NOW saying, oh, it doesn't work, sorry about you wasting over a thousand dollars of your time, that you can't charge to the customer. Maybe we should have told you.

[Vitaliy S.]

Tony, I would appreciate if you could open a support ticket on this and provide full debug logs, as this would definitely help in nailing down this issue. Thanks!

[antspants77]

Hi,
We couldn't afford the resources necessary to reseed again and customer was getting more and more exposed by not having a replica of an important VM, so followed the comments above about going the long way. This involved installing the free version of Veeam B&R 6.5 to the Physical Backup Repository / Proxy server we had running at the DR site, then opening (right click, Open) the VBK file from the "Files" tab on the left (select This Server, then navigate to the drive).
Was then able to import the file to become a VM at the DR site.
However, I selected to rename the VM, by adding _replica to the VM name within the wizard.
When I reconfigured the replication job to map the backup to this new VM, I got the errors
[Backup2] SERVERNAME_replica/SERVERNAME.vmx was not found
[Backup2] SERVERNAME_replica/SERVERNAME-000001.vmdk was not found

I was surprised to see there were snapshots, so when I looked at the Datastore, I realised, that even though, I had selected "Delete from Disk" when I discovered that the replica VM was too corrupted at the very start of all this, the folder was still left behind on the datastore.

I am now restoring again (6 hours for 500GBs) and then will attempt the Replication with mapping to the new VM again.
I didn't place a call, because, I was pretty sure I would get the line "Can you just reseed one more time please" line again. Which would translate into 10 plus hours of my time.
If we are to continue using this product, then something must be done about fixing the replicas, rather than just reseeding. Every engineer know that a clean install or clean seed will fix most problems, but we need something that won't take hours of copying and travel time to rectify.
I will let you know how the long way goes.

[tsightler]

Using the replica mapping feature it is pretty much always possible to recover without reseeding as long as the base VMDK files still exist on the target (it might not always be practical if the source and target have diverged too much). In the absolute worst case you can manually create a new VM on the target that matches the source VM configurationg and attach to the existing VMDK files, then use replica mapping to "repair" the base VMDKs. It's impossible to guess what might have caused your specific issue with replica mapping with the small snippet you provided, it's possible there's some glitch with the rename, but I've used this procedure hundreds of times in dozens of client environments and I'm sure it would have been possible to save the VMDK files assuming they existed on the target at all in a usable way.

[kjc3303]

Did this ever get fixed? I am seeing the same issue, I will log a support call tomorrow.

One thing I would like to put out there is if I start the Replication seeding from the original location of the backup file the replication starts to go process but when I put the Backup job on a USB drive and move to a different server create Repo and try to seed from there it doesn't work with the above error even though it imports the backup job OK.

Kev

[foggy]

I am seeing the same issue, I will log a support call tomorrow.

That would be highly appreciated as support did not get enough information during previous cases related to this issue and additional research is still required.

[kjc3303]

Will do, currently restoring the vm (from the same backup file in the same Repository ) so I can map the replication to it. It's restoring but slowly due to being on a usb drive

I will try to reproduce with a test vm to produce some clean logs and log a support call tomorrow.

Cheers

Kev

[kjc3303]

Support call logged #00190602

Kev

[foggy]

Apart from the support investigation, have you tried to rescan the backup repository where the backup file used for seeding was placed in (instead of importing it manually)? Seems to work this way in our lab (and fails in case of manual import).

[kjc3303]

Hi Foggy. I always use the rescan method- see email below sent to support with further details- I am going to try the manual import method today.

Kev

I do not use import, I copy both .vbk and .vbm file to the remote repository and the re-scan repository

here are the results from the re-scan

20/03/2013 14:38:06 Starting synchronization of backup repositories for all backup jobs
20/03/2013 14:38:06 Enumerating backup repositories. Found 1 backup repositories
20/03/2013 14:38:13 Processing backup repositories
20/03/2013 14:38:13 Performing backup repository VMFS synchronization. Backup repository VMFS synchronized: 1 backups added, 0 updated, 0 removed, 0 skipped
20/03/2013 14:38:13 Backup repositories synchronization completed successfully

As you can see the backup job is recognised and imported.

Please let me know if you would like me to test any further methods, I may not be able to do this until tomorrow now

[kjc3303]

Just a Quick update, all three methods fail

1, rescan repository
2, import from vbm
3, import from vbk

all with the same error

21/03/2013 11:36:34 :: Cannot find VM in the backup file specified for seeding

[foggy]

Kevin, thanks for the update. Please continue working with support on this, the problem seems to be lying deeper.

[kjc3303]

OK a little update and workaround for this issue.

It seems in my case that when the backups are imported for seeding it is adding a duplicate VM entry in the sql database. The support guys are not sure why this is happening at the moment and have taken advanced logging to investigate further.

This is database specific if I create a new database and try to seed everything works as expected. For me as a small shop I can quite easily create a new database and recreate jobs mapping backups to existing jobs.

Support are looking into this further, i have asked them to keep me updated and will in-turn update this topic.

Kev

[kjc3303]

UPDATE to above - Veeam have confirmed the issue here and also confirmed that it is a bug in the software which they are looking to fix in the next release.

The issue is when you have a server in the backup infrastructure with two entries for example your vSphere server which can under the VMware Managed servers tree and also under the Windows Managed servers tree you get the duplicate VM entry mentioned above.

Quite easy to fix change the WINDOWS MANAGED SERVER in the SQL DB (under dbo.hosts) to either IP address or full DNS address restart the console and rescan renamed server.

Thanks

Kev