CoreProtect

CoreProtect is the server's black box. It keeps track of who placed or broke which block, who opened a chest, who took something out of it or put something in, who used which item, and who wrote which command. From these records, it can then answer the questions that come up on every server: who looted my chest, when that build disappeared, who built this house.

When something happens, you don't have to guess or accuse anyone. The /co i (inspect) mode switches clicking into investigation mode: you click a block or a chest, and the chat lists who manipulated it and when.

The second half is rolling back changes (rollback). The command /co rollback u:player t:7d r:50 restores everything the player did in the last seven days within a radius of fifty blocks. If you find you got it wrong, /co restore dostane sv to the state before the rollback. Rollback is also useful for an accident while building: /co rollback t:30m rolls the world back by half an hour.

CoreProtect itself doesn't forbid anything — it just remembers. It doesn't replace a land or region plugin, but it complements them perfectly: land claims prevent damage from happening, CoreProtect helps at the moment it has already happened.

Records are stored in a database. On a small server, the default settings are enough; on a larger one, it pays to switch to MySQL or MariaDB — queries over history are then faster and data is backed up together with the other databases.

Data grows quickly: an active server collects gigabytes of records in a month. That's why deleting old data (/co purge) is included. It pays to set it up right during installation — cleaning up later is much more unpleasant.

1. Find out the server version and download the corresponding CoreProtect (modrinth.com/plugin/coreprotect, Versions tab).
2. Upload the .jar to the plugins folder.
3. Restart the server. On first startup, CoreProtect creates the tables for records itself and prints to the console where it stores the data.
4. Optional: in plugins/CoreProtect/config.yml switch storage to MySQL or MariaDB. It pays off if you have multiple servers or a lot of data.
5. Check the console: a message must appear that CoreProtect is ready and how many records it has in the database.
6. Set permissions: for yourself coreprotect.*, for moderators coreprotect.inspect, and give them coreprotect.lookup. Rollback only if they know what they are doing.
7. Try viewing: type /co i a klikni na blok — the history must be displayed. Turn the mode off again with the same command.
8. Set up old data cleanup: /co purge t:90d deletes records older than 90 days. Without that, the database grows nonstop.
9. Try it on a chest: take out and put in an item, then click on the chest in /co i mode — both must be visible, including the time.
10. Add CoreProtect data to backups: with the default storage it is the plugins/CoreProtect folder, with MySQL a regular database backup.
11. Write down how rollback is used. When you need it, there will be no time to search in the help.

Always turn off View mode (/co i) after yourself. If it stays on, it breaks normal clicking on blocks and opening chests for players, and they think the server isn't working.
Always test rollback and restore first on a small scale (r:3, t:5m). It is an intervention in the world, and the only way back is another rollback.
Set up automatic cleanup. Without /co purge the database grows, an active server grows by gigabytes per month — and the larger it is, the slower the queries are.
On a larger server, switch storage to MySQL/MariaDB. Searching history is then significantly faster, and data is backed up together with the other databases.
Back up CoreProtect data. It is the only evidence you have when dealing with a theft — and players quickly get used to it (“check CoreProtect”).
When something doesn't work, check the console. CoreProtect reports when it fails to write to the database: the server keeps running, but history is not saved — and that is only noticed when someone needs it.
Search first by player name (u:) and time (t:). If you're not sure, start with a broad range and gradually narrow it so the query doesn't hang.