Recovering From a Griefing Incident

You wake up, open Discord, and there are forty messages in general from the last six hours. Someone has taken spawn apart. There is a screenshot of a crater where the shop district was, three people asking whether their chests are gone, and one member helpfully asking whether you have a backup.

Almost nothing that goes wrong in the next hour is technical. It is an owner doing two obvious things in the wrong order, and then discovering that the tool which would have made the repair surgical was never installed. Here is the order to work through, roughly by how much damage each mistake does.

1. Decide whether to stop the server, and decide it now

A running server is still writing. On Minecraft, chunks unload and flush to the .mca region files continuously, and if the damage involves lava or fire spread it is getting worse while you read the thread. On Rust the autosave interval is commonly 600 seconds out of the box and server.savebackupcount defaults to 2 — two more autosaves and the last save predating the incident has rotated out from under you.

But a full stop kicks everyone online and turns a contained problem into a visible outage. The correct first move is usually to remove the source and freeze the evidence instead:

• Minecraft. Ban from console rather than in-game: ban <name> griefing - under review. If you are unsure how many accounts were involved, whitelist on followed by whitelist reload removes anyone not already trusted. Then save-off, then save-all flush.
• Rust. banid <steamid64> "name" "under review" then writecfg, or the ban lives only in memory and evaporates on the next restart. Then server.save.

Stop the server outright only when the damage is unbounded — an active exploit, fire spreading, a script on a loop. Otherwise leave it up. A dead server with no explanation produces more panic than the grief did.

2. Snapshot the broken world before you repair anything

This is the step people skip, and it makes every later mistake unrecoverable. The broken world is your evidence: once you roll back over it you cannot check whether you went too wide. CoreProtect's /co undo reverses only your most recent rollback — it is not an undo of the incident.

With saving paused, copy out the world folders, plugins/CoreProtect/database.db, logs/latest.log and ops.json, then save-on. Copying a live world without pausing writes is how you produce a backup containing a half-written region file, which is worse than having none — the same failure mode covered in the game server backups guide. On Rust, force a save and copy all of server/<identity>/save/ along with oxide/logs/.

3. Establish scope before you restore anything

The most common overreaction is a full restore from last night's backup. It feels decisive. It also deletes everything the forty innocent people built that evening, and you will spend a fortnight apologising to them rather than to the one person actually harmed.

Look before you touch. With CoreProtect, start with a count:

/co lookup u:Griefer t:12h r:#global a:-block #count

That tells you whether you are dealing with a hundred and forty blocks or four hundred thousand. Then narrow by action, because block removal, container access and entity kills are three separate repairs. Once the filter looks right, preview it before it touches the world:

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

#preview renders the change to you alone. Walk it, confirm it is not eating a legitimate build in the same chunks, then apply. Admins who skip the preview are the ones who roll back six hours globally and take out an evening of terraforming with it.

4. The tools only work if you installed them beforehand

Vanilla Minecraft logs nothing about blocks. logs/latest.log gives you joins, leaves, chat, executed commands and the address each account connected from. It does not record who broke what. Without a block-logging plugin, "selective rollback" describes something you cannot do — your only options are restore everything or restore nothing.

Block logging is not an incident-response tool. It is a decision you made months earlier about whether you would have a choice at all.

The two real options on Paper and Spigot are CoreProtect and Prism. CoreProtect ships with SQLite, which is fine small and a bottleneck busy — move it to MySQL before you need it. Check retention too: plenty of admins schedule /co purge t:30d #optimize and later discover their evidence window was shorter than the time it took anyone to notice. Prism is the alternative on modern Paper, logs a wider set of event types, and supports h2, SQLite, MySQL, MariaDB and PostgreSQL. Either is fine. Neither is not.

Rust has no equivalent — no block-level rollback for a base, and no plugin will give you one. What you can have, arranged in advance: an ownership plugin such as Entity Owner, which adds a prod command naming who placed the entity you are looking at; framework logging under oxide/logs/, which contains only what your plugins choose to write; and the admin combat log, combatlog <steamid64>, which defaults to the last 100 events under combatlogsize — minutes of history, not hours. Recent builds no longer write the old Log.Log into the identity folder either, so pass -logfile if you want a server log at all. If you are still choosing a plugin layer, the comparison of SourceMod, AMX Mod X and Oxide is the place to start; on Rust servers the honest planning assumption is that recovery means restoring a save, not repairing a base.

5. Read the logs for who, when, and how they got in

Damage is the symptom; the escalation path is the interesting part. Run a:session for connect and disconnect times, then a:command, then a:block and a:container. The command log usually holds the story — an /op, a //set, a permissions grant issued minutes before the destruction started.

You are sorting the incident into one of three buckets: an outsider who found a hole, a member who turned, or a staff account that was taken over or abused. The third is the most damaging and the most likely on any server old enough to have retired staff who still hold op. Most "hacked server" incidents are permission incidents, which is why staff selection is the load-bearing half of moderating a community.

6. Griefing, a raid and an exploit are three different events

They look nearly identical in a log and need completely different responses.

A raid is the game working. On a Rust PvP server a base going down at 3am is the point; on an anarchy Minecraft server, so is a cratered spawn — which is why the difference between SMP, anarchy and skyblock matters more than owners expect. If a player is furious about something your rules permit, you have a rules problem, and rules people actually follow are a different skill from enforcing them.

An exploit — duplication, an item spawner, a permissions node inherited by default — needs an inventory and container rollback rather than a block rollback, and the real fix is a config change. Banning the finder without patching the hole guarantees a second incident.

Griefing is destruction with no in-game purpose on a server whose rules forbid it. That is the only bucket where a ban is the primary response.

7. Restore or roll back, deliberately

Restore from backup when the damage is structural: corrupt region files, a wiped plugin database, or a change set large enough that the rollback engine would run for hours. The cost is everything since that backup, innocent work included. Roll back the player when the damage is attributable and bounded; the cost is that it only restores what was logged.

There is a third option nobody reaches for: restore the backup into a second world folder on the same box, then copy the affected region into the live world with WorldEdit. Slower and fiddlier, and it keeps the evening's builds. My recommendation is to roll back whenever the lookup returns a countable result and the world files are intact, and to restore only when the world is genuinely damaged — never because a restore feels safer than a filter you are unsure of. Removing that uncertainty is what #preview is for.

8. What you post, and what you leave out

Post within a couple of hours even with nothing resolved. Silence reads as absence, and absence is what makes people leave.

Say four things: what happened in one sentence, whether builds and inventories were affected, the restore point, and when the server is back. Then one specific change. We have taken steps to prevent this is worth nothing; "op is stripped from everyone except the three active admins, and CoreProtect retention is now ninety days" is worth a great deal because it is checkable. Trust is built from verifiable specifics, the same reason measured figures on a listing persuade people and adjectives do not.

Leave out the offender's name. Naming publicly reliably backfires: it commits you to a conclusion before you have finished reading the logs, invites your own members to harass a real person, and recasts you as a party to the dispute rather than the person who fixed it. Handle the ban privately — if it was a member, people will work it out anyway. Leave out the method too, if it was an exploit, until it is closed.

Then close the hole in the same week, while the annoyance still outweighs the effort: audit ops.json and, on Rust, stale ownerid and moderatorid entries in users.cfg; rotate the RCON and panel passwords; get backups off the machine; and tighten entry, because a whitelist people actually apply to filters out drive-by attempts almost entirely.

The repair itself takes an afternoon. Being the only person who can do it at 3am is the part that ends servers, and it is worth reading about burnout and handing over the keys while this is still your first incident rather than your third.