Confluence production backup strategy

[Alex Ignatov]

Hello,

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.

[Peter DeWitt]

@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.

pd

[Brant Schroeder]

Alex,

  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.

[Alex Ignatov]

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]

@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.

.pd

[Gregory Van Den Ham]

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.