Turbot Disaster Recovery Considerations

These are the disaster recovery considerations for Turbot. Customers should take these recommendations then develop specific procedures for disaster recovery of their Turbot cluster. 

 Data Stores

  • DynamoDB Tables
  • CMDB: Stored in CodeCommit or a BitBucket instance

DynamoDB is the primary datastore for Turbot configuration info. Examples include but are not limited to permission grants, imported account details, and security credentials.

Cloud resource configuration and history is stored in the CMDB. Turbot does not strictly need historical information about a resource for proper operation. If the CMDB is lost, Turbot will rediscover cloud resources over the course of 24 hours or longer (depending on the value of the AWS > Resource Discovery Throttle Rules policy). After resource (re)discovery is complete, Turbot will maintain a history of resource changes in the CMDB.

 CodeCommit repos are regionally based. If the customer requires a full history from the CMDB, then measures should be taken to ensure repo replication from the primary Turbot region to the DR region.

BitBucket repos will need to be backed up and replicated to the DR region. 

Turbot AMI

The Turbot AMI must be shared into the account and AWS region where DR will be setup. Organizations should pre-arrange their DR setups with Turbot to ensure smooth deployments should the worst happen.

DR Process Outline

At the DR site, install Turbot in the usual manner with the CloudFormation template. After installation is complete, restore the DynamoDB tables. If using BitBucket, restore the Git repos. If using CodeCommit, ensure the repos are in the DR region. Verify that the Turbot > CMDB > * policies are properly configured for the new BitBucket server. Restart all Web and Worker instances as well as Elasticache. Monitor the new installation for correct operation.

Was this article helpful?
0 out of 0 found this helpful