When a DR policy with Stage 1 and Stage 2 is applied in SWIFT, Stage 1 performs data backup by syncing application volumes to SWIFT storage, and Stage 2 replicates this data to the DR cluster for failover readiness.
Pre-requisite:
2. Source and target cluster should be added in SWIFT
3. At least one storage pool created
DR Policy apply steps for Stage1+2 sync.
1. We first need to apply the Passthrough DR Policy. Go to DR Policies under Business Continuity & DR, click on the created stage-1+2 DR Policy, then click Apply, and select Application Replication.

2. After clicking on ‘Application Replication’, a new window will appear as shown below.





| Fields | Fields Description |
| Policy Name | The Policy name will be displayed for whichever policy you are applying |
| Sync Type | Since you created a Stage1+2 sync mode, it will display the same. |
| Start Time | Here, if you want to sync immediately then you can click on start immediately otherwise you can start the specified time, you just need to 'start later' , You can use this option to start scheduling syncs on or after the given time. If start time is not provided, the syncs will start scheduling immediately as per the DR policy schedule. |
| Platform type | Select the platform where your both cluster is running from source and target |
| Cluster Name | Select the both clusters that is for source and target that you want to sync |
| Namespace | Provide the namespace at source side where you source application running. Also choose the another namespace at target side. |
| Storagepool (Source side) | This is pre-requisite , it should be created before start the sync. |
| Image Groups | We need to provide the image group name it will be created during sync. An Image Group in SWIFT is a collection of volume images captured from an application during the backup or sync process |
| StorageClass (Target Side) | SWIFT will give you choice to choose the storageclass as per your k8s cluster. |
| Application | ALL -> Everything in your IG, all objects will be replicated. Selective --> If you want to do only selected object then you can use this option. Include K8S native objects --> Include native k8s objects' ensures that Kubernetes objects like Services, ConfigMaps, Secrets, and Ingress are migrated along with the application |
| Sync webhook (Source side) | ALL --> If you select this, then all webhook that are present in the source, it will migrated to target. Native Webhook --> Includes cluster-level native Kubernetes webhooks during migration. Dont delete the taints --> By default taints going to be deleted, if you dont want this, then you can select this option |
| Exclude applications for replication | If you want to exclude certain application or objects from source side, then you can do from this option |
| Traipod Options | In the TRAIPDO section, you can choose either Auto-select Port or specify a Custom Port Range (if you have whitelisted ports between 30000–32767). The selected port will be opened in the cloud firewall accordingly. In the TRAIPDO Config section, you will see two options: 1. If you select 'Image and Secret', you will need to provide the image and its corresponding image secret at both sides. 2. If you select 'Image Registry', you can choose an image registry that has already been added to the container registry at the both sides. |
3. Once the Stage-1+2 policy is applied, it will become active and the sync will begin. The sync will run every 5 minutes as per the configured schedule, and you can change the frequency if needed.
4. You can check the sync by navigating to Application Replication under Sync Administration. There, you will see the Sage-1+2 sync started by the applied DR Policy. You can also view the DR Policy name. Refer to the screenshot below for reference.

5.You can also check the Image Groups created during this Stage 1+2 sync. To do this, go to ‘Business Continuity & DR’ > ‘Image Groups’, click on the created image group, and then open the ‘Images’ tab to view the images.

6.You can check the target cluster's namespace — you will see that the same application has been replicated there. The application can now be accessed from the target cluster.

7. Now you can modify the application on the source side, and SWIFT will automatically sync the updated data and applications during the next scheduled sync.
8. You can do Failover and Fallback from stage1+2 DR Policy, there you will get an options .
#Failover

#Fallback : Below Drill-Failed-Over showing because for the testing purpose we selected 'Drill mode' option.

You can follow Failover and Fallback KB