Every few weeks a ticket lands that opens the same way. "Our world is gone."
Sometimes it's Valheim, sometimes Space Engineers, sometimes a Palworld server that eight people have been living in since March. The details are always different. The conversation almost never is – we ask when the last backup was taken, there's a pause, and from the length of that pause I can usually tell whether the next hour is a ten minute job or a genuinely bad afternoon.
So here's the article I keep half-writing inside those tickets. What actually goes wrong, what a backup is really for, and what restoring one looks like when it's four in the morning and people are asking you in Discord whether their base still exists.
Worlds don't usually get deleted. They get made unreadable
This is the part most backup advice skips, and it's the part that decides whether you get your world back.
In my experience there are three ways a world goes, and only one of them looks like deletion.
The save is completely intact and the server just can't open it any more. This is by far the most common one, and it's almost always a version change. A game moves to a new build, the new build can't read the old world, so the server shrugs and generates a fresh one. Project Zomboid did exactly this going from Build 41 to Build 42, and we wrote up that whole mess at the time. Nothing on disk got destroyed. The files sat there being perfectly fine and completely unopenable, which from a player's side is indistinguishable from gone.
The save itself is damaged. Rarer, nastier. A world the game reads partway through and then gives up on. Space Engineers has a lovely example where a sector just refuses to load and the server throws the same error on every start, which we documented separately because it comes up often enough to deserve its own page. Mods are the other big source. A world saved while a mod was installed can end up holding references to that mod permanently, so pulling the mod back out breaks the save rather than reverting it, and that's most of why modded Conan servers die on startup.
Somebody overwrote it. A reinstall to fix something unrelated. A restore done onto a running server. A config change that pointed the server at a new world name and quietly started a second world alongside the old one. Human, avoidable, and the category I have the most sympathy for – every single one of these starts with someone trying to fix a different problem.
Notice that in two of those three, the last good save is the entire recovery plan. Not a mod fix, not a config tweak, not us. The save.
A backup on a timer is a floor, not a plan
Every LOW.MS server has Cloud Backup and Cloud Restore in the sidebar of the control panel, and you can put a backup on a timer with Scheduled Tasks so it happens whether or not anyone remembers. Set that up. It takes about two minutes – that's really the whole ask, and it's the one thing on this list I'd do before anything else.
What I'd push back on is treating it as finished once it's done.
I had a look at what people actually schedule, and the pattern is telling. Where somebody has set up their own task, it's usually a restart or an update – the convenient things. Backups turn up a lot less often. That's the wrong way round: automating what keeps a server tidy, skipping what gets it back.
The other reason a schedule isn't a plan: a backup you've never restored is a hypothesis. It's a file – you believe it contains your world, and you haven't checked. I'd genuinely rather you did a restore once, deliberately, on a quiet Tuesday, than found out the answer on the day it counts.
Keep one copy somewhere we can't touch
Your scheduled backups live on our side, which is convenient right up until the thing you're recovering from also happened on our side, and then it isn't. Backup Manager has a smaller version of the same limitation: it handles archives kept on the box itself, which makes it a handy quick rollback point, but it's no use to you if the box is what broke.
So for anything you'd be upset to lose, pull a copy down and keep it. File Manager in the panel is fine for a small world. For anything chunky, use SFTP on port 8822 – it's meaningfully faster than the browser for bulk downloads and it won't give up on you halfway through.
One folder on your own machine with three dated zips in it is worth more than any amount of theory about retention policies.
The trap: archiving files the server is still writing to
Here's the one that bites people, and it isn't obvious.
A running game server holds its world open. It writes to it on its own schedule, and plenty of games write in several pieces that only make sense together. Take a copy while that's happening and what you get is a snapshot of a moment that never really existed – half the files from before a write, half from after. It'll zip up cleanly. It'll appear in your backup list at a sensible size with the right timestamp. It will not load.
That's the failure mode I find genuinely mean, because a broken backup doesn't announce itself. It sits in the list looking exactly like a good one, for months.
The fix is boring. Stop the server, take the backup, start it again. Where that isn't practical on a busy server, the next best thing is forcing a save through Web Console and taking the copy immediately afterwards, while the disk is at its most consistent. Some people schedule a backup and a restart together for exactly this reason and they've got the right idea.
What a restore actually looks like
Not the marketing version. The real one.
- Stop the server. Fully. Wait for it, don't click stop and start uploading.
- Use Cloud Restore if you can. It stops the service itself, warns you before it overwrites what's currently there, and saves you hand-mixing world files.
- Uploading your own copy instead? Pull down a separate copy of the current world first, broken or not. And if you're not certain which files to replace, ask us before you replace anything.
- Start the server and watch the first boot in Log Viewer rather than assuming.
- Connect and actually look. Is the base there? Is your inventory right? Can somebody else join?
Step one is where people get hurt. Restore onto a running server and you've now got two versions of the truth – the world in memory from before your restore, and the files on disk from after it. When the server next shuts down it writes memory back over disk and your restore evaporates. Worse, it looks like it worked, right up until the following day. We've walked people through unwinding that and it's a great deal harder than the thirty seconds of downtime doing it in order would have cost.
What's worth keeping, and what isn't
You don't need the whole install. The game binaries come back from Steam Update in a few minutes and they're the same bytes for everyone.
What you want is the small stuff that's yours: the world or save folder, your config files, your admin and permission lists, and whatever player database the game keeps if it keeps one separately. That last one gets forgotten constantly – people restore the world, everything looks right, and then nobody has admin any more. Our Windrose backup guide walks through it for one specific game, and the shape of it is the same everywhere.
Take one outside the schedule before anything you'd describe as a change, too. A game update. Adding or removing mods. A big config edit. Letting a new admin near the console. Those are the moments worlds get lost, and they're all moments you can see coming. A nightly backup is for the unexpected; a manual one taken right before you touch something is for the entirely expected.
If you're not sure what your particular game keeps where, open a ticket and ask us before you need to know rather than after. We'll tell you which folders actually matter on your server, and it's a much nicer conversation to have on a Wednesday afternoon than at two in the morning with your Discord going sideways.