offen
v3 breaking changes
This issue exists to track possible breaking changes that would make sense in a v3 (so I don't forget about them). This does not mean a v3 is going to happen soon. It could even be it never happens.
Remove EMAIL_* config
As all notifications are now sent using shoutrrr, the EMAIL_* interface is obsolete and should be removed.
- [ ] Remove configuration shim
- [ ] Remove documentation
Remove BACKUP_FROM_SNAPSHOT
The functionality of BACKUP_FROM_SNAPSHOT can be achieved by using and exec-pre and exec-post command.
- [ ] Remove feature
- [ ] Remove documentation
Default to expanding variables in BACKUP_FILENAME
The option to do this has been introduced later on and false was chosen as a default in order to not introduce a breaking change. true would be the better and more helpful default.
- [ ] Set default to
true - [ ] Update documentation
Also consider doing this for all other configuration values.
Rename BACKUP_SOURCES
BACKUP_SOURCES points to a single location. It should be called BACKUP_SOURCE (just like BACKUP_ARCHIVE).
- [ ] Rename to
BACKUP_SOURCE - [ ] Update documentation
Remove exec-[pre|post] labels
The labels have more granularity now.
- [ ] Remove all handling of
exec-preandexec-post - [ ] Update documentation
Remove BACKUP_STOP_CONTAINER_LABEL
The BACKUP_STOP_CONTAINER_LABEL setting has been renamed: https://offen.github.io/docker-volume-backup/how-tos/replace-deprecated-backup-stop-container-label.html
- [ ] Remove setting
- [ ] Remove documentation
Derive BACKUP_PRUNING_PREFIX from BACKUP_FILENAME if not set otherwise
As discussed here https://github.com/offen/docker-volume-backup/issues/541#issuecomment-2689175474
consider rclone as a universal backend per #65? Ideally combinable with multiple sources and multiple schedules.
Ideally combinable with multiple sources and multiple schedules.
Could you elaborate on how this would be different from what is already possible?
I don't use the config file directory so I didn't know how it works but after looking at it I think it should combine just fine if every environment variable can be set individually for each run. The only difference would be another var with a list of rclone remote:folder targets to upload to. I'd also like a var that controls syncing all archives or just the symlinked latest one (I have a space constrained VPS that I sync just my latest to).
It would also be nice if the backup executable was able to be called multiple time in parallel to allow the same cron expression in multiple config files. Or maybe have backup configs leave out the cron expression and then have separate schedule configs, each with a cron expression and a list of backup configs to run sequentially. That might complicate setting up the container too much.
It would also be nice if the backup executable was able to be called multiple time in parallel
As the packaging format of this tool is a Docker image, I'm not entirely sure if getting rid of the exclusive lock (which probably is possible, albeit makes things more complicated) is worth it. If you really need to, you could still spawn multiple containers from that image which run in parallel just fine.
If the backup command were to be unboxed and distributed as a binary, other constraints would apply here, but up until then I feel it's ok to keep the lock and the simplicity it brings.
What is it that requires the lock? Or, instead of refactoring to not require a lock, could you check the lock in a loop until some timeout, to support identical cron expressions?
The lock is there for two reasons mostly:
- making sure certain filesystem paths are available for exclusive use by the script (this is what could be refactored)
- making sure the behavior around starting/stopping/inspecting Docker containers is predictable (this is mostly there to reduce confusion in users)
I think your idea of waiting for the lock to become available instead of failing hard is a pretty good one though, so that should be a workable solution that allows reuse of cron schedules while still meeting above requirements.
I added support for identical cron expressions in https://github.com/offen/docker-volume-backup/pull/87 - I'll have another look at this myself tomorrow or so, but in case you have any feedback on that @rpatel3001 feel free to chime in.
Support for identical and overlapping cron schedules in now supported in v2.15.0