<img height="1" width="1" style="display:none;" alt="" src="https://px.ads.linkedin.com/collect/?pid=299788&amp;fmt=gif">
Skip to content


Hopefully, after my last blog post, you've spent some time inquiring and thinking about what would happen if the server hosting your Atlassian applications were impacted by a disaster. Now, let's talk about how to mitigate the risk associated with a disaster, starting with the first and easiest thing to implement. A point-in-time snapshot of your Atlassian applications stored in a different geographic region will allow you to restore your applications if your primary data center was taken out by a tornado or other disaster.


What is a point-in-time snapshot? As it pertains to the Atlassian applications, a snapshot would be capturing a copy of your database and the application home directory, bundling it up, and shipping it off to storage elsewhere. There are many ways to accomplish this task, but the important part is that you do it, and you regularly test the quality of the data being backed up. A snapshot will have the longest Recovery Point Objective (RPO) and will have little impact on the Recovery Time Objective (RTO), but it's a great start! The Atlassian applications and their configuration can be redeployed (if using configuration management) or redone (if you haven't gotten to installing it via configuration management yet). Still, nobody wants to go about recreating Jira projects, issues, workflows, etc.


I suspect some of you are asking where you should be storing this snapshot. The easy answer is to store it in the same place you store the rest of the data managed by your disaster recovery (DR) process. Oh, Jira is the first thing you're developing a DR process for? Don't worry, we've got options! If you run it in your own data center and have a second data center somewhere else in the world, then that's a perfect scenario. If you don't, this is where a public cloud like Amazon Web Services (AWS) can be a lifesaver. If you push your snapshots to an AWS S3 (a configurable and secure block storage service) bucket near your Jira servers, you can then replicate that bucket to any number of other AWS regions. Part of the configuration of an S3 bucket is how you want to protect your data, starting with who can access and then who can delete. You can even configure the bucket in a write once, read many (WORM) configuration where only an AWS S3 Lifecycle rule can delete old backups, and no human can delete it. A bucket with WORM configured would satisfy the first part of your DR requirements with the added bonus of providing secure, untouchable point-in-time backups that would be safe from any malware or ransomware that may find its way into your environment.


But remember, the focus of a snapshot is merely the data. We haven't yet answered, "How quickly can the applications be backed up? How can we minimize the downtime and impact on our end users?" Snapshots are only the first step in a robust disaster recovery plan. In my next blog, we'll discuss replication that will round out your DR plan!



New call-to-action

See More From These Topics