CoreProtect protokolliert unterstützte Änderungen und kann einen gezielt gefilterten Rollback durchführen. Prüfe zuerst Lookup, Zeitfenster, Spieler, Radius und Aktion. Es ersetzt keine vollständige Weltsicherung und kennt keine Ereignisse vor Beginn seiner Aufzeichnung. Die Bildschirmfotos stammen aus einem Testserver mit Paper 1.21.1 und CoreProtect 24.0. Die Hausfront wurde für die Demonstration von einem zweiten Testspieler beschädigt und mit einem echten Rollback wiederhergestellt.

Voraussetzungen

CoreProtect installierst du im Panel unter Plugins → Browser. Nach dem Neustart prüfst du die erfolgreiche Aktivierung im Serverlog; /co help zeigt die verfügbaren Befehle, und sofern die installierte Version es unterstützt, liefert /co status Status und Versionsinformationen. Das Protokoll läuft ab diesem Moment automatisch; es gibt nichts einzuschalten. Wichtig ist deshalb, das Plugin vor dem ersten Schaden zu installieren: Was vorher passiert ist, kennt CoreProtect nicht.

Vergib die Befehle nach Aufgabe: Für Helfer, die nur nachsehen sollen, reichen coreprotect.inspect und coreprotect.lookup; für Wiederherstellung kommen gezielt coreprotect.rollback, coreprotect.restore oder coreprotect.undo hinzu. coreprotect.* umfasst auch weitergehende Funktionen und gehört nicht pauschal an jede Moderationsgruppe. Normale Spieler brauchen diese Verwaltungsrechte nicht. Wie Gruppen funktionieren, steht in LuckPerms: Rechte einrichten.

Prüfe den tatsächlich aktiven Datenbanktyp in plugins/CoreProtect/config.yml. Im dokumentierten 24.0-Test wurde SQLite genutzt; dabei liegt das Protokoll in plugins/CoreProtect/database.db. Neue Installationen ab 25.0 verwenden normalerweise DuckDB, bestehende SQLite-/MySQL-Installationen wechseln beim Update nicht automatisch. Sichere die tatsächliche Datenbank vor Änderungen. /co purge t:30d löscht Ereignisse älter als 30 Tage und nimmt sie damit aus späteren Rollbacks heraus.

Den Verursacher finden: Inspector

Der schnellste Weg zu einem einzelnen Block ist der Inspector. /co inspect (kurz /co i) schaltet ihn ein, derselbe Befehl wieder aus. Solange er aktiv ist, zeigt ein Linksklick auf einen Block dessen Geschichte: wer ihn wann gesetzt oder abgebaut hat. Ein Rechtsklick auf eine Fläche zeigt, was an der Stelle daneben einmal stand, auch wenn dort jetzt Luft ist. Ein Rechtsklick auf eine Kiste listet, wer welche Gegenstände hineingelegt oder herausgenommen hat.

Für ein zerstörtes Haus reicht das oft schon: Du klickst auf die Lücke in der Wand und liest den Namen.

Gezielt suchen: Lookup

Wenn mehrere Blöcke betroffen sind, fragst du das Protokoll direkt ab. Der Lookup nimmt dieselben Parameter wie der Rollback, deshalb prüfst du damit zuerst, was ein Rollback überhaupt anfassen würde:

/co lookup u:<Spieler> t:1h r:15 a:-block

Die Parameter: u: ist der Spielername, t: das Zeitfenster (30m, 2h, 7d), r: der Radius in Blöcken um deine Position, a: die Aktion. a:-block steht für abgebaute Blöcke, a:+block für gesetzte, a:container für Kistenzugriffe, a:kill für getötete Tiere und Spieler. Mit dem dokumentierten Include-Filter i: schränkst du auf bestimmte Blöcke ein, zum Beispiel i:chest. Lange Ergebnislisten blätterst du mit /co l 2.

CoreProtect-Lookup: Zeit, Spieler, Aktion und Block je Eintrag
CoreProtect-Lookup: Zeit, Spieler, Aktion und Block je Eintrag

