Can't connect to the remote PostgreSQL Bareos Database

48 views
Skip to first unread message

Stefan Harbich

unread,
Mar 27, 2026, 10:37:33 PM (9 days ago) Mar 27
to bareos-users
Hello everyone,
please tell me if accessing the remote PostgreSQL Bareos database also works via SSL?
I'm getting this message:
...
SQL server not running; password incorrect; server requires ssl; max_connections exceeded.
...
I can connect via SSL using "psql". I found the following note in the documentation:

"The PostgreSQL connection must not be an SSL connection. If the PostgreSQL server only allows SSL connections, the database cannot be opened."

This can't be right, can it? Please change this.

Regards, Stefan Harbich

Sebastian Sura

unread,
Mar 31, 2026, 2:48:55 AM (6 days ago) Mar 31
to bareos...@googlegroups.com

Hi Stefan,

we currently do not support bareos interacting with postgres via ssl as this lead to some hard to debug issues.

Kind Regards
Sebastian Sura

Am 28.03.26 um 03:37 schrieb Stefan Harbich:
Regards, Stefan Harbich --
You received this message because you are subscribed to the Google Groups "bareos-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bareos-users...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bareos-users/c5074013-9a66-404f-9013-be5c6f8ddecfn%40googlegroups.com.
-- 
 Sebastian Sura                  sebasti...@bareos.com
 Bareos GmbH & Co. KG            Phone: +49 221 630693-0
 https://www.bareos.com
 Sitz der Gesellschaft: Köln | Amtsgericht Köln: HRA 29646
 Komplementär: Bareos Verwaltungs-GmbH
 Geschäftsführer: Stephan Dühr, Jörg Steffens, Philipp Storz

Stefan Harbich

unread,
Mar 31, 2026, 3:18:54 AM (6 days ago) Mar 31
to bareos-users
Hello Sebastian,

that's a shame. That security is not the top priority in your company.

Greetings from Stefan Harbich

Bruno Friedmann (bruno-at-bareos)

unread,
Mar 31, 2026, 3:24:20 AM (6 days ago) Mar 31
to bareos-users
Well I found the reply a bit harsh. 

You consider that security in encrypting communication is top priority, while we have considered as top priority consistency of your valuable data.

Regards..

Stefan Harbich

unread,
Mar 31, 2026, 3:41:17 AM (6 days ago) Mar 31
to bareos-users
Dear Mr. Friedmann,

i don't understand your answer.
Why is backup encrypted between the Director and all host systems when the consistency of our data is our top priority?
This contradicts your answer.

Kind regards from Stefan Harbich

Bruno Friedmann (bruno-at-bareos)

unread,
Mar 31, 2026, 9:42:58 AM (5 days ago) Mar 31
to bareos-users
We detected (paid customer use case) a problem when connection between dir and catalog are handle over tcp with ssl enabled (making backup recording at risk and can make them inconsistent at restore time).

As the vast majority 98% of user have the director running where the pg catalog is run, we decided the better fix for the momen is to either connect pg by the socket (which is far more efficient) and do not allow ssl tcp connections. This allow the connection to still be used by tcp but uncrypted if not set inside a vpn or other mitigation.

The communication between daemon stay encrypted by default. Only if a remote host is used for the catalog, the connection between the dir and that host needs to be encrypted by another way than the native libpq tcp ssl.

Hope this clarify my previous statement. 

Stefan Harbich

unread,
Mar 31, 2026, 2:39:39 PM (5 days ago) Mar 31
to bareos-users
Hello Mr. Friedmann,

it's a shame you weren't able to resolve the issue with your paying customer. I'm not a fan of having to manage and support dedicated databases for every use case.
But your company isn't alone in this. I'm hearing more and more that many applications are using their own databases, regardless of the effort required from the end user.
That settles it for me. Thank you for your openness.

Regards, Stefan Harbich

Andreas Rogge

unread,
Apr 1, 2026, 10:01:33 AM (4 days ago) Apr 1
to bareos...@googlegroups.com
Hi Stefan,

the underlying problem is that the way we're using libpq is apparently
not 100% thread-safe when used in conjuction with TLS. Right now we
haven't understood where exactly things break. Maybe it is Bareos' fault
or libpq's or OpenSSL's. Maybe it only happens on with specific versions
of these components.
Sadly, things will work fine for weeks until one of the database
connections fails in really strange ways (i.e. "PGError: lost
synchronization with server" after some strange TLS errors are logged).
This then takes one or more (presumably long-running) backup jobs with
it. In the end, we decided to disable TLS on our end.

Having said that, you can still have a TLS encrypted connection to your
database server using PgBouncer or something like that.
Also, feel free to create a PR that adds a configuration setting to
allow (or even require) TLS on the database connection. We will happily
accept a change like that.

Best Regards,
Andreas

--
Andreas Rogge andrea...@bareos.com
Bareos GmbH & Co. KG Phone: +49 221-630693-86
http://www.bareos.com
Reply all
Reply to author
Forward
0 new messages