Who Owns Your Game Save? Host Data Lock-In and the Worlds You Cannot Get Back

You paid for the server, you built the world, you logged the hours. None of that means the save file is yours to walk away with. Some hosts lock it to their hardware, some delete it by accident, and some lose it in a migration nobody asked for. Here is the evidence, dated, and how to make sure the only copy that matters is the one you control.

The uncomfortable thesis

There is a comforting assumption baked into renting a game server: that the world you create is an asset you own, sitting safely on someone else's hardware until you decide otherwise. The record says that assumption is wrong often enough to plan around. Save files get locked to a vendor, panels hide the raw data, cleanup scripts delete the wrong machines, migrations overwrite hundreds of hours, and self-service restore buttons quietly disappear after an exploit. Most of these are not malice. They are the predictable result of you not holding a copy.

The lock-in problem: Nitrado

Start with the cleanest example of structural lock-in. Players report that on Nitrado, for certain games, the save game is bound to the Nitrado server itself and cannot be exported. One widely shared warning put it bluntly: your save game will be locked to that Nitrado server forever, with no way to pull the raw file and take it elsewhere (r/SCUMgame). This is not a rumor that the company ignores. In October 2025 a Nitrado staff account confirmed in that same discussion that for some games save access is deliberately withheld, citing security concerns and closed-source licensing terms with the game studios.

In fairness, that is a defensible position on its own terms. Some studios genuinely forbid handing players the raw server save, and a host that respects those terms is not doing anything shady. But the practical effect for you is identical to a lock: if you cannot export the file, you cannot leave with it, you cannot self-host it later, and you cannot keep a copy as insurance. Our opinion is that this should be disclosed loudly on the product page for every affected game, not discovered in a forum thread after you have sunk a hundred hours in. Lock-in you can see coming is a tradeoff. Lock-in you find out about during a dispute is a trap.

When the host deletes it themselves

The lock-in case at least leaves your data intact, just stranded. The next category destroys it. On 27 February 2025, Apex Hosting ran an internal maintenance script it called a Ghost Server Cleanup, meant to reclaim machines for servers that no longer existed. The script's logic for identifying a dead server was faulty, so it misidentified a set of active servers and deleted or locked them (Apex Hosting incident report). Apex restored affected worlds from a Backblaze backup, but the most recent backup was up to roughly 13 hours old, so customers permanently lost up to 13 hours of progress.

We want to be precise about how we frame this, because it is the rare case worth holding up as a model of handling a bad situation. Apex called it human error, published a detailed public post-mortem, and shipped concrete process changes: staging environments, mandatory dry runs before destructive scripts touch production, and multi-person approval before such a script can fire. That is roughly the textbook response. The data loss was real and the apology does not give anyone back their 13 hours, but a host that documents exactly how it failed and what it changed is behaving better than the silent majority. The lesson for you is not that Apex is uniquely dangerous, it is that a single buggy automation script can wipe live servers at any host, and a 13-hour-old backup is the difference between an inconvenience and a catastrophe.

When a migration eats your world

Sometimes the host is trying to help you. A Satisfactory player described ZAP-Hosting migrating their server to new infrastructure, framed as an upgrade to improve the experience, and the migration deleted a roughly 400-hour save in the process (r/SatisfactoryGame). Four hundred hours is not a weekend, it is months of evenings. The maddening part is that the trigger was a maintenance action the customer did not request and may not have been clearly warned about. A migration is exactly the moment your data is most exposed, because it is being copied, moved, and the old copy is being deleted, and any break in that chain is unrecoverable if you have no backup of your own.

Termination is the other migration-shaped hazard. A Minecraft server owner reported BisectHosting deleting their world data after a grace period elapsed following a missed payment and server termination (r/MinecraftServer). This one is harder to call a host failure. A late payment, a stated grace period, then deletion is a documented lifecycle, not a surprise script. But it underlines the same point from a different angle: the host's retention clock is not your retention clock, and the day your card declines is not the day you want to discover how short the grace window really is.

When restores get taken away

The landmark case for self-service restores being revoked is ARK Mobile. On 17 December 2020, after a wave of duping exploits, the developers disabled the ability for players to restore backups themselves from the Nitrado web interface, routing all restore requests through manual support instead (PlayARK Mobile). The reasoning was sound from an anti-cheat standpoint, since duping rings were abusing restores to multiply items, but the effect on legitimate admins was that a button they relied on simply vanished, and getting a world back now meant a support queue and a human in the loop.

