Backup System - Encrypted, Automatic, One-Click Restore

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 server does not have to be stopped, but understand what that means. The platform has a mechanism for asking a game to flush its save before the copy starts, and no game on the platform currently declares one — so what is copied is what is on disk at that moment. A file the running game is holding open fails the copy, and the backup is then refused rather than recorded incomplete. For a clean point-in-time copy of a busy world, stop the server first.

Manual backups share a 30 GB quota per server, shown on the page as "Storage Quota (Manual Backups)". They persist until you delete them — nothing removes them for you, and a full quota refuses the new backup rather than evicting an old one. From the panel you can create, restore, re-label and delete them.

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 same download is available through the API for scripting — see Customer API Reference.

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, and immediately before a restore overwrites your world. The Type column on the Backups page names which of those each one was.

Automatic backups are accounted separately and do not count against your 30 GB manual quota. The default retention keeps the last 7 backups or 7 days, whichever comes first. The pre-restore safety copy is exempt from that rule, so a server that backs up often can never delete its own undo.

The retention policy itself — how many to keep, how many days, 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. 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 (used for rollback if needed).

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 for health every 10 seconds for up to 5 minutes.

6. Complete or rollback: If the server passes health checks, the restore is marked complete. If health checks fail, the system automatically rolls back to the safety backup.

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 process is crash-safe at every stage. If a crash occurs during staging, your active save is untouched. If a crash occurs during swap, the atomic rename ensures either the new or old save is active - never a corrupted mix.

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 does not pause the server, and it tolerates a file it could not read rather than failing, so a file the running game holds open may simply be missing from it and nothing says so. That is the trade for taking one every two hours on every server. Your own backups take the opposite position — a file that cannot be copied fails the whole backup rather than producing a quiet partial — which is why they are the ones to use when you want a specific point in time back.