How to Stop Griefing on a Minecraft Server: Protection, Claims and Rollback

Griefing is the destruction or theft of what other players built. No single plugin stops all of it, because it happens in three different ways at three different times: before it happens, while it happens and after it has happened. A server that handles each stage on purpose loses far less.

Stage one: stop it before it happens

There are two designs for preventing damage, and the difference is who decides what is protected.

Staff-defined regions suit the places you control: spawn, shops, event arenas and the world's edge. With WorldGuard you select an area using WorldEdit, then define a region from it and set flags. The documentation's examples show how short it is:

• /rg define town
• /rg flag town pvp deny
• /rg addmember town g:builders

The first command creates the region from your selection, the second stops players fighting inside it, and the third gives a permissions group, written with the g: prefix, the right to build there. WorldGuard needs WorldEdit to define areas, so install both.

Player claims suit everywhere else. In a claims plugin such as GriefPrevention, players protect their own land with the mouse, and the maximum amount of land they can claim grows with their time on the server and cannot be gained by idling, which the plugin's documentation points out. It removes staff from the day-to-day work of protecting builds. Towny goes further and adds towns and nations on top of claims.

You can use both: regions for what you own, claims for what players own. Read each plugin's documentation on how they interact before you let them cover the same ground.

Stage two: see what happened

Protection fails, usually because a trusted player turned out not to be. A block log records what happened so you can act on facts. CoreProtect keeps its log in a database, and its inspector lets staff click a block to see who changed it:

• /co inspect

Turn the inspector on, click a suspicious block and read the history. Do this before you accuse anyone.

Stage three: repair the damage

Once you know who did it, a rollback reverses exactly their changes without touching anyone else's:

• /co rollback u:PlayerName t:2h r:30

The parameters mean user, time span and radius. The CoreProtect documentation notes that a rollback uses a default radius of ten blocks unless you give one, and that a rollback can be previewed before you apply it. Always preview a large one. If you made a mistake, restore reverses a rollback.

Logs grow quickly. The same documentation warns that purging data in game only removes data older than thirty days, so plan the size of your database and when to prune it.

Stage four: the backup behind it all

A rollback plugin can only reverse what it logged. A backup covers everything else, including corrupted files, a broken update and edits the plugin could not see. DriveBackupV2 can create backups on a schedule and upload them off the machine. Keep several generations, and restore one to a test server now and then, because an untested backup is only a hope.

A practical setup for a survival server

• Define a protected region for spawn and set flags so it cannot be built on or fought in.
• Let players claim their own land and set a claim limit that matches how long you want newcomers to wait.
• Install CoreProtect from day one, because it cannot show what it never logged.
• Give rollback commands only to staff you trust, through your permissions plugin.
• Schedule backups and store them somewhere other than the server's disk.

What this will not stop

Protection plugins stop block changes in the places they cover. They do not stop social griefing such as scams, trapping players or hostile builds placed in unprotected land. Rules, reports and a staff team that responds are part of the system too. Write the rules down where players can read them, and apply them the same way every time.