Backups and restore tests

Make a consistent backup

A stopped-server backup is the simplest to verify:

1. Enter stop and wait for Java to exit.
2. Copy all worlds/dimensions, plugin data and JARs, configuration, player/permission lists, launcher, and matching server JAR.
3. Back up external databases with their own supported tools, coordinating the data point with the server files.
4. Keep license and bridge files only in restricted private backups, never a public support archive.
5. Label the archive by date/version and keep another copy outside the server machine.

Copying a live world arbitrarily can capture inconsistent files. Online backups require properly coordinated saves and filesystem/database snapshots. Use tools designed for that workflow and test their restores.

A practical schedule

An initial policy can include a daily maintenance backup, an extra backup before updates/pregen/major changes, and periodic off-machine copies. Choose retention according to data value and world growth. This is operational guidance, not a built-in Nusa backup scheduler.

Wizard files in nusa-config-backups/ back up configuration only. They do not replace world, plugin, or database backups.

Test a restore

Extract an archive into a new folder. Use the corresponding Java/JAR, a separate port, and staging-safe plugin connections. Verify important areas, inventories, permissions, and database-backed functions. Save and restart once.

Record restore duration and the latest recoverable point. Fix a failed test before relying on the backup. Do not delete older backups merely because a new archive was created successfully.