I was trying to do a backup of our installation via /admin/backup.action - in order to migrate it to a new server, and a newer version.
We're currently still on 2.10.2 (ouch), and I was hoping to upgrade to 4.2.12.
Back in 2009, I'd made a similar backup/update procedure, and in my notes, it looks like the backup took about 20 minutes to go through. Now, granted, we have a lot more content, but
With an Xmx of 764m, backup ran out of memory after 30 minutes
With an Xmx of 1536m, it ran out of memory after an hour.
... both with Archive to backups folder and without Backup attachments.
Also note that I disabled our ApacheHTTPD proxy which normally sits in front of Confluence, and restarted the instance before attempting a backup, so I'm pretty confident there wasn't anything else going on at the time.
Of course, I could keep on increasing it until it works, but that means the instance needs to be down the whole time, and since it's currently running on the same server as other apps, these other apps might be impacted if I increase the Xmx for Confluence further.
So I was wondering if
you could help in finding out how long it could take, and how much memory I'd need. If I know in advance it'll take 4gb and 4 hours, whatever, I can make that happen. But I wouldn't want to have yet another OOM exception after 4 hours at staring at my browser.
there is a way to do such a backup without having the webapp up. If you guys had a standalone app that could do just that, I'm pretty sure it'd help in many ways - I could run it off a different server, for one, and wouldn't have to keep my browser opened for it to finish (so I'd run it in a screen session on the server)
Another quick question - let me know if you'd rather me open a different issue for this:
We'll be using the standalone bundle from now on - we do however have standard init.d script that launch Tomcat instances. I was wondering if you could confirm that it's safe, and that start-confluence.sh merely delegates to startup.sh ?
I would echo the sentiments of the other Atlassins.
I would add that you want to make sure that you don't try to jump directly from 2.10.2 all the way up to 4.2.x.
You need at very least to go though the 3.5.x to make sure your transition goes smoothly. My advice is to make sure that everything runs as expected in this version before upgrading again to 4.2.x.
As John mentioned, please do not hesitate to file a request for support on http://support.atlassian.com we are more than happy to help with any part of that process.
The XML backup process for Confluence is VERY memory intensive because the backup is pronted to memory before being written to XML, so whilst there are certain things you can do to mitigate the impact, (such as not backing up the attachments), the only way to do this effectively is to go very aggressive with the memory allocation and let it run.
One option for you would be to dump the database, restore the instance on a new server and that way you could increase the memory allocation without impacting the other applications. Otherwise I would suggest that you increase the -Xmx to 4GB and let it run until it's completed. In terms of how much memory it will require, it's hard to say without knowing the size of your insatnce but 4GB and a couple of hours should be more than sufficient unless your instance is massive.
If that doesn't work then contact Support, including your logs, and we'll investigate the issue for you further.
All the best,
Support tells me the same; I must have misread the documentation, where I thought doing an xml-backup, and restoring *that* when starting up a blank new instance was *the* way to do an upgrade.
I have never managed to do an XML backup, even with what I think is quite a small instance and Xmx 4Gb. An XML backup is not necessary though, a db backup plus home dir backup is sufficient to restore from if things go wrong.
Indeed exporting/importing an XML backup file "should" work fine, however as John stated, it is very memory-consuming (specially if you have a really large instance), in those cases we suggest using the production backup strategy as described in https://confluence.atlassian.com/display/DOC/Production+Backup+Strategy
Please let us know if that makes sense.
Thanks for the input everyone. I did a test run, indeed going via 3.5.17, and simply doing a mysqldump/restore. Now that I read the docs again, I have no idea why I thought this wouldn't work. I bumped into a few hurdles along the way, but I'll try to document them, here at the very least, once I do the upgrade of the production instance.
I attended Atlassian Summit 2019 and learned a lot from the presenters, attendees and knowledgeable Atlassian product managers. The presentations I attended focused on applying Agile, pla...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events