CoreProtect: Grief rückgängig machen und Vorfälle auf dem Minecraft-Server untersuchen

CoreProtect protokolliert jede Spieleraktion und macht Grief mit einem einzigen Befehl rückgängig. Hier zeigen wir Installation, Konfiguration in der config.yml, Ermittlung des Verursachers und das Wiederherstellen der Welt ohne ein Backup einspielen zu müssen.

Warum jeder Server CoreProtect braucht

Wer einen Server ohne Whitelist betreibt oder auch nur fünf regelmäßige Spieler hat, erlebt früher oder später eines von beidem: jemand räumt eine fremde Truhe leer, oder jemand kippt Lava auf einen Bau. Ohne Logs lässt sich nichts beweisen, ohne Rollback wird per Hand repariert oder ein Welt-Backup eingespielt, was alle anderen Änderungen seit dem Backup vernichtet.

CoreProtect löst beides. Das Plugin für Paper und Spigot schreibt jedes Block-Setzen und -Brechen, jeden Truhenzugriff, jede Chat-Nachricht, jeden ausgeführten Befehl und jeden Trank in eine Datenbank. Für einen frei wählbaren Zeitraum lässt sich anschließend jede Aktion zurücknehmen oder erneut anwenden. In der Praxis läuft CoreProtect auf 90% aller Server mit 10 bis 1000 gleichzeitigen Spielern. Im Jahr 2026 gibt es schlicht keine Alternative mit vergleichbarer Geschwindigkeit, Pflege und Kompatibilität.

Diese Anleitung deckt Installation, Konfigdatei, Untersuchungs-Befehle, Rollback und die Datenbank-Frage ab. Versionen: CoreProtect 22.x, Minecraft 1.20-1.21, Paper und Forks.

Installation auf Paper und Spigot

Lade die jar von der offiziellen Modrinth-Seite oder von SpigotMC herunter. Datei in plugins/ legen, Server neu starten, das Plugin erzeugt selbstständig plugins/CoreProtect/config.yml und die SQLite-Datenbank database.db.

Mindestanforderungen: Java 17+, Paper 1.20.1 oder neuer. Auf Spigot funktioniert es ebenfalls, aber Paper ist die empfohlene Wahl. Events werden schneller verarbeitet, das Plugin kommt ohne Lag-Spikes hinterher.

Installation prüfen:

# In der Server-Konsole oder als OP
/co help
/co status

Erscheint die Version und Database is operational, läuft alles. Standardmäßig erhalten Spieler keine Rechte, die müssen explizit über LuckPerms oder ein anderes Permissions-Plugin gesetzt werden.

SQLite oder MySQL

Standardmäßig schreibt CoreProtect in SQLite (database.db neben der Config). Das reicht bis etwa 50 gleichzeitige Spieler oder bis die Datei auf 50-100 GB wächst. Danach werden weite lookup-Anfragen langsam, und ein Wechsel auf MySQL oder MariaDB lohnt sich.

Wann auf MySQL umstellen:

• dauerhaft mehr als 50 gleichzeitige Spieler
• database.db größer als 100 GB
• /co lookup braucht regelmäßig 5-10 Sekunden oder mehr
• Multi-Server-Netzwerk (BungeeCord/Velocity) mit gemeinsamer Log-Datenbank

MySQL-Konfiguration in config.yml:

mysql: true
mysql-host: "127.0.0.1"
mysql-port: 3306
mysql-database: "coreprotect"
mysql-username: "coreprotect_user"
mysql-password: "***"
table-prefix: "co_"

Nach dem Wechsel legt das Plugin neue Tabellen an. Alte SQLite-Daten werden nicht automatisch übernommen, dafür gibt es nur Drittanbieter-Skripte.

Was in der config.yml protokolliert wird

Alles zu loggen frisst Plattenplatz. Auf einem Bauserver mit 200 gleichzeitigen Spielern erzeugen block-break: true plus item-pickup: true Gigabyte pro Tag. Sinnvoll ist nur, was tatsächlich für die Untersuchung gebraucht wird.

Eine bewährte Grundkonfiguration:

