Changed replica's disk while it was off

[larry]

I did a DR test today by mounting a replica’s disk to a live VMware server. When the tests are done and I remove the disks from the server used in testing will the replica job work? The disks will have changed on the replica’s VM while it was off, I do not need to save the changes.

We did it this way because both the live server and the replica needed to be one the live network with AD running and sharing. It was quick and the shares were live in less than 10 minutes with all the rights. The replica VM only held file shares.

[Vitaliy S.]

Hi Larry,

When the tests are done and I remove the disks from the server used in testing will the replica job work? The disks will have changed on the replica’s VM while it was off, I do not need to save the changes.

I don't think this action can break your replication jobs (though I'm not 100% sure), assuming that the target VM hasn't been re-registered or modified. All changes that have been made to the virtual disk should be overwritten by a subsequent replication job run.

Thanks!

[larry]

thanks for the quick info. Never used Veeam this way before so I thougt I should check.

[Gostev]

The disks will have changed on the replica’s VM while it was off, I do not need to save the changes.

This is the most important part, but what you say is very vague.

Assuming the disks contents did change, I actually disagree with Vitaly here, and believe that this way of testing completely ruins the replica. The only way to test the replica without screwing it up is to power on the required restore point in-place, as explained in FAQ topic. Modifying the contents of virtual disk files in any other way has to screw up all dependent restore points (snapshots) for obvious reasons - unless you somehow mounted the virtual disks to the live server as read-only volumes, or reverted all the changes once the testing was done.

Sure, the replica job may still work, but recoveries will be failing as soon as any OS or application hits inconsistent disk area.

If you absolutely must use this way of replica testing, I recommend that you make a copy of the required VMDK files, and attach the copied virtual disks to the live server instead.

[Vitaliy S.]

Yes, this is not the proper way of testing VM replica.

Assuming the disks contents did change, I actually disagree with Vitaly here, and believe that this way of testing completely ruins the replica..

Hmm...I see your point and I agree, as there might be issues with existing snapshots (restore points) that rely on the unmodified virtual disk.

[larry]

I did get an error

Code: Select all

Preparing replica VM Error: A general system error occurred: The parent virtual disk has been modified since the child was created. The content ID of the parent virtual disk does not match the corresponding parent content ID in the child

Error: A general system error occurred: The parent virtual disk has been modified since the child was created. The content ID of the parent virtual disk does not match the corresponding parent content ID in the child 

I just cloned the job and switched to new job. This was still ok for me as this was a real quick way for me to have the same shares on two servers live at the same time. This is not how we normaly would do it but in this case I could restore the server because the live server was up at the same time.

If I had more time I would of cloned the replicated VM and mounted the disk from clones but I only had 15 minutes as my restore time. If it was a real issue the live server would not of been there then I would of just booted the replica. Most other tests are done on our DR network so I don't care if the other server is live.

The server had 300 gig of data and I didn't have the time to restore and have it running in 15 minutes.

[Gostev]

That's what I thought. Thanks for confirming.