CoreProtect Setup Guide: Block Logging, Rollback and Inspect Mode

CoreProtect records every block placement, block break, container interaction and explosion on your server. When someone griefs a build or claims they did not steal from a chest, CoreProtect gives you a timestamped audit trail and the ability to undo changes surgically — either by rolling back a specific player's actions or restoring a specific block or area. This guide covers the full setup and the commands your moderation team will use daily.

Installation and database choice

Drop the CoreProtect jar into plugins/ and restart. On first boot it creates plugins/CoreProtect/config.yml.

The most important configuration decision is the database backend:

• SQLite (default) — stores data in plugins/CoreProtect/database.db. Zero setup, but performance degrades past a few weeks of data on a busy server. Fine for small servers.
• MySQL or MariaDB — recommended for any server with more than 10 active players. Configure in config.yml:

use-mysql: true
table-prefix: 'co_'
mysql-host: 127.0.0.1
mysql-port: 3306
mysql-database: coreprotect
mysql-username: coreprotect
mysql-password: your_password_here

Create the database and user in MySQL before restarting:

CREATE DATABASE coreprotect;
CREATE USER 'coreprotect'@'localhost' IDENTIFIED BY 'your_password_here';
GRANT ALL ON coreprotect.* TO 'coreprotect'@'localhost';
FLUSH PRIVILEGES;

config.yml key settings

check-updates: true
verbose: true              # log actions to console as they happen (turn off on busy servers)
default-radius: 10         # default search radius for /co lookup and rollback
max-radius: 100            # maximum allowed radius for non-admin commands
rollback-items: true       # log item pickups and drops
rollback-entities: true    # log entity kills
log-chat: true             # log chat messages (useful for moderation)
log-commands: true         # log commands run by players
log-logins: true           # log login/logout with IP

On a busy server, set verbose: false to reduce console noise. The logs are still recorded — verbose only controls whether each action prints to the console in real time.

Inspect mode — the first tool to learn

Inspect mode is the fastest way to investigate a single block. Enable it with:

/co inspect
# or shorthand:
/co i

While inspect mode is active, clicking any block shows you every recorded action on that block — who placed it, when, who broke it, and in what order. Left-clicking shows block break data; right-clicking shows interaction data (like opening a chest). Click the same block again to see older entries if multiple actions are recorded.

Toggle inspect mode off with /co i again. The mode persists until you turn it off, which is easy to forget — staff sometimes leave it on and wonder why their blocks are not placing.

Lookups — querying the database

The /co lookup command (shorthand /co l) queries the database with filters. Filters can be combined:

/co lookup user:Steve action:break time:24h radius:20
/co l u:Steve a:block t:1h r:20

Key filter parameters:

• user:<name> — filter by player. Use multiple: user:Steve,Alex.
• time:<duration> — how far back to look. Format: 2h30m, 1d, 30m.
• action:<type> — filter by action: block, +block (placement only), -block (breaks only), click, kill, container.
• radius:<number> — search within N blocks of your position. Use radius:global for a server-wide search.
• block:<material> — filter by block type: block:diamond_ore.
• world:<name> — limit search to a specific world.

Navigate results with /co lookup <page> (e.g. /co l 2 for page 2). Each result shows the timestamp, player, action and block type.

Container logging

CoreProtect logs what goes in and out of containers (chests, hoppers, furnaces, barrels). To check who took from a specific chest:

1. Enable inspect mode: /co i
2. Right-click the chest.
3. CoreProtect shows every item interaction with timestamps and player names.

Or use a lookup filtered to container actions:

/co lookup action:container user:Steve time:12h radius:5

Rolling back a player's actions

The rollback command undoes a player's logged actions within a defined area and time window. Always inspect and look up first to confirm you are rolling back the right actions:

/co rollback user:Steve time:2h radius:15
# shorthand:
/co rb u:Steve t:2h r:15

CoreProtect previews what will be rolled back before executing. Confirm with /co rb confirm or cancel with /co rb cancel.

Rollback restores the physical blocks but does not return items to inventories or restore entity kills. If Steve killed a farm full of animals, you will need to respawn them manually or use a creative-mode spawning tool.

Restoring (undoing a rollback)

If you rolled back too much or the wrong player, restore re-applies the actions that were undone:

/co restore user:Steve time:2h radius:15
/co rs u:Steve t:2h r:15

Restore and rollback can also be applied to specific block types. To only roll back diamond ore breaks (catching xray miners):

/co rb u:Steve t:7d r:global a:-block b:diamond_ore

Checking for xray miners

CoreProtect is the best tool for investigating suspected xray. Run:

/co lookup user:SuspectPlayer action:-block block:diamond_ore time:7d radius:global

If the player broke dozens of diamond ore with no other block types in between, that is a strong indicator of xray. Legitimate miners break many stone and deepslate blocks for every ore they find. A ratio of 1:1 diamond ore to other blocks is a red flag.

Purging old data

Over time the CoreProtect database grows significantly. Purge old data with:

/co purge time:30d

This deletes all logs older than 30 days. Run this monthly as a maintenance task. On SQLite, also run VACUUM on the database file afterward to reclaim disk space:

/co purge time:30d #vacuum

Permission setup with LuckPerms

# Give all staff inspect mode
/lp group helper permission set coreprotect.inspect true
/lp group helper permission set coreprotect.lookup true

# Give mods rollback
/lp group mod permission set coreprotect.rollback true
/lp group mod permission set coreprotect.restore true

# Give admins full access including purge
/lp group admin permission set coreprotect.* true

Common mistakes

• Using SQLite on a busy server. Queries slow down dramatically as the database grows. Migrate to MySQL before you need to, not after.
• Not setting a max-radius. Default unlimited radius means any staff member can run a global lookup and block the server thread. Set max-radius: 500 in config and grant coreprotect.global only to admins.
• Forgetting container logging is on. Some servers disable container logging for performance. If you do, you lose chest-theft evidence entirely. Keep it enabled unless you have a specific performance reason not to.
• Relying on CoreProtect as a backup. CoreProtect records block data but is not a file backup. A corrupted world file cannot be recovered from CoreProtect logs alone. Maintain separate file backups.

Need hosting with full config access? Astroworld Hosting — Pterodactyl panel, NVMe SSDs, 24/7 support.