# Was geschrieben wird
block-place: true
block-break: true
natural-break: false      # Schwerkraft-Brüche: Rauschen, aus
explosions: true          # Creeper, TNT, End Crystal: immer an
fire: true
liquid-tracking: true     # Lava/Wasser-Fluss
sign-text: true
container-transactions: true
item-transactions: true
item-pickup: false        # meist überzogen, frisst Platz
player-interactions: true # Türen, Hebel, Knöpfe
chat: true
commands: false           # an, falls /sudo oder /tp offen sind
worldedit: true           # kritisch, wenn WorldEdit für Staff offen ist

# Speicher
default-radius: 10
date-format: "yyyy-MM-dd HH:mm:ss"
api-enabled: true

# Performance
table-version: 9
disable-wal: false        # WAL beschleunigt SQLite, an lassen

commands: true schreibt jeden eingegebenen Befehl mit Argumenten mit. Hilft bei Verdacht auf Dupes über Befehle, kann aber bei privaten /msg-Inhalten Datenschutz tangieren. Server-spezifisch entscheiden.

Inspector-Modus

Der häufigste Befehl nach Grief: hingehen und prüfen, wer was angefasst hat. Modus aktivieren:

/co inspect
# oder kurz:
/co i

Linksklick auf einen Block zeigt jetzt, wer ihn gesetzt oder gebrochen hat und wann. Rechtsklick auf eine Truhe zeigt jede Transaktion. Sehr praktisch bei Beschwerden wie "aus meiner Truhe sind Diamanten verschwunden": daneben stellen, rechtsklick, ganzes Transaktions-Log mit Name und Zeitstempel sichtbar.

Modus mit erneutem /co i wieder aus.

Inspector benötigt das Recht coreprotect.inspect. Nicht an reguläre Spieler vergeben, sonst sind Moderatoren überflüssig und alle prüfen ihre Nachbarn.

Logs durchsuchen: /co lookup

Wenn statt Klicks eine strukturierte Suche gebraucht wird:

# Alles von Steve in den letzten 7 Tagen
/co lookup u:Steve t:7d

# Was Steve in den letzten 24 Stunden im Radius 100 gemacht hat
/co lookup u:Steve t:24h r:100

# Alle Explosionen der letzten 6 Stunden
/co lookup a:+block t:6h b:tnt

# Truhenzugriffe der letzten Woche
/co lookup t:7d a:container

Ausgabe seitenweise im Chat, weiterblättern mit /co l <page>. Für Exporte ein Webhook-Plugin nutzen oder die Datenbank direkt per SQL abfragen.

Parameter:

