Clean up asynchronous disaster recovery objects in AWS EKS

If you no longer require a disaster recovery object, you can delete it.

Perform the following steps from a location where you have kubectl access to the source cluster:

1. Delete the migration schedule:

   kubectl delete migrationschedules <migrationschedule-name> -n <migrationnamespace>
   note

   Once a MigrationSchedule object is deleted, you should also delete all the associated migration objects that you retrieved in step 2 of the previous section.

2. Delete the associated schedule policy :

   kubectl delete schedulepolicy <your-schedule-policy>

3. Delete the cluster pair from the source cluster and reverse ClusterPair from the destination cluster, if applicable:

   kubectl delete clusterpair <migration-cluster-pair> -n <migrationnamespace>

4. Delete the ClusterPair resources on the destination cluster.

   When you delete the unidirectional or bidirectional ClusterPair on the source cluster, it will not automatically delete the associated secret and backup location on the destination cluster.

   You should manually delete the ClusterPair resources on the destination cluster using the following commands.

   • Delete the associated backup location that is created on the destination cluster. By default, it is created with the same name as your ClusterPair, otherwise update it with your custom backup location name in the following command:

     kubectl delete backuplocation <migration-cluster-pair> -n <migrationnamespace>

   • Delete the secret object created on the destination cluster:

     kubectl delete secret <secret-name> -n <migrationnamespace>

note

• Portworx ensures that the associated backup location is not deleted when deleting a ClusterPair, if it is used by other ClusterPairs.
• If you change the backup location, you must delete all ClusterPairs associated with the backup location and recreate them.