Backups that actually restore: what to keep, and where

Everybody sells backups. Far fewer will tell you where they are kept, and that is the only part that decides whether one helps on the day something goes wrong. A backup is not an archive - it is the copy you can restore, onto working hardware, inside a time you can live with, containing everything the server needs to be itself again. Most things people call a backup fail one of those four tests, and usually the last one: the database was a separate service, the startup variables were never files, or half the plugin data lived in a folder nobody thought to include.

This post is about the shape of a backup policy for one or two servers - what goes in, where the copies sit, how long they live and in what order you put things back. The rehearsal that proves any of it works is a separate job, covered in testing a restore before you need it, and databases have their own rules in database backups and restores.

What has to be in a backup#

Start from the question "if this server were deleted right now, what would I need to rebuild it exactly?" and the answer is never just the save file.

Three categories go missing over and over.

• The database. It is a different service with a different backup mechanism, and a file-level archive of a running database is not a backup of it. If your Minecraft permissions plugin, your FiveM resources or your web app keep state in a database, the archive without that database restores a server that boots and remembers nothing.
• Anything outside the server directory. Panel backups archive the server's own files. A cron job on a VDS writing to /opt/tools, a second mount, or a log directory you moved for space is not in there unless you put it there.
• The settings that are not files. Startup variables, port allocations, schedules, subuser grants and the plan the server runs on all live in the panel database, not on disk. A restored archive comes back with the right world and the wrong start command. Keep a plain text note beside your backups with the startup line, the allocations and anything you changed from the default. It takes two minutes and it is the difference between a restore of twenty minutes and one of two hours.

Version information belongs in that note too. A world/ folder from Minecraft 1.21.4 started under 1.20 will not load, and a mod pack restored without its exact mod versions produces the same crash the backup was meant to undo - see what to do when a mod update breaks.

Where the copies live#

The rule that has survived every change in storage technology is 3-2-1: three copies of the data, on two different kinds of storage or systems, one of them somewhere the first two cannot be destroyed together. It is not a vendor's slogan; it is an admission that failures arrive in clusters.

Applied to a single hosted server, that is concrete:

1. The live data, on the node, being written to right now. This is a copy, not a backup.
2. A backup taken off the machine it protects. An archive on the same storage pool as the thing it protects covers exactly one failure: you deleting your own world. It covers nothing about the disk, the pool, the machine or the account.
3. A copy you hold. Downloaded to your own disk, or pushed to storage that has no relationship to your host. This is the one that survives the case where your account goes away, and it is the one almost nobody has.

The dashed part of most people's plan is the arrow from the archive to a test server. An archive that has never travelled that arrow is a file with a helpful name.

Retention: how many, how old, and which one is locked#

Retention is a question about which mistake you expect. Backups from the last day catch a crash or a bad update. Backups from three weeks ago catch the thing nobody noticed: a plugin that has been quietly corrupting player inventories, a griefer with an ops entry, a table that lost rows on Tuesday.

The classic scheme is grandfather-father-son: keep seven daily backups, four weekly, and a few monthly. On a game plan with two slots you cannot run that, so run the honest small version instead:

• Slot 1 rotates. A nightly backup that overwrites yesterday's. This is your crash cover.
• Slot 2 is locked and holds the last known-good state: the backup you took before the last update, before the last mod change, or after the last successful restore test. Update it deliberately, never on a schedule.
• Your own copy is the depth. Download the rotating backup once a week and keep four of them. Storage on your own machine is far cheaper than a slot, and four weeks of history costs you one drag-and-drop a week.

On RE:NODE, game plans carry two backup slots, the app, web and database lines carry between two and six depending on tier, and the VDS line carries one. Every plan has slots - nothing here is gated by price. Backups are taken on demand or on a schedule, restored with a button rather than a ticket, downloadable, and lockable against rotation. Where the off-machine copies live is not something we publish, which is exactly why point 3 above is your job and not ours.

Consistency: the difference between a copy and a snapshot#

Most game servers hold their world in memory and write it out periodically. Archiving those files mid-write gives you a mixture of two states, and the failure mode is nasty because the archive looks fine: right size, right file names, and a world that refuses to load or loads with a hole in it.

Three ways out, in order of preference:

1. Stop the server, take the backup, start it. Perfect consistency, at the cost of a few minutes offline. For a small group this is the right answer and nobody notices at 05:00.
2. Flush first. Minecraft can be told to stop writing and then put everything on disk: save-off, then save-all flush, take the backup, then save-on. Palworld and Project Zomboid have a Save and a save console command respectively. 7 Days to Die has saveworld.
3. Accept the risk for genuinely append-only data. Logs, uploaded media, static assets. Nothing that a process holds open and rewrites.

Valheim deserves its own line because it is the common casualty: a clean stop saves the world, a kill does not, and the default -saveinterval is 1800 seconds. Backing up a running Valheim server can archive a world up to half an hour behind the game. The Valheim dedicated server guide covers shortening that interval.

The ordering of these steps on a timer is the subject of scheduled tasks worth having - in short, the flush command goes several minutes before the backup task, not in the same minute, and the nightly restart goes after the archive rather than beside it, for the reasons in restart schedules that help.

