v3 breaking changes about docker-volume-backup HOT 9 OPEN

consider rclone as a universal backend per #65? Ideally combinable with multiple sources and multiple schedules.

from docker-volume-backup.

Support for identical and overlapping cron schedules in now supported in v2.15.0

from docker-volume-backup.

Ideally combinable with multiple sources and multiple schedules.

Could you elaborate on how this would be different from what is already possible?

from docker-volume-backup.

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.

from docker-volume-backup.

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.

from docker-volume-backup.

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?

from docker-volume-backup.

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.

from docker-volume-backup.

I added support for identical cron expressions in #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.

from docker-volume-backup.

looks good to me

from docker-volume-backup.