CoreProtect: Logging, Lookups and Rollbacks for Minecraft

A player logs on, finds their base hollowed out, and asks you who did it. Without a block logger you have no answer and no repair — the only tool left is a world backup, which costs everyone else their afternoon. CoreProtect is the plugin that turns that into a two-minute job: right-click the hole, read the name, roll back exactly what that player touched and nothing else.

It has been in continuous development since early 2012 and it is the de-facto standard block logger on Paper, Spigot and Purpur. It needs no configuration to start working. Install it, restart, and it logs from that moment onwards.

This guide covers the inspector, lookups, rollbacks and restores, every parameter letter, the radius trap that turns a small incident into a big one, retention and purging, permissions, and the storage backends. The wider question of when to roll back versus when to restore a backup is covered in Minecraft Grief Protection and Rollback.

Installing It

Drop the jar in plugins/ and restart. There is nothing to configure first; plugins/CoreProtect/config.yml is generated on first run with sensible defaults. Plugin installation in general is covered in How to install plugins for Minecraft Java Edition.

As of 19 August 2026 the current public Community Edition release is v24.0, published 7 July 2026, supporting Spigot 1.16.5 through 26.1.2. It does not yet cover Minecraft 26.2 in a stable public build — the project's development builds cover 26.2 and later, and those are available either self-compiled from GitHub or pre-compiled through the project's Patreon. CoreProtect runs on Bukkit, Spigot, Paper, Purpur, Folia and MultiPaper.

There are several separate CoreProtect editions

The Spigot download is the Community Edition for modern Bukkit-family servers. CoreProtect for Fabric is a different build, distributed through the project's Patreon rather than the main download page. There is also a Legacy Edition for Spigot 1.8 to 1.12, and a Hytale edition. Grab the wrong one and it will not load.

Nothing that happened before you installed it exists

CoreProtect replays a log, and the log starts when the plugin starts. There is no way to recover griefing from before the install. If you are reading this because something has already happened, your only option is a world backup from before the incident — see How to create a backup.

The Commands

Every CoreProtect command is a subcommand of /co. /core and /coreprotect are longer aliases.

Step One: Inspect

/co i turns the inspector on; running it again turns it off. With it on, clicking tells you the history of what you clicked:

For most incidents this is the entire investigation. Walk to the hole where the wall used to be, right-click into it, read the name.

Step Two: Look Up

/co lookup takes the same six parameters as /co rollback and /co restore, which is why learning them once is worth the effort. All of them are optional.

Time amounts combine and accept decimals, so t:5d2h is five days and two hours and t:2.50h is two and a half. A range like t:1h-2h looks at the window between one and two hours ago.

The action list

Several actions take a + or - prefix. + means added, - means removed.

/co lookup i:diamond_ore t:1h a:-block

/co lookup u:Steve t:3d a:container

/co lookup u:Steve a:session

Results are paginated. /co l <page> moves between pages, and /co l 1:10 returns ten lines starting at page one. Adding #count returns just the number of matching rows, which is the fastest way to size an incident before you touch anything.

Lookups are global by default; rollbacks are not

A lookup with no r: searches the entire server. That makes /co lookup u:Griefer t:6h #count a safe first move on any incident — it tells you how much damage there is before you commit to anything.

Step Three: Roll Back

This is the mistake that turns a small incident into a big one

A rollback with no r: uses a radius of 10 blocks around you. The command you just ran to survey damage across the whole map will, if you swap lookup for rollback, fix only the ten blocks nearest your feet — and the console will report success, so you will believe the job is done. Always state the radius on a rollback. r:#global for the whole server, r:#world_nether for one world, or a number.

Preview first. #preview runs the rollback visually, for you alone, without changing the world:

/co rollback u:Griefer t:2h r:#global #preview
/co rollback u:Griefer t:2h r:#global

