Businesses are increasingly adopting Cloud and SaaS applications, moving away from On-Prem deployment models to reduce costs, lower risk and increase agility. Atlassian Apps are no exception. In fact, Atlassian doubled the number of cloud migrations in FY’22 compared to the previous year, with more large enterprise customers such Deutsche Bank and Sun Life moving to the cloud.
Atlassian apps such as Jira, Confluence Cloud and JSM are mission critical to every organization today. These applications contain highly valuable data that needs to be secured and protected from all forms of data loss. As companies plan their Atlassian application migration from an on-premises environment to SaaS, it is important to consider and plan for the protection and security of the data residing in the SaaS application.
There are a plethora of white-papers, blog posts and best practice documents for migrating your Atlassian apps (Jira, Confluence, JSM ) to the cloud, including Atlassian’s own Cloud Migration guide. However, all this guidance misses out on a critical element - how should customers protect data within their Atlassian Cloud applications post migration?
Atlassian Data Protection
Let’s review the guidance that Atlassian provides on how to protect data in your on-premises and Atlassian cloud environments in both pre and post cloud migration scenarios
Pre-Migration: Atlassian Data Center and Server Data Protection
In an on-premises setup (server or data center deployment) the Atlassian applications (Jira, Confluence, JSM) are running on hardware and software controlled and operated by customers. Atlassian strongly recommends to its customers to backup their data using native database tools as articulated in the Administration Guides for Jira Software Data Center and Server 9.3 documentation / Confluence Data Center and Server 7.2 documentation.
“For production use or large Jira application installations, it is strongly recommended that you use native database-specific tools instead of the XML backup service. XML backups are not guaranteed to be consistent, as the database may be updated during the backup process. Inconsistent backups are created successfully without any warnings or error messages, but fail during the restore process. Database-native tools offer a much more consistent and reliable means of storing data.”
This means that if you are currently an Atlassian Data Center or Server customer, your data protection strategy must include backing up your on-premise environment (pre-migration) using native database-specific backup tools. These periodic backups not only provide protection against hardware and system level failures, but also help you recover data from scenarios such as user errors, malicious insiders or accidental deletions.
Post Migration - Atlassian Cloud Data Protection
Now, let’s look at the post migration scenario. When customers migrate to Atlassian cloud, they assume that Atlassian is automatically protecting their data from all forms of data loss. Now, that’s a big fallacy since many customers aren’t often aware of a SaaS service provider’s Shared responsibility model.
In a cloud SaaS setup the control and operational responsibility for operating and maintaining the application lies with the SaaS provider whereas the responsibility of protecting the data still remains with the customer reference the shared responsibility model for SaaS applications.
As a result, customers are solely responsible for the management and protection of their data, accounts, and more. Accidental deletion, user errors, and intentional malicious actions can all lead to data loss, but these scenarios are not addressed within the scope of Atlassian’s built in data protection capabilities.
In fact, Atlassian operates a comprehensive data protection and backup program as part it’s Cloud Security Practices
“We operate a comprehensive backup program at Atlassian. This includes our internal systems, where our backup measures are designed in line with system recovery requirements. With respect to our Atlassian Cloud offerings, and specifically referring to customer and application data, we also have extensive backup measures in place. Atlassian uses the snapshot feature of Amazon RDS (Relational database service) to create automated daily backups of each RDS instance.
Amazon RDS snapshots are retained for 30 days with support for point-in time recovery and are encrypted using AES-256 encryption. Backup data is not stored offsite but is replicated to multiple data centers within a particular AWS region. We also perform quarterly testing of our backups. For Bitbucket, data is replicated to a different AWS region, and independent backups are taken daily within each region.
Now in the same document, Atlassian clearly indicates the scope and purpose of their backups in light of the shared responsibility model, urging customers to make their own regular backups to revert from user initiated errors or changes such as deleted issues/projects, overwritten fields etc.
We do not use these backups to revert customer-initiated destructive changes, such as fields overwritten using scripts, or deleted issues, projects, or sites. To avoid data loss, we recommend making regular backups. Learn more about creating backups in the support documentation for your product.”
Thus it is critical for customers to backup their data residing in Atlassian cloud post migration since the Atlassian data protection and backup strategy does not address data loss resulting from accidental or malicious deletion of data initiated from the customer.
When planning to migrate your Atlassian data into the cloud or if you have already migrated your Atlassian data into the cloud, you as a customer are still responsible for the data in the cloud. Ensure you have a strategy for data protection in place prior to migration to the cloud.
Blogs from Revyz