Backing Up a Minecraft Stack from a Remote Server

Introduction

If you run Minecraft Java and Bedrock servers on a remote host (e.g. a cloud VM) via Docker, you’ll want a local backup of world data, config, and mods so you can restore later. This article walks through a simple approach: stop the containers, create a tarball on the remote host (excluding large or recreatable paths), download it, and save your compose and service files.

The same idea works for any Docker-based Minecraft setup — itzg/minecraft-server (Java) and itzg/minecraft-bedrock-server (Bedrock), with data on bind mounts or volumes.

What We’re Backing Up

• World / level data — world/, plus any extra world folders you care about (e.g. world-backup-survival).
• Config — config/, server.properties, ops.json, whitelist.json, eula.txt, etc.
• Mods — mods/ (including Bedrock’s nested setup when it lives under the Java tree).
• Compose and service files — So you can bring the stack back up elsewhere.

What to Exclude

To keep the backup smaller and avoid redundant or recreatable data:

Exclude	Reason
versions/	Java/Forge versions; the image or installer can re-download them.
libraries/	JARs and deps; same as above.
crash-reports/	Debug-only; not needed for restore.
logs/	Optional; usually skip for backups.
defaultconfigs/	Regenerated from mods.
configureddefaults/	Same.
world-old-*	Old world snapshots; keep only what you need.
world-backup-*.tar.gz	Compressed backups; omit if you already have world/ and other dirs.

You can adjust the list (e.g. keep some world-backup-* dirs) depending on what you want to restore.

Prerequisites

• SSH access to the remote host (key-based preferred).
• tar, gzip, Docker (and Docker Compose) on the remote host.
• Enough local disk space for the tarball (often hundreds of MB to a couple GB, depending on worlds and mods).

Step 1: Discover the Stack

Find containers, compose files, and data paths:

# Containers
ssh REMOTE_HOST "docker ps -a --format '{{.Names}}\t{{.Image}}'"

# Bind mounts / volumes
ssh REMOTE_HOST "docker inspect CONTAINER_NAME --format '{{json .Mounts}}'"

Typical layout:

• Java: e.g. /data/minecraft-java → container /data.
• Bedrock: sometimes under the Java tree, e.g. .../mods/minecraft-bedrock-docker/data → container /data.

Note your compose paths (e.g. ~/minecraft-java-docker-compose.yml) and any systemd units.

Step 2: Stop the Containers

Stop Java and Bedrock so the backup is consistent:

ssh REMOTE_HOST "docker stop minecraft-bedrock-server 2>/dev/null || true"
ssh REMOTE_HOST "docker stop minecraftjava-mc-1 2>/dev/null || true"

Use your actual container names. Ignore “not running” if some are already stopped.

Step 3: Create a Tarball on the Remote Host

From the remote host, create a gzipped tarball of the Minecraft data directory, with exclusions:

# On remote (or via ssh REMOTE_HOST "bash -s" << 'REMOTE')
cd /data
tar czf /tmp/minecraft-backup-$(date +%Y%m%d-%H%M%S).tar.gz \
  --exclude='minecraft-java/versions' \
  --exclude='minecraft-java/libraries' \
  --exclude='minecraft-java/crash-reports' \
  --exclude='minecraft-java/logs' \
  --exclude='minecraft-java/defaultconfigs' \
  --exclude='minecraft-java/configureddefaults' \
  --exclude='minecraft-java/world-old-*' \
  --exclude='minecraft-java/world-backup-*.tar.gz' \
  -C /data minecraft-java

Replace minecraft-java with your top-level folder if different. The archive will contain that folder (e.g. minecraft-java/world/, minecraft-java/config/, …).

Step 4: Download the Tarball and Config Files

From your local machine:

# Download tarball (adjust paths and names)
scp REMOTE_HOST:/tmp/minecraft-backup-YYYYMMDD-HHMMSS.tar.gz ./minecraft-backup/

# Compose and service files
scp REMOTE_HOST:~/minecraft-java-docker-compose.yml ./minecraft-backup/
ssh REMOTE_HOST "cat /data/minecraft-java/mods/minecraft-bedrock-docker/docker-compose.yml" > ./minecraft-backup/minecraft-bedrock-docker-compose.yml
scp REMOTE_HOST:~/minecraft-bedrock-docker.service ./minecraft-backup/  # if you use it

Use your SSH config (e.g. Host REMOTE_HOST) or user@host and -i your_key as needed.

Step 5: Clean Up and Restart

Remove the remote tarball and bring the servers back up:

ssh REMOTE_HOST "rm -f /tmp/minecraft-backup-*.tar.gz"
ssh REMOTE_HOST "cd /data/minecraft-java/mods/minecraft-bedrock-docker && docker compose up -d"
# Start Java too if you use compose:
# ssh REMOTE_HOST "docker compose -f ~/minecraft-java-docker-compose.yml up -d"

Restoring Later

1. Extract the tarball on the target host:mkdir -p /data tar xzvf minecraft-backup-*.tar.gz -C /data
2. Java: Adjust minecraft-java-docker-compose.yml if paths differ (e.g. volume mount /data/minecraft-java:/data). Then:docker compose -f minecraft-java-docker-compose.yml up -d
3. Bedrock: If it lives under the Java tree:cd /data/minecraft-java/mods/minecraft-bedrock-docker docker compose up -d

Bedrock often uses network_mode: host; Java typically publishes port 25565 (or another host port).

Sanitizing Before Sharing

If you publish a blog post or scripts:

• Don’t include IPs, hostnames, usernames, or paths that identify your setup.
• Do use placeholders like REMOTE_HOST, your_key, /data/minecraft-java.
• Compose: Redact OPS, LEVEL_SEED, and any tokens. Use e.g. OPS=OP1,OP2 in examples.
• RESTORE / docs: Strip references to your SSH user, key file, or specific server.

Keep the logic (excludes, tar, scp, restart) and replace anything that could identify you or your infrastructure.

Summary

• Stop Java + Bedrock containers.
• Create a tar.gz of the Minecraft data dir on the remote host, excluding versions, libraries, logs, and optional backups.
• Download the tarball and compose/service files locally.
• Restart the stack on the remote host.
• Restore by extracting the tarball and bringing up the compose files on the target machine.

You’ll have a portable backup of worlds, config, and mods suitable for restore or migration, without storing unnecessary or sensitive data.