Lazy restart of multi volume backup

[mmittelb]

Is your feature request related to a problem? Please describe.
I am using this awesome image (thanks by the way) to backup the volumes of my mailserver. Therefore the mailserver is stopped each time a volume is backed up, which results in 6 restarts everyday. Since resarting all the services takes a lot of resources, I would love to keep the server stopped until all backups are finished.

Describe the solution you'd like
Maybe instead of using a lock, one can use a semaphore and restart the services once all the backups finished. To ensure compatibility I would suggest to activate this feature using an env var.

Describe alternatives you've considered
None

Additional context
I am happy to create a PR to solve this. But I wanted to check upfront, if you agree with this feature request before starting to work on it.

[m90]

I think this sounds good definitely and wouldn't want to keep you from working on it. However, maybe we could flesh out how the configuration works beforehand. How would you envision users enabling this feature in setups where a. one container runs multiple schedules and b. multiple containers run one schedule each?

[mmittelb]

Hey Frederik,
sorry for my late reply. Today I will have some time to work on this issue.

One container - multiple schedules:

1. The feature is activated using the ACTIVATE_LAZY_RESTART=1 environmental variable (default is 0).
2. If the lock is already acquired, the waiting task is creating a unique *.waiting file in the lock directory.
3. The first task is stopping the containers and services and serialising the metadata of stopped containers and services to the lock dir.
4. The backup tasks run until the last lock is released (no more .waiting files in the lockdir).
5. The last backup task loads the metadata of stopped containers and services from disk (+ deletes file) and restarts them.

Multiple containers - one schedule:
Same procedure, but lock dir has to be shared (correct me if I'm am wrong, but that is no difference to the current behavior)

[m90]

A few comments:

The feature is activated using the ACTIVATE_LAZY_RESTART=1 environmental variable (default is 0). Also, such features are usually prefixed as BACKUP_, so maybe this should be BACKUP_USE_LAzy_RESTART?

Other values use string false and true, so I guess this should do the same.

The last backup task loads the metadata of stopped containers and services from disk (+ deletes file) and restarts them.

Is there some mechanism that prevents locks that block forever because the supervising process died or did not work as intended?

Same procedure, but lock dir has to be shared (correct me if I'm am wrong, but that is no difference to the current behavior)

Makes sense. It should also be possible to use this for a single container.