Backups using MySQL replication

[Andy Henson]

I was surprised to see that Cloud-based Confluence only backs up every 24h, as I would expect such a system to use database replication to back up instantly to a offsite backup.

We intend to install Confluence Server on our site, probably using MySQL replication and hourly rsync for attachment backup.

I have a few questions:

a) If we replicate to another site for use by the same company, do we need a second Confluence licence for the backup (for case the main site burns to the ground)?  We would need to be able to get the second site up instantly, partly because all the disaster recover information is on there!  But only one copy would be running at any one time.

b) Would there be any issues in starting up Confluence on a database replica?

c) Why is database replication not mentioned as a backup method in any Confluence documentation?

[Roman Kirilenko]

Confluence license doesn't live in the database, it lives (and server id as well) in confluence.config.xml file within Confluence home directory. But I agree with Nic - if the availability is the main point for you, it'd be better to think about Confluence Datacenter and database redundancy instead of having a "warm" copy.

As an alternative, if your database isn't very large (it seems to be true), you can use mysqldump with -x key to make a consistent database backup without stopping Confluence and backup your home directory separately (backup and restore processes can be quickly automated with simple scripts and cron). In case of large database, MySQL isn't best choice anyway. This appoach allows you to restore your instance "from scratch", even if your database servers are dead, it also can be used to maintain a "cold" copy. If your main instance fails, you can just start this "cold" copy and continue your work (and you don't have to deal with MySQL replication in this case).

Also, you can use MySQL replication and use rync as you described, but your second instance should be stopped. You should make sure that your faulty instance is stopped completely before starting a backup instance.

In fact, you'll get the same Confluence instance with any of these approaches. If you have only one instance started, there will be no licensing issues. It's more like a kind of migration to other hardware.

[Nic Brough -Adaptavist-]

a) No, you can use a "developer" licence for a warm standby, but the licence lives in the database, so the replication would wipe it out.  Just replacing it with a developer licence is easy though, and "disaster recovery" is specifically named as a valid use for developer licences. 

b) You would need to ensure the main Confluence is shut down or at least not able to reach the database.  Break the replication and work off the mirror.  You would need to re-index after starting the replicated Confluence as well

c) Most Atlassian users don't need it, as it involves having more (costly) hardware, and once you're at a scale where it starts to look like a good idea, you're usually in an environment which has network and DBA people thinking exactly what you are, and are more than capable of setting up replicated failover systems for themselves, so they never ask Atlassian!