Someone digs a hole through your spawn wall at 3 AM, empties a community chest, and pours lava across the storage room floor. If your server has no logging, that night turns into a guessing game where everyone is a suspect. CoreProtect turns it into a five-minute job. This guide exists to help you install CoreProtect, read the logs like an investigator, and roll back grief without nuking the legitimate builds sitting a few blocks away.

It is written for Minecraft server owners, administrators, and staff who run survival, SMP, or public servers and need a dependable audit trail. Plugin developers who want to understand how block-change data is queried will also find the command semantics and database notes useful. You do not need to be a database administrator to follow along, but if you are one, the tuning section is built for you.

Everything here comes from running CoreProtect on a Paper 1.21 survival server with a few hundred active players, first on the embedded database and later on MariaDB 11. We deliberately broke things: rolled back tens of thousands of blocks, purged old data, watched query latency, and measured disk growth. The commands, parameters, and numbers below reflect that testing, cross-checked against the official CoreProtect documentation and the CoreProtect GitHub repository.

What CoreProtect Logs (and Why That Matters)

CoreProtect is a data-logging and anti-griefing plugin. Every time a player places, breaks, or interacts with something, it records a row describing who did it, what changed, where it happened, and when. That single sentence is the foundation of every investigation you will ever run, so it is worth knowing exactly what is captured and what is not.

Blocks, containers, and items

• Block placement and breaking, stored with exact coordinates, world, and timestamp.
• Natural and environmental changes such as water and lava flow, fire spread, leaf decay, explosions, and tree growth, so you can tell grief apart from nature.
• Container transactions: items withdrawn from and deposited into chests, barrels, shulkers, hoppers, dispensers, and other inventories.
• Item pickups, drops, crafting, trading, and item frames or paintings being removed.
• Sign text, banner edits, and interactions with doors, buttons, and levers.

In modern CoreProtect builds, the plugin logs far more than the classic block list. It also captures WorldEdit and FAWE operations, suspicious sand and gravel brushing, copper golem interactions, chiseled bookshelf and decorated pot contents, and villager job-site or gossip changes. That breadth is exactly what makes a thorough investigation possible.

Chat, commands, and sessions

Logging is not limited to physical blocks. CoreProtect can record the human layer of an incident too, which is often what actually helps you identify a suspect.

• Player chat messages, including the exact time they were sent.
• Commands typed by players and operators, which is critical for catching abuse of powerful commands.
• Player sessions: login, logout, deaths, and username changes.
• Kills and death reasons, including who caused a death and with what.

All of this is configurable. CoreProtect ships with safe defaults and no required configuration, but you can enable or disable categories such as block placement, block breaking, container transactions, chat, commands, and sessions. You can also include or exclude specific blocks, items, entities, users, and entire worlds through the logging blacklist. If you run a creative plot world where logging is pointless noise, exclude it and save disk.

Installing CoreProtect and Choosing a Database

Installation is intentionally simple, but the database decision you make in the first week will determine how the plugin behaves for the next year. Get it right up front and you will never think about it again.

Install steps

1. Stop the server cleanly so no writes are in flight.
2. Download the latest CoreProtect build and drop the jar into your plugins/ folder.
3. Start the server once to generate plugins/CoreProtect/config.yml and the default database.
4. Stop the server again, open the config, and decide on your storage backend.
5. Set your preferred worlds, logging categories, and the retention window, then start the server and run /co status to confirm logging is active.

For a first run, CoreProtect creates an embedded database automatically. Modern versions default to DuckDB, a columnar store that is fast for this exact read-heavy workload. SQLite, MySQL, and ClickHouse are also supported. For most large communities, MySQL-compatible storage, and specifically MariaDB, remains the most battle-tested choice because it is easy to back up, monitor, and scale independently of the game server.

Why MariaDB or MySQL beats SQLite at scale

SQLite is a single-file database and it is genuinely fine for a small whitelist server with a handful of players. The problem is concurrency. SQLite locks the whole database file for writes, so once dozens of players are breaking blocks, opening chests, and chatting at the same time, write contention builds up. You feel it as server lag spikes and rising tick times. A networked database like MariaDB handles concurrent writes far better and runs comfortably on its own process, which also means you can back it up without stopping the game. If you want the full setup walkthrough, our guide to Database Optimization: Setting Up MariaDB for LuckPerms and CoreProtect covers the entire configuration.

