# InventoryRollbackPlus tasks Task guides and troubleshooting for InventoryRollbackPlus. Check the installed release before changing configuration or data. # Plan per-event inventory history before raising record limits InventoryRollbackPlus limits saved records by event type and player, rather than promising a fixed number of days. A player who changes worlds frequently can cycle through world-change records faster than someone who rarely joins. Plan the useful history and its storage cost before raising every limit. ## Record the starting point Preserve the current configuration and a verified copy of the existing history. Record whether this installation stores YAML files or uses MySQL, along with available capacity at that destination. Increasing game-panel disk allocation does not necessarily enlarge a separate database server. ## Work through the change 1. Open the installed `config.yml` and compare its `max-saves` section with the maintainer reference. The documented event keys are `join`, `quit`, `death`, `world-change` and `force`. Record each current count without replacing it with upstream example defaults. 2. Observe a representative player's event frequency and inspect the oldest and newest records of each relevant type. Estimate the history needed from actual activity: a count of ten joins covers a very different period for daily and hourly reconnects. 3. Measure current history storage and the population it represents. Use those observations for a rough capacity budget, allowing for new players and larger inventories rather than treating one player's record size as a universal constant. 4. If capacity permits, increase only the event count that lacks useful history. Apply the setting through the installed release's documented method, then use a consenting online test player and a harmless event to confirm new records remain available. ## Check the result The selected event should have the intended higher ceiling, while other event limits remain unchanged. Record the observation period and recheck storage after representative activity. Raising a limit retains more future records; it cannot recreate older records already rotated out. ## If the result differs If no new records appear, investigate event capture and storage errors separately. If file usage stays flat on a MySQL installation, inspect the actual database destination instead of assuming retention failed. Avoid changing storage backend and record limits during the same comparison. Pause further increases if capacity is uncertain. Lowering counts can rotate away recovery points as new records arrive, so do not reduce them as an automatic rollback. Preserve the verified history and choose any later retention reduction deliberately; never delete data folders or database tables to make a capacity chart smaller. ## References and related help - [InventoryRollbackPlus maintainer reference 1](https://github.com/TechnicallyCoded/Inventory-Rollback-Plus) - [InventoryRollbackPlus maintainer reference 2](https://github.com/TechnicallyCoded/Inventory-Rollback-Plus/blob/master/src/main/resources/config.yml) - [Restore a recorded player inventory with InventoryRollbackPlus](https://help.cloudexa-hosting.com/books/minecraft-plugins/page/restore-a-recorded-player-inventory-with-inventoryrollbackplus) - [Back up game files before making changes](https://help.cloudexa-hosting.com/books/game-hosting/page/back-up-game-files-before-making-changes) # Separate inventory inspection from staff restore permissions Support staff may need to confirm a loss report without being able to give items or move a player. InventoryRollbackPlus provides separate permissions for viewing backups, restoring and related actions. Test those boundaries with a limited account instead of granting the plugin's full administrative scope. ## Record the starting point Read the installed release's permissions and decide which staff role may inspect, restore or teleport. Save the current permission assignments. Use a test player record and a staff test account that does not have operator status or a wildcard permission. ## Work through the change 1. Grant the documented inspection permission, `inventoryrollbackplus.viewbackups`, to the intended support role. Keep restore and teleport permissions absent unless the role genuinely needs them. 2. Open a test player's backup list using the documented interface. Confirm the staff account can inspect the relevant timestamp and contents. 3. Attempt a restoration action and verify it is denied for the inspection role. Check the separate restore and restore.teleport permissions in the maintainer documentation when configuring the recovery role. 4. Repeat the test after reconnecting and inspect inherited groups. A broad parent-group permission can override an apparently narrow assignment. ## Check the result The inspection account should see the intended records and remain unable to apply recovery actions. The authorised recovery role should pass a separate controlled test. Keep the final permission mapping with staff procedures so an urgent incident does not encourage an improvised wildcard grant. ## If the result differs If a supposedly limited account can restore, check operator status, inherited groups and wildcard permissions before changing the plugin. If it cannot inspect, confirm the exact permission spelling and context. A hidden button alone is not enough evidence that the action is protected. Remove trial grants and restore the previous staff assignment if the boundary cannot be demonstrated. Keep player records untouched during permission testing. If a test restoration was accidentally applied, use the pre-test checkpoint and record the correction. ## References and related help - [InventoryRollbackPlus maintainer reference 1](https://github.com/TechnicallyCoded/Inventory-Rollback-Plus) - [Restore a recorded player inventory with InventoryRollbackPlus](https://help.cloudexa-hosting.com/books/minecraft-plugins/page/restore-a-recorded-player-inventory-with-inventoryrollbackplus) - [Create Minecraft ranks and inheritance with LuckPerms](https://help.cloudexa-hosting.com/books/game-hosting/page/create-minecraft-ranks-and-inheritance-with-luckperms) # Investigate a missing InventoryRollbackPlus event record InventoryRollbackPlus can record several player events, but a missing record may be outside retention or may never have been captured. The existence of a plugin folder does not guarantee every historical inventory is available. Check the record path before telling a player their items are recoverable. ## Record the starting point Collect the player's exact identity, approximate incident time and event type. Record the plugin version and configured storage. Preserve the current data and configuration before changing capture or retention options, because a new policy cannot recreate a record that was never stored. ## Work through the change 1. Inspect the player's available records and their timestamps through the documented interface. Compare nearby event types rather than assuming every entry represents a death. 2. Review the generated configuration's capture and retention settings for the installed release. Check the relevant documented event permissions, such as deathsave, joinsave or leavesave, and any inheritance that may deny them. 3. Use a consenting test account to produce one harmless event of the missing type. Check the console for storage errors and confirm whether a new record appears. 4. Correct only the identified capture, permission or storage problem. Repeat the event and document the oldest reliable recovery point that actually remains. ## Check the result New test events should produce the expected record, and staff should know whether the original incident has a usable checkpoint. Retention counts and event frequency determine history differently from a calendar promise. State that distinction clearly when discussing available recovery. ## If the result differs If no new events save, inspect the first storage error and relevant permissions. If new records save but the old one is absent, compare retained history and other backup sources. Avoid repeatedly changing retention while expecting deleted records to return. Restore any ineffective trial setting and preserve remaining records. Use a separate verified server backup only through an approved recovery process if the plugin record is unavailable. Do not fabricate an inventory or delete the player data to force a new entry. ## References and related help - [InventoryRollbackPlus maintainer reference 1](https://github.com/TechnicallyCoded/Inventory-Rollback-Plus) - [Restore a recorded player inventory with InventoryRollbackPlus](https://help.cloudexa-hosting.com/books/minecraft-plugins/page/restore-a-recorded-player-inventory-with-inventoryrollbackplus) - [Find Minecraft logs and send useful troubleshooting details](https://help.cloudexa-hosting.com/books/game-hosting/page/find-minecraft-logs-and-send-useful-troubleshooting-details) # Create a deliberate inventory checkpoint before a player event A tournament, inventory-clearing minigame or staff experiment benefits from an explicit checkpoint rather than relying on a later join or death event. InventoryRollbackPlus provides a forcebackup command. Verify the saved record before the event begins, and keep its scope distinct from a full server backup. ## Record the starting point Identify the participating online test player and the exact state you need to preserve. Record the plugin version and approved staff role. Ask the player to stop moving items while the checkpoint is taken so its contents correspond to a clear moment. ## Work through the change 1. Use the documented command `/ir forcebackup player ` with the required authorised permission. Confirm the command targets the intended account rather than a similar display name. 2. Open the player's records and check that a new timestamp appears. Inspect representative inventory slots so a success message is supported by an actual saved checkpoint. 3. Record the checkpoint time in the event notes and explain what it covers. It does not replace backups of worlds, plugin databases or other players' inventories. 4. Proceed with the controlled event, then compare the final state before deciding whether a restoration is needed. Restore only the approved components through the normal recovery interface. ## Check the result Staff should have a recognisable pre-event record and a documented reason for it. Test the workflow with a disposable account before a valuable live event. A checkpoint that cannot be located in the restore interface should not be treated as ready for recovery. ## If the result differs If the command is denied, check the documented forcebackup permission rather than granting operator status. If no record appears, inspect storage errors and the target identity. Do not start an irreversible inventory experiment while checkpoint creation remains uncertain. Pause the event when the checkpoint cannot be verified. Preserve any existing records and use the normal server backup process if wider data protection is required. Remove temporary staff permission grants after the event instead of leaving elevated recovery access indefinitely. ## References and related help - [InventoryRollbackPlus maintainer reference 1](https://github.com/TechnicallyCoded/Inventory-Rollback-Plus) - [InventoryRollbackPlus maintainer reference 2](https://github.com/TechnicallyCoded/Inventory-Rollback-Plus/blob/master/src/main/java/com/nuclyon/technicallycoded/inventoryrollback/commands/inventoryrollback/ForceBackup.java) - [Restore a recorded player inventory with InventoryRollbackPlus](https://help.cloudexa-hosting.com/books/minecraft-plugins/page/restore-a-recorded-player-inventory-with-inventoryrollbackplus) - [Back up game files before making changes](https://help.cloudexa-hosting.com/books/game-hosting/page/back-up-game-files-before-making-changes)