The Jira Guy Puts Revyz to the Test - Backing Up Jira Cloud

"So, please, have a backup plan.  And considering all my requirements, Revyz is the best solution I’ve seen for Jira Cloud so far. " 
Rodney Nissen, The Jira Guy

Table of Contents 

• Introduction
• Backup Basics
• 3-2-1 Rule for Backups
• Automation
• Links to the Full Article

When you are a software company like us, one thing that can happen is that you can suffer from a bit of tunnel vision.  You spend all day and a lot of late nights agonizing over code, over new features, complex data, API's and the microcosms of detail.  When your role in your customer's world is to protect data, it is extremely important to be able to focus on the detail, but, it is also important to zoom out a bit and look at things from different angles.

This is why we reached out to Rodney Nissen (a.k.a 'The Jira Guy') who we respect as one of the 'old guard' of the Jira community and who, with his background in enterprise and military grade tech stacks, has a wealth of experience when it comes to data resiliency. 

We asked Rodney to do two things;  

1. To write an article on backup and data recovery in Jira
2. To review our solution and compare it with the incumbent solution offered by Atlassian.

Although we commissioned this article, we mandated that Rodney be his usual honest and oftentimes brutal self in order for us to learn from the process and find opportunities to build an even better product to project Jira Cloud Data.

Rodney did not disappoint and, from the immediate reaction and discourse created on the LinkedIn version of this article, we think that he's done an excellent job of analysis, but also raised a lot of useful and important questions.

Backing Up Jira Cloud

Introduction

Hey there, Jira Guys and Gals!  Yes, it’s been a minute.  Between putting together talks post Team ’24 and working on The Jira Life, I’ve had little creative juice left for here.  Fair enough, but there is only one way to get back on the horse, which starts now. 

Revyz contacted me not too long ago and unloaded some interesting info. Apparently, this article I wrote back in 2021 is one of the top Google returns for “Jira Backup.” But, looking back at it, it could be better. First off, it’s exclusively about DC and Server. I still think this holds up for those running DC, but we know most people these days are on Jira Cloud. 

Second, while the basics are there, I’ve delved deeper into the world of backups, uncovering some fascinating insights. So, I’ve decided to share these backup basics and then compare how Atlassian’s backup solution measures up against the Revyz solution. Without further delay, let’s dig into this.

Backup Basics

• First, you have enough of them in the right places.
• Two, they are automatic.
• You should still test your backups regularly.
• The procedures for accessing and restoring them are accessible.You should know how much data you are willing to lose (Recovery Point Objective, or RPO)and how long you want it to take to restore service (Recovery Time Objective, RTO)

3-2-1 Rule for Backups

So, first, we need to ensure you have enough backups. For this, I employ the 3-2-1 Rule. Have you never heard of it? Simply put, it is:

You should have 3 copies of your data:

1. One original and two copies
2. They should be on 2 different media: tape, cloud storage, hard disk, etc.
3. And 1 of those copies should be kept offsite.  

For example, for my local NAS, I have the following setup:

I have three copies of the data:

• The Original TrueNAS Core Server
• A secondary QNAP NAS that stores a copy of the data, which is delta backed up nightly, full backup Weekly
• A backup stored in Backblaze also backed up weekly

This satisfies the 3-2-1 Rule well. I have three copies of the data, which are locally split between two separate systems. Yes, they are both hard drives, so if you are a purist, consider my offsite backup to be both the second type of media and my one offsite backup.

Automation

Second, your backups should be automatic. You should not have to think about this process day-to-day because, eventually, you will stop doing it. This isn’t your or your team’s fault – this is just human nature. You get busy with higher-priority tasks, and boom, you’re in an emergency and realize your backups have not been run for two months. Which, I’m sorry to say that two months of lost work would be unacceptable.

Read the full article ...

Click here to read the full article and if you'd like to join the debate and conversation, then jump over to the LinkedIn Version and lend us your thoughts.