PulsedMC Know what a backup actually saves you from
Servers rarely die dramatically. What actually happens is smaller and more common: a plugin
update corrupts its own data, someone with too many permissions runs
//set air on spawn, a world upload goes to the wrong folder, or a config edit
stops the server booting at 2am.
Every one of those is a five-minute problem if you have a backup and a very long night if you don't.
| Problem | Best tool |
|---|---|
| Server won't start after a config or plugin change | Panel backup from before the change |
| One player griefed a build | CoreProtect rollback, far more precise |
| World corrupted or wrong world uploaded | Panel backup |
| Moving to a bigger plan | Panel backup, downloaded and re-uploaded |
Restoring to undo one griefed chest throws away everything everyone else did since that backup too. For grief, install CoreProtect and roll back just that player: /co rollback u:Steve t:2h r:50.
Take one by hand right now
Open the Backups tab and click Create Backup. Give it a name you'll understand later, before-1.21-upgrade beats backup3 when you're staring at a list of them under pressure.
It runs while the server is up. Expect a short pause on a big world as it reads everything off disk, and a few minutes before it appears in the list.
What goes in it
Everything in your server directory: worlds, plugins and their configs, server.properties, player data, logs. Effectively a snapshot of the whole server, minus anything listed in .pteroignore.
Create a .pteroignore file in your server root to keep junk out of backups and stay under your slot limit. One pattern per line, logs/, cache/ and *.jar are safe candidates, since the jar is re-downloaded on install anyway.
Put it on a schedule
Manual backups get forgotten exactly when they matter. Go to Schedules → Create Schedule and make one that runs itself.
| Field | Value |
|---|---|
| Name | Nightly backup |
| Minute | 0 |
| Hour | 4 |
| Day of month / Month / Day of week | * |
| Task | Create backup |
Which is the cron line 0 4 * * *: every day at 4am.
Announce it if the world is large
On a big world the backup causes a noticeable pause. Add a task before it so players know what's happening rather than assuming the server is dying:
| # | Task | Wait after |
|---|---|---|
| 1 | Send command say Nightly backup starting, expect a brief pause | 5s |
| 2 | Create backup | - |
Your plan includes a fixed number of backup slots. Once they're full the schedule starts failing silently rather than rotating. Either delete old ones periodically, or lock the ones you care about so routine cleanup can't remove them.
Keep a copy off the server
A backup living on the same machine as the server is only half a backup. Once a month, and always before anything major, click a backup's row menu and choose Download, then keep the file somewhere else entirely.
The old rule still holds: three copies, two kinds of storage, one off-site.
- The live server.
- Panel backups.
- A downloaded copy on your own machine or cloud storage.
A backup you've never opened is a guess. Unzip a downloaded one and confirm the world folder is inside with a level.dat. Thirty seconds now, versus finding out on the worst possible day.
Restore from the panel
When something has gone wrong, this is the fast path:
- Stop the server and wait for the status dot to go grey.
- Take a backup of the current broken state, you may need something out of it later.
- Open Backups, find the one you want, and choose Restore from its row menu.
- Confirm, and wait. Large worlds take several minutes.
- Start the server and check the world before telling anyone it's fixed.
A restore replaces your current server files with the backup's. Everything built, configured or earned since that backup was taken is gone. That's why step 2 exists, take a snapshot of the broken state first, so a restore is never a one-way door.
Restore only part of it
Usually you don't want the whole server back, you want one world, or one plugin's config, without undoing everyone's progress. Do it by hand instead:
- Download the backup rather than restoring it.
- Unzip it on your computer.
- Pull out just the folder you need, say world/, or plugins/Essentials/config.yml.
- Stop the server.
- Upload that piece over the top of the live one, following Uploading an existing world if it's a world folder.
- Start up and check.
Player inventories live in world/playerdata/<uuid>.dat. To restore one person's inventory without touching anyone else, take just their file from the backup while the server is stopped. Find their UUID on a UUID lookup site, or in usercache.json.
Back up before you break things
Make a manual backup a reflex before any of these. It's thirty seconds and it has saved more servers than every other habit on this list.
- Changing
MINECRAFT_VERSIONor reinstalling. - Switching the egg, Paper to Fabric, or adding a Velocity proxy.
- Installing or updating a plugin that stores data (economy, claims, permissions).
- Running WorldEdit at scale, or regenerating chunks.
- Uploading a world.
- Handing someone else console access for the first time.
save-all flush
That forces everything in memory out to disk, so the backup you take a moment later is genuinely current rather than a few minutes stale.
Troubleshooting
The backup fails or never finishes
- Out of slots: delete an old backup and try again.
- Out of disk: check your storage usage. Pre-generated worlds get large fast; add
logs/andcache/to .pteroignore. - Times out on a huge world: trim what's included, or take the world folder off over SFTP instead.
I restored but nothing changed
Almost always because the server was running. It holds the world in memory and writes it back over your restored files on shutdown. Stop the server completely, restore again, then start.
I restored the wrong backup
If you took a snapshot of the current state first (step 5, point 2), restore that one and you're back where you started. If you didn't, older backups are still in the list, the restore replaced your files, not your backup history. Stop the server and restore the right one.
Can I schedule an automatic restore?
No, and that's deliberate, an automated restore would quietly delete real player progress every time it ran. If you want a world that resets on a timer (a minigame arena, say), keep a pristine copy in a separate folder and have a plugin swap it in, rather than using backups for it.
How long should I keep backups?
A reasonable pattern: the last seven daily backups, plus one monthly you never let rotate out. Some problems, a plugin quietly corrupting data, or an inside job, aren't noticed for weeks, and a week of history won't reach back far enough.