Oracle Cloud Infrastructure Documentation

Disaster Recovery

Learn about using File Storage replication for disaster recovery.

Important

When making your disaster recovery plans, ensure that you will have enough available resources to create the clones, file systems, and mount targets necessary for unplanned failovers. Common disaster recovery scenarios require creation of at least one additional file system for each unavailable source file system. At least one mount target is required to provide access to file systems created during failovers. Refer to File Storage Limits for more information.

The following table shows the basic steps of recovery using File Storage replication:

Step Primary Availability Domain Condition Action
1 Failed Failover to target file system
2 Restored Prepare to failback to source: Use reverse replication to sync data in source
3 Restored Re-establish replication from source to target
Important

Disaster recovery requires that you use clones of the source and target file systems. When creating file systems, you must remain below File Storage service limits. Clones are required because you can't use a file system that has been exported as a target file system. Cloning the file system creates a copy of the file system with no history of being exported.

  • Creating a clone is instantaneous and you can immediately access the clone for both READ and WRITE operations. However, there is a minor performance impact on both the parent and clone when accessing shared data while hydration is in progress.
  • You can't delete a clone's parent file system. See Cloning File Systems for more information.

1. Failover to Target

If the region containing the source file system (File System A) is inaccessible, clone the last applied replication snapshot on the target file system (File System B) to a new file system (File System C):

  1. Open the navigation menu and click Storage. Under File Storage, click File Systems.

  2. In the List Scope section, select a compartment.

  3. To view information about a file system, find the file system, click the Actions menu (Actions Menu), and then click View File System Details.

  4. Click the Replication Target name link. The Replication Target Details page is displayed.

  5. Click the Last Snapshot name link. The Snapshot Details page is displayed.
    Important

    Note the Provenance OCID of the last applied snapshot at this time. This identifies the snapshot on the source file system needed when you failback to the source. For more information, see Identifying Snapshots.
  6. Click Clone to use the snapshot to create a new file system (File System C). See Cloning a File System for more information.
  7. Delete the replication target resource from the target file system Details page (File System B).
    Caution

    Deleting the replication target resource stops the replication process, but any in-progress replications might finish after the source is restored. If you don’t delete the replication target, replication will resume when the source file system is restored, which can delete the snapshot needed in a planned failback to the source.
    Tip

    If you're testing: The source availability domain is still available, so you can just delete the replication resource from the source file system. Deleting the replication resource automatically deletes the replication target resource.
  8. Create an export in the new file system (File System C).
  9. Mount the new file system (File System C).

2. Prepare to Failback to Source

When the primary region is restored, prepare to failback to the source. Depending on your requirements, you may failback to a new, empty file system, or failback to a clone of the source file system. Use reverse replication to sync the data and bring it up to date.

Note

Failback to a new file system requires a full base copy. You can use the replication estimator to determine if this scenario would be fast enough during disaster recovery.
  1. Delete the FAILED replication resource in File System A.
    Tip

    If you're testing: You already deleted the replication resource from the source file system, so you can skip this step.
    Note

    When the replication is deleted, the replication snapshot is converted to a user snapshot.
  2. Identify the snapshot common to the source file system (File System A) and the file system that you created when you failed over to the target (File System C). The snapshot you use should be in both the source and clone of the target.
    • On the source file system (File System A), you can use the Provenance OCID you made note of earlier to identify this snapshot.
      Caution

      The Last Snapshot could identify a snapshot that completed after the initial failover to target, not the snapshot used to create File System C.
    • On File System C, you can find the last snapshot with a name like replication-snapshot-<replication_number>-<creation_time_UTC> but a type of User. When you cloned the replication snapshot to create the file system, the snapshot type changed from Replication to User.
    1. If you're using a clone of the original source file system for failback, on the source file system (File System A), clone the snapshot identified in the previous step to create a new file system (File System D).
    2. If you're using a new, empty file system and a full base copy for failback, you can create a new file system (File System D) without cloning.
    1. If you're using a clone of the original source file system for failback, create a new replication where the clone of the original target file system (File System C) becomes the new source, and File System D becomes the new target. Wait for the replication cycle to complete and bring the File System D up to date with File System C. You can verify that the file systems are in sync by creating a snapshot on File System C and waiting for it to appear on File System D.
    2. If you're using a new, empty file system for failback, create a replication using File System C as the source and your new, empty file system (File System D) as the target. Wait for the replication cycle to complete and bring the File System D up to date with File System C. You can verify that the file systems are in sync by creating a snapshot on File System C and waiting for it to appear on File System D.

3. Re-Establish Replication from Source to Target

Re-establish your original replication configuration. Migrate applications from File System C to File System D and stop writing to File System C. Then, create a replication from your source (File System D) to a new target clone (File System E).

  1. Unmount the clone of the original target (File System C).
  2. Delete the replication resource from File System C.
  3. Create an export for File System D.
  4. Mount File System D so that applications can access it.
  5. Clone the last completely applied replication snapshot on File System D to create a new target file system (File System E). To determine the last completely applied snapshot, compare the name and timestamp of last replication snapshot listed in the source with the name and timestamp of the last replication snapshot in the target. The snapshot you use should be in both the source and target.
  6. Create a new replication where the File System D is the source file system and File System E is the target file system.