docker-mc-backup icon indicating copy to clipboard operation
docker-mc-backup copied to clipboard

Feature request: invoke extra commands before/after backup

Open wlritchi opened this issue 3 years ago • 3 comments

As an administrator of a Minecraft server, I would like to be able to specify custom RCON commands to run before and after a backup. I would like to use this in production to provide backup status notifications to operators. I also would like to use this on a force-upgrade migration cronjob[1], to stop the Minecraft server after the backup completes.

I imagine that admins may want to be able to run more than one command at each step. I can see two ways to implement this:

  1. Accept COMMANDS_BEFORE_BACKUP and COMMANDS_AFTER_BACKUP as env vars, parse them slightly (e.g. split on ;), and pass the commands along. This is perhaps a little bit underpowered and might lead to frustration around escaping if users want to run commands that contain our chosen separator.
  2. Allow Docker mounts to provide e.g. /etc/before-backup.sh and /etc/after-backup.sh which, if present, will be sourced at the appropriate time. This gives administrators more control, but it's potentially overpowered for this use case.

Thoughts on either of these, or another alternative that meets my use cases?


[1] Why I'm doing this: I have a world save from a previous version which I'm aiming to migrate to 1.18. While I'm testing the migration, I'm running a cronjob after each backup from the original server, which loads that backup in a temporary 1.18 server with --forceUpgrade. The migrated world is then backed up, and loaded into the final 1.18 testing server. This allows me to run the upgrade process on a separate node, without downtime on the testing server.

wlritchi avatar Feb 22 '22 16:02 wlritchi

Great feature idea! I'm leaning towards option 1 with newlines as the separator to alleviate the escape character issue.

itzg avatar Feb 23 '22 02:02 itzg

This might also be a way to solve #80.

jcotton42 avatar May 14 '22 16:05 jcotton42

Also, it would probably be a good idea to somehow communicate whether or not the backup went through to the commands, as well other state like the exit code from the backup program. Since you're leaning towards number 2, maybe set and export an env var that they could read?

I'm going to take a shot at PR'ing this, since I'll have a use for it.

jcotton42 avatar May 15 '22 04:05 jcotton42