Der Screenshot zeigt aufgezeichnete Änderungen des Testspielers an weißem Beton und hellblauem Glas, mit Koordinaten je Eintrag. Wähle für deinen Fall das passende Zeitfenster; die Beispiele verwenden t:1h. Dieser relative Zeitraum verschiebt sich mit der Uhrzeit, und r:15 hängt von deinem Standort und der Welt ab. Kontrolliere die Treffer unmittelbar vor dem Eingriff erneut und bleibe am geprüften Ort. Bei einer nötigen festen Zeitabgrenzung nutze die von deiner installierten Ausgabe dokumentierte Syntax.

Wiederherstellen: Rollback

Sichere den aktuellen Serverstand und prüfe zunächst eine Vorschau mit denselben Parametern, derselben Welt und demselben Standort:

/co rollback u:<Spieler> t:1h r:15 a:-block #preview

Kontrolliere die Vorschau und das weiterhin passende Zeitfenster. Erst danach führst du den tatsächlichen Rollback aus:

/co rollback u:<Spieler> t:1h r:15 a:-block

CoreProtect meldet im Chat, wie viele Blöcke und Chunks es verändert hat, und nennt Zeitfenster, Radius und Aktion noch einmal. Die Front steht danach wieder, ohne dass irgendjemand einen Block hätte setzen müssen.

Rollback abgeschlossen: sechs Blöcke in zwei Chunks wiederhergestellt
Rollback abgeschlossen: sechs Blöcke in zwei Chunks wiederhergestellt
Die Hausfront nach dem Rollback aus derselben Kameraposition
Die Hausfront nach dem Rollback aus derselben Kameraposition

Ging etwas schief, dreht /co restore mit denselben Parametern den Rollback wieder zurück, und /co undo nimmt den letzten Rollback oder Restore zurück. Kontrolliere auch dabei Welt, Standort und Zeitfenster. Derselbe relative Filter ist keine unveränderliche Treffermenge; eine getrennte Sicherung bleibt der verlässliche Rückweg.

Typische Fehler

  • Der Rollback fasst zu viel an. Ohne explizite Filter kann der Umfang unerwartet groß sein; Defaults hängen von Konfiguration und Befehl ab. Immer Spieler, Radius und Aktion angeben und vorher den Lookup lesen.
  • „No results found". Das Zeitfenster ist zu klein, der Radius zu eng, oder der Schaden liegt vor der Installation von CoreProtect.
  • Kisten sind leer geblieben. Entnahmen gehören zur Aktion container; a:-block stellt nur Blöcke wieder her. Für beides nimmst du zwei Befehle oder lässt a: weg.
  • Die Datenbank wächst. Vor einem geplanten /co purge die Datenbank sichern und die gewünschte Aufbewahrung festlegen. Gelöschte Einträge stehen für spätere Rollbacks nicht mehr zur Verfügung.
  • Eine getötete Kreatur fehlt nach dem Rollback. Prüfe installierte CoreProtect-Version, Aktionsfilter und gespeicherte Entity-Daten. Aktuelle Versionen können unterstützte Entity-Kills zurücknehmen; ältere Versionen oder fehlende Aufzeichnung können das begrenzen. Spielerfortschritt lässt sich dadurch nicht wie mit einer vollständigen Sicherung zurücksetzen.

FAQ

Kann CoreProtect Schaden zurückdrehen, der vor der Installation entstand?

Nein. Das Protokoll beginnt in dem Moment, in dem das Plugin zum ersten Mal läuft; ältere Ereignisse kennt es nicht. Deshalb gehört CoreProtect auf einen öffentlichen Server, bevor der erste Schaden entsteht — nicht erst danach.

Wie verhindere ich, dass ein Rollback zu viel anfasst?

Führe zuerst den Lookup mit genau denselben Parametern aus und lies das Ergebnis. Gib Spieler (u:), Radius (r:) und Aktion (a:) an — verlasse dich nicht auf implizite Standardwerte für den Umfang. Ging es schief, nimmt /co undo den letzten Rollback zurück.

