CoreProtect: Wie lange solltet ihr den Verlauf behalten?
Legt die Aufbewahrungsdauer für CoreProtect danach fest, wie viel Zeit eure Community zum Melden und Untersuchen von Vorfällen benötigt. Prüft anschließend, ob Speicher und Wiederherstellungsverfahren diesen Zeitraum abdecken. Bevor ihr Verlauf löscht, müsst ihr die aktive Datenbank kennen, eine nutzbare Sicherung haben und offene Fälle prüfen. Eine fast volle Festplatte verlangt eine Reaktion; die Moderationsregeln solltet ihr schon vorher festgelegt haben.
Diese Anleitung richtet sich an Betreiber etablierter Server und Teams, die den technischen Betrieb beauftragen. Sie behandelt eine Wartungsentscheidung. Die Beispiele und Prüfschritte sind vorgeschlagene Arbeitsabläufe, keine auf eurem Server ausgeführten Tests oder gemessenen Kapazitätswerte für CoreProtect.
Zuerst den Untersuchungszeitraum festlegen
Fragt eure Moderatoren, wie spät Vorfälle tatsächlich gemeldet werden. Berücksichtigt Spieler, die nach einer Pause zurückkommen, gemeinsam genutzte Bauwerke und Fälle, die zwischen ehrenamtlichen Helfern wechseln. Vereinbart eine Bearbeitungsfrist, die das Team zuverlässig einhalten kann.
Als Planungsmodell eignet sich:
Benötigter Verlauf = längste akzeptierte Meldeverzögerung + Untersuchungszeit + betrieblicher Puffer.
Eine fiktive Community akzeptiert Meldungen bis 14 Tage nach dem Vorfall, plant sieben Tage für die Untersuchung ein und ergänzt neun Tage Puffer. Daraus ergeben sich 30 Tage. Das sind selbst gewählte Regeln, keine CoreProtect-Standardwerte und keine allgemeine Empfehlung. Akzeptiert ihr ältere Meldungen, reicht dieses Beispiel nicht aus.
Haltet fest, ab wann die Frist zählt: Entscheidend ist das Alter der Handlung, nicht der Zeitpunkt, zu dem ein Moderator das Ticket öffnet. Prüft ungelöste Fälle ausdrücklich vor einer geplanten Löschung. Jede Ausnahme braucht einen Verantwortlichen und einen erneuten Prüftermin. Sonst wird aus „vorerst behalten“ unbemerkt eine unbegrenzte Aufbewahrung.
Prüfen, welcher Verlauf tatsächlich vorliegt
CoreProtect unterstützt weltbezogene Einstellungen zur Protokollierung sowie Ausschlüsse über blacklist.txt. Eine längere Aufbewahrung ersetzt keine nie erfassten Aktionen. Prüft die wirksamen Einstellungen jeder relevanten Welt anhand der Konfigurationsdokumentation.
Erstellt eine kurze Übersicht zur Abdeckung. Notiert je Welt, welche Vorfälle die Moderation untersuchen soll, welche Aktionen sie dafür benötigt und welches aktuelle, kontrollierte Beispiel sie finden kann. Führt Lobby, Survival-Welten und Event-Welten getrennt auf. Eine erfolgreiche Abfrage in der Lobby belegt keine vollständige Abdeckung.
Dokumentiert die installierte Plugin-Version, den gewählten Datenbanktyp, den Speicherort beziehungsweise das externe Ziel und die Zuständigkeit für Sicherungen. Zugangsdaten gehören nicht in diese Übersicht. Ein Kollege muss den richtigen Datenbestand identifizieren können, ohne ein Passwort in ein Ticket zu kopieren.
Fehlen erwartete Ergebnisse, verschiebt die Änderung der Aufbewahrungsfrist. Prüft zuerst Welt, Identität, Zeitraum und Protokollierung. Ein leeres Suchergebnis beweist nicht, dass nichts passiert ist.
Drei Entscheidungen getrennt behandeln
| Entscheidung | Zu klärende Frage | Benötigter Nachweis |
|---|---|---|
| Aufbewahrung | Wie weit zurück muss die Moderation untersuchen können? | Vereinbarte Meldefrist und Prüfung offener Fälle |
| Speicher | Kann das System diesen Zeitraum abdecken? | Gemessenes Wachstum, freier Platz und Wartungsreserve |
| Wiederherstellung | Kann das Team gesicherten Verlauf wieder lesen? | Erfolgreiche Probe in einer isolierten Umgebung |
Messt Datenbankspeicher und freien Dateisystemplatz in vergleichbaren Abständen, auch während eines stärker besuchten Events. Notiert, ob Backups auf demselben Volume liegen. Schätzt ab, wann eure selbst festgelegte Mindestreserve erreicht wäre, und plant genügend Reaktionszeit ein. Aus wenigen ruhigen Tagen lässt sich keine Spielerzahl garantieren.
Unterscheidet die aktive Datenbank, Sicherungskopien und vorübergehend benötigten Wartungsspeicher. Eine Aufbewahrungsfrist in Tagen sagt noch nichts über den Platzbedarf eurer konkreten Nutzung aus. Reicht das Budget für den vereinbarten Untersuchungszeitraum nicht aus, klärt diesen Widerspruch mit dem Betreiber, bevor Nachweise gelöscht werden.
Die Löschgrenze eindeutig beschreiben
Laut Befehlsreferenz entfernt t:30d bei einem Purge Einträge, die älter als 30 Tage sind. Die Speicherfreigabe hängt vom Datenbanktyp ab; #optimize ist kein universeller Beschleuniger. Prüft vor der Vorbereitung eure Version.
Lasst den ausführenden Administrator zunächst das Ziel formulieren: „Verlauf vor dem genehmigten Stichtag aus diesen Welten entfernen.“ Eine zweite Person sollte diesen Satz mit dem vorgesehenen Befehl und dem Ausführungszeitpunkt vergleichen können. Haltet die verwendete Zeitzone fest, damit Zeitangaben aus Vorfällen eindeutig zugeordnet werden.
Verbindet die erste Änderung der Aufbewahrung nicht mit Datenbankmigration, Plugin-Update und Weltneustart von Grund auf. Getrennte Änderungen lassen sich besser beurteilen. Wird während der Vorbereitung ein neuer Vorfall gemeldet, muss dessen Bearbeiter die benötigten Nachweise vor dem Fortfahren benennen können.
Ein kopierfertiger Löschbefehl fehlt hier bewusst: Alter und Umfang müssen aus eurem freigegebenen Wartungsplan stammen, nicht aus einem Artikel, der in die Produktionskonsole kopiert wird.
Verlauf so sichern, dass er wieder nutzbar ist
Ein Weltbackup allein ist noch kein Wiederherstellungsplan für CoreProtect. Nehmt Verlaufsdatenbank und Konfiguration in die Übersicht der zu sichernden Komponenten auf. Bei externem Speicher vereinbart ihr mit dem zuständigen Betreiber ein konsistentes Datenbankbackup. Das Kopieren des Minecraft-Verzeichnisses schließt diesen Dienst nicht automatisch ein.
Eine Änderung von database-type überträgt keinen bestehenden Verlauf. CoreProtect beschreibt die Migration als getrennten, versionsabhängigen Vorgang mit Sicherung und Validierung in der Migrationsanleitung. Plant einen Wechsel des Datenbanktyps als eigene Wartung.
Erprobt vor der ersten Bereinigung den Zugriff auf eine Sicherung in einer isolierten Umgebung. Sucht einen bekannten älteren Vorfall und eine aktuelle kontrollierte Aktion. Haltet Ergebnis, Sicherungsdatum und benötigte Zeit bis zur Nutzbarkeit fest. Unsere Anleitung zur Probe einer Minecraft-Wiederherstellung hilft beim Aufbau des Ablaufs.
Trennt den gesicherten Verlauf vom aktiven Datenbestand. Eine alte Kopie über die laufende Produktion zurückzuspielen, nur um eine Moderationsfrage zu beantworten, würde eine eigene Wiederherstellungsentscheidung verlangen. Auch Archivkopien brauchen eine Aufbewahrungsfrist und eine zuständige Person für den Zugriff.
Eine prüfbare Wartung übergeben
Vor der Freigabe sollten folgende Fragen beantwortet sein:
- Welche Meldefrist und welche offenen Fälle wurden geprüft?
- Welche Datenbank und welche Welten betrifft die Aktion?
- Wo liegt die Sicherung, und wann wurde ihre Nutzbarkeit geprüft?
- Wer führt aus, wer kontrolliert, und wann sind beide erreichbar?
- Welche aktuellen und älteren Einträge werden anschließend geprüft?
- Welche fehlenden Nachweise, Backup-Probleme oder Speicherabweichungen stoppen die Arbeit?
Kontrolliert danach den aufbewahrten Verlauf und eine neu protokollierte Testaktion, prüft Fehlermeldungen und messt den tatsächlichen Speicherplatz. Dokumentiert das Ergebnis auch dann, wenn die Dateigröße kaum sinkt. Plant den nächsten Eingriff anhand der Beobachtungen statt einer angenommenen Speicherersparnis.
Soll diese Arbeit Teil eines Infrastrukturauftrags werden, schickt Mineando eure Softwareversionen, Weltliste, Untersuchungsfrist und bisherige Backup-Lösung. Betreute Minecraft-Infrastruktur wird individuell abgegrenzt und angeboten; Wartungszuständigkeiten und Support-Abdeckung werden gesondert vereinbart.
