Updates and backups
- Latest version
- 1.7.4
- Minecraft
- 26.x
- Platforms
- Spigot, Paper, Folia, Purpur, Velocity, BungeeCord
- Minimum Java version
- 25+
This article was written for 1.7.0. The latest stable release is 1.7.4; use the current requirements above.
Updates and backups
This Wiki describes version 1.7.0. Keep a recoverable database backup and a copy of the plugin configuration before changing versions or profile mappings.
Updating the plugin
Older bridge builds: 1.7.0 uses signed protocol v2 and rejects old unsigned packets. Upgrade the proxy and backends together and configure the shared secret on the proxy too. Keep valid existing settings and player data; do not mix legacy builds on the shared database.
SQLite backups and recovery
To recover, stop the backend and keep a copy of the complete current database state, including any -wal/-shm sidecars. Restore the chosen snapshot to the path configured by storage.sqlite.file; handle old sidecars as part of a clean stopped-server restore. Restore matching configuration and restart. Never overwrite the live database while the server runs.
MySQL backups and recovery
Use your database provider's consistent backup and restore tools. The built-in backup command is SQLite-only. Stop participating backends for recovery, preserve the current database, restore a consistent backup with matching configuration, and validate the network before reopening it. Restoring an old backup reverts player data to that backup's state.
What reload applies
Backend
This Wiki describes version 1.7.0. Keep a recoverable database backup and a copy of the plugin configuration before changing versions or profile mappings.
Updating the plugin
- Stop all participating backends. For a bridge upgrade, stop the proxy too so old and new protocol versions are not mixed.
- Back up SQLite or MySQL and the configuration files. Keep the previous JAR for recovery.
- Replace the Universal JAR on every participating backend and on the proxy when installed. Remove duplicate plugin JARs.
- Review new defaults and merge needed settings without overwriting credentials or profile mappings. Recheck unique IDs, matching sync/admin policy and the bridge secret.
- Start the network, check startup and status, then test transfers, profile separation and staff actions before players return.
Older bridge builds: 1.7.0 uses signed protocol v2 and rejects old unsigned packets. Upgrade the proxy and backends together and configure the shared secret on the proxy too. Keep valid existing settings and player data; do not mix legacy builds on the shared database.
SQLite backups and recovery
/isync backup writes a consistent snapshot into plugins/InventorySyncPRO/backups/, named inventories-<timestamp>.db. Only one backup runs at a time. This command backs up the database, not configuration files or worlds. It does not provide automatic scheduled backups or an in-game restore command.To recover, stop the backend and keep a copy of the complete current database state, including any -wal/-shm sidecars. Restore the chosen snapshot to the path configured by storage.sqlite.file; handle old sidecars as part of a clean stopped-server restore. Restore matching configuration and restart. Never overwrite the live database while the server runs.
MySQL backups and recovery
Use your database provider's consistent backup and restore tools. The built-in backup command is SQLite-only. Stop participating backends for recovery, preserve the current database, restore a consistent backup with matching configuration, and validate the network before reopening it. Restoring an old backup reverts player data to that backup's state.
What reload applies
Backend
/isync reload validates configuration and reloads messages. Storage, profiles, synchronization, bridge and manual administration-policy changes require a restart. The administration GUI applies its switches immediately. Proxy /isyncproxy reload reloads proxy.properties; invalid settings leave the last valid proxy configuration active.