This is the most underrated risk on the list, because it is not a one-time accident, it is a policy change. A feature you depend on can be turned off at any time for reasons that have nothing to do with you, and the only defense that survives a policy change is a backup that lives outside the host's control entirely. A DayZ admin made the broader version of this argument: a game server provider without full desktop or file access can leave you unable to retrieve your own data when you need it, no matter how reasonable the host is (r/dayz). Access you do not have is access you cannot count on.

The data-loss timeline

Dated, chronological, worst cases marked in red. Red means data was actually lost or made inaccessible, orange means the capability or control was reduced.

Host by host: what happened to the data

The same incidents in a form you can scan. Recoverability is described as it stood at the time, from the cited sources.

Who handled it well

It would be dishonest to leave the impression that every host is a data hazard. Two contrasting examples are worth naming. When Minehut had a significant outage in May 2024, it responded with a transparent post-mortem and a two-times pro-rated refund for the affected window, treating downtime as something owed back rather than something to bury (Minehut downtime report). That is the behavior pattern you want to see: own the failure, explain it, compensate without being dragged.

Survival Servers is the more honest middle case, and we include it precisely because it is mixed. Its public review record carries genuine data-loss complaints alongside documented recovery wins where the host got a customer's world back (Trustpilot). That is what most real hosts actually look like: not villains, not saints, capable of both losing a world and saving one depending on the day, the staff member, and whether a backup existed. The takeaway is not that one host is safe and another is not. It is that the variable you can actually control is your own copy.

Protect your world: the checklist

None of the above can hurt you much if you treat the host's storage as a cache, not a vault. Here is the routine, in priority order.

• Keep your own off-host backups. Copy the world or save folder to your own computer or to cloud storage that the host does not control. A backup on the same provider that just lost your data is not a backup, it is a coincidence.
• Prefer hosts with full FTP or SFTP and file access. Before you pay, confirm you can browse and download the raw save files yourself. If the only way to reach your world is through the host's panel, you have no exit. For games where the save is locked, like some Nitrado titles, weigh that against how much the world will matter to you.
• Download saves before any migration, plan change, or termination. A migration is the single most dangerous moment for your data, paid or unpaid. Pull a fresh copy before you click anything that moves, upgrades, or downgrades the server, and before a subscription you let lapse hits its grace deadline.
• Test the restore, do not just trust the backup. A backup you have never restored is a hope, not a plan. At least once, load your downloaded save on a fresh local install or a second instance and confirm the world actually comes up. Untested backups fail at the worst possible time.
• Automate and date it. Set a recurring copy, weekly at minimum, more often for active worlds, and keep more than one generation so a corrupted save does not overwrite your last good one. Name backups by date so you can roll back to a known-good point.

FAQ

Can I download my game server save?
Sometimes, and that is the problem. On a host that gives you full FTP or SFTP and file access, you can download your world folder any time. On some managed hosts and game-specific panels the save sits behind the panel with no direct file path out, so you depend on whatever export, if any, the host chooses to offer. Before you commit, confirm in writing that you can pull the raw save files yourself.

Does Nitrado let you keep your save?
It depends on the game. Nitrado offers file access for many titles, but players report that for certain games the save is locked to the Nitrado server and cannot be exported. A Nitrado staff account in October 2025 confirmed that for some games save access is withheld, citing security and closed-source licensing. Check the specific game before you assume your world is portable.

How do I back up my game server world?
Connect over FTP or SFTP, find your world or save folder, and copy the whole directory to your own computer or cloud storage on a schedule. Stop the server or use the host's snapshot feature first so you copy a clean state, then verify the backup by spinning the world up locally or on a second instance. Repeat before any migration, plan change, or risky update.

My game server host deleted my world, what now?
Ask immediately whether they hold an off-server backup and how old it is, the way Apex restored from a roughly 13-hour-old Backblaze copy after its February 2025 cleanup-script incident. If the loss came from a migration or a payment lapse, recovery is far less likely without a copy of your own. The honest answer is that prevention is the only reliable cure, which is why an off-host backup matters more than any host's promise.