borg will by default create its cache directory in ~/.cache/borg. This
means that during backup runs, borg will read and write quite
extensively from/to this directory.
In some situations, it is rather undesirable to have this amount of IO
activity in this location and it would make sense to tell borg to place
its cache elsewhere. This can help for example with placing the cache on
a hard drive where the added IO load will not have as big of an impact
on other running activity for the system.
This change also makes sure that the cache directory environment
variable is cleared out when the configuration option is unset. This
should avoid unpleasant surprises when this environment variable is set
to some unknown value in the context where backupninja is called, which
could lead to borg reading and writing to random places on the system.
This allows the handler to fully make use of the advanced command-line
options for "borg create", such as the replaced "exclude*" options and
others like "--read-special" and "--numeric-owner".
The effect of "keep*" options is not straightforward to understand, so
replacing it with a simpler "keep" option, which replicates the
functionality of other backupninja handlers. This also simplifies the
helper, as the use is then only asked how many days of backups to keep.
At the same time, we add "prune_options" which allows for the use of the
"keep*" options as well as other useful prune options, like "--prefix".
The format option of pg_dump enables tar and custom archive file formats in
addition to the default plain-text file containing SQL commands.
When either the tar or custom format are selected the behaviour of database=all is changed to no longer dump a single file via pg_dumpall. Instead pg_dumpall
is called once to export the "global" data (roles & tablespaces) and then
pg_dump is called once for each non-template table in the database.
To support the GZIP and GZIP_OPTS variables in backupninja and to give the
default --rsyncable gzip compression flag a chance at working on a PostgreSQL
backup, the custom output is forced to not use compression. Instead compression
is done via a pipe to gzip. Hopefully this benefits rsync and rdiff-backup
style backups for reduced backup and storage costs that outweigh the
restoration ones.
