Codex CLI Claude Skill

minecraft-server-admin

Set up, operate, tune, and troubleshoot Minecraft Java 26.x and legacy 1.21.x servers across Paper, Purpur, Folia, Velocity, Fabric, and NeoForge. Use for infrastructure, backups, proxies, and live operations, not plugin or mod development.

LLM Mart · 0 points · 10 views 0 listing impressions 0 install-command copies
Virus-scanned Reviewed automatically before listing.

Full trust report

Download Jahrome907-minecraft-agent-skills-.codex_skills_minecraft-server-admin-dd57c5a.zip · 7 KB
Part of jahrome907/minecraft-agent-skills — 52 skills

Install

skills CLI npx skills add https://github.com/Jahrome907/minecraft-agent-skills/tree/main/.codex/skills/minecraft-server-admin
Claude Code claude plugin marketplace add https://llmmart.ai/marketplace.json && claude plugin install jahrome907-minecraft-agent-skills@llmmart
Git git clone https://github.com/Jahrome907/minecraft-agent-skills.git

The skills CLI installs just this skill, for any of its supported agents. Claude Code installs the whole jahrome907/minecraft-agent-skills collection as a plugin from our marketplace. Git is the plain clone.

Skill manifest

Minecraft Server Administration Skill

Scope and Routing Boundaries

Routing Boundaries

  • Use when: the task is infrastructure or live operations for Minecraft servers (deployment choice, tuning, backups, proxying, security, incident response).
  • Do not use when: the task is writing plugin code (minecraft-plugin-dev) or writing mods/loaders (minecraft-modding, minecraft-multiloader).
  • Do not use when: the task is WorldEdit command workflows (minecraft-worldedit-ops) or EssentialsX workflow/policy design (minecraft-essentials-ops).
  • Do not use when: the task is datapack/resource-pack authoring (minecraft-datapack, minecraft-resource-pack).

References

  • Read references/deployment-checklists.md when the task is an incident, rollout window, proxy change, or recovery drill and you need a compact checklist before acting.

Deployment Decision Matrix

Use this table when choosing a deployment. For an existing server, inspect its stack and version first and preserve them unless migration is requested.

Deployment profile Recommended stack Pick this when Watch-outs
Small SMP on Paper Paper only Up to ~30 concurrent players, broad plugin compatibility, low ops overhead Do not over-tune early; profile before changing many defaults
Larger public Paper server Paper + Spark + stricter plugin/change control Public server with frequent joins, moderate plugin set, uptime matters Plugin sprawl is the top TPS risk
Velocity-backed network Velocity + multiple Paper backends Hub/minigame/factions split across servers, need shared entrypoint Forwarding/auth mismatches can block joins
Purpur gameplay-heavy server Purpur (optionally behind Velocity) You want gameplay knobs exposed in config without custom plugin code Extra toggles increase misconfiguration risk
Folia high-concurrency server Folia + Folia-compatible plugins only Very high concurrency with region-threading goals Many plugins are not Folia-safe
Fabric/NeoForge mod server Fabric or NeoForge server build You require loader mods, custom content, modpack behavior Bukkit/Paper plugins do not apply

Deployment Type Routing

  • Small SMP and most public plugin servers: use Paper baseline first.
  • Use Purpur only when you explicitly need Purpur gameplay controls.
  • Use Folia only when plugin compatibility has been validated for region-threading.
  • Use Velocity when one process is not enough or you need separate backend roles.
  • Use Fabric/NeoForge when the requirement is mod-driven, not plugin-driven.

Java versions

  • Paper and Purpur: Minecraft 26.1+ requires Java 25; Minecraft 1.21.x uses Java 21. Verify the exact Paper/Purpur build and installed plugins before a version change.
  • Current Velocity 4.x requires Java 25. For a legacy proxy, retain the Java version required by that exact proxy release rather than applying the current version by default.

Playbook: Performance Tuning

Step 1: Establish baseline

Collect a baseline before edits. Linux host example:

free -h
top -b -n 1 | head -n 25

Windows PowerShell host example:

