CoreProtect tasks

Task guides and troubleshooting for CoreProtect. Check the installed release before changing configuration or data.

Investigate one chest withdrawal with a bounded CoreProtect lookup

A missing item report needs the correct container, time window and transaction type. Query a small area first so an unrelated server-wide result does not become an accusation.

Follow the procedure

  1. Ask the owner for the chest location, approximate time and missing item type. Record the world and coordinates privately and avoid moving items during the investigation.
  2. Check /co status and confirm CoreProtect was logging the relevant container actions at the time. A plugin installed afterward cannot reconstruct an earlier withdrawal.
  3. Stand at the reported chest and use a bounded query such as /co lookup t:1h r:5 a:-container. Adjust the time to the report rather than searching every historical transaction.
  4. Read the actor, item amount and timestamp for each relevant row. Use the documented include parameter to narrow the item type if the first result contains unrelated transactions.
  5. Compare deposits as well as withdrawals when calculating the change. Check linked containers or automation separately; a net missing count is not necessarily one player’s single action.
  6. Save the relevant evidence and discuss any restoration with the owner. A lookup is read-only and should remain separate from an authorized inventory or container rollback.

Check the result

The result should identify relevant withdrawals in the selected area and period, or establish that no matching logged transaction was found. It does not by itself prove malicious intent. Correlate the item count and ownership context before applying moderation or restoring possessions.

If the result is wrong

If no rows appear, verify the world, time range, logging configuration and retention before widening the search. Do not treat an empty result as proof that the owner invented the loss. Avoid a global rollback or manual database edits while the transaction scope remains uncertain.

References and related help

Exclude routine block types from a CoreProtect investigation

A busy build area can produce thousands of ordinary block records. Use a bounded lookup and a deliberate exclusion list to inspect the incident without changing the world.

Follow the procedure

  1. Record the incident area, world and relevant time range. Decide which block actions are under investigation before excluding anything that could itself be evidence.
  2. Stand at the affected location and run an explicit small-radius block lookup, such as /co lookup t:30m r:10 a:block. Read a sample before adding filters.
  3. Identify routine materials you can safely exclude for this question. Use the documented e: parameter with exact material names supported by your installed Minecraft and CoreProtect versions.
  4. Repeat the lookup with the exclusion list and compare the result count and examples. Keep the unfiltered query in the case notes so another reviewer can reproduce the reasoning.
  5. If the excluded material becomes relevant, remove that exclusion rather than assuming the filtered view is a complete history. Include and exclude parameters answer different questions.
  6. Save only the necessary rows and keep the final filter with the evidence. Do not reuse the lookup as a rollback until an administrator has reviewed its full scope.

Check the result

The filtered result should remove the selected routine materials while retaining the incident’s relevant actions within the same time and area. Compare at least one known included and excluded action. A quieter result is useful only if the filter has not removed the evidence you need.

If the result is wrong

If expected rows vanish, return to the original read-only query and inspect material names and parameter syntax. Broaden one constraint at a time. Do not compensate by running a global search or a world-changing rollback with an exclusion list you have not verified.

References and related help

Limit a CoreProtect lookup to a WorldEdit selection

An irregular incident boundary can be easier to select than describe with a radius. CoreProtect supports a WorldEdit-selection scope, but you must confirm the active selection before using it.

Follow the procedure

  1. Confirm that compatible WorldEdit and CoreProtect versions are installed. Read the radius parameter reference for r:#worldedit or its documented alias on your release.
  2. Select the intended area in the correct world using WorldEdit’s supported selection controls. Check both horizontal bounds and height; a shallow selection can omit relevant blocks.
  3. Run a read-only lookup such as /co lookup t:1h r:#worldedit a:block. Keep the time and action constraints explicit even though the selection already limits space.
  4. Compare a known action inside the selection with a known action outside it. Review the displayed locations rather than assuming the selection used by another administrator is yours.
  5. If results are incomplete, inspect the selection again before increasing the time range. A newly selected world or region can change the meaning of the same command.
  6. Record the bounds, world and query in the case notes. If a rollback is later approved, preview that exact selection and filter again before any world-changing action.

Check the result

The lookup should return relevant logged actions inside the selected volume and omit the outside test action. An empty result may indicate a wrong selection rather than absent history. Confirm the spatial scope with known examples before drawing a conclusion.

If the result is wrong

If CoreProtect does not recognize the selection, check the installed integration and permission without replacing plugins during an active investigation. Fall back to a clearly bounded radius query if appropriate. Do not run a rollback while the active selection or world remains uncertain.

References and related help

Review an inventory rollback before restoring missing player items

Inventory recovery can duplicate items if the original transactions are not understood. Inspect the specific account and time window before approving a CoreProtect inventory rollback.

