Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
At Bareos we use dbconfig to setup, configure, and also process db
schema upgrade when Major version of Bareos are installed.

But quite a number of our user have very very large database, hundreds
of GB even TB, and dumping locally into an hardcoded place a file has often
lead to get / or /var partition full.

We have done all kind of research about the parameter
`dbc_config_allow_backup` as state in documenation, but without success.

   * What exactly did you do (or not do) that was effective (or
     ineffective)?

As documented we place dbc_config_allow_backup='' into
/etc/dbconfig-common/config and try the package upgrade.

The backup dump is created in /var/cache/dbconfig-common/backups

We also tried using ENV var dbc_backup='false' but it look like this one
is always reset to true in code with the $RET

   * What was the outcome of this action?

We really want to allow the usage of dbconfig with Bareos to most of
user and allow to skip db dump during package upgrade.

   * What outcome did you expect instead?

Db upgrade nicely handled, but not backup created.

ps: To be considered at the same time use a configurable place instead
of hardcoded path in the backup part

dbc_config_backup_path='/var/cache/dbconfig-common/backups' by default
having this variable can mitigate the case, as user would be able to
indicate a location able to able the dump.

fix doc and usage by standarizing dbc_config_allow_backup to be
dbc_config_allow_backup='false' and inside the code compared to true

if [ $dbc_config_allow_backup = 'true' ] ... a bit more same way as
other variables.

Thanks for you attention.
reference for bareos debian scripts https://github.com/bareos/bareos/debian

*** End of the template - remove these template lines ***

Hi,


This variable isn't about making backups, but backing up in the debconf
state machine. I think you're looking for a new feature, but at the same
time that what you are looking can be achieved by pre-seeding the
bareos/upgrade-backup debconf question.


Indeed, it's the variable that holds the answer from the debconf
question I referred to above, which is given by the system
administrator. However, the question is asked with low priority, so by
default most admins don't see the question and provide the default answer.
A kind request: please don't file two bugs in one bug report.


Can you please suggest some text that improves the documentation? Maybe
add the word "debconf" before "state machine"?

Paul

On jeudi, 22 janvier 2026 18.56:56 h heure normale d’Europe centrale Paul Gevers wrote:

HI Paul, thanks for your time and remarks, this help on our side, how we want
to achieved our goals.

Ok people like me and some colleague where not up to date on the whole
debconf/dbconfig universe and get mislead be the man page.
You're absolutely right, with the help of our deb guru, we have been able to
figure out how to do this, by simply explaining (in our documentation) how to
disable it.

```
echo "bareos-database-common bareos-database-common/upgrade-backup boolean
false" | debconf-set-selections -v
```

Will simply do the trick.

;-) was a suggestion, and if you find the idea to be useful I will simply open
a new one, but if it has now chance to be fixed, then it can stay like it is.

Thanks for your proposal, adding the "debconf" would at least for myself ring
a bell that's not concerning the module but the global state.

I'm not too confident in myself and my limited knowledge of the debconf system
doesn't allow me to propose something that would make the sentence more easier
to understand even with a quick look.

But still the non empty is a bit wired compared how to all the other variables
are used ('true', 'false') might be a "ancient time" way of life ;-)

Hello Paul,

just for your information:
for our project we worked around this by following
https://github.com/bareos/bareos/pull/2506

So from our side, this bug can be considered closed.

Regards,
Jörg