Replication policies

A replication policy defines how replication is configured between systems.

The topology of a replication policy specifies the type of replication to be used. The following topologies are available:

High availability

  • This type of replication policy is used with storage partitions.
  • The policy specifies the systems that are used for high availability.

    The locations of the systems in the policy define the layout of the systems seen in the management GUI. The system in location 1 is shown on the left, and the system in location 2 is shown on the right. This layout remains fixed and is not affected by the direction of replication between systems, simplifying monitoring and management from either of the systems.

  • This type of policy can be used for 2-site high availability and 3-site (high availability with disaster recovery) configurations.
  • This type of replication policy will be configured with highly available snapshots enabled by default if both systems support this feature. For details, see Highly available snapshots.
  • You can start from the Storage partitions panel in the GUI to add or remove high availability for a partition.

Disaster recovery policies

Disaster recovery policies can be categorized into two types: synchronous and asynchronous. Synchronous or asynchronous disaster recovery can be used with volume groups that are in a storage partition. The storage partitions are linked to define the systems that are used for disaster recovery replication. It can be used for 2-site disaster recovery or 3-site (high availability with asynchronous disaster recovery) configurations. You can use the Volume groups panel in a storage partition to add or remove replication for a volume group. You can also switch between synchronous and asynchronous policies.

Synchronous disaster recovery policies
Synchronous disaster recovery policy provides a high-performance solution for protecting data across sites. In synchronous replication, data is written to both the primary and secondary sites at the same time, ensuring consistency between locations. The storage partitions are linked to define the systems that are used for disaster recovery replication. Synchronous replication is not supported over TCP/IP connections.
Asynchronous disaster recovery policies

Asynchronous replication helps protect data across sites without requiring high-bandwidth connectivity. Unlike synchronous replication, data writes occur first at the primary site and then replicate to the secondary site with a slight delay. This design reduces network load while still meeting your Recovery Point Objective (RPO).

2-site asynchronous disaster recovery

  • This type of replication policy is used with volume groups that are not in a storage partition.
  • This type of policy is suitable for environments that cannot use storage partitions for disaster recovery. For example, replication for hosts that are not currently supported in a partition. For more information, see Storage partitions.
  • The policy specifies the systems and the I/O groups in those systems that are used for replication.
    • The locations of the systems in the policy define the layout of the systems seen in the management GUI. The system in location 1 is shown on the left, and the system in location 2 is shown on the right. This layout remains fixed and is not affected by the direction of replication between systems, simplifying monitoring and management from either of the systems.
  • This type of policy can be used for 2-site replication only.
  • You can use the Policies tab of the Volumes > Volume groups panel in the management GUI to add or remove this type of replication for a volume group.
  • The volumes in the recovery volume group are offline and inaccessible if using a replication policy with a 2-site-async-dr topology.

Both types of replication policies for asynchronous replication define a maximum acceptable recovery point for the recovery copy. An alert is generated if the recovery point exceeds this value.

Replication policies cannot be changed after they are created. However, a new policy can be used to replace the existing one if changes are required.