Get-CimInstance Win32_OperatingSystem | Select-Object FreePhysicalMemory,TotalVisibleMemorySize
Get-Process java | Sort-Object CPU -Descending | Select-Object -First 5 Id,CPU,WorkingSet,Path

In server console:

tps
mspt
spark healthreport

Record:

  • peak player count
  • MSPT at idle and at peak activity
  • top plugins by CPU from Spark report

Step 2: Profile the real bottleneck

Use Spark instead of guesswork:

spark profiler --timeout 180
spark tps
spark tickmonitor --threshold-tick 50

The 50 ms threshold reports ticks that exceed one normal 20 TPS tick; adjust it only when the incident threshold is intentionally different.

Then identify whether the issue is:

  • plugin task load
  • entity count / mob farm pressure
  • chunk generation / disk I/O
  • garbage-collection pauses

Step 3: Apply targeted fixes

Do not tune everything at once. Apply one group at a time.

  1. Chunk and simulation pressure:
  • lower view-distance and simulation-distance first
  • pre-generate worlds for survival-heavy maps
  1. Entity pressure:
  • adjust despawn ranges and mob-spawn behavior in Paper world config
  • cap problematic entities where appropriate
  1. Plugin pressure:
  • disable or replace top offenders from Spark traces
  • reduce async task frequency where plugin settings allow

Step 4: Use stable startup flags

For Java 25 on current Paper/Purpur, start with a simple measured baseline:

java -Xms4G -Xmx4G -jar server.jar --nogui

Increase heap only when profiling and player load justify it. Add collector flags only after validating them against the exact JDK and Paper version.

Step 5: Verify improvements

After each change set:

spark tps
spark healthreport

Keep the change only if MSPT/tick stability improves under representative load.


Playbook: Plugin Operations

Safe plugin change workflow

  1. Build a plugin inventory:
  • plugin name and version
  • required dependencies
  • minimum server version
  1. Stage updates:
  • apply plugin updates in staging first
  • run smoke checks: joins, teleports, economy, permissions, saves
  1. Production rollout window:
  • announce maintenance window
  • stop server cleanly
  • snapshot plugin jars and config
  • deploy update batch
  1. Post-rollout verification:
  • watch startup logs for API warnings
  • run command and permission sanity checks
  • track TPS/MSPT for 15-30 minutes

Rollback checklist

  • Keep previous plugin directory snapshot.
  • If severe regression occurs:
    • stop server
    • restore prior plugin jars/configs
    • start and confirm login/world integrity
  • Document failing plugin/version pair for future blocks.

Playbook: Proxy and Forwarding (Velocity)

Velocity baseline

velocity.toml essentials:

bind = "0.0.0.0:25565"
online-mode = true
player-info-forwarding-mode = "modern"
forwarding-secret-file = "forwarding.secret"

Backend server requirements

server.properties on backend:

online-mode=false

Paper backend forwarding support (config/paper-global.yml):

proxies:
  velocity:
    enabled: true
    online-mode: true
    secret: "paste-the-shared-forwarding-secret-here"

Use the same secret value stored in Velocity's forwarding.secret file; the backend config takes the secret string itself, not a file path.

Keep enforce-secure-profile at the server default unless you are handling a specific legacy-client or incident workaround. It is not part of the baseline Velocity setup. Also confirm settings.bungeecord: false in spigot.yml; do not enable BungeeCord forwarding and Velocity modern forwarding at the same time.

Validation runbook

  1. Confirm proxy port is reachable from clients.
  2. Confirm backend is firewalled from direct internet access.
  3. Join through proxy and verify:
  • UUID consistency
  • skin/profile forwarding
  • plugin permission behavior

Common proxy incidents

  • "Invalid player info forwarding":
    • mismatch in forwarding mode or shared secret between Velocity and backend.
  • Random auth/session failures:
    • mixed online-mode expectations or direct backend exposure.

Playbook: Backup and Recovery

Backup policy template

Asset Frequency Retention Notes
Every configured world folder Hourly incremental + daily full 7 daily, 4 weekly Include custom and externally stored worlds
plugins/, config/, and root server state Daily 14 daily Required for operational restore
Proxy config/secrets Daily 30 daily Store encrypted off-host
Container/orchestration files On change + weekly 8 weeks Git-tracked where possible

