PRE and POST commands in docker labels

[zsuatem]

It would be useful to add declaration of PRE and POST commands in docker labels similarly to what Traefik does.
This would allow easier execution of commands like docker exec nextcloud-postgres pg_dumpall -U nextcloud -f /data/nextcloud.sql without editing Resticker configuration.

[zoispag]

In this case resticker would need access to docker.sock (mount), to be able to inspect the containers for certain labels and run the hooks inside other containers. I would think this to be outside of the scope of resticker, but let's hear from @djmaze.

[zsuatem]

This is true but now if you want to run these commands on a host you mount docker.sock.

From the Readme Execute commands prior to backup

It's possible to optionally execute commands (like database dumps, or stopping a running container to avoid inconsistent backup data) before the actual backup starts. If you want to execute commands on the host, mount the Docker socket to the container."

[djmaze]

I was never and I still not am a fan of mounting the docker socket into containers. It should be a rare exception do this IMHO. Also, I think this feature would raise the complexibility of this tool quite a bit.

I was just thinking of having a mechanism which works outside the restic container. As I am also a fan of microservices, I imagine a separate and generic service / container:

1. The new service has the docker socket mounted and acts has a webhook listener.
2. If you POST to /after-backup, it searches for containers with the after-backup.command label and then executes the command in that container.
3. The service could also offer running a docker swarm job instead in order to work in swarm (multi-host) configurations.

So in Resticker's POST_COMMAND, you would just have something like curl -X POST http://webhook-service/after-backup.

[zoispag]

I was also thinking about the complexity of restiker inspecting all running containers, scanning for labels and it feels a bit out of scope. But a webhook sidecar that can talk to other containers is actually brilliant! 👏🏼

[smainz]

I do not know how you are using the PRE and POST hooks, but my usage look like:

     TZ: Europe/Berlin
      PRE_COMMANDS: |-
        docker stop app db
      POST_COMMANDS_EXIT: |-
        docker start db app
    networks:
      intern:
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock

which makes it a universal backup tool for any container.

And yes, I am using my own, slightly enhanced version of resticer

[djmaze]

I am using only POST commands, and only for signaling success or failure to a healthchecks instance so I know the backups are working.

Stopping a database in order to backup its filesystem data is the wrong way in my opinion. It should not be necessary to stop an app in order to back it up.

If you are using something like MariaDB or Postgres, you should instead have a separate container which takes a normal sql dump of the database and puts it in a volume which resticker can backup. Then you just need to make sure the sql dump container is run via a cron schedule before resticker does the backup.

Personally, as I am using Docker Swarm instead of only Compose, I am using swarm-cronjob in order to schedule those jobs. I also recently built a container which does an (encrypted) dump of a postgres database as an example.

Well, of course you could also use the PRE_COMMANDS in order to run such a container which does the sql dump.

[smainz]

I need to guarante that the backups taken are from a 100% consistent state. How do you do this is an application which has multiple storage backends, which need to be in sync?
In this case it is files (blocks thereof) in a file system and the meta data in the database.

[djmaze]

Okay, if you have that strict consistency guarantees, then your approach might actually be the sanest one.

Another approach might be to spawn two cron jobs at the same time, one doing the db dump and one doing a filesystem snapshot. Or just do this in one script which is run as a cron job before the backup.

Of course, I do not know your specifics, so this might not be possible at all in your case.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.