Original PortalMine editorial illustration. This page is maintained as practical server-owner documentation.
Quick answer: World backups may not include plugin databases. Inventory every external and local database, create consistent backups with matching files, encrypt credentials and archives, and test restoration with the exact plugin version.
Find where plugin data actually lives
Plugins may store data in YAML or JSON files, SQLite databases inside the plugin directory, or external MySQL-compatible servers. Inventory each plugin’s storage mode and connection details. Do not assume that backing up the world folder captures permissions, economy, claims, or inventories.
Identify shared databases used by multiple servers or proxies. A backup and restore plan must preserve relationships between tables and services, not only one game instance.
Coordinate file and database consistency
A world snapshot and database export taken at different logical times can produce mismatched state. For critical systems, stop the server cleanly or use the database and plugin’s supported consistent-backup method. Record the timestamp of every component.
SQLite files should not be copied while writes are active unless the database’s backup mechanism is used. Copying only the main file can miss journal or write-ahead-log data.
Create reliable external database exports
Use a database-native dump or snapshot method that preserves schema, indexes, character set, and data types. Capture required users or privileges separately when they are part of recovery. Check command exit status and archive size rather than assuming a scheduled task succeeded.
For large databases, consider transaction-consistent options and the load imposed on production. Test the chosen method with the actual database engine and table types.
Protect credentials and backup contents
Database dumps can contain player identifiers, messages, economy records, and other sensitive information. Encrypt backups in transit and at rest, restrict access, and avoid embedding passwords in scripts that are readable by the game process or public repository.
Use a dedicated backup account with the minimum required privileges. Rotate exposed credentials and document who owns the recovery keys.
Apply retention and off-host storage
Keep multiple generations: recent frequent copies for operational mistakes and older copies for corruption discovered late. Store at least one copy outside the production host and monitor both capacity and last-success time.
Retention should account for database growth. A policy that works today may fail silently after months of player activity unless storage and archive sizes are tracked.
Restore into an isolated test environment
Create an empty test database, import the backup, and start a matching server copy against it. Verify table counts, plugin startup, player data, writes, and a second restart. Restoration should never be tested by overwriting the only production database.
Check collation, timezone, SQL mode, and engine version differences. A dump can import successfully while application behavior changes because the destination environment is not equivalent.
Plan migrations and schema changes
Plugin updates may alter database schema on first startup. Back up immediately before the migration and keep the old plugin files. Record whether downgrade is supported; some schema changes require restoring both database and plugin version.
During host migration, transfer database data through a verified export or replication process and prevent both old and new servers from writing simultaneously.
Document recovery ownership
The runbook should state where backups are stored, how to decrypt them, which plugin version can read them, and who can approve restoration. Remove obsolete credentials and test access before an incident.
Database protection is complete only when the team can restore the data and prove that the game features using it work correctly.
Editorial review notes
This guide is written for small Minecraft communities and self-service hosting users. Exact commands, configuration names, compatibility, and limits can vary by edition, server software, runtime, host, and installed extensions. Test changes on a copy, keep verified backups, and consult the current documentation for version-specific requirements.