nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Confluence Recommended Backup Schedule

Thomas Zahn1

We are using Confluence in a regular office environment where the majority of our users are on a 9 AM - 5 PM M-F work schedule, but we also have NOC employees that use it 24/7.

I wanted to know if there is a recommended backup schedule (full database dump using a cron job) that is the best compromise between data retention and site availability (i.e. we don't want Confluence to hang or be unavailable during peak hours while the backup is being run).

Accepted answers

Mike Rathwell

Thomas,

I guess it all depends on how big your installation is for how long it will take to dump the DB and copy the data directories (you need both). Better to get the app directories as well so you retain all your configurations. The "official" way to back it up is to take Confluence offline to make the DB dump and filesystem copy.

That said, I've made copies of my instance (DB dump and filesystem copy) in the middle of the normal production day while the system was hot to make a snapshot to use in dev when planning and testing for upgrades, etc. I always have been able to restart the instance on the dev box. So far I've not noticed anything that didn't make the move and I just make sure it is clean with a re-index after I bring up the snapshot image.

Since this is a backup you'd be going back onto the same OS, I would assume, when recovering. The recovery from that method I just cited is the same as moving the instance from one server to another. Basically, the steps I take (at a high level are):

Restore the DB dump
Copy the application and data directories to the same filesystem locations as the production box
Start Confluence
Rename (if necessary) the Base URL in Administration to match the hostname of the new box.

Caveat: If you have your DB server on a separate host from your Confluence instance, make SURE you're pointing to the correct database. If the DB server is on the same host as your Confluence instance (as mine is) I make sure the datasource points explicitly to localhost so I don't inadvertantly mess up the production DB.

I'd suggest that you try that move process a few times to see how it goes. If you do the dump and copy process off hours when only the NOC is in (which I presume uses Confluence more for reference than contribution) the chances that an in-flight change to the DB is missed won't happen. Even if a bit does get lost and you have to recover from a disaster/failure/whatever, a few missing edits or attachements - no biggie in the grand scheme of things.

Hope this helps.

All comments

Mike Rathwell

Thomas,

Restore the DB dump
Copy the application and data directories to the same filesystem locations as the production box
Start Confluence
Rename (if necessary) the Base URL in Administration to match the hostname of the new box.

Hope this helps.

Thomas Zahn1

Thanks for the detailed answer and your lessons learned from experience using Confluence in production. Good point about the app directories. I assumed all the configurations were in the database as well. Do you know if the configs are copied in the Confluence XML backup? I've enabled that as an additional layer of redundancy.

Mike Rathwell

Thomas, Short answer is no. The XML backup is the content only. You have to have a hot and ready Confluence instance to restore it to. The only configurations that are kept are the Confluence user level admin settings; not the base application running directories. That said, having the XML backup is a good belt/suspenders backup strategy. Watch your logs, thought. As your instance gets bigger you WILL eventually run into Java heap errors (leaving an incomplete and useless backup) and have to adjust Java accordingly to compensate. I should note, also, that by backing up the way I cited, saving the app directories ALSO preserves all your user installed macros/plugins as well as your discrete settings for both user and system macros. Basically, Confluence comes up in its new home looking EXACTLY like it did on the original server. Coincidentally, an extension of that same backup methodology let me move from Ubuntu to Windows Server 2012 (many reasons for that, some of them actually good ones) and have it look and feel at the Confluence Admin and user levels exactly as it was before. If you're interested, I detailed that in another answer here https://answers.atlassian.com/questions/15835508/migrate-confluence-from-linux-to-windows Using those steps (leaving out the Linux to Windoze twiddles) it always, always, always works. In fact, when I did the migration to the new server, I NEVER shut down Confluence; I just made my snapshot to migrate at a quiet point of the evening. I've not gotten a single comment that one iota of data or edits were lost.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

confluence

confluence-administration