About volume replication

This page provides details for how to protect your data using volume replication.

About volume replication

You can protect your data through cross-location volume replication, which asynchronously replicates a source volume in one location to a destination volume in a different location. This capability lets you use the replicated volume for critical application activity in case of a location-wide outage or disaster. The replicated volume can also be used as a read-only copy during normal usage.

Volume replication moves only used data blocks during the initial transfer, and only changed blocks transfer during incremental transfers. Only the bytes that transfer incur charges, which optimizes transfer times and lowers costs.

Volume replication workflow

During volume replication, a process called initial transfer replicates all source volume content to the destination volume. The initial transfer process takes a snapshot on the source system and transfers its contents to the destination volume. After the initial transfer completes, the replication mirror status changes to Mirrored. As a result, the destination volume becomes read-only and reflects the contents of the source volume's snapshots, which includes all snapshots taken before the initial snapshot.

After the initial transfer process completes, the scheduled replication interval proceeds in the form of incremental updates in the following sequence:

  1. The process creates a new snapshot on the source volume.

  2. It calculates the data changed between the new and the previous snapshots.

  3. The process transfers these changes to the destination volume. The transfer status in the replication resource changes to Transferring.

    After all the changes are transferred, the destination volume's contents transition from the old snapshot to the new snapshot.

Setting modifications

As long as a replication is in a mirrored state, any modifications made to the source or destination volume settings will replicate to the partner. If the service level of the source volume is changed by moving it to a different pool, the destination volume is not changed.

If replication stops, source and destination volume settings and new data no longer mirror changes made to either volume.

  • Replicated data: Volume replication mirrors all user data and snapshots of source volumes to destination volumes.

  • Automated capacity adjustments: Volume replication automatically adjusts the capacity of the destination volume to the capacity of the source volume while the replication relationship exists.

Considerations for volume replication

Before you can perform a volume replication, consider the following:

  • Location-based support: NetApp Volumes only supports volume replication between the following specific location pairs:

    • asia-southeast1 and australia-southeast1

    • europe-west2 and europe-west3

    • europe-west2 and europe-west4

    • europe-west2 and europe-west6

    • europe-west3 and europe-west4

    • europe-southwest1 and europe-west3

    • northamerica-northeast1 and northamerica-northeast2

    • northamerica-northeast1 and us-central1

    • australia-southeast1 and asia-southeast1

    • us-central1 and us-east4

    • us-central1 and us-west2

    • us-central1 and us-west3

    • us-central1 and us-west4

    • us-east4 and us-west2

    • us-east4 and us-west4

    • us-west2 and us-west4

    • us-west3 and us-west4

Where Standard is in Preview, NetApp Volumes supports volume replication between the following specific location pairs:

  • europe-west1 and europe-north1
  • us-west1 and us-east1

  • asia-south1 and asia-south2

  • Quota assignment: You must have a quota set for the number of replicated source and destination volumes. To request a quota increase, use the Google Cloud console NetApp Volumes Quotas page.

  • Topological support: Volume replication doesn't support cascading and fan in and out topologies. For example, a volume can't be both a source and destination volume.

  • Source and destination volume location: Both the source volume and the destination volume must exist in the same project. However, they can exist on different VPCs.

  • Service level-based support: Source and destination volumes can have either Premium and Extreme service levels or the Standard service level.

Volume replication pricing

NetApp Volumes charges for replication separately from volume capacity. Charges are based on the number of bytes transferred between primary and secondary volumes. For more information, see NetApp Volumes pricing.

Recovery point objective (RPO)

Since volume replication is a scheduled, asynchronous replication, the content of the destination volume always lags behind the source volume. The recovery point objective (RPO) specifies how current the data is on your destination volume and which point in time version of your data is stored. In case of a disaster, RPO helps you find out the amount of data you lost.

You can determine the RPO of volume replication by either checking lag times or replication snapshots. Though lag time provides a quick way to estimate RPO, replication snapshots are a more accurate measure.

  • Lag time: The elapsed time since the creation of the snapshot on the source volume that was last replicated to the destination volume. Lag time represents the difference in age of the destination volume data in relation to the source volume data. It updates every five minutes and provides an overview of the RPO. If your replication is skipping replication intervals, a warning warning icon displays next to the lag time in Google Cloud console. If it continues to occur, your data change rate on the source volume is too high to transfer within a replication interval. We recommend that you choose a longer replication interval or ignore the warning for one-off situations like heavy data modification activity on the source.

  • Replication snapshots: Replication snapshots are captures of data exactly as the data appears at a specific moment in time. Replication snapshots provide the most accurate look at RPO. Volume replication uses two rolling snapshots for replication. The timestamp of the latest replication snapshot on the destination volume specifies the point-in-time (UTC) of the latest data on destination volume.

    You can derive the timestamp (replication-<timestamp>) from the replication snapshot name, which follows the UTC format (YYYY-MM-DD-HHMMSS).

Requirements for storage pools

The storage pools with source and destination volumes must meet the following requirements:

  • Must be a part of a valid location pair

  • Must have the same Active Directory policy configuration

  • Must point to the same Active Directory

  • Must have the same LDAP settings

Replication schedule

The replication schedule attempts to run the replication at designated intervals. If a previous replication is in progress, the replication for the current cycle skips and checks again at the next interval. This behavior is most common during the initial replication, which transfers the initial volume blocks and takes the longest time to replication. The replication schedule runs based on the following times for each schedule type:

Replication schedule frequency Time of scheduled operation
Every 10 minutes :00, :10, :20, :30, :40, :50
Hourly :05 after the top of each hour
Daily :10 after midnight each day

What's next

Create a volume replication.