Encrypted backups and passwords

[theit]

Hi,

I'm using barman to backup a couple of PostgreSQL servers (versions 15, 17 and 18 actually) from a remote machine. Backing up and restoring them so far works pretty good.

Recently I turned on encrypted backups. By following the documentation I created a new GnuPG key pair and added the following parameters to the server's conf:

• encryption = gpg
• encryption_key_id = ...
• backup_compression = none
• backup_compression_format = tar

IIUC I have to configure "encryption_passphrase_command" to refer to a tool that outputs the necessary password to stdout.
For testing purposes I copied the GnuPG key passphrase into a file "~/.passphrase" and configured

• encryption_passphrase_comman = "cat ~/.passphrase"

Not nice, but at least for testing purposes I'm able to restore such an encrypted backup.

Question:
Is it possible to configure barman to ask the passphrase from the user in the console window? I.e. similar to what pinentry does when interacting with a GnuPG secret key.
I've tried "systemd-ask-password --echo=no -n" as command, but that didn't work.

BTW:
I'm using barman 3.18.0 running on Ubuntu 24.04.4

[martinmarques]

Can you tell us a bit about "how" it was that systemd-ask-password didn't work? Do you have any log errors?

Based on what I've read from the manual of systemd-ask-password it should work without problems.

[theit]

systemd-ask-password in the console itself works (I entered "foo" as test password):

barman@barmanhost:~$ systemd-ask-password --echo=no -n --emoji=no
Password:
foobarman@barmanhost:~$

From within a restore attempt last friday:

barman@barmanhost:date; time PATH=$PATH:/usr/lib/postgresql/15/bin barman restore --remote-ssh-command "ssh postgres@pghost" test_pg15 --target-time "2026-05-15 13:00:00Z" --delta-restore --get-wal auto /var/lib/postgresql/15/main; date
Fri May 15 02:46:39 PM CEST 2026
Starting remote restore for server test_pg15 using backup 20260515T064337
Destination directory: /var/lib/postgresql/15/main
Remote command: ssh postgres@pghost
Doing PITR. Recovery target time: '2026-05-15 13:00:00+00:00'
Copying the base backup.
EXCEPTION: Command failed: {'ret': 1, 'out': '', 'err': 'Failed to query password: Permission denied\n'}
See log file for more details.

real    0m3.584s
user    0m1.511s
sys     0m0.287s
Fri May 15 02:46:42 PM CEST 2026
barman@barmanhost:~$

[theit]

From the log file in /var/log/barman:

(...)
2026-05-15 14:05:23,435 [696851] barman.recovery_executor INFO: Doing PITR. Recovery target time: '2026-05-15 13:00:00+02:00'
2026-05-15 14:05:24,166 [696851] barman.recovery_executor WARNING: Unable to retrieve safe horizon time for smart rsync copy: The /var/lib/postgresql/15/main/.barman-recover.info file does not exist
2026-05-15 14:05:24,170 [696851] barman.recovery_executor INFO: Copying the base backup.
2026-05-15 14:05:24,202 [696851] barman.cli ERROR: Command failed: {'ret': 1, 'out': '', 'err': 'Failed to query password: Permission denied\n'}
See log file for more details.
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/barman/encryption.py", line 71, in get_passphrase_from_command
    out, _ = cmd.get_output()
             ^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/barman/command_wrappers.py", line 336, in get_output
    return self._get_result(*args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/barman/command_wrappers.py", line 425, in _get_result
    self.check_return_value(allowed_retval)
  File "/usr/lib/python3/dist-packages/barman/command_wrappers.py", line 438, in check_return_value
    raise CommandFailedException(dict(ret=self.ret, out=self.out, err=self.err))
barman.exceptions.CommandFailedException: {'ret': 1, 'out': '', 'err': 'Failed to query password: Permission denied\n'}

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/barman/cli.py", line 2900, in main
    args.func(args)
  File "/usr/lib/python3/dist-packages/barman/cli.py", line 1428, in restore
    server.recover(
  File "/usr/lib/python3/dist-packages/barman/server.py", line 2511, in recover
    return self.backup_manager.recover(
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/barman/backup.py", line 1228, in recover
    recovery_info = executor.recover(
                    ^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/barman/recovery_executor.py", line 217, in recover
    self._backup_copy(
  File "/usr/lib/python3/dist-packages/barman/recovery_executor.py", line 3406, in _backup_copy
    backup_info = operation.execute(
                  ^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/barman/recovery_executor.py", line 1892, in execute
    return self._execute(
           ^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/barman/recovery_executor.py", line 2568, in _execute
    return self._execute_on_chain(backup_info, destination, self._decrypt_backup)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/barman/recovery_executor.py", line 1995, in _execute_on_chain
    volatile_backup = method(backup, destination, *args, **kwargs)
                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/barman/recovery_executor.py", line 2625, in _decrypt_backup
    passphrase = get_passphrase_from_command(
                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/barman/encryption.py", line 73, in get_passphrase_from_command
    raise EncryptionCommandException(f"Command failed: {e}") from e
barman.exceptions.EncryptionCommandException: Command failed: {'ret': 1, 'out': '', 'err': 'Failed to query password: Permission denied\n'}
(...)

[martinmarques]

Now I see (and remember how this was implemented). The feature for getting the passphrase happens in a non-interactive subprocess. For this reason, there is no way of getting the password from interaction with the user recovering

[martinmarques]

The main reason, IIRC, for keeping this non-interactive is that the interactive mode would only work when executing the barman recover interactively, meaning from a TTY shell. But you also need to decrypt the WALs, some may be decrypted at that point if user --no-get-wal, but others might need decrypting by non-interactive execution of barman get-wal which comes from barman-wal-restore.

[theit]

@martinmarques I see your point for non-interactive restore.
But in my opinion a restore requires me to enter the corresponding command(s) somewhere in a shell, meaning that I have a TTY session available; at least on the machine where I start the barman restore. In other words: It's not non-interactive...

Wouldn't it be possible to, say, add another command to the configuration file to allow for an interactive restore where I'm able to enter the password?

[theit]

I managed to make it work, but it was a bit tricky:
The following was added to the server's configuration:

encryption_passphrase_command = "systemd-ask-password --echo=no -n --keyname=barman --id=barman/gnupg --accept-cached"

Before starting the restore of an encrypted backup execute the following command:

%> systemd-ask-password --echo=no -n --keyname=barman --id=barman/gnupg --no-output

It's a two-step process, but it works, more or less interactive.

Perhaps worth mentioning in the documentation?