Something has eaten your world — a mod update, a griefer, a build that was there last night and is not there now. The Backups tab on a uniz.host server can put an earlier copy back. Read the first section before clicking anything: a restore overwrites the current world and cannot be undone, so the order you do things in is the whole game.
Putting an older world back
Open the server from /dashboard/servers, then the tab labelled Backups. The card lists every backup you hold, each row carrying a badge — Manual, Scheduled or Uploaded — plus its size and the date and time it was taken. A row that reads Backing up… instead of a size is still being written; wait for it.
Stop the server first
A restore writes into the volume the game keeps open, so it is only allowed while the server is stopped. Press Stop on the Overview tab and let the state settle before you go back to the backups list. If you try anyway, the request comes back as a conflict and nothing is touched.
Creating a backup is a separate question, answered further down: some servers can be snapshotted live, all of them can be snapshotted while stopped.
Pick the backup by its date and time
Every row shows the moment it was created. That timestamp, not the label, is what tells you whether you are about to recover last night or last week. If you name your manual backups when you take them — the create dialog offers an optional name — that name shows next to the badge and makes this step much less nerve-racking.
Leave the safety backup ticked
The confirm dialog spells the danger out: This overwrites the current world with the backup. It cannot be undone. Underneath it is a checkbox, Back up the current world first (recommended), ticked by default every single time the dialog opens.
Leave it on. With it on, the platform takes a fresh backup of the world as it is right now, and only when that backup is verified as a real stored object does the restore run. If the safety backup fails, the restore is cancelled and your current world is never touched. That chain runs server-side, so closing the tab does not interrupt it.
Two things worth knowing about it. It consumes one of your five manual slots, and it is filed under the label ก่อนกู้คืน ("before restore"). And if the manual pool is already full, the checkbox is disabled and the panel says so — Manual backup slots are full (5/5) — delete a backup to enable the safety backup. In that state the restore will still run, without a safety copy. Delete an old backup first.
Start the server yourself once the restore finishes
This is the step people miss. When the restore completes, the server stays stopped. Nothing starts it for you, on either the safety-backup path or the direct one. You get a notification that the server was restored, and then you press Start. While the job is still running, Start is refused with a conflict — that is the platform protecting the volume, not an error on your part.
What a restore actually changes, and what it leaves alone
The backup is unpacked over the server's data volume. Anything the backup contains replaces what is on disk under the same name. Anything created after that backup, which the backup therefore does not contain, is still there afterwards. So a restore rolls your world back, but it does not "undo yesterday" wholesale: a mod you added this morning is still installed, and a file you want gone still needs deleting by hand.
Before a single byte is written, the archive is streamed through an integrity check end to end. A truncated or corrupt file — most likely one you uploaded yourself — fails at that stage, with your current world untouched.
Which servers can back up while they are online
This is decided per game in code, not per plan, and it is narrower than most people assume.
| Server | Backing up while it runs |
|---|
| Minecraft, Java edition (including crossplay) | Yes — the world is flushed and autosave frozen for the duration |
| Minecraft, Bedrock edition | No — stop it first |
| Every other game we host | No — stop it first |
On a Java Minecraft server the panel says so directly: Backs up live — no need to stop the server. Everywhere else the rule is the one in the table, and it is enforced when the request is sent, not by the button: on any game other than Minecraft Java, a backup of a server that is not stopped is refused, whatever the panel appears to offer. Stop it first and the same button works.
The consequence catches people out on the schedule, so it is worth stating plainly: on any game other than Minecraft Java, a scheduled backup that comes due while the server is online is declined and retried later, not run. A Palworld server left online around the clock with a daily schedule collects no automatic backups at all. Either arrange for it to be stopped around the scheduled hour, or take a manual backup at the end of each session.
Setting up the automatic schedule
The schedule card sits above the list and is Off until you change it. Two modes are on offer: Every N hours, where the interval choices are 4, 6, 12 and 24 hours, and Daily at, which takes an hour of the day. The label on the time picker — Time (Thai time) — is not decoration; the hour is read in Thai time regardless of where you are.
Three checkboxes shape when a due backup actually fires:
Skip when nobody has played since the last backup — on to begin with, and the reason a quiet server does not accumulate seven identical copies.
Back up when the last player leaves — a session-shaped trigger rather than a clock-shaped one.
Wait until the server is empty — hold a due backup rather than run it under a live session.
Below them, the retention picker — "keep last N scheduled backups" — takes any number from 1 to 7 and starts at 3. As new scheduled backups land, older ones past that count are deleted automatically. Nothing takes effect until you press Save schedule.
Manual backups, uploads, and the pool of five
Back up now opens a small dialog with an optional name, up to 60 characters, and takes a snapshot immediately. Upload backup sends a file you already hold — a world you exported from elsewhere, or a backup you downloaded from here — and is accepted in any server state, running included, because it never touches the volume.
Manual backups and uploads share one pool of five per server. Scheduled backups do not count against it; they have their own retention number. When the pool is full, the next manual backup or upload is refused until you delete something.
Uploads have two more rules. The file must be a zstd backup archive — .zst or .tar.zst — and anything else is rejected with Only .tar.zst backup files can be uploaded. And it may not be larger than the server's own disk allowance. Uploading also requires the server's owner to have topped up with real money at least once; coupon, referral and admin credits do not open that gate. A teammate uploading on a not-yet-funded owner's server will be told to ask the owner.
One sharp edge: Delete on a row removes that backup straight away. There is no confirmation dialog.
Download on any finished row hands you the archive. The link is minted fresh, is single-use, and lives about a minute — a browser download cannot carry an authorisation header, so the link itself is the credential and it is deliberately short-lived. Reloading it or coming back to it later will not work; press Download again for a new one. What lands on your machine is the same archive format the upload button accepts, so a backup can be carried between servers.
What a backup contains
A backup is an archive of the server's data volume, which is everything the game itself writes.
For Minecraft that is the lot: the world folders, server.properties, mods or plugins, whitelist and ops files, and every config file on the volume. For the Steam-based games, the parts a fresh install would simply re-download — the game binaries — are left out on purpose, so backups stay small; saves and configuration are always included. On Palworld, mod .pak files you placed in the mods folder survive the round trip, while the shipped game paks are excluded.
What is not in a backup is anything that lives in your uniz.host account rather than on the volume: your plan and RAM size, the server address, team members and their permissions, the backup schedule itself, and your credit balance. Restoring an old backup does not roll any of those back.
Who is allowed to do all this
The Backups tab is visible to the server's owner and to any team member granted the Backups permission, which covers creating, restoring, downloading, uploading and deleting backups as well as editing the schedule. Two dependencies are easy to miss: restoring needs the server stopped, and stopping it needs the Power permission, so a member with backups alone cannot finish a restore; and the upload funding check reads the owner's top-up history, not the caller's.
Read next
- — what every tab and card on the server page is for
- — where the world files a backup contains come from