Someone will grief your server. Given enough players and enough time it is a certainty, and the question is only how much it costs you when it happens. The good news is that grief is a solved problem, and the solution is two plugins that do different jobs and cover each other. One logs everything so you can undo damage after the fact. The other stops most of the damage happening at all. Run both. This post explains how they fit together, and it sits under the wider guide to running a Minecraft SMP.
Two layers, not one
People reach for either prevention or recovery and stop there, and both alone leave a gap. A land-claim plugin stops players wrecking each other's builds, but it does nothing about the trusted friend who turns out not to be, or grief in unclaimed wilderness, or a mistake you made yourself with WorldEdit. A logging-and-rollback plugin can undo anything, but only after the fact, and only if you notice. Together they close each other's gaps: claims stop the routine grief before it lands, and the log catches everything the claims did not. That is why the standard setup is both, and has been for years.
CoreProtect: the undo button
CoreProtect logs every block placed and broken, every container opened, every sign edited, every bucket emptied, tagged with who did it and when. It sits quietly in the background recording, and then when something goes wrong it lets you inspect the history of any spot and roll the damage back. It is the plugin you will be quietly grateful for the first time someone torches a base while you were asleep.
The two commands you use most are inspect and rollback. Inspect puts you in a mode where interacting with a block shows its full history, who placed or broke it and how long ago, so you can see exactly what happened and who did it before you touch anything. Rollback reverses changes by a player, over a time window, within a radius, so you can say in effect undo everything this player did in the last three hours within fifty blocks and watch the grief unwind. There is also a restore, which is the opposite of a rollback and reapplies changes you rolled back, which is your safety net if you roll back too much.
The conceptual shape is: inspect to understand, rollback to fix, restore if you overcorrected. The exact syntax matters and is easy to get wrong under pressure, so keep the reference to hand rather than improvising. Inspect mode is /co inspect, or /co i for short, and you toggle it on, interact with blocks to read their history, then toggle it off. A rollback takes flags: /co rollback u:<user> t:<time> r:<radius>, so /co rollback u:Steve t:3h r:50 undoes what the player Steve did in the last three hours within fifty blocks. Restore uses the same flags, /co restore u:<user> t:<time> r:<radius>, and reapplies whatever a matching rollback removed.
A rollback is powerful, which makes it the tool most able to make things worse if you are careless. Inspect first, always, so you know the actual player name and the real time window. Start with a tight radius and a short time, check the result, and widen only if you need to. Too broad a scope can undo legitimate building alongside the grief, and while restore can walk that back, it is far calmer to scope it correctly the first time.
Who gets to run these commands is a permissions question, and you grant it to your mod group and above rather than handing out op. The LuckPerms setup guide covers how to build that ladder so inspection and rollback land with staff and nobody else.
GriefPrevention: stop it before it starts
Recovery is good, but the calmest server is the one where the grief never happens. That is what a land-claim plugin does. GriefPrevention is the common choice, and its model is refreshingly simple: players claim land with a golden shovel. They hold the shovel, click one corner of what they want to protect, click the opposite corner, and the area between is theirs. Inside a claim, nobody but the owner and the people they trust can build, break or open containers. Grief inside a claim simply does not work, because the plugin refuses the action.
Players earn claim blocks over time, which caps how much of the world any one person can fence off and stops the map filling up with abandoned claims. Owners can trust specific friends into a claim for building, or grant narrower access like container-only, so a shop can let customers buy without letting them tear the walls down. It puts the routine boundary disputes in players' own hands, so your staff are not mediating every argument about who broke whose fence.
GriefPrevention is not the only option here. If its simple golden-shovel style does not fit your server, Towny is the main alternative worth knowing: it builds claims around towns and nations, which suits a more political, community-run map where players group into settlements rather than fencing off individual plots. For most SMPs, though, the golden-shovel model is easy for players to understand and easy for you to run, which is most of the battle.
Why you want both, concretely
Picture the failure each one misses. With only claims, a griefer gets trusted into a base by a friend and empties the chests, all permitted because they were trusted. Claims cannot help. CoreProtect can, because every container access was logged and you can roll it back and see who did it. Now picture only CoreProtect: a griefer spends an hour tunnelling through a dozen unclaimed builds. You can roll it all back, but that is your evening gone, and only if a player reports it before the log ages out. Claims would have stopped most of it at the door. Run both and each covers the other's blind spot.
A note on performance
CoreProtect logs a lot, and the log is a database that grows every day. On a busy server it can become the largest thing on disk and, left unattended, a source of slow queries. That is a reason to keep it tidy, not to skip it. Set a sensible retention window so the database prunes old data automatically, and remember that inspect and rollback are database queries, so a huge unpruned log makes them slower. Purging data older than your realistic report window, often a few weeks, keeps the database lean and the commands fast. The command is /co purge t:<time>, so /co purge t:30d clears everything older than thirty days, and run from in game it will only purge data past that thirty-day mark. Thirty days is a sensible default for most servers, long enough to catch a late-reported grief and short enough to keep the database quick. Keeping the database on fast local NVMe helps too, one reason we keep container storage on Gen4 NVMe with nothing over the network in the hot path.
Where this fits
Grief protection is one layer of a wider staff setup. The permissions that decide who can inspect and roll back come from LuckPerms, the punishment side is covered in moderation and staff tooling, and the whole plugin baseline sits in essential SMP plugins. The running a Minecraft SMP pillar ties them together.
All of this runs better with tick budget to spare, because a logging plugin and its database want I/O headroom to stay quick. Our Minecraft hosting reserves the cores, RAM and fast storage so the safety net does its job without dragging the tick.