Example backup script (Paper/Purpur)

For a production server, quiesce world writes before copying live world folders. The example below assumes a maintenance window and a cleanly stopped server. If you use RCON-based live backups instead, choose a client/secret mechanism that does not expose the password in command arguments. A safe implementation must run save-off, then save-all, copy the data, and guarantee save-on cleanup even when the copy fails. Do not treat a flush or save-all alone as a live backup protocol. Folia disables save-all; use a clean stop or a verified platform snapshot there. Test the restore path before trusting any backup.

For Fabric or NeoForge recovery, additionally inventory mods/ and record the exact loader launch state: Minecraft and loader versions, Java version, launch command and arguments, launcher or installer artifacts, and any version or library manifests used by that deployment. Restore those matching components with the configured world folders; this Paper/Purpur example does not capture them for you.

Supply the complete world-folder list as arguments, relative to SERVER_ROOT, after checking level-name and any multi-world plugin configuration. Back up worlds stored outside that root separately; do not infer coverage from world*.

#!/usr/bin/env bash
set -euo pipefail

if [[ "${SERVER_STOPPED_CONFIRMED:-}" != "1" ]]; then
  echo "Set SERVER_STOPPED_CONFIRMED=1 only after stopping the server cleanly." >&2
  exit 1
fi

DATE="$(date +%Y-%m-%d_%H-%M-%S)"
BACKUP_ROOT="/backups/minecraft"
SERVER_ROOT="/srv/minecraft"
DEST="${BACKUP_ROOT}/${DATE}"

if [[ "$#" -eq 0 ]]; then
  echo "Usage: backup.sh <world-folder> [additional-world-folders...]" >&2
  exit 1
fi
for world_dir in "$@"; do
  if [[ ! -d "$SERVER_ROOT/$world_dir" ]]; then
    echo "Missing configured world folder: $world_dir" >&2
    exit 1
  fi
done

mkdir -p "$DEST"

tar -czf "${DEST}/worlds.tar.gz" -C "$SERVER_ROOT" -- "$@"

state_items=()
for item in \
  plugins config server.properties bukkit.yml spigot.yml paper-global.yml \
  paper-world-defaults.yml permissions.yml ops.json whitelist.json \
  banned-players.json banned-ips.json; do
  [[ -e "$SERVER_ROOT/$item" ]] && state_items+=("$item")
done

if [[ "${#state_items[@]}" -gt 0 ]]; then
  tar -czf "${DEST}/server-state.tar.gz" -C "$SERVER_ROOT" "${state_items[@]}"
fi

Recovery drill (must be tested)

  1. Stop server.
  2. Restore selected backup to staging directory.
  3. Validate ownership/permissions.
  4. Start server in maintenance mode.
  5. Verify:
  • world spawn loads
  • player data is readable
  • key plugins initialize
  1. Reopen to players.

Define targets:

  • RPO (acceptable data loss window)
  • RTO (acceptable restore duration)

Playbook: Live Troubleshooting

Incident triage flow

  1. Classify incident:
  • crash on startup
  • severe lag / TPS collapse
  • join/auth failures
  • memory/disk pressure
  1. Capture evidence first. Linux host example:
df -h
free -h

Windows PowerShell host example:

Get-PSDrive -PSProvider FileSystem
Get-CimInstance Win32_OperatingSystem | Select-Object FreePhysicalMemory,TotalVisibleMemorySize

From server/proxy console:

spark tps
spark healthreport
  1. Stabilize:
  • stop risky rollout changes
  • disable newest suspect plugin first
  • reduce player impact (maintenance mode, temporary queue, restricted worlds)
  1. Recover and document:
  • apply rollback or hotfix
  • document root cause and permanent preventive action

Fast symptom map

Symptom First checks Typical root cause
Startup crash after plugin update latest logs, plugin dependency chain incompatible plugin/API mismatch
High MSPT only at peak hours Spark profiler, entity/chunk stats mob farms, heavy scheduled tasks, chunk I/O
Players cannot join via proxy forwarding mode + secret + backend exposure Velocity/backend config mismatch
Periodic hard lag spikes GC pauses + autosave + backup overlap memory pressure, backup I/O contention