Stellt ein Rollback auch Kisteninhalte wieder her?

Nur wenn die Aktion container mitläuft. a:-block betrifft ausschließlich abgebaute Blöcke. Für Blöcke und Kisten nimmst du entweder zwei Befehle oder lässt a: ganz weg. Für Entity-Kills hängt die Wiederherstellung von Version und gespeicherten Entity-Daten ab; prüfe die Dokumentation deines installierten Builds. Daraus folgt keine allgemeine Wiederherstellung von Spielerinventaren oder Fortschritt.

Wie groß wird die Datenbank, und was tue ich dagegen?

Die Größe hängt von Aufzeichnung, Spielaktivität und Aufbewahrung ab. Prüfe den aktiven Datenbanktyp: SQLite nutzt database.db, neuere DuckDB-Installationen database.duckdb; externe Datenbanken müssen separat gesichert werden. /co purge t:30d löscht ältere Ereignisse. Lege davor eine geprüfte Sicherung an und führe den Purge in einem ruhigen Wartungsfenster aus; das Umstellen des Datenbanktyps allein überträgt keine alten Daten.

Ersetzt CoreProtect das Backup?

Nein, beide lösen verschiedene Probleme. CoreProtect dreht gezielt einzelne Änderungen eines Spielers zurück und lässt alles andere stehen. Ein Backup hilft bei beschädigten Weltdateien, versehentlich gelöschten Welten und allem, was vor der Installation passiert ist.

Weiterführende Guides

Damit es gar nicht erst zum Schaden kommt, schützt du wichtige Bereiche mit WorldGuard: Regionen anlegen. Welche Gruppe welche Befehle bekommt, regelst du mit LuckPerms. Für alles, was CoreProtect nicht kennt, bleibt das Backup im Panel.

Quellen

Einen Rollback in zwei getrennten Prüfungen vorbereiten

Grenze den Schaden mit Lookup auf denselben Spieler, Zeitraum und Bereich ein, den du zurücknehmen möchtest. Prüfe zusätzlich Containeraktionen, falls Inventare betroffen sind; ein reiner Blockfilter erfasst diese nicht. Verwende bei größerem Umfang die Vorschaufunktion, wenn deine Version sie anbietet. Sichere vor dem Eingriff Welt und Protokolldatenbank und notiere die verwendeten Parameter. Prüfe anschließend Bauwerk und Behälter mit derselben Kameraposition beziehungsweise denselben Koordinaten. Ein Purge löscht ältere Nachweise unwiederbringlich aus dem Protokoll und gehört deshalb nicht zum akuten Reparaturversuch.

CoreProtect: Beispiel ansehen

Eigene Aufnahmen aus einer Demo-Umgebung. Die gezeigte Version und Einrichtung können von deinem Server abweichen.

  1. Die Hausfront ist intakt.
  2. Ein zweiter Spieler bricht Blöcke heraus.
  3. /co lookup zeigt, wer was abgebaut hat.
  4. /co rollback stellt die Front wieder her.
Die Hausfront vor dem Schaden, feste Kamera.
Die Hausfront vor dem Schaden, feste Kamera.

CoreProtect 24.0 · Paper 1.21.1 · 2026-09-14

Ein zweiter Spieler bricht Blöcke aus der Front. CoreProtect protokolliert jeden Abbau.
Ein zweiter Spieler bricht Blöcke aus der Front. CoreProtect protokolliert jeden Abbau.

CoreProtect 24.0 · Paper 1.21.1 · 2026-09-14

/co lookup zeigt, wer wann welchen Block abgebaut hat.
/co lookup zeigt, wer wann welchen Block abgebaut hat.

CoreProtect 24.0 · Paper 1.21.1 · 2026-09-14

Nach /co rollback ist die Front wiederhergestellt; der Chat nennt Zeitraum, Radius und Blockzahl.
Nach /co rollback ist die Front wiederhergestellt; der Chat nennt Zeitraum, Radius und Blockzahl.

CoreProtect 24.0 · Paper 1.21.1 · 2026-09-14