Undo Pod Exists for Source Pod

Troubleshooting for VMware Solutions

Audience
Public
Source Type
Documentation

Failed to demote source consistency group 'e184134e-5a94-9f76-5c53-ae33e6df93d5'. SRA command 'prepareFailover' failed for consistency group 'e184134e-5a94-9f76-5c53-ae33e6df93d5'. Demoting the pod <pod name> failed. Error message from Purity: Message from Purity='ctx:<pod name>,msg:Cannot demote pod because the associated undo-demote pod has not been eradicated.' Message from Purity='ctx:PATCH,msg:https://flasharray-m20-2.purecloud.c..._quiesce=False'. Please verify that the source pod is setup correctly.

One of the first steps of a recovery operation is to demote the source pod. When a pod gets demoted an "undo" pod gets created to store the state of the pod upon the time of demotion. This undo pod can then be manually eradicated or will be eradicated automatically in time according to the eradication time (defaults to 24 hours). For a given pod, only one undo pod can exist at a time (though this might change in the future). If an undo pod exists for a pod the pod cannot be demoted again until the undo pod is eradicated.

So if the source pod has an undo pod upon an attempted recovery you will see the plan quickly fail:

If this is the case, identify the undo pod and eradicate it:

Now re-run the recovery preferably in planned migration mode (or in disaster recovery mode if that is necessary for some other reason).

If you cannot eradicate it (for instance safe mode is enabled and objects cannot be manually eradicated) you must re-run the recovery plan in disaster recovery mode:

When run in disaster recovery mode and the source cannot be demoted, that step will fail, but the error will be skipped. Causing the source to not be demoted.

Note that this will allow a recovery, but the target side will not be able to be reprotected until the undo pod is gone. As soon as the undo pod is eradicated, run the recovery one last time to complete the process (demotion of the source pod) which will also enable replication to restart from the source (previously the target) pod.

Confirm the recovery:

This will complete that step and any other step that might not have been possible during the initial recovery.