Atlassian provides a standard architecture for deploying its tools on AWS (Amazon Web Services). If we look at the architecture of JIRA, for example, it may look something like the one depicted in the diagram for JIRA Data Center:
We need to have a robust backup and recovery plan before considering the setup production-ready. For the backup, we need to identify the components with persistent data and configure the backups based on the organization’s RTO and RPO policies. We need to ensure the data for the database hosted in Amazon RDS and shared filesystem data in Amazon EFS is backed up. We don’t need to worry about the rest of the infrastructure since we should be spinning it up based on the IaC(Infrastructure as Code) approach of using the official Cloudformation templates. Any changes to the Cloudformation templates should be version-controlled, and ideally, production changes should be deployed automatically by your CI/CD tool.
RDS has a built-in backup option where by default, it takes a snapshot once every 24 hours, but you can enable more frequent backups. As for EFS, you need to set up an AWS Backup service to perform regular backups based on a pre-defined schedule. However, it is best to use AWS Backup to centralize and automate the backups for both RDS and EFS with a typical backup schedule. When using AWS Backup to set up your file system backups manually, you first create a backup plan. The backup plan defines the backup schedule, backup window, retention policy, lifecycle policy, and tags.
As part of a backup plan, you can define the following:
Schedule – When the backup occurs
Backup window – The window of time during which the backup must start
Lifecycle – When to move a recovery point to cold storage and when to delete it
Backup vault – Which vault is used to organize recovery points created by the Backup rule
Ideally, we should not enable the backups manually; instead, we should update the Cloudformation templates to extend the idea of infrastructure as code. By default, AWS backups are restricted to a single region. However, you can automatically copy backups to multiple AWS Regions as part of a scheduled backup plan. This article from AWS goes over setting up cross-region backups. Backups are only useful if you can perform restores while meeting your RPO and RTO requirements. We strongly suggest testing the restore process to ensure the backups are set up correctly. In the follow-up blog post, we will go over the backup restore details and how we automated the process.
Addteq has created a point-and-click user interface for spinning up production/test/sandbox instances and automatically configuring backup (option for multi-region) and recovery called Codefactori Enterprise. Also, the option to restore the instance with a single click in any region! Alternatively, we offer fully managed hosting as part of the Codefactori SaaS platform.
