Replication failed

[johnlong]

First a little back story. I had to increase a disk on the prod server. That went fine. The replication job complained, deleted snapshots and started a remirror. Something failed, network problems or something I'm assuming, and the job failed. the retries also failed. I tried recreating the rep job and it fails with the same message.

I called support and they said there is no hope. I will have to delete the replica and start over. Case number 00254769

This is the error.
7/4/2013 9:20:43 AM :: Discovering replica VM Error: A general system error occurred: The parent virtual disk has been modified since the child was created. Parent virutal disk's content ID does not match with the parent content ID in the child

I have to re seed the job and that will take days leaving me without a usable replica in the DC. The wan link between sites is only 15mbps so it will take days to copy a seed over and well, it's a long weekend and shipping a disk to the DC will be difficult and the DC is a 4 hour drive from me.

Is there any hope in reusing the replica to reseed or is my only option to reseed manually?

Thanks and happy 4th!
John

[veremin]

Hi, John. Have you tried mapping functionality? I mean, create a new job from the scratch and point it to the existing replica VMs (Job Settings -> Seeding -> Map to existing VMs)? Prior to mapping you can also try similarly increase the disk size at DR site in order to both VMs to be completely identical.

More information regarding it can be found in the corresponding User Guide (p.150).

Thanks.

[johnlong]

I did map the new rep job to the replicated vm.

I figured out what happened. Because you told me to increase the disk size on the replica I went in and tried that. When I went in and looked at the disks the attached disks were 0gb in size. I removed the disks and re added the correct disks, which the one that was increased in production was already increased on the replica.

I reran the rep job and it's calculating digest.

The root cause is this, the replication job failed once with this error and the job didn't correct the disks that were attached to the replica.
7/3/2013 8:41:28 AM :: Error: Client error: There is not enough space on the disk.
Failed to write data to the file [R:\SA-Rep\Replicas\vm-15192\2013-07-03T110442.vbk].
Failed to process [saveDiskDigestsCli].

The repository ran out of space. I have since freed up enough space to where this won't happen again.

I guess the question now is why did the replica get messed up in the way it did?

Thanks!

[veremin]

The replication job complained, deleted snapshots and started a remirror

The original behavior is expected. If you try to increase disk size of source VM, during the synchronization stage VB&R will delete previous restore points and start everything from the scratch, since VMware doesn't allow resizing a disk that has a snapshot.

More information regarding it can be found in this topic; kindly take a look.

However, it’s rather difficult to say why replication job failed, especially, without log investigation; most likely it’s something environmental (network issues, etc.).

Thanks.

[johnlong]

Well, the reason the job failed is because the repository filled up and it couldn't write digest or cbt data. The failure caused the replica to be left in a state where it was unusable. Not sure what is going on in the background when replication takes place but the hard disks attached to the replica were 0GB in size which caused subsequent jobs to fail.

It wasn't till you suggested that I increase the disk size on the replica that I discovered that the disks that were attached to the vm were wrong.

I'm guessing that my situation is very rare which is why the Veeam support tech I talked to didn't suggest I check the drives that were attached to the VM. The first and only suggestion was to delete the replica and start over.

[veremin]

Yep, it seems, indeed, to be nothing but a concourse of unfortunate circumstance. Thus, it was rather hard to support team to get the root cause of such a behavior. Thanks.