Test a backup before you need to rely on it

A successful backup message is a useful starting point, but recovery is the real test. Keep a record of what was backed up, when it was captured and which application version created the data.

Make a recovery inventory

List the world or application files, configuration, plugin/mod versions and any separate databases. A database hosted outside the server's file directory may need its own export. Confirm the backup tool's scope instead of assuming it includes everything on your account.

Capture a consistent copy

Schedule a quiet window. Stop the application or use its documented consistent-backup procedure before copying changing data. Record the backup time and download an independent copy where your plan permits it. Verify that the archive opens and expected directories are present.

Perform a test restore

1. Choose a separate test location with enough disk space. Do not restore over the only working copy.
2. Match the application version and required runtime.
3. Restore the files and import any separate database into an isolated test database.
4. Disable outbound jobs, scheduled emails, webhooks or public access that should not run twice.
5. Start the test application and inspect its logs.
6. Verify representative data: a known build in a game world, an account record, an uploaded image or a recent database entry.

Write down the restore duration and anything missing. Those findings tell you whether the recovery plan works under real conditions.

Does one backup replace a history of backups?

No. A recent backup may already contain an unnoticed mistake. Keep more than one useful recovery point within your plan limits and storage budget.

Should I update software during the restore?

Recover the known working version first. Mixing a restore with an upgrade makes it harder to identify the cause of a failure.

For Paper-specific update precautions, consult the official updating guide. See also panel backups.