Confluence Admin 103: Backup Options and Strategies
In our first blog, we provided pointers on Organizing a Confluence Site. Following that, we discussed Designing your site. In our last blog (of this three part blog series), we’ll walk through backing up a site to prevent disasters from happening.
A vital strategy for administering a Confluence instance is backing up your content. To start, we’ll keep it simple – Back up your content and back it up often. Then, test the backed-up content to ensure it works. Confluence comes equipped with automatic backups straight out-of-the-box. However, in most cases, this is not sufficient enough. There are also a few different factors a Confluence Administrator should consider when creating a different backup strategy. Continue reading to learn about Confluence’s out-of-the-box capabilities and considerations to build your backup strategy.
Confluence Out-of-the-Box Back Up Options
Confluence Cloud backups are fairly straightforward and reliable for disaster recovery. With a Cloud instance, Confluence backups occur every day and are stored for thirty days. Confluence System Administrators have the ability to create their own backups. To do so, navigate to the Confluence settings under Backup Manager in the Administration section.
Confluence Server performs daily backups automatically as a scheduled job. During this backup, Confluence produces a full site XML export. According to Atlassian documentation, “this method can be useful for small sites, test sites, or in addition to your database and directory backups.”
If you have modified the ehcache.xml file, you should consider backing up <conf-home>/config. If you have a large site that takes a long time reindexing, consider backing up <conf-home>/index to eliminate the need for reindexing once you restore.
Unless your instance is operating at a large scale, Atlas Authority does not recommend backing up <conf-home>/index. We understand retrieving stable index snapshots is difficult, please reach out to work with us to build something stable.
Minimal Back Up
Atlassian provides a few reasons why they do not advise using this minimal backup strategy:
- As your site grows and users continuously create pages, the XML backup takes longer and could possibly cause downtime.
- XML backups consume a lot of disk space if left alone. Imagine a 5 GB Confluence instance backed up every day for a year. This will result in nearly 2 terabytes of data per year.
- The bigger the Confluence site, the bigger the XML backup and, should you need to, the longer it will take to restore the site.
If you want to learn how to disable the automatic backup or edit how frequently your Confluence site backs up, visit this documentation. If you have a small instance, this method may be acceptable for now. However, keep this documentation handy just in case you run into a situation and need to know how to restore a site from the XML backup.
All things considered, we recommend looking at additional backup options to go beyond Confluence’s out-of-the-box capabilities to properly back up your production site.
Configuring Back Ups
Two factors to consider when deciding your backup strategy are your Recover Point Objective (RPO) and Recover Time Objective (RTO). These are two metrics that help organizations better define their Confluence (and Jira) backup strategies. These two terms may look the same, but it’s important not to get them confused. They will help you determine the number of tolerable hours for data recovery, how frequently you should back up, and what your recovery plan looks like.
Recover Point Objective
RPO will help you decide how much data is tolerable to lose during an outage. It is usually measured in the number of hours. With this number, you can then determine how much time can occur between an outage and your last back up, thus giving you an idea for how frequently you should back up. If your tolerable data loss is 100 page edits and on average your organization edits 10 pages per hour, then your RPO is ten hours. This means, you should back up your Confluence instance at least once every ten hours. In order to determine your backup recovery plan, you must first determine your RPO.
Recover Time Objective
RTO will help determine how quickly you need to recover your Confluence infrastructure once an incident occurs and this is measured in an amount of time. RTO tells your team how much time can pass before the outage seriously disrupts the normal Confluence flow. As an example, if your business decides that it can continue to normally operate without Confluence for 12 hours, then your RTO is 12 hours. Should anything happen, knowing your RTO will help prepare you and your team to recover from the disaster.
Setting RPO and RTO
A common practice for setting RPO and RTO is to rank your applications and services into different tiers. You can set the RPO and RTO dependent on your organization’s SLAs (service level agreement). You might find that mission-critical applications (tier 1) such as Jira or Confluence will require a shorter RPO and RTO than a tier 2 or 3 application.
Backing Up Content
In regards to the content within your backup, you should back up the following:
- the database
- install directory
- home directory (including attachments)
It is important that you maintain your backups. You should use some form of automation to delete old backups and keep the most recent ones. Lastly, to test backup quality, make sure to refresh your staging instance from backups.
The commands to back up your database will depend on your database vendor. A database back up and restore is a bit easier and more consistent than the XML back up and restore. However, it needs to be tailored to your database. Please contact us if you need help configuring an automated backup plan for your specific database.
As mentioned, backups are of the utmost importance to any Confluence instance. It is not nearly enough to simply back up your instance, but also crucial to test backups to ensure they are working properly. A great way to do this is to use the backup as your source when you are refreshing your testing environment. This allows you to not only keep your testing environment updated, but also reassures the success of your backups. Contact us if you need additional consultation on how to set up a robust backup plan.