About this talk
This talk discusses best practices for disaster recovery in Jira, emphasizing the importance of backups for maintaining data integrity in various business contexts. The speaker, Greg, shares his extensive experience in data backup and recovery, explaining that although Atlassian provides some backup options, users cannot solely rely on them due to limitations in restoring specific data. He highlights that Jira has evolved from a software development tool to a vital resource for many organizational functions, including IT service management and customer relations, making data protection essential. Greg also addresses risks such as human error and service outages that can lead to data loss and outlines strategies for implementing effective backup solutions. He reinforces the necessity of adhering to the 3-2-1 backup rule and advocates for the use of third-party backup software that can efficiently secure and recover Jira data.
Full transcript
[Music] hi hello every everyone and welcome on today's session about how to become a Master of Disaster Recovery in Jura so today we are not going to destroy anything to cause any disasters mostly I would like to share with you some good practices which you should follow in case of any disaster with your jira or maybe how to prepare for such a disaster so before we'll jump
directly into the topic I just would like to let you know who am I and why I'm going to talk about chur backup so so my name is gor Bon but I used to introduce myself as Greg um I'm working with data backup for more than 13 years so it's quite a lot of time spent on on talks with with people with customers who needs to to
protect their data to bake them up properly and of course I'm working for Z software uh which provides those backup services for more than 15 years uh on the market we are protecting as Z one and it protect both this classic standard infrastructure like endpoints servers virtual machines but on the other hands we've got G protect brand we are going to focus on today because it's dedicated
especially for devops ecosystems like G repositories Jura and so on H there are some big Brands behind us but of course I don't want to make you bored talking about the company so let's jump directly into the topic so first of all we have to ask ourself a question do I really need to back up Aira it's service run mostly running directly in the cloud there are
some data but are they so crucial and important for our businesses to bake them up or maybe it's just not necessary and not needed so let's firstly take a look what Chira nowadays is because if you are directly into software developer company I'm quite sure you know jira from software software project management so we can we can track our issues our releases and bugs we can solve
problems using the Jura but this product evolves pretty much in in the recent years and now it's not used only by it companies Who develops who creates some some kind of software or processes or or platforms or Solutions but nowadays it's h it have it has way wider usage so it's not only for software development but also for whole it service management for customer services for human
resources we can easily over the jira nowadays track customers issues dat cases everything what's related we can use it almost as even small CRM what we met in our experience with other customers that they use Jura also for that propose it's also pretty useful in terms of some Incident Management or maybe also we can use it for example for managing your own biring on off biring process
with some new employees or me of or your team members so as you can see there jira has pretty wide usage and it's not all only dedicated for for software development teams anymore uh so as you can see there are a lot of important they might be a lot of important data and for most of companies Chira is a crucial system so for example from my perspective
as chief of R&D at Z software if I lose access to our Jura it's huge disaster because here we've got our all our ads our work scheduled we know what tasks should comes with which relas so there a lot of very important information for me and I believe for most of you also in jira if you are using it there are a lot of valuable and important
data you don't want to lose so is it possible to lost data from jira let's take a look at two years before uh here you can see the screenshot of post incident review which which had place on April uh 22 it affects more than 700 of their customers and one of our potential customer were also affected so so so here were also in this group of of
those seven almost 800 of customers with no access to jira what happened there were two teams they were migrating that jir instances between infrastructures and there were communication gap between those two teams one of the team requested or just waiting for IDs of instances that should be removed but the auor send them instead of those instances ID of the entire bucket or the entire platform that has
to be removed so the team responsible for the data removal did its job and remove everything so that's why April 5th 2022 a lot of users were not able to access their Jura instances of course they they were able to to recover from that to restore the users's data but even looking at this just few sentences just few sides from from their post incident review we can
read that the first customer will restart three days after the incident and the last customer needs to wait two weeks to recover their data to to get back access to their jira assets and everything what's they important for them so from my perspective it's a huge disaster and I cannot allow for that at my company to wait two weeks for jirat to be back and aval for
me so obviously atashian started from from the biggest customers restoring their data so so they're the biggest customers who are affected gets gets back access to Jura instances three days after the incident so for three days they were not able to plan schedule or track they work and it's huge disaster so that's why you may need to back up your jira but you may think that atlan
has backups of your Jura instances because somehow they were able to restore those data so it means there is some backup in place we cannot create data from from nowhere just just just write the same issues the same task as where on your Jura instance so it has to be restored directly from a backup and you're right they have backups but if we will take a closer
looks at documents at Lan prepared we can easily read that they cannot use their backups to roll back changes that was caed by user so if you will do anything by mistake if you will remove some issue maybe in result of this script you're going to test you lost some data or or some important configuration then it's your problem how to revert this situation how to restart
data you've already lost and such thing happened and it's proven in batttle that atashian even if they have your backup they want restore those data and from my perspective as service provider as as vendor it's quite understand it's quite unstable that they don't want to to restore to recover the user data because of the way they've got it implemented it was the feature dedicated for the entire
infrastructure not for the single customer and recovering single instances it's a huge effort on the atashian side so that's why they don't want and they can't use their backups to recover just a single customer just a single instance moreover if we'll take a look inside their terms of service or even there are some special documents which describes the responsibility between atlan and their customers then we can
read about shared responsibility models and following this model you can easily find that atlan is responsible for hosting of their services for their availability for the security and everything what's going under the hoods so in general they have do their job to provide you access to to jira whenever you need and whenever you want on the other hand your responsibility as the end user is about the
data the policy the compliance the ACT and the apps you are installing there inside a jira so just from this graphic which is taken directly from atashian from from their documents we can easily read that responsibility over the data is on our side on the end user side so if something gets wrong then we can get an issue and if you are still not convinced that you
may need to back up your GE app to to protect it additionally because as we agreed atlan have some backups has some backups in place but they are able to recover them only in case of of issues day cost and moreover you may need even to wait two weeks to get back access to your data so implementing any backups even those manuals will be way cheaper than
waiting two weeks for a ility to track your issues to to to solve the problems and work with Chira and of course if you're convinced few weeks ago I I was waiting for my flight to to woro to another one conference I was scrolling my LinkedIn wall and I found this post so it may happen that you just lost access to jira in in some different reasons
and you may won't be able to quickly get back access to such instance as in this case so so I keeps my finger closed that everyone of you who's using a jira is as safe as as necessary and one need to write such post on social media trying to find out anyone from a flashion who can help them solve the problem and get get access to their
J of course it's real LinkedIn post if you try to find Luan probably this post is still on his wall but of course it's not the only reason why you should protect your Jura so so it's not only about you know making some changes on on the atashian side or just locks of the backup because if data are not lost it's still okay that we don't need
to do anything but there are some more traits that you should be aware of so first of all some external trats I haven't heard about any ransomware attack on Jura instances and probably it has it hasn't took place so far but the same was with just our computers and the data before first first ransomware attack no one's heard about the ransomware uh ransomware nowadays hits get repository
so I believe it's just about the time when it starts hitting another crucial and important services including of course Jura um we can also lost access data by some Bad actors by some int intentional human error maybe we can have we may have in our companies and bad levers who who will decide to for example remove all his job directly from a jira maybe there will be
some wrong permissions for them set and he will be allowed to do so uh we can also L access to to our jira instances in terms of service outages or service downtime so as as I said few times before it's pretty crucial and pretty important to have your jira instance to your main quite often main software to track your work pretty well protected against such situations and
last but not least legal and compliances everyone wants to have pretty nice looking certificates and and compliances which proven the security level in your company in your organization but most of current certifications and standards requires to cover the most valuable assets and services using backup and Disaster Recovery systems so if you are using jira I believe it's one of the most valuable assets you have it's crucial
system for your business continuity and in order to get is ISO 2701 or maybe in order to get Su to type two certification you must cover this service also with some third party with some external backup with some additional manual protection whatever just protect it so as you know disaster may happen there are a lot of situation you can you can easily lost your data so you
have to be prepared for a disaster so how to be prepared how to do so first of all remember to cover all data all projects all issues and all assets that are available or resources in general that are directly available inside jira there are a lot of dependences inside like workflow statuses tasks projects and so on and so on I can count it for quite a long
of so just keep in mind when you are searching when you are planning your Disaster Recovery to cover all data that are important and available directly inside your jira instance and just in the meantime one one one Tech think about our our today's presentation uh in Pine app on the right side you got a chat and Q&A panel so just as a reminder you can use the
Q&A panel to ask any questions you want me to answer later on after the presentation so let's jump into the slides because there are few more slides and let's talk about backup performance so there are a lot of limitation on the atashian side and being honest with you it was very very hard to develop and Implement Jura backup into our services we provide to our customers so
here you've got our special knowledge we want to to share with you on what you need to keep in mind when you're planning your backup or disaster recovery for business continuity proposes so first of all as I said before keep in mind to cover all data that are inside your jira uh it's also very important to met 3 to one backup Rule and if you're not familiar
with this rule it says that you just that you have must have free copies of your data in two different location and at least one outside of the company or in general in a different location than the source of your data only in this case you can truly think that your data are safe and secured and keeping the backups on the vendor side like with aan for
example doesn't meet this very important backup rule because only following this role gives you guarantee that you will be able always to recover your data and of course in order to meet this role it's very good to have in place backup replication between multiple locations why because taking twice the same backup of Jura instance minute after minute or hour after hour may be very difficult or even
impossible due to the limitations on their side and of course it's also very important to think about retention on how long do you want to have your data available to be recovered with what data granularity it will help you to schedule the backups pretty well and also to not lost any important and followable data so for example uh you may want to schedule your backups to be
performed between 8:00 a.m. and 6:00 p.m. every one hour or every two hours uh because because those are your working hours and there are a lot of changes made during that time but you agree that you can lost two hours of your work that's why you may have want to to make this backup every two hours and in result in case of any incident during that time
you will just lost two hours of your team works it's still a disaster but not as huge as losing the entire Jura instance and thanks to their attention you can you can determine on how long do you want to keep your data so for example if there will be some bad actor who removes your data today and you will Discover it three four five days later still
you want to have ability to recover your data so let's take a look at disaster recovery and points that we need to cover that we need to think about when planning this part of our business continuity so first of all we need cross recovery we need ability to restore jira instance to any older even brand new instance in case anything happen H so even if the entire
AWS which atashian uses to host day your infrastructure will Goes Down Still you will be able to restore your jira for example to jira Data Center which is onsite representation of of the same what you are using directly with a Jura Cloud uh it's also very important to have point in time restore abilities so so you don't want to recover not only the latest version but also
any previous one for example just for forensic reason just to make maybe some investigation some additional checks to verify how your jira or some project changes within the time and also it's very important to have ability for Chon recovery because we know from experience how long it may take to restore the entire jira instance and we cannot be up those processes because most of the restar of
of the instance is done on the atashian site so that's why granular recovery might help you for example to restore some single project or maybe even a single issue to some sidebox instance to verify the content of project to test your backups because it's very important and do not forget about testing your backups you don't have backup unless it's tested so if you do backups but don't
test them don't thing that you have already backup in place firstly you have to test the backup to make sure that it's recoverable and all important and valuable data are there so it's also very important and valuable to keep in mind your data security so if you're are going to create your own script maybe your own solution or or use any thirdparty software keep in mind that
this software this solution will get access will gain access to your production Jura instance with valuable and sensitive information so it's very important to manage Secrets used to access your J usually it's it's an API key uh so it's very important to manage them in safe and secure way way to be sure that no one except you can access this secret over over the solution you're implementing
to protect your jira it's also very important and we cannot forget about data encryption so every backup should be encrypted before it lands on the destination storage just in case and third party and bad actor will get access to your storage still that person didn't didn't get access directly to your data um in terms of access we cannot forget also about secure authorization so it's good practice
to use any external identity providers just to combine multiple systems into one place of trust which you can through which you can manage privileges accesses responsibilities and permissions to partic systems any additional logs any additional information or emails sent to to some external systems to external CMS to to to your email to your Slack are just only additional factors which improves your security because it gives you
the overview of your of your backups of your security of your safety with no need of looking directly into to the system because I'm quite sure for those who are responsible for data security backup is not the only system you need to be aware of so as I said few times before just remember to test your backups to test restore but not on the production environment and
here I've got some story of of our customer I cannot tell you which one but then I cannot tell you the name of the customer but of course I can share with you his history so the customer decides to test our products and his backups were completed with some warnings he was warn he were warned uh in backup Samar Direct in our system in email notification he
received there were also we hook sent to to some external customer systems uh with the same warning the warning said that some attachments are not protected because they are corrupted because our software cannot get access to those attachments directly from jira there were Leist of few hundreds of attachments the customer had thousands of them but on the list there were just few thousands of attachments that were
not protected at all and customer ignores the sorning he decided to test rester which is pretty obvious and as I said is a m for you if you want to be sure that your data are safe that you never lost them then you have to test your restore restore processes and procedures to make sure that you can every time in every disaster continue your business but unfortunately
for the customer instead of running another instance uh another s like sandbox he decided to recover to his production um our service also informs users and warns him on what about he's going to do that you're going to override your production instance and is making sure by additional prompt if it's the operation you are planning to do and you want to do and of course customer confirms
everything after that uh his Jura instance his current Jura instance were overwritten by by data from from his backups and unfortunately he lost access to some of the attachments not all few hundreds because they were truly uh truly broken and inaccessible uh some of them were in the trash but but some some references left in their origin project and this costed some some warnings uh but in
general he lost some attachments so customer and together with us tried to reach out slash and team to restore the data but unsuccessfully so as I said from from Defender perspective I can understand that uh that they don't have those processes implemented to to restore a single customer inance but just keep in mind while you are testing restore do not do it on the production so that's
one of the reasons we've implemented init prodct ability to recover your jira instance with no users at all so you don't need to worry about uh about any any billing any additional cost from the atashian side you can easily run your sandbox instance and recover your Jura to the sandbox every time you want to so in general how to solve the problem how to protect the Jura
well how to follow the guidelines the best practices uh there are not too many ways you can use uh for now I can let you know that that that leion is working on something new on some new abilities for for admins to back up and restore the tra but at this moment it's just available to few customers who sign up for every Access program and just only
for them rest of the users may use their native expert feature you can easily log in to your Jura instance as and through admin panel you can export your jira instance so you will receive some some XML and zip file which contains all information that are stored on your instance am I said all information oh it's not true because this backup is not a complete one and
it doesn't contain all of your data and even following the jira jira site we can easily read that there are a lot of resources that are not covered like for example automation rules so you can spend a lot of time to set up the best Automation in your J instance but following the expert feature you won't protect that automation H moreover attachments avatars and logs so every
res which has some size in general even not greater because avats usually are quite small are possible to export every two days so so you cannot protect your Jura as often as you want and sometimes attachments are crucial in tasks in issues in work we are tracking or we are doing there is another solution we can follow uh but only in case of Jura data Senter and
only for those who still are using Jura server and do not migrate to Jura cloud or Jura data center so in general for Onsite Jura instances uh with this case you can protect the entire system on the infrastructure level you can back up the entire machine virtual or physical one where where your jir instance is running and this back C Co is everything uh the entire jira
it's database attachment the system already configured to run or J so in general there is everything of course the size of this backup will be way bigger than the exper directly from from jira because because in this case you will also you will get also the con you will get also the entire operating system inside your backup for example and of course there is the duplication increments
and so on which reduce the size of the backup but still those data at least must be processed during the backup um there is also no grar recovery usually with such backups you just need to recover the entire system with everything inside so in general in terms of an saster restore may take a longer time but still it's quite good approach to protect your jira and last
but not least is to use third party dedicated backup software so even at flashion recommends to use any third party solution to protect the data you've got directly in your Chira instance what you need to think about what you need to to cover with this third party backup software is first of all best backup and Disaster Recovery practices so just keep in mind about 3 to1 rule
about recovery possibilities uh do not forget also about the times needed to to perform such a backups so third part of software usually also is the fastest in terms of data recovery because you're recovering just your Jura instance not entire entire operating system and all files and data inside operating system it's only your Chira instance uh you can also using thir party software resour single project single
issue single attachment and in overall is the cheapest in time of if we will calculate time and money needed for implementation for maintaining this solution or for example for time which will be needed during a disaster to restore then uh such Solutions as third party backup are overall the cheapest and of course there are just only a few vendors few Solutions in the market available three or
four maybe uh which can help you to pick up your giraff so you can easily test every of them among of those Free Solution you can find also our own which is get prodct with this pretty nice lion in the logo and just giving you overview uh in terms of of baking up your chura uh G protect is based on our very Advanced Zer one backup platforms
so it has all professional features uh that are necessary to protect your environment and we bring those advantages directly to devops ecosystem backups so G protect supports a lot of different kind of data uh a lot of different platforms like GitHub bit bucket gitlab Jura pretty soon aure devops and still we are going to improve kit protect in that way to to provide more services covered uh
of course it supports data encryption compression the duplication Secrets uh secure secret management uh there are very very detailed audit logs and everything what you require from the professional backup services so right now I hope that you've got full knowledge on Jura backup and disasters and on how to recover from them but we've got around three four minutes left uh I haven't seen any qu questions from
you but if you have any just let me know and drop your question in the Q&A panel and while waiting for questions if there won't be any then I can make some small demo for you of of a so let me find the kit protect instance I have have here in place okay so if you're ready here is my brand new product so let's went to dashboard
as you can see the trial will expire in two weeks and every one of you can just went to our website and register for a such trial and oh I think it doesn't change the screen so you still can see my unfortunately H so I believe you will be able to check it on your own if if you can't see uh if you can't see my demo
but it was just addition from oh here it is I can see that that right now you you can see the demo so just quickly showing you how easy it is to integrate git protect with if jir there is some some time disruption between my presentation and what I see on Pine so here is devops and obviously we just need to press the jira right now I
have to provide the instance URL everything I have under the hand but this is that one instance as you can see so I've just provided the instance URL I have to provide the login and also I have to provide the J token so Jura hh2 and I have to paste the token here let me press save and only what I have to do is just to press
proceed now my Jura is integrated with G protect I've got a question if I would like to run the backup now so yes that's why i' I've decided to use get protect to run a backup so the backup is already started here we've got the plan dashboard we can see that the backup is already started we can check some more details even going directly to our tasks
to see what's going exactly and here we are in progress on backup initialization and we are compressing data and attachments at this stage so that's all from this pretty short demo I had prepared right now for you and as I can't see there any more questions then I don't have anything more to say than thank you and may the backup be with you have a great day
guys and thank you for your time I hope my presentation gives you some useful information on how to be safe and protect your jira instance have a great day and bye
