Can't backup, running OOM

[Gregory Joseph]

Hi there,

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 ?

[Daniel Borcherding · Accepted solution]

Hello Gregory,

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.

[Gregory Joseph]

Thanks for the input - see my comment above, I'll try to update the thread (with my mistakes and findings) once I'm done.

[Gregory Joseph]

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.

[AlysonA]

Hello Gregory,

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.

[Gregory Joseph]

Thanks for the input - see my comment above, I'll try to update the thread (with my mistakes and findings) once I'm done.

[Gregory Joseph]

Hey Jamie, thanks. My understanding was that I'd need an xml-backup to do an upgrade. Must have misread something. See below...

[JamieA]

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.

[JohnA]

Hi Gregory,

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,
John

[Gregory Joseph]

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.

*confused*