Anticheat Plugin Data Folders After an Upgrade

Does an upgrade reset an anticheat's data folder?

Usually not. Replacing the anticheat jar leaves its data folder in place, so old config, generated files, and cached state from the previous release can still be active. Before the first restart on the new jar, back up the data folder, compare each file with the new release's defaults, and confirm which values the new version reads.

What does the data folder hold?

A Bukkit-style plugin usually keeps its files in a folder named after the plugin, inside the plugins directory. The contents vary by plugin. Typical contents include configuration files, message or language files, and sometimes logs or data files the plugin writes while it runs. Read your plugin's documentation for the exact list instead of assuming one.

What does the folder look like before and after an upgrade?

The tree below shows a typical layout before and after replacing the jar. Your plugin's file names will differ. Look for the new jar name, the old config still in place, and any new file the new version creates beside it.

Before                            After
plugins/                          plugins/
  <Anticheat>-<old>.jar            <Anticheat>-<new>.jar
  <Anticheat>/                     <Anticheat>/
    config.yml   (your values)       config.yml   (same file, check keys)
    messages.yml                     messages.yml
    logs/        (evidence)          logs/        (keep, do not delete)

How do you back up the folder before replacing the jar?

Stop the server before you copy, so no file changes during the backup. Keep the archive name specific enough to find later: plugin name, old version, and date.

cd <server-root>/plugins
mkdir -p ~/backups
tar -czf ~/backups/<PluginName>-<old-version>-<YYYY-MM-DD>.tar.gz <PluginName>

How do you compare old values with the new defaults?

Generate a fresh copy of the config on a staging server with the new jar, then compare it with your old file. The goal is to find keys you changed on purpose, keys that changed default, and keys that no longer exist.

• Copy the old data folder to a staging server, and start it with the new jar so the plugin writes its current defaults.
• Diff the old config against the new one with a command such as diff -u.
• List keys that appear only in the old file. The new version may ignore them.
• List keys whose default changed, and decide for each whether your value still applies.
• Apply the decisions to production, then record each key you kept, changed, or removed.

diff -u <old-config-copy> <new-default-config>

What signs show that a stale file is still active?

A stale file can keep control of behavior after an upgrade. Check these signs in the startup log and in staging alerts before you assume the new jar is in charge.

• A value you changed earlier does not match the value the new version reports at startup.
• A check or option you removed still produces alerts.
• New options you expected to see have no visible effect.
• Messages still show text from the old language file.

Which files should you never delete on upgrade?

Treat the data folder as a record, not just a settings folder. Some plugins keep logs or stored state that staff use for appeals or history. Deleting a file to fix a startup problem can erase that record, and it can also reset your settings to defaults.

What should you back up and diff?

Back up the whole plugin folder, not only the config. Diff the config and message files, and note any file the new jar adds or stops writing. Keep the archive outside the server folder.

What is the upgrade procedure, step by step?

Run these steps on staging first, then repeat them on production. Do not skip the backup check.

• Announce a maintenance window, and tell staff that alerts may pause during the restart.
• Stop the server, then archive the plugin folder with the command above.
• Open the archive and confirm it contains the data folder and its config file.
• Replace the anticheat jar, and match the PacketEvents version to what the new release expects.
• Start once on staging, and read the startup log for the plugin version line and any config warnings.
• Compare the regenerated config with your backup, and decide each changed key.
• Run an alert-only window on staging, then repeat the steps on production.

How do you roll back safely?

A rollback needs the old jar and the old data folder together. A newer version can write config keys that an older jar does not understand. Restore the full backup when you are unsure, and avoid restoring only the config file.

If the new version fails after startup, stop the server, put back the old jar, restore the full data folder from the archive, and start again.