Best Practices and Known Issues for Block-Level Replication

Updated

Best practices and known issues for block-level replication are as follows:

  • The block-level replication source cache is created in the Job Results directory. For optimal replication performance with a high I/O rate, move the Job Results directory to a different SSD on the source server.

  • To avoid replication lag, use a dedicated network link with good bandwidth between the source server and the destination server.

  • For optimal replication and permanent boot performance, configure granular replication and recovery point store on a separate disk and a destination server. Configuring the recovery point store on an SSD disk will improve performance.

  • For optimal granular replication performance, set the minimal ACRP interval to 1 hour.

  • Creation of frequent recovery points such as specifying a recovery point interval in seconds with larger recovery point retentions (such as days or weeks) might degrade recovery point store performance.

  • Pseudo-off-peak time might degrade recovery point store performance.

  • Align recovery point intervals, retention, and off-peak time so that the recovery point store can merge and produce more coarse recovery points with time.

  • Over-provisioning the recovery point store space might lead to performance degradation and failure during the merge operation.

  • Merging recovery points requires space. Provision adequate space.

  • If you run a resync operation manually, then all existing recovery points become invalid.

  • To optimally use the memory on the destination server, granular fan-in configuration using the same destination server must be shared with the local recovery point store.

  • During an active replication operation, the destination volume explorer view is not refreshed with the current data. To see the refreshed view of the destination volume, suspend the replication operation, or you can create a replica copy without suspending the replication operation.