How to automate your MU Online server's backup to Google Drive

Losing a MU Online server's database — with accounts, characters, items, and purchase history — is the kind of incident that can end a project overnight. Yet it's common to see admins doing manual backups "whenever they remember," which is just a matter of time before it goes wrong. This tutorial builds a complete, automated pipeline: database dump, compression, optional encryption, upload to Google Drive via rclone, rotation of old versions, and failure alerts — all scheduled to run on its own every day.

Why the cloud is an essential part of your backup strategy

The classic backup rule is 3-2-1: three copies of the data, on two different media types, with one copy off-site. A backup that only lives on the same disk as the production server doesn't protect against hardware failure, ransomware, or an operator error that wipes everything. Google Drive fills the off-site role at low cost, with simple integration via rclone.

Pipeline overview

The full flow has five steps, executed in sequence by a single scheduled script:

Installing and configuring rclone

rclone is the standard tool for syncing files with dozens of cloud providers, including Google Drive, without exposing credentials in plain text in the script.

curl https://rclone.org/install.sh | sudo bash
rclone config

In the interactive wizard, choose n for a new remote, name it gdrive_mu, select the drive (Google Drive) type, and follow the OAuth authentication flow in your browser. At the end, confirm it's working:

rclone lsd gdrive_mu:

If it lists your Google Drive account's folders, the setup is correct.

Generating the database dump

For MySQL/MariaDB (common in MuEMU and derivatives), use --single-transaction to avoid locking tables in use during the dump:

mysqldump --single-transaction --routines --triggers \
  -u backup_user -p"$DB_PASS" mu_online > /backup/mu_$(date +%F).sql

For SQL Server (common in IGCN servers), use sqlcmd with a BACKUP DATABASE straight to a .bak file:

BACKUP DATABASE MuOnline
TO DISK = 'C:\Backup\MuOnline_20260730.bak'
WITH COMPRESSION, INIT;

Create a dedicated database user for backups (backup_user), with read-only and BACKUP permissions only — never the GameServer's administrative user. This reduces the risk if the script is ever leaked.

Packaging critical configuration files

Besides the database, it's worth including in the backup the GameServer/ConnectServer configuration files (which rarely change but are expensive to rebuild from scratch) and the last few days of logs:

tar -czf /backup/config_$(date +%F).tar.gz \
  /srv/muserver/Data/*.txt \
  /srv/muserver/Data/*.xml \
  /srv/muserver/logs/*.log

Encrypting the backup before upload

Since the dump contains sensitive data (hashed passwords, purchase history, player emails), it's recommended to encrypt before sending to the cloud, even though Google Drive is private by default:

gpg --symmetric --cipher-algo AES256 --batch --passphrase "$BACKUP_PASSPHRASE" \
  /backup/mu_$(date +%F).sql

This produces a .gpg file that can only be opened with the defined passphrase — keep that passphrase in a vault separate from the server (the team's password manager), never in the same script.

Uploading to Google Drive

With the files ready, the upload is a single line:

rclone copy /backup/ gdrive_mu:mu-backups/$(date +%Y-%m)/ --progress

Organizing by month folder (2026-07/) makes manual navigation in Drive easier when you need to quickly locate a specific backup.

Complete daily backup script

Putting the steps together into a single script (daily_backup.sh):

#!/bin/bash
set -e
DATE=$(date +%F)
BACKUP_DIR=/backup
DB_DUMP="$BACKUP_DIR/mu_$DATE.sql"

mysqldump --single-transaction -u backup_user -p"$DB_PASS" mu_online > "$DB_DUMP"
tar -czf "$BACKUP_DIR/config_$DATE.tar.gz" /srv/muserver/Data/*.txt /srv/muserver/Data/*.xml
gpg --symmetric --cipher-algo AES256 --batch --passphrase "$BACKUP_PASSPHRASE" "$DB_DUMP"
rm -f "$DB_DUMP"

rclone copy "$BACKUP_DIR/" gdrive_mu:mu-backups/$(date +%Y-%m)/ --progress
echo "Backup for $DATE completed successfully." >> /var/log/mu/backup.log

Rotation: deleting old backups

Keeping every backup forever quickly eats up space. A common scheme is to retain the last 7 daily backups and delete the rest, both locally and on Drive:

find /backup -name "*.gpg" -mtime +7 -delete
rclone delete gdrive_mu:mu-backups/ --min-age 90d

Alerting on failure

A backup that fails silently is worse than having no backup at all — it gives a false sense of security. Add a trap to the script to notify on error, reusing the same Discord/Telegram webhook used for event announcements:

trap 'curl -s -X POST "$DISCORD_WEBHOOK_URL" -d "{\"content\":\"⚠️ Daily MU Online backup failed!\"}" -H "Content-Type: application/json"' ERR

Scheduling the automatic run

On Linux, schedule via cron to run in the early morning, outside peak player hours:

0 4 * * * /usr/local/bin/daily_backup.sh >> /var/log/mu/backup_cron.log 2>&1

On Windows, use Task Scheduler pointing to a .bat that calls rclone and sqlcmd, with a daily trigger at 4:00 AM.

Testing the restore periodically

An untested backup is a gamble. Every month, download the most recent file and restore it in an isolated test environment (never in production) to validate that the whole process works end to end:

rclone copy gdrive_mu:mu-backups/2026-07/mu_2026-07-30.sql.gpg /tmp/test/
gpg --decrypt --batch --passphrase "$BACKUP_PASSPHRASE" /tmp/test/mu_2026-07-30.sql.gpg > /tmp/test/mu_restored.sql
mysql -u root -p mu_test < /tmp/test/mu_restored.sql

Common errors and fixes

Automated backup checklist

• rclone installed and Google Drive remote configured and tested.
• Dedicated database user for backups, with minimal permissions.
• Dump + compression + encryption script working manually.
• Upload to Google Drive validated with rclone lsd.
• Local and remote rotation configured.
• Failure alert via Discord/Telegram implemented.
• Daily schedule confirmed (cron or Task Scheduler).
• Restore tested in an isolated environment within the last month.

With the backup running and tested on its own, the biggest source of operational risk on your server stops being "forgot to save" and becomes just monitoring the alerts. If you're still building the infrastructure from scratch, go back to the MU Online server creation tutorial to make sure the foundation is solid before automating the rest.

Frequently asked questions