Skip to main content
Backup System - Encrypted, Automatic, One-Click Restore - visual guide

Backup System - Encrypted, Automatic, One-Click Restore

Every server includes encrypted off-site backups with a safety-first restore workflow. Create manual backups, schedule automatic ones, and restore with one click - your data is protected at every step.

How Backups Work

Every GameGrid server includes a complete backup system with encrypted off-site storage. Backups are uploaded to Wasabi S3-compatible object storage, which is separate infrastructure from the machines your servers run on โ€” so losing a host does not lose your backups.

All backups are encrypted before they leave the platform, with AES-256-GCM: a fresh 12-byte random IV per backup and a 16-byte authentication tag stored alongside the ciphertext, so a tampered object fails to decrypt rather than decrypting to something else. A SHA-256 checksum is computed on upload and verified again on download; a backup with no recorded checksum is refused rather than restored.

Manual Backups

Create on-demand backups at any time from your server's Backups page with "Create Backup Now". Each one can carry a label and a note so you can find it again. The name "Before Migration" is kept for the backup GameGrid takes before it moves a server, so you cannot give a backup that name.

The server does not have to be stopped, but understand what that means. Immediately before the copy starts, the platform asks your game to write its save to disk, using whatever command that game provides for it. The copy is then taken as the files stand at that moment.

Some games have no such command. They offer no way to be told to save while they keep running, and write their world on their own schedule instead. On those games there is nothing to ask, so a backup of a running server holds whatever the game last wrote. A game like that may not write its world at all while the server sits idle, so the backup can be as old as the server's last restart. That is still a real backup of a real world and it restores; it is simply not a copy of this exact second. Your game's own Backups article says which kind it is, and stopping the server first always gives you the exact moment. On the Backups tab, a running server of a game like that shows a box, Stop the server, back up, then start it again: GameGrid warns the players where the game can be spoken to, stops the server, takes the backup and starts the server again by itself. Players are disconnected while it is stopped.

If the running game has a file open at the moment the copy reaches it, the copy waits and tries again โ€” a few seconds for that file, and up to a minute across the whole backup. That covers the brief locks a game takes while writing its own save. A file still held after all of that fails the backup, which is then refused rather than recorded incomplete; the Status column names the file.

Manual and automatic backups share one 30 GB storage total per server, shown on the page as "Backup storage (manual and automatic)". Each manual backup is removed 30 days after it was taken. The page shows that day under the date, as "Deleted on ..."; nothing removes one earlier, and a full storage refuses the new manual backup rather than removing an old manual one. When the storage is full, the oldest automatic backup is removed first; a new manual backup is refused until there is room. From the panel you can create, restore, re-label and delete them. A backup that is still being made cannot be deleted until it has finished. For a world you want to keep longer than 30 days, use the Vault.

A verified backup has a Download button on the Backups page, which opens the archive in a new tab for your browser to save. The copy is your files as backed up, without the credentials the platform keeps in your server's folder for its own tools (see How Backups Work). Downloading is a panel action; the Customer API has no download.

Automatic Backups

Automatic backups happen on their own. Every server is backed up once a day; a backup is also taken immediately before a game update is applied, immediately before a restore overwrites your world, and immediately before Wipe Server or Delete Savegames deletes it; those two stop rather than go ahead if the backup cannot be made. The Type column on the Backups page names which of those each one was ("pre update", "pre restore", "pre wipe", "pre delete savegames"), and each can be restored like any other backup.

Automatic backups count toward the same 30 GB as your manual ones and give way first: when the storage is full, the oldest automatic backup is removed to make room. The newest automatic backup is always kept, even when that takes you over the 30 GB: then the Backups page says your backup space is full, we email you (at most once a month while it stays full), and a new manual backup is refused until you delete manual backups you no longer need. The default retention keeps the last 7 backups or 7 days, whichever comes first. Whatever the policy, every backup is removed 30 days after it was taken, except the newest automatic backup, which is kept until a newer automatic backup replaces it (so a server that has made no automatic backup for a month still has its last one). The pre-restore, pre-wipe and pre-delete-savegames copies are exempt from that rule and are never removed to make room, even for a manual backup, so a server that backs up often can never delete its own undo. Each of those copies is removed on its own 30 days after it is taken, so restore from one within that time. They still count toward the storage while they exist.

The retention policy itself โ€” how many to keep, how many days (1 to 30), an overall size ceiling, and whether scheduled backups should wait until no players are online โ€” is set through the Customer APIโ€™s backup-schedule endpoints. An update changes only the settings it names; anything you leave out keeps its current value. There is no control for it in the panel.

If a scheduled backup fails, the platform retries: a server whose only backup in the last 24 hours failed is queued again within about half an hour, because a failed backup is not a backup.

Restore with Safety

Restores follow a multi-step safety workflow designed to never corrupt your active save data:

1. Validate: The backup's structural integrity and file completeness are verified.

2. Safety backup: An automatic backup of your current save is created. It appears in your backup list and is exempt from retention, so you can restore it yourself if you want your old save back.

3. Stage: The incoming backup is extracted to a temporary location - your active save remains untouched.

4. Atomic swap: The staged backup is swapped into place using an atomic filesystem rename - either completes fully or not at all.

5. Health check: the restored server is checked before the restore is called complete.

6. Complete, or a result that says what happened to your files: a restore that stops before the swap is reported as rolled back, and your server's files were not changed at all. One that fails after it is reported as failed, which means they may have been changed - the safety copy from step 2 is in your backup list, and restoring it is your choice, not something the platform does for you.

Player Protection

If players are connected when a restore is initiated, the system requires explicit confirmation before proceeding. This prevents accidental data loss during active gameplay.

The restore is staged so that a crash before the swap leaves your active save untouched, and that is what a rolled back result means. A crash during or after the swap is reported as failed rather than guessed at: your files may have been changed, and the safety copy from step 2 is the way back.

Disaster Recovery Snapshots

In addition to the customer-facing backup system, the platform takes separate disaster-recovery snapshots every 2 hours, for every server on a host โ€” running or stopped. These are what Host-Failure Recovery rebuilds from, and they are distinct from your own backups.

DR snapshots use the same encryption and checksumming as customer backups but do not appear in your backup list and cannot be chosen for a restore.

They are also a plainer copy: a DR snapshot never asks the game to save first, whatever the game is. Your own backups do ask, on every game that has a command to ask with โ€” which is why they are the ones to use when you want a particular moment back. Both refuse rather than quietly dropping a file they could not read, and both wait out the brief locks a running game takes while writing its own save.