Direct answer

Copy plugin state, not just JAR files. Permissions, economy, claims and inventories may live in plugin folders, SQLite files or an external database. A world-only backup can restore terrain while losing the state needed to run the server correctly.

Inventory all state

  1. Record the server and plugin versions, plugins/ folder, root YAML/TOML/JSON configuration, world folders and proxy configuration.
  2. Check each important plugin’s storage setting: local files, SQLite or an external MySQL/MariaDB/PostgreSQL service. A filesystem copy will not automatically back up a remote database.
  3. Use a clean shutdown or documented consistent snapshot before copying local plugin data. Arrange database-native consistent backups for external stores.
  4. Keep secrets and credentials protected; do not share a raw config archive publicly.

Verify a restore

Restore the archive into an isolated test installation at the original software versions. Confirm groups, balances, protected regions and player data as applicable; read console warnings before upgrading plugins. Schema migrations can make a new database incompatible with an older plugin version.

Version and safety notes

Plugin data locations and database migration behavior vary by plugin release. A remote database needs its own consistent export process.

What to retain

Keep the last known-good server JAR and plugin list, but treat downloads separately from persistent data. Make a fresh pre-update copy even when automated backups run frequently. If the plugin has a documented export command, include it in the procedure rather than editing a live database file.

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