• u: - Spielername (oder #environment, #tnt, #fire)
• t: - Zeit zurück: 1m, 1h, 7d, 30d, kombinierbar als t:1d2h
• r: - Radius in Blöcken um dich, r:#world für die ganze Welt, r:#chunk für den aktuellen Chunk
• a: - Aktion: block, +block (nur place), -block (nur break), chat, command, container
• b: - konkreter Block: b:diamond_ore, b:tnt
• e: - Ausschluss: e:#dirt,grass_block filtert Rauschen
• i: - Item-Filter für Container: i:diamond

Grief zurücknehmen: /co rollback

Wenn klar ist, wer es war und wie groß der Schaden, wird zurückgesetzt:

# Alles von Steve in der letzten Stunde im Radius 50 zurücknehmen
/co rollback u:Steve t:1h r:50

# Alle TNT-Setzungen der letzten 30 Minuten weltweit
/co rollback t:30m a:+block b:tnt r:#world

# Lava-Aktionen der letzten 2 Stunden
/co rollback t:2h a:liquid e:water

Rollback läuft asynchron: große Bereiche laggen den Server nicht, dauern aber Minuten. Fortschritt steht in der Konsole. Nicht abbrechen, auf Rollback complete warten.

Wichtig: Rollback stellt den Zustand VOR der ersten Aktion in der Auswahl wieder her. Wenn Steve einen Block gesetzt und dann gebrochen hat, ist das Ergebnis ein leeres Feld (kein Block). Parameter erst auf einer Testfläche prüfen.

Wiederherstellen: /co restore

Was, wenn ein Teil des Rollbacks zu viel war? Etwa: der Griefer wurde rückgängig gemacht, dabei aber auch ein Nachbar, der seine Löcher reparierte. Dann:

/co restore u:Steve t:1h r:50

Restore ist die Umkehrung: Welt wird in den Zustand NACH den Aktionen zurückgeführt. Im Grunde Undo für Rollback. Für teilweises Wiederherstellen mit b: und e: filtern.

Aufräumen: /co purge

Die Datenbank wächst schnell. Auf einem Server mit 100 gleichzeitigen Spielern und ohne item-pickup sind das 5-10 GB pro Monat. Nach einem halben Jahr 30-60 GB, lookups werden zäh. Alte Daten löschen:

# Alles älter als 30 Tage entfernen
/co purge t:30d

# Nur eine Welt
/co purge t:30d w:world_nether

purge nachts oder bei wenig Aktivität laufen lassen. Sperrt die Datenbank während der Operation. Bei SQLite anschließend Speicher mit VACUUM zurückgewinnen:

sqlite3 plugins/CoreProtect/database.db "VACUUM;"

Bei MySQL: OPTIMIZE TABLE co_block, co_container, co_chat;. Auf großen Tabellen kann das eine Stunde dauern, dann besser bei gestopptem Server.

Performance und Monitoring

Worauf achten:

• DB-Größe: Wachstum verfolgen. Wächst sie schneller als 10 GB pro Woche, wird zu viel geloggt. item-pickup, natural-break, liquid-tracking reduzieren.
• TPS während lookup: Anfragen mit r:#world und t:30d sind schwer. Bei SQLite blockieren sie Schreibvorgänge, neue Events können nicht protokolliert werden, Lag-Spikes drohen.
• Disk IOPS: SQLite erzeugt viele kleine Schreiboperationen. SSD ist Pflicht, auf HDD bricht CoreProtect ab 50 Spielern zusammen.

Indexe auf co_block(time, user) und Co. werden vom Plugin selbst gepflegt, kein manuelles Tuning nötig. Für eigene Report-SQL-Queries eigene Indexe auf den Filterspalten anlegen.

Echter Fall: nächtlicher Grief

Du loggst dich morgens ein, am Spawn ist ein Tunnel ins Admin-Zimmer gesprengt. Niemand online, unklar wer und wann. Vorgehen:

1. Neben den ersten gesprengten Block stellen. /co i, linksklick. Name und Zeit der ersten Explosion sichtbar.
2. /co lookup u:Griefer123 t:12h r:#world a:+block b:tnt zeigt jede TNT-Setzung des Spielers in den letzten 12 Stunden weltweit. Resultat: TNT von 03:14 bis 03:42 platziert.
3. /co lookup u:Griefer123 t:12h a:container prüft Truhenzugriffe. Häufig wird zuerst die Admin-Truhe geleert und dann mit der Explosion vertuscht.
4. /co rollback u:Griefer123 t:12h r:#world setzt alle Aktionen aus dem Zeitraum zurück. Blöcke und Truheninhalte kommen zurück.
5. Spieler bannen, in LuckPerms prüfen, wie er WorldGuard umgangen hat. Oft kommt der Griefer über einen Alt-Account mit erschlichenen Rechten.

Ein Admin-Zimmer rückgängig machen dauert 2-5 Minuten, großflächiger Welt-Grief 10-30 Minuten.

Was NICHT zurückkommt

CoreProtect ist mächtig, aber nicht allmächtig. Nicht wiederhergestellt werden:

• Mob-Drops: ein für Perlen getöteter Enderman wird nicht protokolliert
• Ofen-Schmelzungen: das geschmolzene Item ist weg, das Roherz wird nicht zurückgerechnet
• Verzauberungen und Amboss-Kombinationen: ein neues Item gilt nicht als Kombination zweier alter
• Welt-Veränderungen ohne Spieler: Spawner-Updates, Wasser-Erosion, teilweise über liquid-tracking, aber nicht immer sauber
• die Welt selbst, falls der Ordner gelöscht wurde: CoreProtect speichert Änderungen, nicht die Welt. Bei gelöschtem world/ ist ein Welt-Backup nötig

Für Spieler-Inventare werden nur Container-Transaktionen wiederhergestellt (Truheninhalte). Das persönliche Inventar wird von /co rollback nicht angefasst. Dafür ein eigenes Plugin wie InventoryRollback Plus.

Integration mit anderen Plugins

Die CoreProtect-API ist offen, viele Plugins nutzen sie:

• WorldGuard: blockierte Aktionen erscheinen als bypass_attempt im Log
• Citizens: NPC-Interaktionen werden mit dem NPC-Namen geloggt
• MythicMobs: eigene Mobs und ihre Angriffe via /co lookup a:kill sichtbar
• WorldEdit: //set, //paste und Co. werden vollständig geloggt. Eine fehlerhafte WE-Operation lässt sich per /co rollback u:OperatorName a:worldedit zurücknehmen

Für Entwickler bietet die CoreProtect-API Abfragen per Code: Aktionen nach Koordinaten holen, nach Spieler filtern, in eigenen Plugins verwenden.

FAQ

Kann CoreProtect die Welt wiederherstellen, wenn der Ordner gelöscht wurde?

Nein. CoreProtect speichert Änderungen in einer Datenbank, nicht die Welt selbst. Wurde world/ gelöscht, ist ein Welt-Backup nötig. CoreProtect hilft nur, wenn die Welt noch da ist und in ihr etwas verändert wurde. Welt-Backups separat einrichten, etwa mit AutoSaveWorld oder per Snapshot des Hosters.

Wie viel Plattenplatz braucht CoreProtect pro Monat?

Hängt von Aktivität und Konfiguration ab. Auf 100 gleichzeitigen Spielern mit Standard-Config und ohne item-pickup rechne mit 5-10 GB pro Monat. Mit item-pickup: true und commands: true werden 20-30 GB daraus. /co purge t:60d einmal monatlich hält das Wachstum unter Kontrolle.

Was ist besser: CoreProtect, Prism oder LogBlock?

CoreProtect ist 2026 das aktivste und schnellste. Prism hat eine stärkere API und Web-Oberfläche, aktualisiert sich aber langsamer. LogBlock ist alt und wird selten gepatcht, für neue Server nicht zu empfehlen. Wer schon LogBlock fährt und es läuft, kann bleiben, aber eine Migration zu CoreProtect macht das Leben einfacher.

Lässt sich das Inventar eines Spielers zurückrollen?

Nur Container-Inhalte über /co rollback ... a:container. Das persönliche Inventar wird von CoreProtect nicht erfasst. Dafür InventoryRollback Plus oder PlayerInventoryRollback zusätzlich installieren, die loggen Inventar-Slots gesondert.

Funktioniert CoreProtect auf Folia?

Es gibt einen Fork für Folia, aber nicht alle Funktionen sind stabil. Rollbacks über große Regionen können wegen Folias regionalisiertem Threading abstürzen. Auf normalem Paper läuft CoreProtect ohne Vorbehalte. Wer Folia für Performance braucht und Logs benötigt, sollte Alternativen prüfen oder auf eine stabilere Version warten.

Wie schütze ich die Log-Datenbank vor dem Griefer selbst?

Hatte der Griefer OP-Rechte, könnte er die Datenbank manipulieren, um Spuren zu verwischen. Schutz: MySQL auf einen separaten Host mit IP-Whitelist auslagern, regelmäßige mysqldump-Backups per cron, Kopien offline halten. Bei SQLite täglich database.db nach S3 oder auf eine externe Platte sichern.

Wie lange dauert ein Rollback über 100k Blöcke?

Auf SSD mit SQLite etwa 1-3 Minuten, MySQL ist schneller. Auf HDD gar nicht erst versuchen, das dauert über 20 Minuten mit Stottern. Fortschritt in der Konsole verfolgen, im Chat erscheint er nicht zeilenweise.

Nächste Schritte

Installiere CoreProtect direkt bei der Server-Erstellung, vor dem ersten Vorfall. Nach einer Woche Aktivität DB-Größe prüfen, ungenutzte Log-Kategorien abschalten, /co purge t:60d als geplante Aufgabe monatlich einrichten. coreprotect.inspect nur an Staff vergeben, normale Spieler brauchen es nicht und es belastet das System.

Und schütze den Server selbst gegen externe Angriffe. Die sauberste Log-Historie nützt nichts, wenn der Server unter DDoS fällt und Spieler abwandern. MineGuard bietet Minecraft-bewusstes Filtering ohne TPS-Verlust, lieber vorher einrichten als hinterher.