About file share replication

Replication overview

After you created a file share, you can set up replication.

When a replica share is created, the first replica contains the data of the entire share. Thereafter, only the changes that occurred after the previous replication are added.

You can create a replica share in another zone of the same region. You can also create a replica in another region in the same geography, if you have another VPC in the target region. Cross-geography replication is not supported.

When you create your replica file share in another zone of the same region, the replica share inherits the encryption type and key from the source file share. The encryption can't be changed.

When you replicate your file share to another region, the replica must match the type of encryption that the source share has. However, it does not inherit the encryption from the source. In other words, if the source share is encrypted with provider-managed keys, the replica must have provider-managed encryption, too. If the source share is encrypted with a customer-managed key, the replica must be encrypted with a customer-managed key as well. However, it does not have to be the same key. When you create the replica, provide the CRN of the key that you want to use.

Based on the replication schedule, the service pulls data from the source file share to the replica file share. You can choose how often you want to sync changes from the source share to the replica. You can specify an hourly, daily, weekly, or monthly replication schedule. Replications must be scheduled at least 1 hour apart.

When you replicate across regions, the data is crossing VPC boundaries. Both VPCs and file shares must belong to the same account, and you need to establish service-to-service authorizations between the file services of the two regions. The data is encrypted in transit while it's moving between file shares. Charges for data transfer between the two file shares are calculated with a flat rate in GB increments. The charges are based on the amount of data that was transferred during the entire billing period.

When you replicate data across regions, consider the local data residency laws because moving data across borders can have legal implications.

Replication is an asynchronous operation and it's not instantaneous. You can use the replication sync information to see the duration of the replication process and the transfer rate. By reviewing the replication sync information, you can adjust your replication schedule, and balance your costs with how often you need the data to be refreshed on the replica. By viewing the job logs and the transfer rates, you can also determine whether the size of the data that needs to be transferred fits within the replication window.

Data on the replica share is read-only. You can obtain read/write access to the data in two ways:

• Fail over to the replication site - The read/writes from the source file share are paused and a final copy of the file share data is pulled into the replica share. The replica share becomes read/write accessible, and a reverse replication relationship is established. The original source file share now becomes the replica share and set to read-only. The service then begins pulling data from the new source file share.

  If a source file share is compromised, replica shares are a good way to recover operations. A failover to a replica share ensures no disruption to your services.

  When you initiate the failover, you can specify what happens to the replication relationship if the failover process times out or fails. This option is commonly used when you have a time requirement for how long your file share can be offline. You must specify what you want to happen if the operation times out or if the replication fails due to the original site, which is degraded or unavailable.

  • If the source site is not available due to a planned maintenance, you can choose to keep the replication relationship. The replication resumes as scheduled when the original source site is operational again.
  • In a disaster recovery situation, you can choose to split the volumes to bring the replica share online as soon as possible. However, in this case, you might not have the latest data set available and you might need to manually reconcile the state in your application. Because the replication relationship is severed, you need to set up replication anew when the original site becomes operational again.

• Remove the replication relationship - In this case, you split the two shares apart and create two independent file shares. Both shares are read/write accessible and data is no longer synchronized between the two. In the API, this operation is called a replica split operation. Removing the replica relationship is permanent, you cannot reestablish it between the two shares. However, you can create new replicas in the same zone or other zones of the same region.

Removing the replication relationship or failing over to the replica does not occur when another operation is being performed on the source or replica file share. (An example of such an operation is expanding the file share size.) The split or failover operation remains pending until the other operation completes.

Use cases

You can use replication to address disaster recovery concerns. The replication addresses these scenarios:

• Disaster Recovery from an application failure.

  In this scenario, the application that you are running fails. The data is unaffected, but the application is not operational. You can perform a failover, where the data is quiesced and sent to another zone. The virtual server instances in that zone can be configured to take over the operation of the application while the primary servers are repaired.

• Disaster Recovery due to IBM Cloud infrastructure failure.

  In this scenario, the IBM Cloud availability zone in which your application is running becomes unusable. You need to start your application in the replica location as quickly as possible and use the replicated data from the last replication event. You can initiate the Failover with the split option to make the replica volume independent. Replication is stopped.

• Facilitate regular maintenance of your applications.

  Use replication to facilitate certain administrative tasks such as upgrades with greater availability. Migrate data between two zones that might be running different levels of application code. Running in two environments independently can allow greater flexibility in your deployment process.

• Data migration or geographic expansion.

  You can use replication to migrate data between two MZR regions easily. After your data is replicated, you can remove the replication relationship and your replica file share becomes available with your data ready to use independently in the new region.

Next steps

1. Create a replica file share in the UI, from the CLI, with the API or Terraform. If you want to set up replication between different regions, you need to establish service-to-service authorizations between the file services of the two VPCs first.

   If you want to create a replica share in a different region where you use a different KMS solution, establish service-to-service authorizations between the file service and the target KMS.

2. Verify that the replication is working by checking the replication status and the replication sync information. The system queries the last sync status every 15 minutes.

3. Use the replica file share - If the primary file share fails or becomes unavailable for any reason, you can fail over to the replica file share. When you perform the failover, the replica share becomes the new primary file share, with read and write capability.

4. Restart the replication with the original file share as scheduled when it's back online. In this case, you can continue to use the replica site as primary, or fail back to the original site.