Direct answer

Set backup frequency from the amount of progress you can afford to lose. For an actively changing survival server, an hourly or several-times-daily snapshot may be useful, but there is no universal schedule. Daily-only copies may be enough for a quiet private server; backups before updates are essential.

Choose a recovery objective

  1. Decide your recovery point objective (RPO): how much player progress can be lost after a failure.
  2. Estimate how frequently worlds, databases, plugins and configuration files change. Database-backed economy or claims plugins may need a coordinated backup, not just a world copy.
  3. Choose a documented stop/snapshot method that produces consistent data, and test its duration during a quiet window.
  4. Run a fresh backup before Minecraft updates, plugin updates, world edits and migrations, regardless of the recurring schedule.

Example schedule

A medium survival server might keep frequent recent snapshots plus daily and weekly copies; adjust the interval to disk growth and acceptable data loss. Keep some copies off the same host. Do not copy live-changing world region files blindly unless the snapshot method guarantees consistency.

Version and safety notes

Backup plugins, remote storage and databases may require different consistency procedures. Confirm your software supports the chosen snapshot method.

Verify the schedule

Monitor last-success time, archive size, failed jobs and free storage. Restore one selected snapshot to a separate test server at least periodically and confirm player data and plugin state match. A scheduled task that runs without producing a usable restore point is not a backup strategy.

References

Check documentation for the versions and hosting environment you actually run.

Was this article helpful?
Help us improve this article

Tell us what is missing, unclear, outdated, or incorrect. You can also suggest something we should add.

What could we improve?
Do not include passwords, server IPs, or other private information.0 / 1000