Decide what the audit trail must answer
CoreProtect records block, container, item, chat, command and other server activity so an administrator can investigate a change and, when appropriate, reverse it. It is an audit and recovery aid, not a time machine: it cannot reconstruct events from before the plugin was enabled, and it does not replace a restorable world backup. Start with the questions a moderator actually needs to answer: who changed this area, when did it happen, what was placed or removed, and which actions should be restored?
Write down the Paper build, Minecraft version, Java runtime, worlds, plugins and backup location. CoreProtect's current community release supports Minecraft 1.16.5 and newer; use the exact release page and generated configuration. The trust checks in /blog/install-plugins-paper-minecraft-server matter because a plugin runs with the server account's access.
Choose a maintenance window, stop Paper cleanly and take a complete backup before installing. Preserve the server directory, worlds, configuration, plugins and any external database at one known point. A rollback changes world data, so the backup is your escape hatch if the filter is too broad or a plugin interaction surprises you. Keep the original archive until a test lookup, a preview and a small restore have all passed.
- Define the moderation question and the worlds it covers.
- Confirm the Paper/Minecraft target and use the matching CoreProtect build.
- Back up the stopped server before adding a plugin that can change blocks.
- Keep a written recovery point and rollback owner for the maintenance window.
Install the Paper plugin and verify the first boot
Download CoreProtect Community Edition from the project's official GitHub release or a project-controlled download linked from its documentation. Read the release notes and choose the Bukkit/Paper server JAR, not a Fabric build or an unrelated add-on. With Paper fully stopped, place one CoreProtect JAR directly in the server's plugins directory. Keep an older JAR in the offline backup rather than beside the new file; Paper does not support two active copies with the same plugin name.
Start Paper normally and read logs/latest.log from the beginning. Paper's plugin guide says the file must be at the root of plugins and that the console plugins command should show a newly enabled plugin in green. A red or missing entry is a failed installation, not a reason to continue to a production rollback. Resolve an invalid plugin description, duplicate name, missing Java requirement or other startup error first, then stop and edit only the generated CoreProtect files.
Run /co help from the console or as an authorized operator after the clean boot. The current command set includes inspect, lookup, rollback, restore, purge, reload and status. Confirm config.yml was created and make a small block change in a test area. A lookup for that change is a better installation check than a directory existing on disk.
- Use one official Paper-compatible JAR and install it while the server is stopped.
- Read the full startup log and confirm a green CoreProtect entry.
- Run /co help and /co status from the intended Paper backend.
- Create one harmless test change, then confirm that CoreProtect can find it.
Configure logging, storage and retention deliberately
CoreProtect's configuration lives in its plugin folder. Leave generated defaults for the first test, then review which block, container, item, entity, chat and command events your community needs. Per-world files such as world_nether.yml override only the values they contain, letting you reduce lobby noise without disabling survival auditing.
The current documentation describes embedded and external database options, and warns that changing database-type selects a separate dataset rather than copying history. Do not switch storage by hand during an incident. If migration is genuinely required, use the console-only process, keep database-lock enabled, back up config.yml and the source database, and validate the target before restarting. For one Paper server, the generated embedded configuration is usually the safest starting point.
Retention is a capacity decision. The normal /co purge command removes old history only when you ask for it, while automatic purging is a Patreon-only feature in current 24.0+ documentation. Before deleting data, decide how long moderators need to investigate and how much disk the history may consume. Run a manual purge from the console with an explicit age, preserve the backup, and remember that purging history does not undo blocks in the world.
- Keep the first logging test broad enough to prove the events you need.
- Use per-world overrides only after documenting why a world differs.
- Treat database-type changes as migrations, not harmless config edits.
- Set a retention policy before running /co purge; never confuse it with a world rollback.
Inspect a block before running a global lookup
When a player reports griefing, start at the exact block rather than searching the entire database. Give a trusted moderator the narrow coreprotect.inspect permission (default: operator) and toggle /co inspect. Left-click or interact with the affected block as the project documents, read the actor, action and timestamp, then toggle inspect off. Capture the result and the server time before changing anything. Inspection is evidence collection, not an automatic repair.
Use /co lookup for a wider pattern. Parameters constrain a user with u:<name>, time with t:<time>, radius with r:<blocks>, action with a:<action>, and materials with i:<include> or e:<exclude>. For example, /co lookup r:20 t:2h a:-block limits block breaks to 20 blocks over two hours. Lookups are global by default, so add a boundary for local incidents.
Results paginate. Record the command, page, world, time range and relevant rows. Confirm a player's identity and the affected world before treating a name as proof of intent; automated actors and explosions can also appear. Never paste raw logs, database files or credentials into a public report.
- Use inspect for one block and lookup for a deliberately bounded pattern.
- Always specify a time window and radius for local grief reports.
- Record the exact command and result before attempting a rollback.
- Keep CoreProtect data and moderation notes away from public channels.
Preview and roll back only the confirmed damage
CoreProtect rollback uses the same filters as lookup. Begin with a preview hashtag so the server reports what would change without touching the world: /co rollback u:PlayerName t:30m r:15 #preview. The command documentation applies a default radius of 10 when none is supplied, while r:#global explicitly requests a global rollback. Treat that default as a safety net, not a substitute for writing the radius yourself.
Compare the preview with the incident record. Narrow by action or material—for example a:-block for broken blocks or i:stone—and exclude unrelated changes with e:. If it includes a farm, machine, container or legitimate build, refine the filter. Never run a global user rollback because a name appears in one lookup. Confirm the world and time boundary before applying.
Run the confirmed rollback from the console or with coreprotect.rollback. Watch the server log, keep players out of the area and take a fresh backup before a large repair. Inspect several repaired blocks, check containers and redstone, and have the requesting moderator verify the result.
- Use #preview first and write an explicit user, time and radius filter.
- Inspect the preview for legitimate neighboring work before applying it.
- Prefer the smallest action/material filter that answers the incident.
- Back up before broad repairs and verify multiple restored locations afterward.
Use restore or undo when the repair was wrong
A rollback is not irreversible if CoreProtect still has the relevant history. The /co restore command uses the same parameters and reverses a previous rollback by restoring the player actions that were removed. The documentation also provides /co undo as an alias that applies the opposite action. Use a preview again, keep the same time/radius boundary, and identify the rollback in the change record before attempting to undo it.
Restoring is not the same as loading a world backup. It can reapply logged changes, but cannot recreate unlogged data, repair a plugin database or guarantee a perfect state after overlapping rollbacks. For a large or ambiguous incident, preserve the current world and logs, then restore the coherent backup in isolated staging. The workflow in /blog/automatic-paper-minecraft-server-backups is safer for catastrophic damage.
Run a post-repair acceptance check: join with a normal account, visit the repaired area, inspect containers and claims, reconnect, and confirm that scheduled backups still complete. Keep the before-and-after timestamps, commands, operator, preview output and verification result. This turns a one-off command into an auditable change and makes future moderation decisions easier to defend.
- Use /co restore or /co undo only after identifying the exact earlier rollback.
- Preview the inverse operation with the same narrow filters.
- Use a complete backup restore for large, ambiguous or database-related damage.
- Record and verify the repaired state before returning the area to players.
Limit permissions and keep the audit useful
CoreProtect permissions default to operator for sensitive commands. Grant coreprotect.inspect, coreprotect.lookup, coreprotect.rollback, coreprotect.restore and coreprotect.status separately to a reviewed moderator group instead of handing out coreprotect.*. The permissions guide lists the individual nodes, and the least-privilege model in /blog/setup-luckperms-paper-server shows how to build inherited groups, test ordinary accounts and remove a grant cleanly.
Keep the CoreProtect database and configuration in the normal backup set. Test an isolated restore after a Paper or plugin update, and record retention, storage path, database type and rollback owner. If shared storage or multiple backends becomes necessary, follow CoreProtect's migration documentation rather than copying files between live servers.
Use CoreProtect to answer measured incidents, not to replace moderation policy, backups or access control. Review the latest release notes before updating, install one version at a time, and repeat the known test change, lookup, preview and small restore after every upgrade. More administration guides live at /blog. If the verified workload needs isolated staging, dependable storage or more support, compare the documented options at /pricing after the audit workflow itself is proven.
- Grant individual CoreProtect nodes to a reviewed moderator group.
- Back up CoreProtect data with worlds and plugin state, then test the restore path.
- Treat database migrations as maintenance projects with a source backup and validation.
- Repeat a known lookup and preview after every plugin or Paper update.
Frequently asked questions
Quick answers
Does CoreProtect work on a Paper server?
Yes. Install the official Bukkit/Paper-compatible CoreProtect JAR in Paper's plugins folder, restart fully and confirm that the plugin enables in the startup log.
How do I inspect who broke a block with CoreProtect?
Give a trusted moderator coreprotect.inspect, toggle /co inspect, interact with the affected block and record the actor, action and time. Toggle inspect off when finished.
How do I safely roll back griefing with CoreProtect?
Run a narrow /co lookup, then a /co rollback with explicit user, time and radius filters plus #preview. Review the preview, back up and apply only the confirmed repair.
Can I undo a CoreProtect rollback?
Usually. /co restore uses the same filters to reverse a rollback, and /co undo is the documented opposite-action alias. Preview the inverse and keep the same boundary.
Does CoreProtect replace Minecraft backups?
No. CoreProtect can inspect and reverse logged actions, but it cannot recover unlogged history, plugin databases or every form of world corruption. Keep and test complete server backups.