Operational Config Reference

server.properties high-impact keys

max-players=100
view-distance=10
simulation-distance=8
sync-chunk-writes=true
max-tick-time=60000
enable-rcon=false

bukkit.yml and spigot.yml

Use Spigot/Bukkit docs as authoritative for version-specific defaults and side effects. Tune conservatively and re-measure after every change set.

Paper config files

  • config/paper-global.yml
  • config/paper-world-defaults.yml

Adjust these only after profiling identifies an actionable bottleneck.


Deployment Patterns

Docker Compose (Paper)

services:
  paper:
    image: itzg/minecraft-server:java25
    container_name: mc-paper
    environment:
      EULA: "TRUE"
      TYPE: "PAPER"
      VERSION: "26.2"
      MEMORY: "10G"
    ports:
      - "25565:25565"
    volumes:
      - ./data:/data
    restart: unless-stopped

This Docker example targets current Paper 26.2 and Java 25. Re-check plugin compatibility and take a restorable backup before changing an existing server's Minecraft or Java line.

Pterodactyl/Wings notes

  • Keep startup command and memory allocations consistent with tested JVM flags.
  • Pin panel and Wings versions to supported combinations.
  • Validate backup mount and restore workflow before production.

Security Hardening Checklist

  • Keep online-mode=true unless proxy forwarding requires backend online-mode=false.
  • Never expose backend Paper ports directly when using Velocity.
  • Restrict RCON and panel/admin surfaces by firewall/IP allowlist.
  • Rotate secrets (forwarding.secret, panel credentials, backup credentials).
  • Keep plugin sources trusted; verify checksum/release source before install.
  • Maintain off-host encrypted backups.
  • Keep Java runtime and host OS patched.

References

Paper (primary)

Spigot/Bukkit (primary config reference)

Proxy and ecosystem docs