If the result is wrong, /co undo reverses your last rollback or restore by running the opposite action over the same data. /co restore does the same thing explicitly and is also how you reapply something you rolled back by mistake.

Four refinements do most of the real work:

• a:-block rolls back only what they broke, leaving anything they placed alone. Useful when a griefer also built something you want to keep as evidence.
• e:stone,dirt excludes block types you would rather not churn.
• i:diamond_ore does the inverse and touches only what you name.
• r:#worldedit (or r:#we) limits the rollback to your current WorldEdit selection. This is the cleanest way to repair one building without touching its neighbours — select the damage with //wand, then roll back inside it. See Minecraft WorldEdit: Selections, Brushes and Schematics.

Four hashtags can be appended to a command:

Worked examples

/co rollback u:Notch t:1h r:#global e:stone,dirt

/co rollback u:Notch t:1h i:stone a:-block r:20

/co rollback t:15m r:#worldedit

/co restore u:Steve t:20m r:10 a:container

Retention: Your Rollback Window Is Finite

/co purge t:30d

Purging is how you stop the database growing forever, and whatever value you purge at is your rollback window.

From the console, /co purge can delete anything older than 24 hours. In game it will only delete data older than 30 days — a guard rail against somebody purging the evidence of their own griefing. You can scope a purge to a world (/co purge t:30d r:#world_nether, CoreProtect v19 and later) or to block types (/co purge t:30d i:stone,dirt, v23 and later).

Adding #optimize also reclaims disk space, but it is rarely worth it: SQLite already rebuilds and reclaims as part of a manual purge, DuckDB checkpoints automatically, and on MySQL and ClickHouse #optimize can slow the purge down significantly. The project's own guidance is that it is generally unnecessary.

Retention is the real limit on what you can undo

A griefer who plants a trap and triggers it two months later is past the end of a 30-day log, and there is nothing to replay. Pick a retention period you can live with. It is a straight trade against disk usage, and it is the number that decides whether an old incident is recoverable at all.

CoreProtect 24.0 and later can purge on a daily schedule via auto-purge in config.yml — auto-purge: 180d keeps 180 days, the minimum accepted value is 30d, and auto-purge-time: 03:30 moves the run off midnight. That feature is exclusive to the project's Patreon builds. On a Community Edition build, put a /co purge on the panel's Schedules tab instead; scheduling is covered in Minecraft Scheduled Restarts and Server Automation.

If you are enabling automatic purging on a database that has never been purged, run one manual /co purge at the same retention first, so the scheduled runs are only keeping up rather than catching up.

Permissions

Every command has its own node and they all default to op:

There is also a set of child permissions designed to be used negatively: coreprotect.lookup.block, .chat, .click, .command, .container, .inventory, .item, .kill, .spawn, .near, .session, .sign and .username. Each defaults to op, and setting one to false on a rank removes that one kind of lookup while leaving the rest.

lp group mod permission set coreprotect.lookup true
lp group mod permission set coreprotect.rollback true
lp group mod permission set coreprotect.lookup.chat false
lp group mod permission set coreprotect.lookup.command false
lp group mod permission set coreprotect.purge false

Setting a negative node is a LuckPerms job, not a CoreProtect one — see How to Set Up LuckPerms Permissions for Minecraft. Note the difference between unset and false there: only an explicit false beats an inherited true.

Where the Data Lives

The database sits in plugins/CoreProtect/, selected by database-type in config.yml. Four backends exist:

New installations on 25.0 and later default to DuckDB; on older builds, including the current 24.0 Community Edition, new installs use SQLite. Upgrading an existing install never silently switches backend — CoreProtect derives the value from your old config and writes the matching sqlite or mysql entry.

Two warnings about changing it. Changing database-type selects a different dataset; it does not copy your data, so you will appear to have lost your history. And migration (/co migrate-db <target>) is a Patreon-build feature: SQLite to MySQL needs 23.0+, and anything involving DuckDB or ClickHouse needs 25.0+. Migration is console-only, pauses persistence while it runs, can take hours on a large database, and requires an empty target.

For most servers, leave it alone. MySQL is worth considering only if you want the log off the game server's disk — you can create one from the panel's Databases tab, per How to create a Database via your panel.

The log is not a backup, and it sits on the same disk as the world

A rollback replays events; a backup stores state. CoreProtect cannot help with a corrupted region file, a botched version upgrade, a world folder somebody deleted, or a volume-level failure — none of those fired a block-change event, and the database dies with the world anyway. Take a backup before you roll back. /co undo is your first line of retreat; the fresh backup is your second.

Common Issues

• /co rollback only fixed a small area. No r: was given, so it used the default radius of 10. Re-run with r:#global or a number.
• /co lookup returns nothing for an old incident. It is past your purge retention, or it predates the install.
• The rollback rebuilt the griefer's work too. You rolled back everything they did. Use a:-block to reverse only breaks.
• Items came back but the ones in the thief's inventory did not. Container transactions (a:container) restore what was taken from a chest. A rollback acts on the world, not on hunting items down across the map.
• The database file is huge. Expected on a busy server. Purge to a retention you can live with; #optimize will not help on SQLite because a manual purge already reclaims space.
• The plugin loaded but nothing is logged. Check /co status, and check the per-world logging settings and the logging blacklist in config.yml — both can turn logging off for specific worlds, users or blocks.
• It will not start on a Fabric server. The Bukkit build does not run on Fabric. The Fabric edition is a separate Patreon-distributed download.

FAQ

Can I roll back griefing from before I installed CoreProtect?

No. It replays only what it logged, and it starts logging when it starts running. A world backup from before the incident is the only option.

How far back can it roll back?

As far as your data goes, which is set by how often you purge. /co purge t:30d leaves a 30-day window.

Does CoreProtect slow the server down?

It writes through a background consumer queue rather than on the main thread, and some of the busiest servers in the game run it. If you suspect it, profile rather than assume — see Diagnosing Minecraft Server Lag.

Will it undo stolen items?

Container transactions are logged, so a:container rollbacks restore items taken from chests. a:inventory records what moved through a player's own inventory, but a rollback acts on the world rather than reaching into people's inventories.

Does it log WorldEdit?

Yes, and supported FastAsyncWorldEdit clipboard pastes too. That is also why r:#worldedit works as a rollback scope.

Do I need WorldGuard as well?

They do different jobs and most established servers run both. CoreProtect is the higher priority: without it an incident is unrecoverable, whereas without WorldGuard it is merely repeatable. See Minecraft WorldGuard: Region Protection Explained.

What is the fastest sequence when something has just happened?

Ban or kick the griefer, take a manual backup, /co i and click the damage to identify them, /co lookup u:<name> t:6h r:#global #count to size it, #preview the rollback, then commit it. The full runbook is in Minecraft Grief Protection and Rollback.

What to Read Next

• Minecraft Grief Protection and Rollback for the incident runbook and how rollbacks compare to backups
• Minecraft WorldGuard: Region Protection Explained for stopping it happening again
• Minecraft WorldEdit: Selections, Brushes and Schematics for r:#worldedit selections
• How to Set Up LuckPerms Permissions for Minecraft for the negative child permissions above
• How to create a backup — the layer CoreProtect does not replace
• Minecraft Scheduled Restarts and Server Automation for scheduling a purge without a Patreon build
• Minecraft Whitelist and Ban Management for keeping them out afterwards

Primary sources used for this guide (all checked 19 August 2026): the official CoreProtect documentation — commands and parameters, permissions, configuration, automatic purging and database migration; the CoreProtect Community Edition resource page on SpigotMC for the current release, supported versions and the separate Fabric, Legacy and Hytale editions; and the CoreProtect project on Modrinth.

Made with 💜 by GameServerKings