Better Pruning

[Drallas]

I like this straightforward solution to backup my Docker Volumes.

Unfortunately "The mechanism used for pruning old backups is not very sophisticated" some kind of Policy based pruning would be nice.

Any thoughts on if it's possible / doable to implement something like this?

[m90]

It's definitely possible to implement a more sophisticated mechanism, however I don't think I will work on it myself for the following reasons:

• I don't need it for my personal use of this image
• it's a tricky feature to implement (how does the API look like and how does this work against different storage backends) and making mistakes here can have very grave consequences (backups being deleted inadvertently)

That being said in case anyone else wants to pick this up and implement something like this, I am open for discussion.

---

On a side note, another possible approach would be using post-exec hooks for triggering something like rotate-backups or similar. I never tried this though, but I think it could work.

[Drallas]

Thanks for tagging this as an enhancement, i would like to help, but it's a bit outside my comfort zone (zero Golang experience) to take this one on by myself.

I agree that it might be a tricky feature to implement, but perhaps the Restic
Forget and Prune files provide some inspiration for someone to get this started!

Btw: My initial idea was to back up to local storage and then use Restic or Rclone scripts as some kind of (post-exec 'hook') to move the file's to B2. But it's much cleaner to have all the backup logic in the docker-compose files. Just one drawback, "unsophisticated" pruning! 😞

[simboel]

As a workaround you could execute multiple instances of this tool with different backup-filenames / prefixes. This way you could replicate some of the behaviour (like monthly backups for the last 6 years & daily backups for the last 2 months & hourly backups for the last 2 days).

This can even be done with docker-compose "overrides" (docker-compose.yml -f base.yml -f monthly.yml) where the base config is in base.yml (like GPG and S3 bucket name etc.) and monthly containing the CRON and the prefix / filename and retention configuration.

Maybe this could be added as a recipe to the README?

[m90]

As a workaround you could execute multiple instances of this tool with different backup-filenames / prefixes.

This is a great suggestion, thank you very much. Also note that you wouldn't even need to use multiple instances but could also mount multiple configuration files for each schedule as described here: https://github.com/offen/docker-volume-backup#run-multiple-backup-schedules-in-the-same-container

[m90]

I added a section on this to the README: https://github.com/offen/docker-volume-backup#define-different-retention-schedules

[m90]

This is still relevant, even if it's just for explaining the workaround.

[MaxJa4]

Maybe adding a parameter like BACKUP_RETENTION_AMOUNT (to stay similar with _RETENTION_DAYS) or BAKCUP_KEEP_LAST_N which works like "keep N newest backups and prune everything else" which would be an alternative option to the time/age based pruning.