Switching is a config change, not a rewrite. You point CoreProtect at your database host, port, name, username, and password, restart, and the plugin creates its tables. CoreProtect even ships a migration command so you can move existing history between backends without losing your audit trail. Whatever you choose, remember that a database is only as good as its backups, which is why we also keep How to Set Up Automated Minecraft Server Backups on Linux in the playbook.

The CoreProtect Command Reference

CoreProtect has a small command surface, but the parameters are where the power lives. Learn them once and you will never fumble an investigation again. Run /co help in game for the built-in reference.

The parameters that do the real work

• u:<user> restricts results to one or more players, for example u:Steve or u:Steve,Alex. You can also target environmental causes such as u:#tnt, u:#creeper, or u:#fire.
• t:<time> sets a time window. Units are weeks, days, hours, minutes, and seconds, and they combine: t:2w,5d,7h or t:5d2h. Ranges like t:1h-2h and decimals like t:2.50h also work.
• r:<radius> targets blocks within that many blocks of your position. Use r:30 for a local fix or r:#global to hit the whole server. World-scoped radii such as r:#world_nether and WorldEdit selections with r:#we are supported too.
• a:<action> narrows to one action type: a:block, a:+block, a:-block, a:container, a:chat, a:command, a:session, a:kill, and more.
• i:<include> limits the search to specific blocks or items, for example i:diamond_block,netherite_block.
• e:<exclude> removes matches, so e:tnt keeps the explosion out of your results.

One subtle but important difference: lookups default to a global search, while rollbacks default to a radius of 10 blocks unless you specify otherwise. Forgetting that single fact is the most common reason a rollback does not touch the damage the admin expected.

# Who broke blocks within 30 blocks in the last hour?
/co l u:Steve t:1h r:30 a:-block

# Roll back everything Steve placed or broke near spawn in 2 hours
/co rb u:Steve t:2h r:#global

# Undo a mistaken global rollback
/co undo

# Delete logs older than 90 days
/co purge t:90d

A Repeatable Grief Investigation Workflow

Grief reports arrive as emotion, not data. The victim is angry and the timeline is fuzzy. Your job is to convert the report into a precise set of filters. A consistent workflow keeps you from over-rolling or missing damage.

Step 1: Confirm the grief

Stand where the damage is and run /co inspect, then click the affected block or chest. The inspector shows the most recent changes without you typing a filter. This is the fastest way to answer the only question that matters first: was this a player, or was it a creeper, fire, or decay? If the inspector shows no player actions, you may be looking at a natural event and there is nothing to roll back.

Step 2: Find who and when

Once you know the damage is player-caused, widen the view. Run a lookup anchored to your position with a generous radius and a time window that covers the report. If you do not have a suspect yet, run a lookup without u: so you can see every player who touched that area.

/co l r:50 t:3d a:block
/co l r:50 t:3d a:container

The results give you a name and an exact timestamp. From there you can pull the suspect session with /co l u:Steve t:3d a:session to see when they logged in and out, and /co l u:Steve t:3d a:chat to read what they were saying around the incident.

Step 3: Scope the rollback precisely

Scope is everything. A rollback that is too wide erases innocent work; one that is too narrow leaves the grief in place. Use the suspect name, a time window that brackets the incident, and the tightest radius that still covers the damage. Prefer action filters so you do not accidentally revert unrelated activity.

/co rb u:Steve t:30m r:40 a:block
/co rb u:Steve t:30m r:40 e:tnt

Always run a lookup with the identical filters before you roll back. If the lookup output looks like exactly the damage, the rollback will too. That one habit prevents almost every rollback disaster.

Step 4: Communicate with the victim

Restoring the blocks is only half the job. Tell the player what you found, what you did, and what happens next. A short, factual message keeps trust intact and stops the ticket from reopening. If the rollback cannot fully restore contents, say so immediately and compensate fairly rather than letting the player discover the gap later.

Best Practices for Safe Rollbacks

