CoreProtect Retention: How Much History Should You Keep?

Choose CoreProtect retention from the time your community needs to report and investigate incidents, then check whether storage and recovery procedures can support it. Before deleting history, identify the active database, preserve a recoverable copy and confirm that no open case still needs the records. A nearly full disk is a reason to intervene, but it is a poor moment to invent your moderation policy.

This guide is for established server owners and teams commissioning managed operations. It provides a maintenance decision, rather than another rollback tutorial. The examples and acceptance checks below are proposed procedures; we have not run them on your server or measured a CoreProtect capacity benchmark.

Set the investigation window first

Ask moderators how long incidents actually take to surface. Include players returning after a break, reports about shared builds, and cases passed between volunteers. Then agree a response window your team can realistically maintain.

Use this planning model:

Required history = maximum accepted reporting delay + investigation allowance + operating margin.

For a hypothetical community accepting reports up to 14 days after an incident, allowing seven days for investigation and keeping a nine-day margin gives 30 days. These numbers are policy choices, not CoreProtect defaults or universal recommendations. If your community accepts older reports, this example is insufficient.

Write the starting point precisely: the age of the underlying action, not the day a moderator opens the ticket. Give unresolved cases an explicit review before scheduled deletion. An exception needs an owner and an expiry review, otherwise “keep it for now” quietly becomes indefinite retention.

Confirm what history you actually have

CoreProtect supports per-world logging overrides and exclusions through blacklist.txt. A retention period cannot recover activity that was never recorded. Check the effective settings for each relevant world against the configuration documentation.

Create a small coverage register. For each world, list the incidents moderators promise to investigate, the actions needed as evidence, and a recent controlled example they can find. Include your lobby, survival worlds and any event world separately. Do not assume that a working lookup in the lobby proves coverage everywhere.

Record the installed plugin version, selected database backend, database location or remote destination, and the person responsible for backups. Keep access credentials out of the register. A teammate should be able to identify the correct dataset without copying a password into a ticket.

If results are missing, pause the retention change. Check the world, identity, time window and recording configuration before treating an empty result as proof that nothing happened.

Separate three maintenance decisions

Decision	Question to answer	Evidence to keep
Retention	How far back must moderators investigate?	Agreed reporting window and open-case review
Storage	Can the current system sustain that window?	Measured growth, free space and maintenance headroom
Recovery	Can the team retrieve preserved history?	A successful isolated recovery rehearsal

Measure database storage and available filesystem space at consistent intervals, including a busy event period. Record whether backups share the same volume. Estimate when you would reach your own minimum headroom, then schedule intervention early enough for a person to respond. Do not turn a short quiet sample into a promised player capacity.

Distinguish active database size, backup size and temporary maintenance requirements. A retention target expressed in days does not tell you how much disk a particular workload needs. If the budget cannot support the agreed investigation window, resolve that conflict with the owner before deleting evidence.

Make the purge boundary explicit

The command reference defines t:30d for a purge as deleting records older than 30 days. Disk reclamation depends on the backend; #optimize is not a universal shortcut. Check your version before preparing the maintenance command.

Have the operator write a plain-language statement first: “Remove history older than the approved cutoff from these worlds.” A reviewer should be able to compare that statement with the intended command and current time. Record the timezone used in the maintenance notes so that case timestamps can be interpreted consistently.

Do not combine a first retention change with a database migration, plugin upgrade and world reset. Separate changes make the outcome easier to assess. If an incident arrives during preparation, give the case owner a chance to identify affected evidence before proceeding.

We deliberately omit a ready-to-run deletion command: its approved age and scope must come from your register, not from an article copied into a production console.

Preserve history you can actually recover

A world backup alone is not your CoreProtect recovery plan. Include the history database and its configuration in the recovery inventory. For external storage, agree a consistent database backup method with whoever operates that service; do not assume copying the Minecraft directory includes it.

Changing database-type does not transfer existing history. CoreProtect documents database migration as a separate, version-dependent operation with backup and validation steps in its migration guide. Treat a storage-engine change as its own maintenance project.

Before the first purge, rehearse access to a preserved copy in an isolated environment. Check an older known incident and a recent controlled action. Record what you found, the copy date and the time needed to make it usable. Our Minecraft recovery rehearsal guide helps structure that exercise.

Keep the preserved history separate from the live dataset. Restoring an old copy over current production just to answer one moderation question would need a separate recovery decision. Give archived copies their own retention period and named access owner too.

Hand over a maintenance checklist

Before approving the job, require these answers:

1. Which reporting window and unresolved cases were reviewed?
2. Which database and worlds will the operation affect?
3. Where is the recovery copy, and when was its usability checked?
4. Who runs the operation, who reviews it, and when can they respond?
5. Which recent and older records will be checked afterward?
6. What stops the job if the evidence, backup or storage assumptions are wrong?

Afterward, verify retained history and a newly recorded controlled action, review errors, and measure actual space. Record the outcome even if the file size barely changes. Adjust future planning from observations rather than an assumed amount of reclaimed storage.

If you need this included in an infrastructure assignment, send Mineando your software versions, world list, investigation window and current backup arrangement. Managed Minecraft infrastructure is scoped and quoted individually; agree maintenance responsibilities and support coverage separately.