I think I'm stupid Honestly I'm sorry I used that much of your time because I haven't thought about my exclude_patterns Seems like they excluded the paths i tried with tmpfs - after removing the…
The named pipe is in the path you named (/run/user/0/./borgmatic/postgresql_databases I set it to /root/borgmatic and backup worked just fine and the Postgres Backup is in this path…
- It looks like Borg is reading files from, among other places,
/run/user/0/./borgmatic/postgresql_databases. But I wonder if thepg_dumpcommand is actually writing to a named pipe there.…
hey, i'm more than happy to help if a developer is this nice - unfortunately that's not my usual experience ;)
So I'm pretty sure there is the issue. The postgres backup gets no return code…
Had to go back more versions than i thought i needed to. It happens since 1.9.0 and with 1.8.14 it worked without issues So I'm not exactly sure if its the same issue as the issue creator has -…
After some retries i could reproduce borgmatic running fine when borg returns code 100 because of a file which was changed throughout the backup Which is kinda funny since it's kind of an…
Traceback (most recent call last):
File "/usr/bin/borgmatic", line 8, in <module>
sys.exit(main())
^^^^^^
File "/usr/lib/python3.12/site-packages/borgmatic/commands/bo…
It's using /run/user/0 as a runtime directory
The runtime directory is still existing when it hangs. After ctrl-c the runtime directory continues to exist (including the named pipe)
ll…
Just another update - i have this issue only when borg itself exits with return code 0 when creating a backup I just got an return code 100 (because a file changed during the backup) from borg…
SSH command line: ['ssh', 'XXX@XXXX', 'XXX/borg', 'serve', '--debug']
Remote: using builtin fallback logging configuration
Remote: 33 self tests completed in 0.51 seconds
Remote: using…
That would be one possible solution.
I've got another idea but please take it as something from someone without knowledge of borg itself.
Would it be possible to append to an existing…
For everything in /etc/systemd/system/ i'd expect the symlink to be backed up. Same for the /var/lib/machines/XXX/etc/systemd/system/ because that's the default location for systmed-nspawn…
Looks pretty good - "pretty" because the file exclusion triggered for a masked systemd service file in my nspawn container
ssh://XXX/./backups: Excluding special files to prevent Borg from…