I’m another user that would like to be able to disable compression on backups. It wastes space on my backup systems which have deduplication + compression built-in. I’m using Attic (Borg is a fork of Attic), and also my own rsnapshot-like implementation on btrfs.
When the backup job runs, I assume it does this?..
- Creates a temp folder
- Puts dump.sql, meta.json and the images etc into the temp folder
- Create the tarball from the temp folder
- Deletes the temp folder
Is this correct, or does it work differently?
If this is how it’s done, what is the path to this temp folder?
If that’s the case, then I could have my backup systems access that temp folder directly for the latest backup content (and just ignore the tarball altogether). I guess this would mean having rsync connect to the docker app filesystem rather than the host OS?
To allow us to do this, the only change to Discourse would be that instead of the temp folder being deleted immediately after the tarball is created, that either of the following happens instead:
- delete yesterday’s backup temp folder as the first step of today’s backup job - this means the temp files are left in place for 24 hours for me to rsync
- or maybe the temp folder it doesn’t need to be deleted at all? The new backup job would just overwrite old files in the temp folder? Maybe not a good idea if images are deleted?
In either of the scenarios above, it would make sense for the temp folder to be a fixed path, rather than one that contains date/time.