Troubleshooting Failback Errors

Error – Could not associate failback client to recovery instances

If you see the "Could not associate failback client to recovery instances" error when using the Failback Client, that may mean that you associated the incorrect credentials with your User. Ensure that you attach the AWSElasticDisasterRecoveryFailbackInstallationPolicy policy to the user or role and restart the failback process. Learn more about Failback Client credentials.

Error – Could not verify recovery instance connectivity to DRS

If you see the "Could not verify recovery instance connectivity to Elastic Disaster Recovery" error when using the Failback Client, you should troubleshoot potential connectivity issues:

1. Make sure that the agent on the recovery instance is activated and running.

2. A public IP must be set on the recovery instance in Amazon EC2.

3. TCP Port 443 outbound must be open on the recovery instance for the pairing to succeed.

4. Make sure that you don't have this error in your agent logs: Error – driver was compiled for a different kernel not loading.

Error message: AWS Replication agent is not connected to DRS. Verify the agent is installed and running, and that it has connectivity to the service

In certain cases, following an attempt to perform a reverse replication action, you will receive an error message indicating that the AWS Replication agent is not connected to AWS Elastic Disaster Recovery. In this case, verify that:

1. The agent is installed and running

2. The server is connected to the internet or the NAT gateway

If after performing the steps above you did not identify any agent or connectivity issues, reinstall the agent as recovery instance and try again.

Error message: botocore.exceptions.CredentialRetrievalError: Error when retrieving credentials from cert

The Failback Client uses Amazon Linux 2 (AL2) and leverages certificate-based authentication to AWS Elastic Disaster Recovery endpoints for certain actions. AL2 assumes that the hardware clock time provided from the underlying hardware or hypervisor is UTC, which can result in time skew if it is not. Ensure that the time configured within the BIOS or EFI Shell of the failback target is set to UTC, and not LocalTime.