Taking one by hand#

You will do this at some point: before a risky change, before a migration, or because you want a copy that is not in your host's hands. Over SFTP or the file manager you can download the folders directly, but making the archive server-side first is faster and gives you something to checksum.

$ cd /home/container$ tar -czf /home/container/backup-$(date +%F).tar.gz \    world world_nether world_the_end plugins server.properties ops.json$ sha256sum backup-$(date +%F).tar.gz > backup-$(date +%F).sha256

Then verify before you trust it, and again after you have downloaded it:

$ gzip -t backup-2026-09-21.tar.gz && echo "archive intact"$ tar -tzf backup-2026-09-21.tar.gz | wc -l$ sha256sum -c backup-2026-09-21.sha256

Three numbers are worth writing down each time: the file count, the byte size, and how long the archive took to build. A backup that is suddenly 90% smaller than last week's is the single most reliable early warning you get, and it is only visible if you ever looked at last week's. gzip -t catches a truncated download, which is the other common surprise - a 4 GB archive that stopped at 3.1 GB because the browser tab was closed.

Remember that the archive contains your secrets. wp-config.php, .env, RCON passwords and database credentials all travel with it. Treat a downloaded backup the way you treat the server itself, and read environment variables and secrets if any of those are currently sitting in a file you have emailed to somebody.

Restoring without making it worse#

The instinct in an incident is to restore immediately over the top. Resist it for sixty seconds, because the broken state is evidence and it is about to be destroyed.

1. Stop the server. Not restart - stop. A running process will write over whatever you put in place.
2. Take a backup of the broken state, or at least download the affected folder. If the restore turns out to be older than you thought, this is the only way back to the version with today's work in it.
3. Restore into a place that is not production if you have any doubt about which backup is the right one. Restoring to a second server costs an hour of a small plan and removes the guessing.
4. Restore the files, then the database, in that order, and check that the application's expected schema version matches the code you have restored. A database newer than the files is the ugliest case: see migrations without downtime.
5. Reapply the panel-side settings from your note - startup variables, ports, schedules.
6. Start and verify something specific. Not "it boots". Log in, open the thing that broke, check the last change you remember making before the backup ran.

The five ways a backup turns out not to be one#

• It is on the same disk. The game's own rolling saves, the backups/ folder beside the world, the copy in /home/container/old. All of them survive exactly the mistakes you make with the file manager and none of the ones the hardware makes.
• It is missing the database. Covered above, and it accounts for more failed restores than every other cause combined on app and web workloads.
• It ran, but on nothing. A schedule that backs up a server that has been renamed, or a dump command whose database name changed, produces a small archive every night. Watch the size.
• It cannot be read. Truncated downloads, an archive built while the disk was full, a corrupt gzip stream. A checksum at creation and a checksum after transfer costs nothing.
• Nobody knows the procedure. The archive is perfect and the person who set it up is asleep. Write the restore steps in the same note as the startup variables.

A backup nobody has restored is a hypothesis. Restore one into a test server occasionally; it takes half an hour and it is the only way to know.

Matching the schedule to what you can afford to lose#

Two numbers describe any backup policy, and naming them stops most arguments. The recovery point objective is how much work you are willing to lose - the gap between backups. The recovery time objective is how long you are willing to be down while you put it back.

The row that catches people is the last real one. If losing an hour of database writes is unacceptable, nightly dumps will not do it whatever their retention, and you need continuous archiving on infrastructure you control - which usually means a VDS rather than a slot. For everything else, a nightly backup plus a locked known-good copy plus a weekly download is a complete policy, and it is achievable on the smallest plan sold.

FAQ#

How often should I back up a game server?

Nightly, at the quietest hour, plus a manual one immediately before any update, mod change or configuration experiment. The manual ones matter more than the schedule: most restores happen because of a change somebody made, not because of a failure.

Does a backup include my database?

Not unless you put a dump of it in the server's folder before the backup runs. Panel backups archive the server's files. A database - a panel database slot, or a separate PostgreSQL or MongoDB server - is a different service and needs its own dump, which is why the schedule order in this post puts the dump first.

Is a locked backup safe forever?

It is safe from rotation, not from deletion. Locking stops a scheduled backup pushing your known-good copy out of the slots. It does not survive the server being deleted, and it does not replace holding your own downloaded copy.

How long does a restore take?

Long enough that you should measure it rather than assume. Restoring a 500 MB game server from a panel backup is a few minutes; a 40 GB modded server with a database is an evening. The only honest answer is the number you got the last time you tried it, which is why you should try it.

Can I restore a backup onto a different server?

Yes, and it is the safest way to check one. Download the archive, upload it to a second server on the same or a larger plan, and start it there. This is also how you move between plans or hosts - moving a server without losing players covers the DNS and player-facing side.

What about backing up the whole platform, not just my server?

That is the host's job and it is separate from yours. Ours are nightly, copied to separate hardware, verified and pruned on a schedule. It protects the platform, not your decisions - a world you deleted yesterday is not recoverable from it, which is what your own backup slots are for.