Snapback

Backups are the easy half. This one does the other half.

Roll your server back to any backup with one command. Free, no dependencies, no upsell.

---

Why another backup plugin

Making archives is a solved problem. Plenty of plugins do it, several of them for free.

Restoring is where it falls apart. A world gets griefed, or a plugin update eats your player data, and now it is midnight and you are stopping the server, hunting for the right zip, unpacking it by hand, hoping you put the folders back exactly where they came from — and hoping harder that you did not miss one.

Snapback does that part for you, and does it at the only moment it can actually work.

The restore, and why it is built this way

While the server is running, a world cannot be restored. The server holds those files open: on Windows you cannot overwrite them at all, and on Linux the next autosave writes the world back out of memory and erases whatever you unpacked. Any plugin that unzips an archive on command is fighting that, and losing quietly.

So the decision and the work are split apart:

1. /backup restore <file> — shows what would happen: how many files, which mode, what you would lose. Changes nothing.
2. /backup restore <file> confirm — archives the current state as before-restore-*.zip, writes a marker, stops the server.
3. You start the server. The restore runs in onLoad — the one point in the plugin lifecycle that happens before the worlds are loaded.
4. /backup restore cancel — changed your mind, marker gone.

What stops a rollback from making things worse

A restore is itself destructive. Each guard exists because of a specific way this goes wrong:

• A safety copy first. Everything after the backup you are restoring is about to disappear. before-restore-*.zip captures the current state and is excluded from keep-last rotation, so a few more backups cannot delete it.
• Plugin jars are not rolled back. Rolling a world back a week almost never means wanting every plugin downgraded a week with it — including this one. Off by default, one setting to enable.
• The backups folder is never touched. Otherwise a restore could delete the archive it is reading from.
• Archive entries are checked for path escapes. A crafted zip containing ../../ cannot write outside your server folder — checked when the archive is inspected, and again while unpacking.
• The marker is only cleared on success. Unpacking the same archive twice is harmless; a forgotten marker on a failed restore is a lost world. An unreadable archive gets the marker renamed, and the server starts on your current files.

Backups

• Scheduled or manual — an interval in minutes, or 0 for /backup run only
• Worlds found automatically — no list of world names to keep in sync
• keep-last — old archives removed automatically
• skip-if-no-activity — no scheduled backup when nobody joined since the last one
• include / exclude — anything else you want, and anything you don't. session.lock, logs and caches are excluded out of the box
• Compression level 0–9
• Chat notifications for anyone holding snapback.notify
• Discord notifications — post to a channel via webhook when a backup completes or fails (optional)

The server is told to flush the world to disk and stop writing before the copy starts, and writing is switched back on afterwards — always, including when the archive fails. Skip that and you get half-written region files in an archive that looks fine until the day you need it.

Packing runs off the main thread, so a large world does not freeze everyone on the server.

Commands

Command	What it does
/backup run	Back up now
/backup list	Archives with size and age
/backup status	Time until the next scheduled backup
/backup restore <file>	Preview a rollback — changes nothing
/backup restore <file> confirm	Safety copy, then stop the server
/backup restore cancel	Cancel a scheduled rollback

Permissions: snapback.use, snapback.notify, snapback.restore — all default to op.

Configuration

restore:

  # Archive the current state before rolling back, as before-restore-*.zip.
  # It is excluded from keep-last rotation.
  safety-copy: true

  # Whether to overwrite plugin jars from the archive.
  # Off by default: by restore time the server has already opened them,
  # and rolling a world back rarely means rolling every plugin back too.
  replace-plugin-jars: false

  # true  - world folders from the archive replace the current ones entirely
  #         (a true rollback)
  # false - files are laid over the current ones; chunks missing from the
  #         backup stay as they are now, leaving a mix of two states
  # Off by default: deleting a world folder cannot be undone.
  clean-worlds: false

Every message is in the config. A Russian translation ships as config-ru.yml and lands next to your config on first start — swap the file, restart, done.

Discord notifications

Snapback can post a message to a Discord channel every time a backup finishes or fails, using a webhook. No bot to invite, no login, no extra server permissions — just a URL.

1. In Discord: open the channel, click the gear icon (Edit Channel) → Integrations → Webhooks → New Webhook → Copy Webhook URL.
2. Open plugins/Snapback/config.yml, find the discord section, set enabled: true and paste the URL into webhook-url.
3. Restart the server, or run /reload confirm.

discord:
  enabled: false
  webhook-url: ""
  notify-success: true
  notify-failure: true

notify-success / notify-failure let you turn off one type of notification if you only care about failures (or only successes). Treat the webhook URL like a password — anyone who has it can post messages to that channel.

Requirements

• Paper (or a Paper fork) — built and tested against 26.2
• Java 25
• No dependencies

What is not in it

• No cloud upload. Local copies only — no S3, Google Drive or FTP. If your disk dies, they die with it. This is the honest limitation, and the main reason to also keep an off-server backup.
• No incremental backups — every archive is a full copy
• No backup of external databases

Why free

Because backup plugins already have good free options, and a paid one would have to be clearly better than all of them on day one. This is a first release: I would rather have it running on real servers and hear what breaks.

Bug reports are welcome and get priority. A report with your config and the relevant log lines gets fixed fastest.