Checkpoint™ Explained

The backup completed successfully. The backup is also broken.

Here is a scenario that happens more often than anyone wants to admit.

Your server runs a scheduled backup. The backup completes. The file lands in storage. Everything looks fine. Green checkmark. Success.

Three weeks later, something goes wrong. You restore that backup. The server starts. The world loads. And then it does not. The save file is corrupted. Half the map is missing, or the entire thing fails to parse, or player inventories are gone. The backup was "successful" in the same way that photographing a document mid-shred produces a "successful" photo. You captured something. It just was not usable.

This happens because most backup systems do not care what state your files are in when they grab them. If Rust is mid-autosave and your backup tool scoops up the .sav file while it is being written, you get half a save file. If Minecraft is flushing chunks to disk and the backup grabs the region files during that process, you get a world with holes in it.

The backup tool did its job. It copied the files. The files were just garbage at the moment they were copied.

Why this is hard to catch

The insidious part is that you cannot tell by looking at the backup. It has the right file names. It has a reasonable file size. It compresses fine. It uploads fine. Every system along the way reports success because technically nothing failed. The file was there. It was copied. Done.

You only find out the backup is broken when you try to use it. Which is, by definition, the worst possible time to find out.

Some server operators have been running backups for months without a single usable restore point and do not know it. The odds are not even that bad. If your server autosaves every 5 minutes and your backup takes 2 minutes to run, there is a roughly 40% chance that at least one critical file gets caught mid-write on any given backup. Roll those dice daily and eventually you hit a streak of bad ones.

What Checkpoint™ does

Checkpoint™ is built into every Panel API backup on Pink Narwhal. It is not a setting. It is not a toggle. It is just how backups work here.

Before the backup starts, Checkpoint™ talks to your game server. It knows what game you are running through our Smart Profiles system, and it coordinates with the game to ensure everything is written to disk cleanly before a single file is touched. The server finishes what it is doing, flushes its state, and holds still. Different games need different coordination. Checkpoint™ handles this per game, automatically. You do not configure anything.

This is the part that matters most. By the time the backup actually begins capturing files, your server's data is already in a clean, stable state. There is no race condition. There is no window where a file might be half-written. The game has finished writing. The backup has not started yet. That gap is the whole point.

During the backup, Checkpoint™ independently verifies that the files it captured are consistent. If something unexpected happens (a plugin writing out of turn, an external process touching the disk), it catches it and handles it automatically. No manual intervention. No notification spam. It resolves the issue itself and moves on.

After the backup, Checkpoint™ tells the game server to resume normal operations. Whatever it coordinated before the backup, it undoes. Your players do not notice. The whole process adds a few seconds to your backup time.

The result: every backup that completes is a backup you can actually use.

This works with custom profiles too

Smart Profiles cover the popular games out of the box. Rust, Minecraft, and more. But if you are running something unusual, or you have written your own game profile with custom save commands, Checkpoint™ works the same way. As long as your profile tells us how to coordinate with the server, Checkpoint™ uses those instructions. Panel API is the only requirement.

If you are using SFTP connections, Checkpoint™ does not apply. We need the ability to communicate with the game server, and SFTP does not give us that channel. This is one of several reasons we recommend Panel API when your hosting provider supports it.

Integrity all the way to storage

Checkpoint™ does not stop at the archive.

Every backup is cryptographically verified as it streams to cloud storage. When the upload finishes, that verification is stored alongside the backup. Before any restore, we check that the data in storage still matches what was originally uploaded.

If the archive was corrupted in transit, truncated by a network hiccup, or altered in storage for any reason, the restore will not proceed. You get a clear error instead of a silently broken restore.

For large servers, backups are automatically split into smaller pieces. Each piece is independently verified. A single corrupted chunk does not silently poison your entire restore. It gets caught and flagged before anything touches your server.

The integrity chain runs from the moment your files are captured to the moment they land back on your server. No gaps.

What this means in practice

For most servers, Checkpoint™ is invisible. The coordination step ensures files are clean, the verification confirms it, and the backup completes without incident. You never think about it.

For servers under heavy load (high player counts, lots of disk I/O), Checkpoint™ does a bit more work behind the scenes. This is normal. It means the system is being thorough, and it is still handling everything without bothering you.

The outcome is the same either way: if a backup says it completed, it is clean. If something genuinely cannot be resolved, Checkpoint™ tells you what happened and why, with specific details. But that scenario requires something truly unusual to be happening on the server. Under normal operation, Checkpoint™ just works.

Why we built this

We looked at backup systems for game servers and noticed the same pattern everywhere. Backups run on a timer. Backups grab files. Backups upload files. Nobody checks whether the files were in a usable state when they were grabbed. It is the most important question in the entire process and it is the one nobody asks.

A backup service that cannot tell you whether your backups are actually usable is a storage service with extra steps.

Your backups should be something you rely on without thinking about it. If a backup says it succeeded, that should mean something. Checkpoint™ makes sure it does. Quietly, automatically, on every backup.