borgmatic-collective/borgmatic

Watch

Fork 57

Postgres Backup stalls since 2.1.7 #1352

New issue

Open

opened 2026-09-16 18:38:43 +00:00 by nachfuellbar · 4 comments

nachfuellbar commented

2026-09-16 18:38:43 +00:00

What I'm trying to do and why

I'm using borgmatic on my arch linux machine and just saw the postgres backup was stalled since 5th september.
I just downgraded to 2.1.6 and now it's working again.
I had another issue where it didn't work since 2.1.6 when i had check active which is why i have skip actions check currently in my config.

Steps to reproduce

Use borgmatic with postgres backup and 2.1.7
Postgres Backup never finishes which is why the whole backup never finishes

Actual behavior

No response

Expected behavior

No response

Other notes / implementation ideas

No response

borgmatic version

2.1.7

borgmatic installation method

Arch Linux Package

Borg version

1.4.5

Python version

3.14.7

Database version (if applicable)

Postgres Server 17.11, Client 18.6

Operating system and version

No response

### What I'm trying to do and why I'm using borgmatic on my arch linux machine and just saw the postgres backup was stalled since 5th september. I just downgraded to 2.1.6 and now it's working again. I had another issue where it didn't work since 2.1.6 when i had check active which is why i have skip actions check currently in my config. ### Steps to reproduce 1) Use borgmatic with postgres backup and 2.1.7 2) Postgres Backup never finishes which is why the whole backup never finishes ### Actual behavior _No response_ ### Expected behavior _No response_ ### Other notes / implementation ideas _No response_ ### borgmatic version 2.1.7 ### borgmatic installation method Arch Linux Package ### Borg version 1.4.5 ### Python version 3.14.7 ### Database version (if applicable) Postgres Server 17.11, Client 18.6 ### Operating system and version _No response_

witten commented

2026-09-16 19:20:29 +00:00

Owner

I don't see anything obvious in the 2.1.7 changelog that might be related to this (either the Postgres issue or the check issue), but it's always possible that some bug crept in.

Can I get a look at your logs when running with --verbosity 2 --files from when you encounter each of these issues with 2.1.7? I'm particularly interested in seeing the last thing logged before the hang, but the entire log would be helpful. Also, can I see your postgresql_databases: configuration?

Thank you!

I don't see anything obvious in the 2.1.7 changelog that might be related to this (either the Postgres issue or the `check` issue), but it's always possible that some bug crept in. Can I get a look at your logs when running with `--verbosity 2 --files` from when you encounter each of these issues with 2.1.7? I'm particularly interested in seeing the last thing logged before the hang, but the entire log would be helpful. Also, can I see your `postgresql_databases:` configuration? Thank you!

nachfuellbar commented

2026-09-16 19:31:58 +00:00

Author

As for the config of postgresql_databases:

postgresql_databases:
    # Database name (required if using this hook). Or "all" to
    # dump all databases on the host. (Also set the "format"
    # to dump each database to a separate file instead of one
    # combined file.) Note that using this database hook
    # implicitly enables read_special (see above) to support
    # dump and restore streaming.
    - name: all

      # Label to identify the database dump in the backup.
      # label: my_backup_label

      # Container name/id to connect to. When specified the
      # hostname is ignored. Requires docker/podman CLI.
      # container: debian_stable

      # Container name/id to restore to. Defaults to the
      # "container" option.
      # restore_container: restore_container

      # Database hostname to connect to. Defaults to connecting
      # via local Unix socket.
      hostname: 192.168.XX.XX

      # Database hostname to restore to. Defaults to the
      # "hostname" option.
      # restore_hostname: database.example.org

      # Port to connect to. Defaults to 5432.
      # port: 5433

      # Port to restore to. Defaults to the "port" option.
      # restore_port: 5433

      # Username with which to connect to the database. Defaults
      # to the username of the current user. You probably want
      # to specify the "postgres" superuser here when the
      # database name is "all". Supports the "{credential ...}"
      # syntax.
      username: XXXX

      # Username with which to restore the database. Defaults to
      # the "username" option. Supports the "{credential ...}"
      # syntax.
      # restore_username: dbuser

      # Password with which to connect to the database. Omitting
      # a password will only work if PostgreSQL is configured to
      # trust the configured username without a password or you
      # create a ~/.pgpass file. Supports the "{credential ...}"
      # syntax.
      password: XXXX

Just remembered the issue with the hang for check only happend in systemd and seems like the postgres backup was successful with 2.1.7 when i used the cli. I'm going to try the part with the verbosity options afterwards when the backup is finished As for the config of postgresql_databases: ``` postgresql_databases: # Database name (required if using this hook). Or "all" to # dump all databases on the host. (Also set the "format" # to dump each database to a separate file instead of one # combined file.) Note that using this database hook # implicitly enables read_special (see above) to support # dump and restore streaming. - name: all # Label to identify the database dump in the backup. # label: my_backup_label # Container name/id to connect to. When specified the # hostname is ignored. Requires docker/podman CLI. # container: debian_stable # Container name/id to restore to. Defaults to the # "container" option. # restore_container: restore_container # Database hostname to connect to. Defaults to connecting # via local Unix socket. hostname: 192.168.XX.XX # Database hostname to restore to. Defaults to the # "hostname" option. # restore_hostname: database.example.org # Port to connect to. Defaults to 5432. # port: 5433 # Port to restore to. Defaults to the "port" option. # restore_port: 5433 # Username with which to connect to the database. Defaults # to the username of the current user. You probably want # to specify the "postgres" superuser here when the # database name is "all". Supports the "{credential ...}" # syntax. username: XXXX # Username with which to restore the database. Defaults to # the "username" option. Supports the "{credential ...}" # syntax. # restore_username: dbuser # Password with which to connect to the database. Omitting # a password will only work if PostgreSQL is configured to # trust the configured username without a password or you # create a ~/.pgpass file. Supports the "{credential ...}" # syntax. password: XXXX ```

nachfuellbar commented

2026-09-16 19:42:04 +00:00

Author

Okay seems like it's working when i try it now - was the package just broken locally?
I'm going to try some more with removing the skip from check, etc
I might want to let it try it's nightly backup too just to be sure.

Okay seems like it's working when i try it now - was the package just broken locally? I'm going to try some more with removing the skip from check, etc I might want to let it try it's nightly backup too just to be sure.

witten commented

2026-09-16 21:29:55 +00:00

Owner

Thanks. Your config looks pretty standard. If the hang only happens when running borgmatic under systemd and not manually via command-line, then the problem is likely that the systemd service is too locked down. To check that, I'd recommend commenting out all security-related options in your systemd service and then reloading your systemd daemon to pick up those changes. That includes everything from LockPersonality on through CapabilityBoundingSet.

If commenting those out "fixes" the problem, then you can try re-introducing security options a few at a time until you find the problem child.

Thanks. Your config looks pretty standard. If the hang only happens when running borgmatic under systemd and *not* manually via command-line, then the problem is likely that the systemd service is too locked down. To check that, I'd recommend commenting out all security-related options in your systemd service and then reloading your systemd daemon to pick up those changes. That includes everything from `LockPersonality` on through `CapabilityBoundingSet`. If commenting those out "fixes" the problem, then you can try re-introducing security options a few at a time until you find the problem child.

witten added the

question / support

label

2026-09-16 21:30:00 +00:00