How to monitor disk space on your MU Online server and prevent crashes from full disks

A full disk is one of the most silent and destructive causes of crashes on MU Online private servers: unlike a CPU spike that players feel as lag, the disk fills up gradually, with no visible symptom, until the moment MySQL simply stops accepting writes — and at that point you're already dealing with potentially corrupted character data, not just a server that's down. This tutorial shows how to identify the biggest space consumers on a MU server (logs, backups, database tables), set up automatic alerts before the disk hits its limit, and build a cleanup and archiving routine that keeps the server healthy without losing history that's important for ban investigations and player disputes.

Why a full disk is more dangerous than high CPU

A CPU spike degrades the experience (lag), but the server keeps running and recovers on its own once the spike passes. A full disk is binary: at one moment MySQL writes normally, at the next it refuses any write, because there's no physical space for the transaction log file (ib_logfile) or for the tablespace itself to grow. This can freeze GameServer in the middle of a character save, with a real risk of data corruption — a much more serious problem than any amount of lag.

Main space consumers on a MU Online server

Step 1 — Measure current disk usage

Before setting up any alert, understand where space is being used today. On Linux:

df -h
du -sh /var/lib/mysql /var/log /path/to/server/Logs /backup

On Windows, tools like WinDirStat or a recursive Get-ChildItem in PowerShell help map out the biggest directories before deciding what to clean up or rotate.

Step 2 — Configure log rotation

On Linux, logrotate compresses and archives logs automatically, preventing a single file from growing without limit:

# /etc/logrotate.d/mu-gameserver
/path/to/server/Logs/*.log {
    daily
    rotate 30
    compress
    missingok
    notifempty
}

This keeps 30 days of compressed history and discards anything older — enough for most player-dispute investigations, without letting the disk grow indefinitely.

Step 3 — Automate cleanup of old backups

MySQL backups need a clear retention policy. A simple script running via cron/scheduled task handles it:

#!/bin/bash
# Keeps only the last 14 daily backups
find /backup/mysql -name "*.sql.gz" -mtime +14 -delete

Never delete backups manually without confirming there's at least one recent, intact copy — always validate the newest backup before running cleanup on the older ones.

Step 4 — Archive event/PK log tables that grow without limit

Tables like PK logs, rare item drop logs, and chat logs can grow to millions of rows over months. Instead of letting them grow indefinitely inside the active database, periodically archive old records to a separate table or an external dump:

-- Example: move records older than 90 days to an archive table
INSERT INTO LOG_PK_ARCHIVE SELECT * FROM LOG_PK WHERE Data < NOW() - INTERVAL 90 DAY;
DELETE FROM LOG_PK WHERE Data < NOW() - INTERVAL 90 DAY;
OPTIMIZE TABLE LOG_PK;

Step 5 — Set up automatic disk space alerts

A simple alert with cron and a Discord webhook already prevents most surprises, even without a full monitoring stack:

#!/bin/bash
USAGE=$(df / | tail -1 | awk '{print $5}' | sed 's/%//')
if [ "$USAGE" -gt 85 ]; then
  curl -H "Content-Type: application/json" -d "{\"content\":\"⚠️ Disk usage at ${USAGE}% on the server!\"}" https://discord.com/api/webhooks/YOUR_WEBHOOK
fi

Schedule this script to run every 15-30 minutes via cron (Linux) or Task Scheduler (Windows).

Step 6 — Define tiered alert thresholds

A single last-minute alert doesn't give you time to react. Set up progressive thresholds, each with its own urgency:

Step 7 — Separate disks by function when possible

If budget allows, keep MySQL on a separate disk (or partition) from logs and backups. This way, even if logs grow out of control, MySQL still has room to write — avoiding the worst-case scenario of character data corruption.

Step 8 — Test space recovery in a simulated scenario

Before relying on the routine, simulate a near-full-disk scenario in a test environment and confirm that log rotation, backup cleanup, and table archiving actually free up enough space in time. A cleanup script that's never been tested is as risky as having none at all.

Common errors and fixes

Disk monitoring checklist

• Current disk usage mapped by directory (logs, backups, MySQL).
• Log rotation configured with a defined retention (e.g., 30 days).
• Automatic old-backup cleanup script implemented.
• Archiving routine for fast-growing log tables.
• Automatic tiered alerts configured (70/85/92/97%).
• MySQL and logs/backups disks separated, if possible.
• Space recovery tested in a simulated environment.

With disk space under control, the next step is to integrate these alerts into a more complete monitoring dashboard, combining CPU, memory, and database connections in one place — see the MU Online server creation tutorial to review your infrastructure foundation before moving to a more robust observability stack.

Frequently asked questions