• Test on a copy first. Restore your database into a staging server, rehearse the exact rollback command, and confirm the result before touching production.
• Warn your staff. Post in your staff channel before a large rollback. Builders who see their work vanish mid-session will panic and start rebuilding, which complicates everything.
• Avoid overlapping rollbacks. Wait for one rollback to finish before starting another. Two big jobs competing for the same coordinates produce unpredictable results.
• Use /co undo as your safety net. It reverses your last rollback or restore, so a mistake is recoverable, but only if you act before running something else.
• Roll back the cause, not just the symptom. If a player duplicated items, rolling back the blocks does not remove the duped stacks. Handle that separately, as covered in Preventing Item Duplication Exploits on Paper Servers.
• Document every rollback. Log the ticket, the filters, and the outcome so a second admin can reconstruct what happened weeks later.

Performance Tuning, Retention, and Backups

Retention and pruning

CoreProtect grows forever by default. That is a feature and a trap. A busy public server can generate gigabytes of rows per month, and an unbounded database eventually slows lookups and eats your disk. Set a retention policy that matches your practical investigation window, usually 30 to 90 days. Purge old data on a schedule with a command like /co purge t:90d, run from the console during low traffic.

Note the safeguards: from console you can only purge data older than 24 hours, and in game the minimum is 30 days. That protection exists so a tired admin cannot wipe recent history by accident.

Tuning for large databases

• Keep the database on fast storage, ideally an SSD, and separate from the world files if possible.
• Give MariaDB a sensible buffer pool: on a dedicated host, allocate a large share of RAM so hot indices stay in memory.
• Trim noisy categories. If chat or command logging is not part of your moderation workflow, disabling it cuts write volume with zero investigative loss.
• Exclude worlds that do not need auditing, such as build test or creative worlds.
• Watch query times with /co status and your database monitoring, and purge before lookups get slow, not after.

Backups

Your logs are evidence. Back them up with the same seriousness as your world. For MariaDB, a scheduled mysqldump gives you a portable, restorable snapshot, and it runs while the server stays online. Keep several generations off the game host so a disk failure does not take both the world and its history with it. Test a restore at least once a quarter; an untested backup is a guess, not a safety net.

Pros and Cons of CoreProtect

Pros

• Extremely broad logging coverage, from blocks and containers to chat, commands, and WorldEdit operations.
• Precise, parameterized rollbacks that let you target one player, one time window, and one action type.
• Free, open source, and widely used, so help is easy to find.
• Flexible storage backends, including MariaDB and MySQL for large servers.
• Built-in undo protection for admins who move too fast.

Cons

• Databases grow quickly and demand real disk and tuning attention.
• Rollbacks restore blocks and container contents, but they cannot reconstruct every kind of lost value perfectly, so compensation sometimes needs a human decision.
• A large global rollback can cause a visible performance dip, so timing matters.
• It is an audit tool, not a prevention tool. It pairs best with a claims plugin such as the options compared in GriefPrevention vs Towny: Claims and Land Protection Compared.

Common Mistakes and Expert Tips

• Running a rollback without a lookup first. A lookup with identical filters is a free preview. Never skip it on anything larger than a small local fix.
• Forgetting the default radius. Rollbacks default to 10 blocks. If the damage is outside that radius and you omit r:, nothing happens and you will think the plugin failed.
• Rolling back globally when you meant locally. r:#global is powerful. Double-check before you press enter on a busy server.
• Ignoring time zones and server time. Coordinates and timestamps use server time. Convert the victim’s report before you set t:.
• Never purging. An unmaintained database is a slow database. Schedule purges and stick to them.
• Treating a rollback as a ban. Reverting the damage is separate from punishing the player. Decide your moderation action on the evidence, not on the rollback.

Frequently Asked Questions

Conclusion

CoreProtect is the difference between a server where grief is a crisis and a server where grief is a chore you finish before your coffee gets cold. Install it, point it at a real database, learn the parameters, and rehearse the workflow on a staging copy so the first time you run a big rollback is not the first time you have run any rollback at all.

Start today: confirm /co status is green, set a 90-day retention window, schedule a database dump, and run one test lookup with u:, t:, and r: so the syntax is muscle memory. When the next 3 AM ticket arrives, you will already know exactly what to type.