Files (minecraft-agent-skills)
  • references
    • deployment-checklists.md 2.1 KB
      # Minecraft Server Admin Checklists
      
      Load this file when the task needs a compact operational checklist rather than a
      full prose playbook.
      
      ## New Server Bring-Up
      
      - Confirm target platform: Paper, Purpur, Folia, Velocity network, Fabric, or NeoForge.
      - Record Minecraft version, Java version, and plugin/mod compatibility constraints.
      - Create initial backups path and retention policy before first public launch.
      - Lock down firewall rules so only intended ports are exposed.
      - Verify startup, join flow, world save path, and log location.
      - Run a baseline performance capture before adding more plugins or mods.
      
      ## Proxy Change Window
      
      - Confirm forwarding mode and shared secret on both Velocity and backend.
      - Block direct public access to backend servers.
      - Test staff login, normal player login, permissions, and skin/profile forwarding.
      - Keep previous proxy config and backend config available for immediate rollback.
      
      ## Performance Investigation
      
      - Capture current MSPT/TPS and player count before changing configs.
      - Run Spark or equivalent profiling before tuning view distance or entity rules.
      - Change one tuning area at a time: chunks, entities, plugins, or JVM.
      - Re-measure after every change under similar load.
      
      ## Backup and Recovery Drill
      
      - Verify latest full backup and latest incremental backup exist.
      - Restore to a staging path first, not over production.
      - Confirm world folders, plugin configs, and player data load correctly.
      - For Fabric/NeoForge, confirm the restore includes `mods/` plus the recorded
        loader, Java, launch arguments, and deployment manifests.
      - For a live RCON backup, confirm its tested sequence is `save-off`,
        `save-all`, copy, then guaranteed `save-on` cleanup. Use a clean stop or
        verified platform snapshot for Folia because it disables `save-all`.
      - Measure actual restore time and compare it to the target `RTO`.
      
      ## Security Hardening Quick Pass
      
      - Disable unused admin surfaces such as RCON unless deliberately required.
      - Keep secrets off public repos and shared screenshots.
      - Review operator permissions, LuckPerms groups, and panel access.
      - Confirm scheduled backups, update windows, and incident contacts are documented.
      
  • SKILL.md 14.5 KB
    ---
    name: minecraft-server-admin
    description: "Set up, operate, tune, and troubleshoot Minecraft Java 26.x and legacy 1.21.x servers across Paper, Purpur, Folia, Velocity, Fabric, and NeoForge. Use for infrastructure, backups, proxies, and live operations, not plugin or mod development."
    ---
    
    # Minecraft Server Administration Skill
    
    ## Scope and Routing Boundaries
    
    ### Routing Boundaries
    - `Use when`: the task is infrastructure or live operations for Minecraft servers (deployment choice, tuning, backups, proxying, security, incident response).
    - `Do not use when`: the task is writing plugin code (`minecraft-plugin-dev`) or writing mods/loaders (`minecraft-modding`, `minecraft-multiloader`).
    - `Do not use when`: the task is WorldEdit command workflows (`minecraft-worldedit-ops`) or EssentialsX workflow/policy design (`minecraft-essentials-ops`).
    - `Do not use when`: the task is datapack/resource-pack authoring (`minecraft-datapack`, `minecraft-resource-pack`).
    
    ## References
    
    - Read `references/deployment-checklists.md` when the task is an incident, rollout window, proxy change, or recovery drill and you need a compact checklist before acting.
    
    ---
    
    ## Deployment Decision Matrix
    
    Use this table when choosing a deployment. For an existing server, inspect its
    stack and version first and preserve them unless migration is requested.
    
    | Deployment profile | Recommended stack | Pick this when | Watch-outs |
    |---|---|---|---|
    | Small SMP on Paper | Paper only | Up to ~30 concurrent players, broad plugin compatibility, low ops overhead | Do not over-tune early; profile before changing many defaults |
    | Larger public Paper server | Paper + Spark + stricter plugin/change control | Public server with frequent joins, moderate plugin set, uptime matters | Plugin sprawl is the top TPS risk |
    | Velocity-backed network | Velocity + multiple Paper backends | Hub/minigame/factions split across servers, need shared entrypoint | Forwarding/auth mismatches can block joins |
    | Purpur gameplay-heavy server | Purpur (optionally behind Velocity) | You want gameplay knobs exposed in config without custom plugin code | Extra toggles increase misconfiguration risk |
    | Folia high-concurrency server | Folia + Folia-compatible plugins only | Very high concurrency with region-threading goals | Many plugins are not Folia-safe |
    | Fabric/NeoForge mod server | Fabric or NeoForge server build | You require loader mods, custom content, modpack behavior | Bukkit/Paper plugins do not apply |
    
    ### Deployment Type Routing
    
    - Small SMP and most public plugin servers: use Paper baseline first.
    - Use Purpur only when you explicitly need Purpur gameplay controls.
    - Use Folia only when plugin compatibility has been validated for region-threading.
    - Use Velocity when one process is not enough or you need separate backend roles.
    - Use Fabric/NeoForge when the requirement is mod-driven, not plugin-driven.
    
    ### Java versions
    
    - Paper and Purpur: Minecraft 26.1+ requires Java 25; Minecraft 1.21.x uses
      Java 21. Verify the exact Paper/Purpur build and installed plugins before a
      version change.
    - Current Velocity 4.x requires Java 25. For a legacy proxy, retain the Java
      version required by that exact proxy release rather than applying the current
      version by default.
    
    ---
    
    ## Playbook: Performance Tuning
    
    ### Step 1: Establish baseline
    
    Collect a baseline before edits. Linux host example:
    
    ```bash
    free -h
    top -b -n 1 | head -n 25
    ```
    
    Windows PowerShell host example:
    
    ```powershell
    Get-CimInstance Win32_OperatingSystem | Select-Object FreePhysicalMemory,TotalVisibleMemorySize
    Get-Process java | Sort-Object CPU -Descending | Select-Object -First 5 Id,CPU,WorkingSet,Path
    ```
    
    In server console:
    
    ```bash
    tps
    mspt
    spark healthreport
    ```
    
    Record:
    - peak player count
    - MSPT at idle and at peak activity
    - top plugins by CPU from Spark report
    
    ### Step 2: Profile the real bottleneck
    
    Use Spark instead of guesswork:
    
    ```bash
    spark profiler --timeout 180
    spark tps
    spark tickmonitor --threshold-tick 50
    ```
    
    The 50 ms threshold reports ticks that exceed one normal 20 TPS tick; adjust it
    only when the incident threshold is intentionally different.
    
    Then identify whether the issue is:
    - plugin task load
    - entity count / mob farm pressure
    - chunk generation / disk I/O
    - garbage-collection pauses
    
    ### Step 3: Apply targeted fixes
    
    Do not tune everything at once. Apply one group at a time.
    
    1. Chunk and simulation pressure:
    - lower `view-distance` and `simulation-distance` first
    - pre-generate worlds for survival-heavy maps
    
    1. Entity pressure:
    - adjust despawn ranges and mob-spawn behavior in Paper world config
    - cap problematic entities where appropriate
    
    1. Plugin pressure:
    - disable or replace top offenders from Spark traces
    - reduce async task frequency where plugin settings allow
    
    ### Step 4: Use stable startup flags
    
    For Java 25 on current Paper/Purpur, start with a simple measured baseline:
    
    ```bash
    java -Xms4G -Xmx4G -jar server.jar --nogui
    ```
    
    Increase heap only when profiling and player load justify it. Add collector flags
    only after validating them against the exact JDK and Paper version.
    
    ### Step 5: Verify improvements
    
    After each change set:
    
    ```bash
    spark tps
    spark healthreport
    ```
    
    Keep the change only if MSPT/tick stability improves under representative load.
    
    ---
    
    ## Playbook: Plugin Operations
    
    ### Safe plugin change workflow
    
    1. Build a plugin inventory:
    - plugin name and version
    - required dependencies
    - minimum server version
    
    1. Stage updates:
    - apply plugin updates in staging first
    - run smoke checks: joins, teleports, economy, permissions, saves
    
    1. Production rollout window:
    - announce maintenance window
    - stop server cleanly
    - snapshot plugin jars and config
    - deploy update batch
    
    1. Post-rollout verification:
    - watch startup logs for API warnings
    - run command and permission sanity checks
    - track TPS/MSPT for 15-30 minutes
    
    ### Rollback checklist
    
    - Keep previous plugin directory snapshot.
    - If severe regression occurs:
      - stop server
      - restore prior plugin jars/configs
      - start and confirm login/world integrity
    - Document failing plugin/version pair for future blocks.
    
    ---
    
    ## Playbook: Proxy and Forwarding (Velocity)
    
    ### Velocity baseline
    
    `velocity.toml` essentials:
    
    ```toml
    bind = "0.0.0.0:25565"
    online-mode = true
    player-info-forwarding-mode = "modern"
    forwarding-secret-file = "forwarding.secret"
    ```
    
    ### Backend server requirements
    
    `server.properties` on backend:
    
    ```properties
    online-mode=false
    ```
    
    Paper backend forwarding support (`config/paper-global.yml`):
    
    ```yaml
    proxies:
      velocity:
        enabled: true
        online-mode: true
        secret: "paste-the-shared-forwarding-secret-here"
    ```
    
    Use the same secret value stored in Velocity's `forwarding.secret` file; the backend
    config takes the secret string itself, not a file path.
    
    Keep `enforce-secure-profile` at the server default unless you are handling a
    specific legacy-client or incident workaround. It is not part of the baseline
    Velocity setup. Also confirm `settings.bungeecord: false` in `spigot.yml`; do
    not enable BungeeCord forwarding and Velocity modern forwarding at the same time.
    
    ### Validation runbook
    
    1. Confirm proxy port is reachable from clients.
    2. Confirm backend is firewalled from direct internet access.
    3. Join through proxy and verify:
    - UUID consistency
    - skin/profile forwarding
    - plugin permission behavior
    
    ### Common proxy incidents
    
    - "Invalid player info forwarding":
      - mismatch in forwarding mode or shared secret between Velocity and backend.
    - Random auth/session failures:
      - mixed `online-mode` expectations or direct backend exposure.
    
    ---
    
    ## Playbook: Backup and Recovery
    
    ### Backup policy template
    
    | Asset | Frequency | Retention | Notes |
    |---|---|---|---|
    | Every configured world folder | Hourly incremental + daily full | 7 daily, 4 weekly | Include custom and externally stored worlds |
    | `plugins/`, `config/`, and root server state | Daily | 14 daily | Required for operational restore |
    | Proxy config/secrets | Daily | 30 daily | Store encrypted off-host |
    | Container/orchestration files | On change + weekly | 8 weeks | Git-tracked where possible |
    
    ### Example backup script (Paper/Purpur)
    
    For a production server, quiesce world writes before copying live world folders.
    The example below assumes a maintenance window and a cleanly stopped server. If
    you use RCON-based live backups instead, choose a client/secret mechanism that
    does not expose the password in command arguments. A safe implementation must
    run `save-off`, then `save-all`, copy the data, and guarantee `save-on` cleanup
    even when the copy fails. Do not treat a flush or `save-all` alone as a live
    backup protocol. Folia disables `save-all`; use a clean stop or a verified
    platform snapshot there. Test the restore path before trusting any backup.
    
    For Fabric or NeoForge recovery, additionally inventory `mods/` and record the
    exact loader launch state: Minecraft and loader versions, Java version, launch
    command and arguments, launcher or installer artifacts, and any version or
    library manifests used by that deployment. Restore those matching components
    with the configured world folders; this Paper/Purpur example does not capture
    them for you.
    
    Supply the complete world-folder list as arguments, relative to `SERVER_ROOT`,
    after checking `level-name` and any multi-world plugin configuration. Back up
    worlds stored outside that root separately; do not infer coverage from `world*`.
    
    ```bash
    #!/usr/bin/env bash
    set -euo pipefail
    
    if [[ "${SERVER_STOPPED_CONFIRMED:-}" != "1" ]]; then
      echo "Set SERVER_STOPPED_CONFIRMED=1 only after stopping the server cleanly." >&2
      exit 1
    fi
    
    DATE="$(date +%Y-%m-%d_%H-%M-%S)"
    BACKUP_ROOT="/backups/minecraft"
    SERVER_ROOT="/srv/minecraft"
    DEST="${BACKUP_ROOT}/${DATE}"
    
    if [[ "$#" -eq 0 ]]; then
      echo "Usage: backup.sh <world-folder> [additional-world-folders...]" >&2
      exit 1
    fi
    for world_dir in "$@"; do
      if [[ ! -d "$SERVER_ROOT/$world_dir" ]]; then
        echo "Missing configured world folder: $world_dir" >&2
        exit 1
      fi
    done
    
    mkdir -p "$DEST"
    
    tar -czf "${DEST}/worlds.tar.gz" -C "$SERVER_ROOT" -- "$@"
    
    state_items=()
    for item in \
      plugins config server.properties bukkit.yml spigot.yml paper-global.yml \
      paper-world-defaults.yml permissions.yml ops.json whitelist.json \
      banned-players.json banned-ips.json; do
      [[ -e "$SERVER_ROOT/$item" ]] && state_items+=("$item")
    done
    
    if [[ "${#state_items[@]}" -gt 0 ]]; then
      tar -czf "${DEST}/server-state.tar.gz" -C "$SERVER_ROOT" "${state_items[@]}"
    fi
    ```
    
    ### Recovery drill (must be tested)
    
    1. Stop server.
    2. Restore selected backup to staging directory.
    3. Validate ownership/permissions.
    4. Start server in maintenance mode.
    5. Verify:
    - world spawn loads
    - player data is readable
    - key plugins initialize
    1. Reopen to players.
    
    Define targets:
    - `RPO` (acceptable data loss window)
    - `RTO` (acceptable restore duration)
    
    ---
    
    ## Playbook: Live Troubleshooting
    
    ### Incident triage flow
    
    1. Classify incident:
    - crash on startup
    - severe lag / TPS collapse
    - join/auth failures
    - memory/disk pressure
    
    1. Capture evidence first. Linux host example:
    
    ```bash
    df -h
    free -h
    ```
    
    Windows PowerShell host example:
    
    ```powershell
    Get-PSDrive -PSProvider FileSystem
    Get-CimInstance Win32_OperatingSystem | Select-Object FreePhysicalMemory,TotalVisibleMemorySize
    ```
    
    From server/proxy console:
    
    ```bash
    spark tps
    spark healthreport
    ```
    
    1. Stabilize:
    - stop risky rollout changes
    - disable newest suspect plugin first
    - reduce player impact (maintenance mode, temporary queue, restricted worlds)
    
    1. Recover and document:
    - apply rollback or hotfix
    - document root cause and permanent preventive action
    
    ### Fast symptom map
    
    | Symptom | First checks | Typical root cause |
    |---|---|---|
    | Startup crash after plugin update | latest logs, plugin dependency chain | incompatible plugin/API mismatch |
    | High MSPT only at peak hours | Spark profiler, entity/chunk stats | mob farms, heavy scheduled tasks, chunk I/O |
    | Players cannot join via proxy | forwarding mode + secret + backend exposure | Velocity/backend config mismatch |
    | Periodic hard lag spikes | GC pauses + autosave + backup overlap | memory pressure, backup I/O contention |
    
    ---
    
    ## Operational Config Reference
    
    ### `server.properties` high-impact keys
    
    ```properties
    max-players=100
    view-distance=10
    simulation-distance=8
    sync-chunk-writes=true
    max-tick-time=60000
    enable-rcon=false
    ```
    
    ### `bukkit.yml` and `spigot.yml`
    
    Use Spigot/Bukkit docs as authoritative for version-specific defaults and side effects.
    Tune conservatively and re-measure after every change set.
    
    ### Paper config files
    
    - `config/paper-global.yml`
    - `config/paper-world-defaults.yml`
    
    Adjust these only after profiling identifies an actionable bottleneck.
    
    ---
    
    ## Deployment Patterns
    
    ### Docker Compose (Paper)
    
    ```yaml
    services:
      paper:
        image: itzg/minecraft-server:java25
        container_name: mc-paper
        environment:
          EULA: "TRUE"
          TYPE: "PAPER"
          VERSION: "26.2"
          MEMORY: "10G"
        ports:
          - "25565:25565"
        volumes:
          - ./data:/data
        restart: unless-stopped
    ```
    
    This Docker example targets current Paper 26.2 and Java 25. Re-check plugin
    compatibility and take a restorable backup before changing an existing server's
    Minecraft or Java line.
    
    ### Pterodactyl/Wings notes
    
    - Keep startup command and memory allocations consistent with tested JVM flags.
    - Pin panel and Wings versions to supported combinations.
    - Validate backup mount and restore workflow before production.
    
    ---
    
    ## Security Hardening Checklist
    
    - Keep `online-mode=true` unless proxy forwarding requires backend `online-mode=false`.
    - Never expose backend Paper ports directly when using Velocity.
    - Restrict RCON and panel/admin surfaces by firewall/IP allowlist.
    - Rotate secrets (`forwarding.secret`, panel credentials, backup credentials).
    - Keep plugin sources trusted; verify checksum/release source before install.
    - Maintain off-host encrypted backups.
    - Keep Java runtime and host OS patched.
    
    ---
    
    ## References
    
    ### Paper (primary)
    
    - https://docs.papermc.io/paper/
    - https://docs.papermc.io/paper/getting-started/
    - https://docs.papermc.io/paper/admin
    - https://docs.papermc.io/paper/profiling/
    
    ### Spigot/Bukkit (primary config reference)
    
    - https://www.spigotmc.org/wiki/spigot-configuration/
    - https://www.spigotmc.org/wiki/bukkit-configuration/
    - https://www.spigotmc.org/wiki/start-up-parameters/
    
    ### Proxy and ecosystem docs
    
    - https://docs.papermc.io/velocity/
    - https://docs.papermc.io/velocity/getting-started/
    - https://docs.papermc.io/folia/faq/
    - https://spark.lucko.me/docs
    - https://spark.lucko.me/docs/Command-Usage
    - https://github.com/itzg/docker-mc-backup
    - https://geysermc.org/wiki/geyser/
    - https://pterodactyl.io/project/introduction.html
    

Comments (0)

Sign in to join the conversation.

No comments yet.

Reviews (0)

No reviews yet.

Related