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; } } }

Backup of Confluence through Tomcat not working

Benjamin W.

Hello

I'm quite new to Confluence, so please excuse if this is an easy one :-)

We have JIRA and Confluence 6.9.1 running on the same server host (on Premise, Windows), proxied by Apache with own subdomains (jira.company.com, confluence.company.com).

I am trying to make a backup of Confluence.

When proceeding on this via Admin Web Interface, the backup takes very long time (actually even after 8 hours not finished) and causes high traffic on the server itself (100% CPU).
I found this thread here describing the same issue:

https://community.atlassian.com/t5/Confluence-questions/Confluence-Backup-Speed/qaq-p/174479

So seems to be the case when Confluence gets proxied with Apache. Recommendation / solution is to proceed the backup not through Apache but rather through backend Tomcat directly. Found the documentation over here: https://confluence.atlassian.com/conf69/manually-backing-up-the-site-950285456.html

I verified the server.xml, it shows that Tomcat is listening on Port 8090 for Confluence:

Also the server shows that it is listening on this port (verified with netstat -ano).

Based on the kb article mentioned above I assume the correct URL to proceed a backup of Confluence through the backend Tomcat should be:

http://localhost:8090/Confluence/admin/backup.action

When I proceed this URL on the server in neither IE or FF, I only get a 404 page not found.
The developer tools of the browser are prompting a 403 authorization required.
Based on this, I tried to create a Token in the same browser session. The login page seems to accept the credentials (both AD and local directory), but the behaviour remains unchanged.

Also when using https and / or different Port (8091) does not make any difference.

Based on this, my question is if the URL I am using above is correct? Am I missing something?

Thanks in advance for your support.

Regards, Benjamin

Accepted answers

Benjamin W.

In case anyone else has need of it, find here the solution for this issue.
I have contacted Atlassian Support, they advised to check Server.xml and remove the following entry:
◦proxyName="confluence.company.com" proxyPort="443" scheme="https" secure="true"
And this did the trick. After another restart, I was finally able to Access Confluence directly through Tomcat on port 8090.

The issue with high CPU usage on Backup remained the same. As our Environment was classified as a large one, this behaviour might be normal. As optimizations, the following configuration can be done in order to Speed up.
>> increase maxThreads from currently 30 to 120
>> increase hibernate.c3p0.max_size from currently 30 to 150

But it will not Change the issue in General. In our case, the only practicle was is doing a database dump.

In general, @Alexis Robert, thank you very much for your contribution and support!

All comments

Alexis Robert

Hi @Benjamin W.,

you almost got everything right ! The only problem with what you're doing is that when you call localhost:8090, you're actually trying to request a page from your own computer and not from the Confluence server.

You should call localhost only if you're connected to your Confluence Windows server with RDP for example, and opened a web browser directly on the server.

But don't worry, you can still perform the backup from your own computer - you just need to call the right IP address. You will basically need to look for the Windows server IP address, and access Confluence this way: http://my.ip:8090

Let me know if you have any questions,

--Alexis

Benjamin W.

Hi @Alexis Robert

thanks for your fast feedback.

Sorry, did not correctly describe it in my post:
I have ensured that I was accessing the URL from the Confluence server, so localhost was referring to the correct host. In my opinion it also seems that the URL is somehow correct, as the 404 page not found is a site in context of Confluence.

I have also tried to start the backup from remotely (not server itself). But mostly same result.

Might it be an issue with authorization? (as the browser developer tools state a 403 authorization required)
When I'm doing backup from the Admin site, logging in to Confluence requires credentials....

....and when accessing the Settings-section, I am prompted for Admin-credentials.

Might it be the case that the authorization fails as a second log in "as Administrator" is required?

I have tried to log in as administrator (above) and then, in the same browser session (to share the token), execute the backup.action URL. But also this results in the page not found exception above.

Regards, Benjamin

Alexis Robert

Do you try to access directly the backup URL ? If yes, you should actually do the entire process using the IP address at the beginning:

Go to http://192.168.41.12:8090 and log in (don't use https here)
Navigate to the Administration menu
Navigate to the Backup menu
Start the backup

I believe this should work, I have tried it myself on a Confluence instance and works fine.

Let me know how it goes,

--Alexis

Benjamin W.

Hi @Alexis Robert

ok, now got the point.

But unfortunately, this isn't working. I have the feeling this is related to (mis) configuration in our environment.
From http://192.168.41.12:8090/ I am prompted for the Confluence login page. When providing valid credentials, there is no redirect to a site within Confluence, just reloading the login-page.

When I enter Confluence via DNS https://confluence.company.com, after logging in I am redirected to https://confluence.company.com/#all-updates. So at this point, I am having a valid token. Now, when manually changing the URL to http://192.168.41.12:8090/#all-updates, it again prompts me for credentials.
Also, there is a redirect from Port 80 to 443 (http://confluence.company.com will turn to https://)

I have also tried to access a deep-link by IP. Means accessing normal space via https://confluence.company.com/display/ATL/Atlassian, then change to https://192.168.41.12:8090/display/ATL/Atlassian which results in "https not possible", then change to http/192.168.41.12:8090/display/ATL/Atlassian which results in prompt for credentials. (see behaviour above)

Is it the case that Tomcat is not correctly configured for redirects?

Thanks and regards, Benjamin

Benjamin W.

But it will not Change the issue in General. In our case, the only practicle was is doing a database dump.

In general, @Alexis Robert, thank you very much for your contribution and support!

Welcome!

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

Quick Links

Find more posts tagged with

confluence

server

confluence-server

apache

tomcat

backup