Follow the procedure

  1. Confirm the player identity and collect the exact loss time, item types and any container or trade involved. Ask the player to avoid further transfers while the incident is reviewed.
  2. Check that the installed release logged inventory transactions when the loss occurred. A current setting cannot recreate records that were never collected.
  3. Use a read-only query for the named account with a narrow time range and the documented inventory action parameter. Review both additions and removals to understand the full transaction chain.
  4. Look for corresponding container, pickup or trade activity that could leave the same items elsewhere. Returning a withdrawal without checking its destination can create an unintended duplicate.
  5. Rehearse the proposed recovery on an isolated copy containing matching world and database state. Use the installed release’s supported preview and inventory rollback behaviour where available.
  6. Have an authorized administrator approve the exact recovery scope and capture pre-change item counts. Keep normal backups and a targeted reversal plan available before touching production inventories.

Check the result

The review should explain which transactions caused the loss and whether a targeted inventory recovery can restore the intended state without duplicating items. A list of removals alone is insufficient. Record the account, filters and expected item totals before any authorized live action.

If the result is wrong

If the transaction chain remains ambiguous, stop the rollback proposal and preserve the evidence. Consider a documented manual restitution decision instead of guessing a broad rollback. Never combine unrelated players or long time ranges merely because the desired item appears somewhere in the output.

References and related help

Reverse an accidental CoreProtect rollback with the matching scope

An accidental rollback should be reversed from its recorded parameters, not followed by a broader repair. Capture the operation details before another administrator changes the same area.

Follow the procedure

  1. Pause building in the affected area and record the rollback command, executor, completion time and reported scope. Identify whether the action was a rollback, restore or only a preview.
  2. Read the installed command documentation for restore and /co undo. The documented undo performs the opposite of the relevant rollback or restore; verify which operation the current context will target.
  3. Take a current recovery copy before making a second world change. Preserve the CoreProtect database and any before-incident backup so later review has both states.
  4. Rehearse a matching restore or supported undo on an isolated copy when the affected area is valuable. Keep the same user, time, action and spatial filters rather than widening them.
  5. Have the authorized administrator execute the reviewed reversal once. Watch completion output and keep other staff from starting overlapping recovery commands.
  6. Compare the affected blocks and containers with the recorded expected state. Check work performed after the first rollback separately, since a reversal may not preserve every intervening player action.

Check the result

The incorrectly reversed actions should return to the intended state within the matching scope, with completion output retained. Verify both the original damage and any legitimate later work. A command saying finished does not establish that every affected player’s possessions are correct.

If the result is wrong

If the reverse preview or rehearsal is wrong, stop and retain the current state for review. Do not alternate broad rollback and restore commands repeatedly. Use the exact recorded operation or a coordinated backup recovery plan, with world and database state kept consistent.

References and related help

Turn off CoreProtect inspection without granting rollback access

Inspection mode changes what happens when staff click blocks, so leaving it enabled can confuse routine building. Teach inspectors the toggle while keeping world-changing recovery permissions separate.

Follow the procedure

  1. Check the installed CoreProtect permissions reference and identify the inspector capability. Do not grant rollback, restore, purge or administrative access simply to let a helper inspect a block.
  2. Use a non-operator helper account with the intended role. Run /co inspect or the documented /co i alias and click a disposable test block.
  3. Confirm the expected inspection output appears. Check whether the helper’s ordinary block action is replaced by inspection so they understand why clicking behaves differently.
  4. Run the same inspection toggle again to disable it. Click another test block and verify the account has returned to its normal allowed building behaviour.
  5. Test reconnect behaviour on your installed release and record whether inspectors must toggle the mode again. Avoid assuming state persists or resets identically across plugin versions.
  6. Confirm the helper cannot invoke recovery or purge operations. Keep the staff guide clear that a block-history result is evidence for review, not permission to alter another player’s build.

Check the result

The helper can enter inspection, read the expected block history and leave inspection cleanly, while recovery commands remain denied. A successful read demonstrates the inspector role; normal block interaction after the second toggle demonstrates that the apparent building problem is resolved.

If the result is wrong

If clicking still does not behave normally, check region protection, game mode and other inspection plugins before changing CoreProtect permissions. If history is unavailable, verify logging and retention. Do not grant operator status or reset player data to clear an inspection-mode misunderstanding.

References and related help

Plan CoreProtect retention without losing evidence needed for recovery

Older audit records consume storage but may be the only evidence for a delayed grief report. Decide a retention policy from actual recovery needs before scheduling any irreversible purge.

Follow the procedure

  1. Measure the current database size and growth over several normal days. Record the existing retention policy, backup coverage and the oldest report staff are expected to investigate.
  2. Check which logging categories account for growth and which are needed for your moderation workflow. Do not disable essential logging merely to make a storage graph smaller.
  3. Read the installed purge documentation carefully. Time cutoffs remove records older than the chosen age, and database optimization behaviour differs between storage backends.
  4. Agree a retention period that covers your published support and appeal expectations. Keep a consistent archived database copy if older records must remain available outside the live server.
  5. Rehearse the proposed purge on an isolated restored database and compare record availability before and after. Measure actual reclaimed space rather than assuming row deletion immediately shrinks every database file.
  6. Only schedule a separately approved production purge after backup recovery has been checked. Restrict purge access to administrators and record the cutoff, scope and completion result.

