itzg / itzg/docker-mc-backup

Feature request: invoke extra commands before/after backup

Open
#68 4 comments 1 reaction 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Shell
Stars
538
Forks
69
Avg merge
3h 28m
Merged PRs (30d)
2

Description

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.

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by locating the backup lifecycle and its existing configuration entry points. Compare the requested COMMANDS_BEFORE_BACKUP and COMMANDS_AFTER_BACKUP settings with the proposed /etc/before-backup.sh and /etc/after-backup.sh mounts, including support for multiple commands. Done means administrators can reliably run custom actions before and after backups for notifications and server control.

Written by the indexing model from the issue text.

Assessment

Tech stack
docker, shell
Domain
devops
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.