Quickly Disaster-proof your Oracle Cloud Infrastructure Registry (OCIR) Images

May 11, 2022 | 9 minute read
Robert Ronan
Principal Product Manager
Text Size 100%:


This is guest publication from Ruchidnya Kadam at Rackware


RackWare SWIFTTM provides a quick and easy solution to migrate data to and from various image registries. Once your policy is set, SWIFT will take timely backups of your image registry and prevent image data loss. 


You can set up a Disaster proof policy to sync images between Oracle Container Registry (OCIR) and any of the following image registries:

  • Docker Hub
  • Azure Container Registry (ACR)
  • Amazon Container Registry (ECR)
  • Google Container Registry (GCR)

 This blog will cover how to make you OCIR registry disaster proof in a few simple steps.


Step 1:

On your Oracle marketplace RackWare DR subscriptions page, you can get a quick overview of how DR policy would work on a subscription basis.


Rackware Swift Subscription


Configure the compartment and the region in which you want to launch your DR subscription and select on ‘create.’


Create Compute Instance

Step 2:

After this step SWIFT will be installed. Once you have your SWIFT up and running, access the SWIFT server and set password for admin user

sudo swiftcli user modify admin --password <password>

Now you can access the SWIFT dashboard using the URL ‘Error! Hyperlink reference not valid.

Enter the username and password that was set with the above command and click on ‘Login.’


Swift Logon


Step 3:

Under the ‘Image Registries’ tab on the right panel, click on the ‘Add’ option to discover a new registry.


Image Registries

Here provide all the necessary details for your source OCIR registry which you would like to make disaster proof.


Image Registry Add

Note: Data can be synced from one region to another in OCIR, by giving different regions while discovering the registry.


Repeat this step for the target registry as well, to which you would like to sync your images.


Repeat Registry Add


Step 2:

A DR policy can be initiated directly as shown in Step 6 - part 2, but to validate if the replication is working as per expectations, a manual replication is preferred to be executed first. This same replication can later be attached to your DR policy. To replicate your images from your source registry to your target, you can find the ‘All Replications’ tag under the ‘Sync Administration’. To start our new replication, click on the ‘New’ button and select ‘Registry Replication’.


All Replications


Step 3:

Choose the appropriate options as required for your migration depending on whether you want to sync all repositories or selective repositories.

Repository mapping in case of OCIR:

In case your target registry is an OCIR registry and the repository name you wish to replicate from the source is present in any compartment of the target registry, the repository cannot be created for the need to have unique repository names across compartments. Hence in this case to avoid failure of sync, you may rename this repository using the repository mapping options provided.

Another case where repository mapping is mandatory would be if you wish to replicate images in the same OCIR registry. Intra-registry replication is one where the source and target registry names are the same, hence providing an alternative name for each source repository to be synced is necessary.

Repository mapping in case of docker hub as the target:

Docker doesn’t allow backslash in its repository name. Hence if your source repository from OCIR contains ‘/’ in its name, one of two things will happen:

  1. Provide an alternative name using repository mapping
  2. If not provided SWIFT will auto convert the backslash to an underscore in the source repository name

For Example: ‘demo/repo1’ -> ‘demo_repo1’


Source Image Registry


Step 4:

Now to make your registry disaster proof you will need to first create a DR policy by selecting ‘DR Policies’ under ‘Business Continuity & DR’ and create a ‘New’ DR Policy.


Swift Administration


Step 5:

Configure the parameters of the DR policy with a ‘passthrough’ sync type and the time intervals at which you would like to take your back up for your registry and then click on ‘CREATE’.

The various scheduling options that you can apply to your DR policy are as follows:

  1. By schedule – Either daily or weekly at some specific time of day. Along with this, you can exclude days that you don’t want replications to run on.
  2. By frequency – This option allows to run replications continuously at a specific frequency of some minutes/hours. Along with this, you can exclude time slots in which you don’t want replications to run on.
  3. Once – This option gives the user the liberty to run a replication only once on a decided date and time.
  4. Continuous – This option indicates that there will be replications that will run continuously after the former is completed.


DR Policy


Step 6:

The last step would be to apply your replication to your DR policy. Once you select the DR policy click on the ‘Apply’ button and select ‘Registry Replication’.


Registry Replication


There are 3 ways to apply a DR policy:

  1. Select ‘Existing replications’ and select the registry replication performed by steps 2 & 3.


Apply DR Policy

  1. After steps 2 & 3, you can go to the ‘All replications’ page, and click on the “Apply” next to your replication.


All Replications

Next, select your DR policy and choose to either start it immediately or later at some specific time.


Apply DR Policy

  1. You can skip steps 2 & 3 and select ‘New Replication’ to directly configure the replication performed in step 3.


With these steps your Oracle Container Registry will be periodically backed up at your destination registry and make it disaster proof.


Oracle target registry before replication:

Containers and Artifacts



Oracle target registry after replication:

Containers and Artifacts


Failover and Fallback:

SWIFT also offers two more features, failover and fallback, to help secure your registry images in case of a disaster. You can access them with these arrows:


DR Policy1

  1. Failover: When a DR event occurs and the source site is down, the DR side needs to come in to picture. In such a case, you may execute the ‘failover command’ to make the DR side operational. After a failover operation is performed, the state of the DR policy will be changed to ‘FailedOver’ and the subsequent scheduling of syncs will be paused.

You may choose which operations you want to apply the failover to – all or only some.

The Drill Mode is only to check if the failover operation would work correctly in the event of a mishap. It will not actually sync any images over to the destination registry.


Failover DR-Policy1

  1. Fallback: In a case when the source registry is down and the user wants to bring it back, a  fallback operation can be performed. All the options of a fallback are similar to those of the failover operation.

Note: A Fallback operation can only be performed after a failover operation.

FallBack DR-Policy1



RackWare SWIFT provides a quick and easy solution to migrate data to and from various image registries. You can now add anothler layer of resiliency and Disaster-Proof your Oracle Container Registry (OCIR). 

Here are some of the handy links you can leverage to explore the Rackware and Oracle partnership activities further:

Robert Ronan

Principal Product Manager

Previous Post

Easily Lift-and-Shift all your container registries to Oracle Container Infrastructure Registry (OCIR)

Robert Ronan | 5 min read

Next Post

Success With Containers in a Multi-Architecture World

Tim Clegg | 6 min read