How to automate cleanup of old logs on your MU Online server

A MU Online server generates an impressive amount of logs: ConnectServer connections, GM actions on the GameServer, network errors, item transactions, failed login attempts, and much more. Without a retention routine, these files grow indefinitely until they fill the disk — and a full disk crashes the database, freezes the GameServer, and can even corrupt data being written at the moment of failure. This tutorial shows how to build a retention policy by log type, automate cleanup/compression with cron (or Task Scheduler on Windows), and monitor disk usage so you're never caught off guard.

Why logs without rotation are a real risk

A mid-sized MU Online server with a few hundred concurrent players can generate hundreds of megabytes to a few gigabytes of logs per day, depending on the configured verbosity level. Without rotation, within a few weeks these files take up dozens of gigabytes — and the most common symptom isn't a graceful warning, it's the database crashing from lack of disk space mid-transaction, which can cause inconsistencies in accounts and items.

Classifying log types by criticality

Not every log deserves the same treatment. Defining a retention policy by type avoids deleting something important while also avoiding keeping unnecessary junk for months:

Mapping where each emulator writes its logs

In IGCN, logs usually live under Data/Log/ inside each service's folder (GameServer, ConnectServer, JoinServer). In MuEMU, it's common to have a Logs/ folder at the root with per-day subfolders (Logs/2026-07-30/). Before writing the cleanup script, take a real inventory of your environment:

find /srv/muserver -iname "*.log" -o -iname "*.txt" | grep -i log | sort
du -sh /srv/muserver/*/Log* 2>/dev/null

This shows exactly which folders are consuming the most space and should guide the priority of your retention policy.

Cleanup script by file age (Linux)

The find command with -mtime is the right tool for applying age-based retention, without needing complex logic:

#!/bin/bash
# log_cleanup.sh — runs daily via cron

# Debug logs: delete after 3 days
find /srv/muserver/Logs/debug -name "*.log" -mtime +3 -delete

# Network logs: delete after 7 days
find /srv/muserver/Logs/network -name "*.log" -mtime +7 -delete

# Audit/trade logs: compress after 7 days, delete after 90
find /srv/muserver/Logs/audit -name "*.log" -mtime +7 ! -name "*.gz" -exec gzip {} \;
find /srv/muserver/Logs/audit -name "*.gz" -mtime +90 -delete

echo "$(date): log cleanup completed" >> /var/log/mu/cleanup.log

Equivalent script on Windows (PowerShell)

For servers running on Windows, the same concept using Get-ChildItem and a date filter:

$cutoff = (Get-Date).AddDays(-7)
Get-ChildItem "C:\MuServer\Logs\network" -Filter *.log |
  Where-Object { $_.LastWriteTime -lt $cutoff } |
  Remove-Item -Force

$auditCutoff = (Get-Date).AddDays(-90)
Get-ChildItem "C:\MuServer\Logs\audit" -Filter *.gz |
  Where-Object { $_.LastWriteTime -lt $auditCutoff } |
  Remove-Item -Force

Save it as log_cleanup.ps1 and set it up in Windows Task Scheduler with a daily trigger.

Compressing before deleting (cheap extended retention)

Compressing old logs before actually deleting them is a cheap way to extend the investigation window without using much space — plain-text log files typically compress 80–95% with gzip:

gzip -9 /srv/muserver/Logs/audit/GMLog_2026-06-*.txt

This turns, for example, 500 MB of June logs into roughly 30–50 MB, keeping the ability to audit retroactively for much longer at the same disk cost.

Native rotation vs. a custom script

On Linux environments, logrotate is a native and more robust alternative to a raw find script, especially if the server processes write to the file continuously (it avoids truncating a log that's in use):

/srv/muserver/Logs/network/*.log {
    daily
    rotate 7
    compress
    missingok
    notifempty
    copytruncate
}

The copytruncate directive matters here: it copies the current content, compresses it, and truncates the original file in place, without needing to restart the GameServer process for it to resume writing to a "new" file.

Proactively monitoring disk usage

Besides cleaning up, it's important to know when the disk is approaching its limit before it becomes an emergency. A simple check script, reusing the same alert webhook already used for backups and events:

USAGE=$(df -h /srv/muserver | awk 'NR==2 {print $5}' | tr -d '%')
if [ "$USAGE" -gt 85 ]; then
  curl -s -X POST "$DISCORD_WEBHOOK_URL" \
    -H "Content-Type: application/json" \
    -d "{\"content\":\"⚠️ MU server disk at ${USAGE}% usage!\"}"
fi

Scheduling the run

On Linux, a daily cron job in the early morning, outside peak hours:

30 3 * * * /usr/local/bin/log_cleanup.sh >> /var/log/mu/cleanup_cron.log 2>&1

On Windows, Task Scheduler with a daily trigger at 3:30 AM, pointing to the PowerShell script with an unrestricted execution policy (-ExecutionPolicy Bypass), in case the default policy blocks unsigned scripts.

Difference between deleting and archiving to the cloud

For servers with compliance requirements or a history of player disputes, deleting for good may not be ideal. An alternative is to move (not delete) compressed logs to cloud storage before removing them from the local disk, using the same approach as the Google Drive backup tutorial — this preserves history off-server without occupying local disk space indefinitely.

Common errors and fixes

Automated log cleanup checklist

• Inventory of log folders done and each one's volume measured.
• Retention policy defined by log type (audit, network, debug, crash).
• Cleanup script (find/PowerShell or logrotate) implemented and tested.
• Compression configured for audit logs before final deletion.
• Disk usage monitoring with alert configured.
• Automatic scheduling confirmed (cron or Task Scheduler).
• Cloud archiving process evaluated for sensitive logs.

With log cleanup running on its own and the disk monitored, you eliminate one of the most mundane — and most avoidable — causes of server downtime. If your infrastructure is still in its early stages, review the MU Online server creation tutorial to make sure disks and log paths are sized correctly from the start.

Frequently asked questions