Off-site seeding replication is taking a long time

[Oskr]

Hello
Can someone help me with a problem I'm having an off-site replication about three mv together weighing 2.6 TB, which was performed as follows:
1) Create a backup of virtual machines source site to be replicated
2) Costume those backups to DR site
3) Create a new repository backups on the DR site
4)) In the new repository amount backups of virtual machines source site
5) Create a replication task with the following settings
• Select the site 3 mv source I want to replicate the weight is 2.6 mv tb
• I select the destination
• The metadata repository where the new repository chosen amount backups
• In the data transfer select the proxy corresponding to each site manually not automatic
• Select communication for accelerator wan one in every room
• Now the important step that selections for initial seeding to take backups of the new repository that has backups of virtual machines source site
• And that execution on demand
As I understand it would be correct to reduce the time of the replica as we used the initial backup to only take incremental ie data that has changed the site origin, but takes a long time in 4 hours just to echo 10 % of all the replica of the 3 mv which together weigh 2.6 TB
This time something is right or wrong settings ?, please anyone could help me with this as I go two weeks trying to replicate but still slow.
Or it is perhaps best restore the datastore mv DR site and then use the option of mapping replication.
Thank you.
Backs have two proxies one in the origin site and another site in the DR will also have the role of acceleration wan
The proxy origin is virtual site and DR site proxy is physical in which volumes are presented directly from the SAN storage that was repository for backups

[foggy]

• The metadata repository where the new repository chosen amount backups

Repository for metadata should be located on the source side, close to the source storage, as mentioned in the job wizard. This allows to avoid data flowing back and forth over the slow link.

As I understand it would be correct to reduce the time of the replica as we used the initial backup to only take incremental ie data that has changed the site origin, but takes a long time in 4 hours just to echo 10 % of all the replica of the 3 mv which together weigh 2.6 TB

Initial job run after seeding requires digests calculation to be performed to define changes that should be sent over to target. This operation might take considerable time, however subsequent runs will be faster. Also, during the first job run with WAN acceleration enabled WAN cache is being populated, which also requires time.

I suggest first to change the metadata repository to the one on source and see how it goes. If letting the job to perform this initial run still not an option due to the time it requires, you can disable WAN acceleration for this first run and try direct mode first or pre-populate the WAN cache.

[Oskr]

Thank you for the suggestion

I have a question, the repository for metadata how much space is recommended? and this repository for metadata is not the same as the repository for backups assigned ie a new data repository that nothing is to be used only for metadata.

Because the repository for backups created on the site of origin was an external disk allowing disk to bring the DR site and import the backup for the seeding replica.

The right steps to create the mirror task would be:

1) Job name
2) Describe the DR site: low Connection
3) Select the source site MV
4) Select the Host, the resource pool and datastore for replica lift the DR site
5) Select a repository for metadata that is in the source site (not the repository backups of VMs) (on the optimization of storage choose WAN, LAN or local? Replication is to be performed off-site)
6) Data transfer proxies choose this at each site, as for accelerators wan
7) I choose the repository where the backups of the source site mv imported.
enabled the Guest Processing and finally when to run the task.

These would be advisable for the replication job?

[foggy]

I have a question, the repository for metadata how much space is recommended? and this repository for metadata is not the same as the repository for backups assigned ie a new data repository that nothing is to be used only for metadata.

It can be any existing repository that holds some backup files, no need to create a separate one. As for the space required, typical metadata size can be calculated as 128MB for each 1TB of source VM data (per each replica restore point).

5) Select a repository for metadata that is in the source site (not the repository backups of VMs) (on the optimization of storage choose WAN, LAN or local? Replication is to be performed off-site)

For off-site replication, 'WAN target' should be selected.