replica seeding/job upgrade proceedure confirmation

[cmdrriker]

I have read the user guide, forum posts, and several blog posts regarding the proceedure to upgrade a legacy version
5 replica to version 6, and want to double check that I understand the proceedure correctly.

Could someone please verify that the steps I plan to use are correct.

1. create a new job with the low connection bandwidth checked

2. select the production virtual machine to be replicated

3. specify the same host, resource pool, vm folder and datastore that the existing v5 replica is using as the
"location in the DR site" where the replica should be created

4. a: specify the source proxy as that one closest to where the production vm is located
b: specify the target proxy as the one closest to where the existing replica vm and datastore is located
c: use the same replica suffix as that used on the existing v5 replica
d: use the same number of restore points as the existing v5 replica

5. map the production vm (the one to be replicated) to the existing v5 replica vm

6. After the job has successfully completed, modify the job properties to uncheck the low connection bandwidth/enable
replica seeding setting as this is no longer needed on future runs.

Are the above steps correct?

Also, I did try on several new jobs to use the "detect" feature for the replica mapping, but this does not work. Is
this an indication of a problem?

[Vitaliy S.]

Yes, your procedure looks good to me. Detect works only for VMs that were once created by version 6.0 or later replication job.

[cmdrriker]

Vitaly, thank you for your quick reply, you were faster to respond then support and I needed confirmation quickly, thank you again. I now have a couple of post seed questions.
It seems that none of the previous rollback points from version 5 were preserved when the version 6 seed/replica was created. So it appears if I need to go back to a point in time that preceeded the replica conversions (from version 5 to version 6) that I would be reverting to a version 5 replica, is that correct? Also, there are now two replicas shown in the replica list, one in version 5 format, and one in version 6 format, that now exist for each production virtual machine. So it seems that the post seed process would be, in order to maintain the 14 rollback points we want to have, that we would retain the version 5 format replicas until we have accrued 14 roll back points on the version 6 replicas. At that point, I think we can then safely remove the version 5 replicas from the replica list, but NOT delete them from disk, because those same vmdk files now form the basis of the version 6 replicas. Is that correct?

[Vitaliy S.]

It seems that none of the previous rollback points from version 5 were preserved when the version 6 seed/replica was created. So it appears if I need to go back to a point in time that preceeded the replica conversions (from version 5 to version 6) that I would be reverting to a version 5 replica, is that correct?

Yes, this is expected behavior, since v5 and v6 has different replica format and these formats cannot co-exist in the same job.

Also, there are now two replicas shown in the replica list, one in version 5 format, and one in version 6 format, that now exist for each production virtual machine. So it seems that the post seed process would be, in order to maintain the 14 rollback points we want to have, that we would retain the version 5 format replicas until we have accrued 14 roll back points on the version 6 replicas.

Correct.

At that point, I think we can then safely remove the version 5 replicas from the replica list, but NOT delete them from disk, because those same vmdk files now form the basis of the version 6 replicas. Is that correct?

Yes, that's correct. Here is an existing topic, please look it through if you haven't done it yet: Mapping new v6 job to v5 replica's and v5 incrementals