Add prune support using a separate service and cron schedule

[djmaze]

closes #22

[zoispag]

Thanks for working on this! :)

Question: Is there a fundamental issue with starting a second go-cron process for pruning? I was thinking, if PRUNE_CRON is provided, then a separate process would run inside the same container, to handle the pruning, in a different schedule, whereas the main PID will always be responsible for performing the backups.

[djmaze]

@zoispag There are several points to this:

1. Of course it is possible to spawn a second go-cron instance in the background for the prune job. This prevents proper process management and container termination handling by Docker, as the second instance is not waited for by its parent process. This is a minor issue though which probably does not lead to problems in practice. Also, the output of both jobs is now tangled up.
2. The prune process needs a huge amount of memory, so it makes sense to run it on a different node with enough resources. You can also set different resource limits for this container (either using compose v3 limits in swarm mode or compose v2 limits for non-swarm mode with docker compose).
3. When using Docker swarm mode (as I am doing), the backup container has to be run all nodes while the prune process only needs to be run on one. That node, as said above, should have enough resources for the prune process. It can be selected effectively by setting (memory) resource reservations on the service.

If you don't have big issues with that approach, I prefer to keep this as two separate containers / services.

EDIT: If you don't like the duplication of the env variables, you can use the env_file setting in the compose file.

[zoispag]

I am not using swarm, but I can see the reasoning behind. I am also aware that restic prune utilizes way too many resources. In my setup, I am using docker-compose, and for some of the combination of services (for example x.test and x.prod), I am using the same s3 bucket as a repo. Thus, I have to add a new container in docker-compose.override.yml for one of these combinations. The other approach would allow me to specify only the PRUNE_CRON as an ENV variable in docker-compose.override.yml. But I agree, not much of a hassle, since I still have to do something either way.

If you don't like the duplication of the env variables, you can use the env_file setting in the compose file.

Of course, there are no ENV variables in the compose file. The docker-compose.yml itself, is shared across more than 80 servers, which are happily backed up using resticker 😄