Confluence production backup strategy


Our team just purchased Confluence and I am setting up the service for production. I have gone through the production strategy recommendations and it seems fair to me, but I have question about how to implement it.

"To avoid any data inconsistency and corruption, it is recommended to shut down Confluence before creating a database backup or dump." Based on this caveat in the strategy manual, I will need to shut down the service every time to archive the home folder + SQL dumps, which is kind of disrupting for production if I want to do it daily.

Is there any way of following this strategy without actually shutting down the service?

Our setup: Confluence 6.4.0 + PostgreSQL both inside of single KVM VM.

3 answers

1 vote
Brant Schroeder Community Champion Oct 18, 2017


  We just do a nightly snapshot of the VM and the DB.  This ended up being the easiest way to backup the system with the least amount of disruption.  We have had to recover once and did it without any issue.

1 vote
Peter DeWitt Community Champion Oct 18, 2017

@Alex Ignatov,you should be able run a dump of postgres without dropping Confluence.  I have done this before on both windows and Linux servers.  You can also run a backup of the attachments directory without dropping Confluence.  But as @Brant Schroeder said above, if it's in a VM just take a snap each night and use that as your backup.


Thank you for your replies Brant and Peter!

VM snapshots of course crossed my mind, but after some googling I found that many won’t recommend it as production backup strategy primarily due to the fact that restoring VM from a snapshot looks like pulling the plug on the server and rebooting it. In that case it basically relies on database features to restore from such event. Which frankly even PostgreSQL official documentation encourages to trust to (WAL file). It is kind of 99% reliable which is not bad though and I hear that many successfully use snapshots for this purpose. Plus you guys confirmed that it worked for you, so I would definitely try it.

I will probably consider doing a mix of both VM snapshots + cron-scheduled SQL-dumps to make it more reliable (depending on resulting backup sizes). I will most likely include the home folder backup in cron job as well, however I am not sure how consistent it is going to be, since @Peter DeWitt as I understand tried archiving only the attachments, not the configuration files of a running instance. That is why I was initially confused by Confluence recommended production strategy..

In any case, it appears that I have few options now to work on. Thank you everyone for your input.

Peter DeWitt Community Champion Oct 19, 2017

@Alex Ignatov, didn't mean to leave those out.  We have a copy of all config (modified) files in bitbucket.  Sounds like you are on track.  Good luck.


I'll drop in a penny.  My experience has been, as long as the database file is older than the attachments directory things are usually ok when you start up.   If you have an attachments directory older than the database, you could end up with a bunch of missing attachment errors.  That is not show stopping, but some manual work involved to fix that.

Suggest an answer

Log in or Sign up to answer
Community showcase
Posted Feb 06, 2019 in Confluence

Try out the new editing experience

Hi team, I’m Avinoam, a product manager on Confluence Cloud, and today I’m really excited to let the Community know that all customers can now try out the new editing experience and see some of the ...

1,030 views 51 8
Join discussion

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you