About Failback with Arpio
Failback is currently available for EC2, RDS, Aurora, and DynamoDB resource types only. If you are looking for more detailed documentation on performing a failback, please view our performing a failback documentation.
Where failback fits in your Disaster Recovery plan
A disaster recovery plan is not just about responding immediately to malicious attacks, or unexpected events, although Arpio can also help you with that. A complete Disaster Recovery plan allows you to return your business to normal as quickly and safely as possible. Failback restores your primary environment applications to an operational state.
An example failback process
When you are ready to return to your primary environment:
- Ensure that your primary environment is ready to take production traffic. This may involve manual steps, like validating that malicious actions have been undone, or verifying that AWS services and resources are operating as designed .
- Perform a test failback, by following our guide to Performing a Failback.
- Arpio will ask you to set up some extra access to the primary environment via the installation of a new CloudFormation stack.
- Once Arpio has completed the failback process, you should test that your application works correctly, and that the primary environment has been restored with up-to-date data from the recovery environment.
- Schedule a time to perform a real failback. We suggest scheduling a maintenance window to perform a failback, during which no production traffic is served by your applications, to minimize the chance of data loss.
- Perform the failback, by:
- Following the steps to perform a failback, just like in step 2.
- Flip DNS, or make any other changes required to serve production traffic from your primary environment.
- Test that your application is working correctly in the primary environment.
- Begin the “Conclude Recovery” process to reset the recovery environment back to its original “pilot light” state.
- (optional) To improve the security posture of your Arpio usage, you can delete the CloudFormation stack that was added as part of step 2.
- At this point your application should be running just like it was before the incident, and recovery points should be getting created again.
- (optional) Perform a “Test Recovery” to gain extra confidence that you’re protected, should some other incident occur.