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:
The process creates a new snapshot on the source volume.
It calculates the data changed between the new and the previous snapshots.
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:
NetApp Volumes only supports volume replication between the following specific location pairs:
For Standard, Premium, and Extreme service levels:
asia-southeast1
andaustralia-southeast1
europe-west2
andeurope-west3
europe-west2
andeurope-west4
europe-west3
andeurope-west4
europe-west3
andeurope-west6
europe-southwest1
andeurope-west3
northamerica-northeast1
andnorthamerica-northeast2
northamerica-northeast1
andus-central1
australia-southeast1
andasia-southeast1
us-central1
andus-east4
us-central1
andus-west2
us-central1
andus-west3
us-central1
andus-west4
us-east4
andus-west2
us-east4
andus-west4
us-west2
andus-west4
us-west3
andus-west4
For Flex service level:
asia-east1
andasia-east2
asia-northeast2
andasia-northeast3
asia-south1
andasia-south2
asia-southeast1
andaustralia-southeast1
australia-southeast1
andaustralia-southeast2
australia-southeast2
andasia-east2
europe-southwest1
andeurope-west3
europe-west1
andeurope-central2
europe-west1
andeurope-north1
europe-west1
andeurope-west8
europe-west1
andeurope-west9
europe-west3
andeurope-west1
europe-west3
andeurope-west4
europe-west8
andeurope-west12
europe-west10
andeurope-west9
europe-west12
andeurope-west1
me-central1
andme-central2
me-west1
andeurope-west1
northamerica-northeast1
andnorthamerica-northeast2
southamerica-west1
andsouthamerica-east1
us-central1
andus-west1
us-east4
andus-central1
us-east5
andus-east1
us-east5
andus-south1
us-south1
andus-east1
us-west1
andus-east1
Quota assignment: Depending on your project replication requirements, you might need to increase the quota for the number of replicated source and destination volumes for a specific region or service level. 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 must have the same service level, except for volumes on Premium and Extreme service levels, which can be mixed in a replication.
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 |