Backups

A backup is a tar of the server's data directory piped through zstd, produced by the agent on your node. The panel persists a row immediately with status CREATING, dispatches the backup.create order, and flips the row to READY (with its size) or FAILED when the agent finishes. Archives are written next to the data directory at /var/mcdata/backups/<backup-id>.tar.zst so they survive deleting the server's container.

GET    /api/servers/:id/backups                 list
POST   /api/servers/:id/backups        { name }  create (async)
POST   /api/servers/:id/backups/:bid/restore     restore
DELETE /api/servers/:id/backups/:bid             delete

Owners and admins have full access; a subuser needs the BACKUPS_MANAGE permission.

Restore refuses to run while the server is RUNNING — restoring over a live world corrupts data. Stop the server first. The agent wipes the data directory's contents and unpacks the archive in place, then the row returns to READY.

Add a BACKUP task to a schedule to snapshot automatically. The task payload is the backup name and supports a {date} placeholder, e.g. nightly-{date}. Scheduled backups run through the same lifecycle as manual ones.

The archive lives on your own VPS, so your provider's volume snapshots or your own restic / rsnapshot routine still apply if you want off-box copies. Flush the world first (save-all flush via the live console) for a consistent snapshot of a running Minecraft server.