Dear Maintainer,

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

   * What led up to the situation?

Recently the package was upgraded to 2.3-1.

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

I didn't change my configuration after the upgrade. And even after using the new configuration, the backups failed when the systemd service was used.

   * What was the outcome of this action?

I received an email that the backups failed.
----8<-----
*Errors/Warnings* (below) reported during backup on *juilin.aybara.org:
(socket)*:

  | pg_dump: error: could not close output file: Broken pipe
  | Running (as user 'postgres' command 'pg_dump 'postgres' --port 5432
--username postgres --create' has failed                                        
  | Something went wrong
'/home/backups/pgsql/daily/postgres/postgres_2025-02-21_12h22m.sql.gz' does not
exists (error during dump?)
  | pg_dump: error: could not close output file: Broken pipe
  | Running (as user 'postgres' command 'pg_dump 'template1' --port 5432
--username postgres --create' has failed                                        
  | Something went wrong
'/home/backups/pgsql/daily/template1/template1_2025-02-21_12h22m.sql.gz' does
not exists (error during dump?)
  | pg_dump: error: could not write to output file: Broken pipe
  | Running (as user 'postgres' command 'pg_dump 'ttrss' --port 5432 --username
postgres --create' has failed
  | Something went wrong
'/home/backups/pgsql/daily/ttrss/ttrss_2025-02-21_12h22m.sql.gz' does not exists
(error during dump?)
  | Something went wrong
'/home/backups/pgsql/daily/postgres_globals/postgres_globals_2025-02-21_12h22m.s
ql.gz' does not exists (error during dump?)

Full backup log follows:

  *info*| AutoPostgreSQLBackup version 2.3
  *info*| Homepage: https://github.com/k0lter/autopostgresqlbackup
  *info*| Backup of Database Server (postgresql) - juilin.aybara.org: (socket)
  *info*| Backup Start: Fri Feb 21 12:22:07 PM CET 2025
  *info*| Backup of Database (daily) 'postgres'
  *info*| Rotating 14 daily backups...
 *error*| pg_dump: error: could not close output file: Broken pipe
 *error*| Running (as user 'postgres' command 'pg_dump 'postgres' --port 5432
--username postgres --create' has failed                                        
 *error*| Something went wrong
'/home/backups/pgsql/daily/postgres/postgres_2025-02-21_12h22m.sql.gz' does not
exists (error during dump?)
  *info*| Backup of Database (daily) 'template1'
  *info*| Rotating 14 daily backups...
 *error*| pg_dump: error: could not close output file: Broken pipe
 *error*| Running (as user 'postgres' command 'pg_dump 'template1' --port 5432
--username postgres --create' has failed                                        
 *error*| Something went wrong
'/home/backups/pgsql/daily/template1/template1_2025-02-21_12h22m.sql.gz' does
not exists (error during dump?)
  *info*| Backup of Database (daily) 'ttrss'
  *info*| Rotating 14 daily backups...
 *error*| pg_dump: error: could not write to output file: Broken pipe
 *error*| Running (as user 'postgres' command 'pg_dump 'ttrss' --port 5432
--username postgres --create' has failed                                        
 *error*| Something went wrong
'/home/backups/pgsql/daily/ttrss/ttrss_2025-02-21_12h22m.sql.gz' does not exists
(error during dump?)
  *info*| Backup of Database (daily) 'postgres_globals'
  *info*| Rotating 14 daily backups...
 *error*| Something went wrong
'/home/backups/pgsql/daily/postgres_globals/postgres_globals_2025-02-21_12h22m.s
ql.gz' does not exists (error during dump?)
  *info*| Backup End: Fri Feb 21 12:22:16 PM CET 2025
  *info*| Total disk space used for /home/backups/pgsql:

For more information, try to run AutoPostgreSQLBackup in debug mode, see
`autopostgresqlbackup -h`
----8<-----

   * What outcome did you expect instead?

Normal working backups for all my postgresql databases.

When I do a manual run of /usr/sbin/autopostgresqlbackup, it does create backups that I expect.

----8<-----
root@juilin:/home/backups/pgsql# ls -ltr daily/ttrss/
total 859832
-rw------- 1 root root 109707606 Feb 12 06:25 ttrss_2025-02-12_06h25m.Wednesday.sql.gz
-rw------- 1 root root 109782403 Feb 13 06:25 ttrss_2025-02-13_06h25m.Thursday.sql.gz
-rw------- 1 root root 109844040 Feb 14 06:25 ttrss_2025-02-14_06h25m.Friday.sql.gz
-rw------- 1 root root 110039180 Feb 16 06:25 ttrss_2025-02-16_06h25m.Sunday.sql.gz
-rw------- 1 root root 110180948 Feb 17 06:25 ttrss_2025-02-17_06h25m.Monday.sql.gz
-rw------- 1 root root 110248374 Feb 18 06:25 ttrss_2025-02-18_06h25m.Tuesday.sql.gz
-rw------- 1 root root 110312635 Feb 19 08:01 ttrss_2025-02-19_08h00m.sql.gz
-rw------- 1 root root 110314609 Feb 19 08:08 ttrss_2025-02-19_08h07m.sql.gz
root@juilin:/home/backups/pgsql# date; /usr/sbin/autopostgresqlbackup
Fri Feb 21 12:24:17 PM CET 2025
root@juilin:/home/backups/pgsql# ls -ltr daily/ttrss/
total 967776
-rw------- 1 root root 109707606 Feb 12 06:25 ttrss_2025-02-12_06h25m.Wednesday.sql.gz
-rw------- 1 root root 109782403 Feb 13 06:25 ttrss_2025-02-13_06h25m.Thursday.sql.gz
-rw------- 1 root root 109844040 Feb 14 06:25 ttrss_2025-02-14_06h25m.Friday.sql.gz
-rw------- 1 root root 110039180 Feb 16 06:25 ttrss_2025-02-16_06h25m.Sunday.sql.gz
-rw------- 1 root root 110180948 Feb 17 06:25 ttrss_2025-02-17_06h25m.Monday.sql.gz
-rw------- 1 root root 110248374 Feb 18 06:25 ttrss_2025-02-18_06h25m.Tuesday.sql.gz
-rw------- 1 root root 110312635 Feb 19 08:01 ttrss_2025-02-19_08h00m.sql.gz
-rw------- 1 root root 110314609 Feb 19 08:08 ttrss_2025-02-19_08h07m.sql.gz
-rw------- 1 root root 110529170 Feb 21 12:24 ttrss_2025-02-21_12h24m.sql.gz
root@juilin:/home/backups/pgsql#
----8<-----

Dear Maintainer,

after the upgrade to Debian Trixie, we ran into a different problem
which most likely does have the same underlying reason as the bug
reported in #1098493. In our case, it was a failing POSTBACKUP script.
When looking at the systemd unit which is triggered by the timer, I
noticed the

    ProtectHome=true

line. So this essentially means that /home, /root and /run/user aren't
accessible [1] for autopostgresqlbackup when run as systemd service.
Since our POSTBACKUP script requires something from /root and the
original reporter of #1098493 attempts to write backups to
/home/backups/pgsql, this is likely the culprit. Adding a drop-in using

    systemctl edit autopostgresqlbackup.service

and the following content:

    [Service]
    ProtectHome=read-only

seemed to fix this. Of course, for backups to /home to work, this should
be something like this:

    [Service]
    ProtectHome=false

Or maybe this (likely more secure/safe):

    [Service]
    ProtectHome=tmpfs
    BindPaths=/home/backups/pgsql

I'm not sure about the best solution for this on a package level, using
ProtectHome=true is certainly a good thing from a security and safety
point-of-view, so maybe just documenting this is sufficient given that
autopostgresqlbackup works in the default configuration.

Also note that the issue described in [2] actually might make it harder
to debug this kind of problem since relevant or helpful log messages
might be lost and not end up in the visible logs unless run in debug
mode.


Hope this helps,
Manfred


[1] https://www.freedesktop.org/software/systemd/man/latest/systemd.exec.html?#ProtectHome=
[2] https://github.com/k0lter/autopostgresqlbackup/issues/44