Check the result

The retention plan should state what remains searchable live, what can be recovered from archives and what will be permanently unavailable. Its storage estimate should come from a rehearsal on the same backend. A purge is a data-loss decision, not a routine fix for an unexplained full disk.

If the result is wrong

If the rehearsal removes records you still need, increase the retention period and keep production unchanged. Restore the isolated test from its backup when comparing alternatives. Do not run a shorter production purge first and expect a later setting change to recover deleted history.

References and related help

Investigate a growing CoreProtect consumer queue without discarding it

A growing write queue can explain why recent actions do not appear in lookups yet. Preserve queued evidence and inspect database performance before pausing processing or restarting the server.

Follow the procedure

  1. Capture /co status and the relevant startup or database error messages. Record the time so you can compare queue behaviour against the server’s player count and workload.
  2. Check disk space and database availability through the panel or database administrator. A connection failure, full disk and slow storage require different corrections.
  3. Repeat the supported status observation after a short interval. Determine whether the queue is shrinking, stable or growing rather than relying on one large number.
  4. Read the /co consumer documentation before touching it. It is a console control that pauses or resumes processing; running it blindly can worsen an existing backlog.
  5. Reduce avoidable high-volume work such as a planned mass edit while investigating. Keep ordinary logging enabled and ask support to assess persistent database errors.
  6. After the underlying issue is corrected, observe the queue draining and query a known recent disposable block action. Record how long it takes to become searchable.

Check the result

The backlog should trend downward and newly recorded test actions should become visible after processing catches up. An enabled plugin with delayed lookups is not the same as lost evidence. Confirm both storage health and the recent test record before declaring recovery complete.

If the result is wrong

If processing remains stalled, preserve logs and request database-specific support before restarting or changing backends. Do not delete database files, discard queued records or repeatedly toggle the consumer. Restore a paused consumer only through the documented control once you know its current state.

References and related help

Explain why CoreProtect has no record of an older action

An empty lookup can reflect scope, retention or logging settings rather than a broken database. Work through those possibilities before telling a player that an event did not happen.

Follow the procedure

  1. Write down the reported world, location, account, action type and approximate time. Check the server’s timezone and whether the report refers to a different backend or restored world.
  2. Run a read-only lookup with an explicit time range, small radius and appropriate action category. Check the exact world and position before broadening filters.
  3. Inspect the relevant logging option in the installed CoreProtect configuration. Establish what was enabled at the incident time, using saved configurations or change records where available.
  4. Check retention and recent purge history. Also identify any database replacement, migration or backup restore that could explain why older records differ from current gameplay.
  5. Create a disposable action of the same supported type and query it after processing catches up. This distinguishes current logging failure from unavailable historical evidence.
  6. Report the narrow conclusion: no matching retained record was found under the tested conditions. Keep uncertainty explicit and use other evidence before moderation or restitution decisions.

Check the result

The investigation should identify a concrete scope mistake, current logging fault or historical coverage limit where possible. A successful new test proves present logging only. It does not prove older events were recorded, and an empty historical result does not prove no event occurred.

If the result is wrong

If current actions are also missing, collect status and database errors and investigate the processing queue. Preserve the existing database while seeking support. Do not reinitialize storage, import random tables or accuse a player solely because one filtered query returned nothing.

References and related help

Rehearse a supported CoreProtect database-backend migration

CoreProtect’s migration command is available only in specific supported builds and backends. Rehearse the matching procedure before changing where a live server stores its audit history.

Follow the procedure

  1. Record the installed CoreProtect build and current backend. Check the migration documentation for feature availability, supported destination types and any release or licensing requirement.
  2. Take a consistent backup of the database and plugin configuration. Preserve a matching world recovery copy if the audit history is part of an ongoing restoration workflow.
  3. Prepare an isolated server copy and a new destination namespace with no existing CoreProtect data. Keep the source database and production connection untouched during rehearsal.
  4. Follow the documented console-only migration workflow for that release. Review its validation mode and ensure the required database-lock setting remains in the documented state.
  5. Compare known historical records and active logging after migration. Where supported, choose full validation when the rehearsal’s time budget permits rather than assuming sampled validation checks every row.
  6. Record duration, disk requirements and the configuration changes made by the migration tool. Plan a controlled production window only after the rehearsal has completed and its data checks pass.
CloudExa game panel: create a server backup
CloudExa game panel reference. This image shows the panel, not the CoreProtect interface.

Check the result

The isolated destination should contain the expected records and accept new test actions through a clean plugin startup. Verify several old locations and a new action, plus the migration’s reported validation result. Successful connectivity alone is insufficient evidence of a complete history transfer.

If the result is wrong

If validation fails or the installed build lacks the feature, keep production on its current backend and retain the rehearsal logs for support. Do not bypass checks by copying guessed tables. Roll back the matched database and configuration rather than swapping only a jar across schema changes.

References and related help