Review GriefDefender expiration settings before enabling cleanup

An inactivity policy can affect valuable player claims. Review the active configuration and matching release behavior without running a production deletion to see what happens.

Before you start

GriefDefender uses LuckPerms and claim-aware rules. Current documentation describes YAML by default with optional HOCON; check the format your server actually generated. Claim, parent and wilderness contexts matter, so record the location and affected player before changing rules.

Work through the check

  1. Back up claim storage, configuration and the matching world data, recording the plugin and LuckPerms builds beside the checkpoint.
  2. Read the installed release’s expiration options and any administrative or playtime exemptions, keeping the current production policy unchanged during the review.
  3. Restore into an isolated server with independent storage and prepare known active, inactive and exempt test owners to compare the configured thresholds.
  4. Use only a documented preview facility if that release provides one; otherwise observe the isolated scheduler and logs, recording ownership and protection before and after its test cycle.

Confirm the result

The isolated test should identify which claims the intended policy affects and which exemptions work. Production owners and their protection should remain unchanged while the policy is evaluated.

If the result differs

Do not borrow Lands preview commands or assume that a similarly named GriefDefender cleanup control is non-destructive. Missing activity data or a mismatched release requires investigation before activating an expiry policy.

Recover safely

Keep production cleanup disabled or at its recorded safe setting until the review is complete. Recover a deleted claim only from a verified matching backup and a planned recovery procedure, not by guessing its former boundaries.

Documentation and related help

Check the GriefDefender maintainer documentation and GriefDefender maintainer reference against your installed release before applying changes.


Revision #1
Created 2026-11-09 16:36:22 UTC by CloudExa Hosting Admin
Updated 2026-11-09 16:36:22 UTC by CloudExa Hosting Admin