Cómo Configurar Backups Automáticos Externos en el Servidor de MU

Todo administrador de MU Online vive bajo la misma amenaza silenciosa: un disco que falla, un comando equivocado en el SQL, un ataque de ransomware o un proveedor que simplemente desaparece con tu máquina. La base de datos guarda cuentas, personajes, inventarios, guilds, resets y el historial económico entero del servidor. Perder eso no es un problema técnico — es el fin del proyecto y de la confianza de la comunidad. Este tutorial muestra cómo montar un flujo de backup automático externo, es decir, que copia los datos críticos fuera de la máquina de origen, de forma programada, verificada y con rotación. El foco aquí no es solo "generar un .bak", sino garantizar que exista siempre una copia recuperable en un lugar que sobreviva a la muerte del servidor principal. Las rutas, versiones y valores citados son ejemplos y varían según el proveedor/versión — lo que importa es entender el concepto y adaptarlo a tu estructura.

Requisitos previos

Antes de automatizar cualquier cosa, asegúrate de que lo básico esté en su lugar. Este tutorial asume un servidor de MU ya corriendo (si todavía estás montando el tuyo, mira la guía de cómo crear un servidor de MU Online).

• Acceso administrativo al VPS o máquina que aloja el servidor (RDP en Windows, o SSH en Linux).
• Base de datos funcional — normalmente SQL Server (2008/2014/2019 son comunes en MU S6) o MySQL/MariaDB en servidores más modernos.
• Un destino externo definido: nube (almacenamiento de objetos, drive), un segundo VPS o storage remoto accesible por SFTP/rclone.
• Herramienta de sincronización instalada. El rclone es la elección más versátil por hablar con decenas de proveedores; SFTP nativo también sirve.
• Espacio en disco local suficiente para generar el archivo comprimido antes del envío (regla práctica: 2x el tamaño actual de la base).
• Un usuario de servicio dedicado para el backup, sin privilegios más allá de lo necesario.

Entiende qué realmente necesita copiarse

El error más común es creer que "backup del servidor" es solo la base de datos. Un MU tiene dos categorías de datos críticos, y las configuraciones no están dentro del SQL.

Si personalizaste spots en mapas de fin de juego o drops de un evento, esos datos viven en archivos de texto del GameServer — un backup solo del SQL no los recupera. Trata la carpeta de datos del servidor como parte obligatoria del backup.

Paso 1 — Generar el backup de la base de forma consistente

El backup necesita ser un "retrato" consistente de la base, no una copia de archivos abiertos en uso. Nunca copies los archivos .mdf/.ldf (SQL) o el directorio de datos de MySQL "a mano" con el servicio corriendo — eso genera archivos corruptos.

En SQL Server, usa el comando nativo, que garantiza consistencia y además comprime:

BACKUP DATABASE [MuOnline]
    TO DISK = N'D:\Backups\MuOnline\MuOnline_full.bak'
    WITH
        COMPRESSION,   -- reduce mucho el tamaño del archivo
        CHECKSUM,      -- graba verificacion de integridad
        INIT,
        STATS = 10,
        NAME = N'Backup completo MuOnline';

En MySQL/MariaDB, el mysqldump genera un dump lógico consistente:

mysqldump --single-transaction --routines --triggers \
  -u backup_user -p muonline > /backups/muonline_$(date +%F).sql

El parámetro --single-transaction evita trabar las tablas durante el dump en bases InnoDB. El objetivo de esta etapa es tener, al final, un único archivo por ejecución, con fecha en el nombre, listo para ser comprimido y enviado.

Paso 2 — Empaquetar base y configuraciones juntas

Un backup útil junta la base y las carpetas de configuración en el mismo paquete fechado. Así, a la hora de restaurar, todo vino del mismo momento. Un script simple lo resuelve en Windows con PowerShell:

# gera-pacote.ps1 — junta .bak + carpeta Data en un zip fechado
$stamp   = Get-Date -Format 'yyyyMMdd_HHmm'
$destino = "D:\Backups\Pacotes\mu_$stamp.zip"

# 1) ejecuta el backup SQL (procedure o comando directo)
sqlcmd -S localhost -Q "BACKUP DATABASE [MuOnline] TO DISK='D:\Backups\MuOnline\MuOnline_full.bak' WITH COMPRESSION, CHECKSUM, INIT"

# 2) empaqueta el .bak + la carpeta de configuraciones del GameServer
Compress-Archive -Path @(
    "D:\Backups\MuOnline\MuOnline_full.bak",
    "D:\MuServer\GameServer\Data"
) -DestinationPath $destino -Force

Write-Host "Paquete generado: $destino"

En Linux, el equivalente es un tar con el dump y la carpeta de datos:

tar -czf /backups/mu_$(date +%F_%H%M).tar.gz \
    /backups/muonline_$(date +%F).sql \
    /opt/muserver/GameServer/Data

Paso 3 — Enviar al destino externo con rclone

Con el paquete listo localmente, el envío externo es el corazón de este tutorial. El rclone conecta a prácticamente cualquier proveedor (drives, almacenamiento de objetos compatible con S3, SFTP) con la misma sintaxis. Después de correr rclone config una vez para crear el "remote", el envío es una línea:

# envia el paquete mas reciente y mantiene log
$arquivo = Get-ChildItem "D:\Backups\Pacotes\*.zip" |
           Sort-Object LastWriteTime -Descending | Select-Object -First 1

rclone copy $arquivo.FullName "remote:backups/mu/" `
    --bwlimit 8M `        # limita banda para no ahogar a los jugadores
    --log-file "D:\Backups\Logs\rclone.log" `
    --log-level INFO

El parámetro --bwlimit (ejemplo: 8 MB/s, ajusta a tu enlace) evita que la subida consuma todo el ancho de banda y cause lag en el juego. Si prefieres SFTP puro hacia un segundo VPS, el concepto es el mismo: transferir el paquete fechado a una máquina físicamente diferente de la de origen.

> Un destino externo solo es externo de verdad si está en otra máquina/infraestructura. Copiar a "otra carpeta" o "a otro disco del mismo VPS" no protege contra la pérdida de la máquina entera.

Paso 4 — Verificar la integridad antes de confiar

Enviar un archivo corrupto es peor que no tener backup, porque crea falsa seguridad. Valida siempre. En SQL Server, la verificación nativa comprueba el CHECKSUM sin restaurar:

RESTORE VERIFYONLY
FROM DISK = N'D:\Backups\MuOnline\MuOnline_full.bak'
WITH CHECKSUM;

Para el paquete enviado, compara el tamaño y el hash local con el remoto. El rclone tiene un comando dedicado que comprueba esto automáticamente:

rclone check "D:\Backups\Pacotes\" "remote:backups/mu/" --one-way

Si el hash coincide, el archivo llegó íntegro. Registra el resultado en el log de cada ejecución — así, si algo se traba en medio de la madrugada, sabes exactamente cuál fue el último backup bueno.

Paso 5 — Rotación y retención en capas

Guardar todo para siempre llena el storage y dificulta encontrar el archivo correcto en una emergencia. Usa retención en capas, manteniendo más granularidad en los datos recientes:

remote:backups/mu/
  ├── diario/    → ultimos 7 dias
  ├── semanal/   → 1 por semana, por 4 semanas
  └── mensal/    → 1 por mes, por 6 meses

La limpieza de los antiguos también es automatizable. El rclone elimina archivos más viejos que cierta edad con un solo comando:

# elimina backups diarios con mas de 7 dias en el destino externo
rclone delete "remote:backups/mu/diario/" --min-age 7d

Localmente, haz la misma rotación para no llenar el disco del VPS, manteniendo solo los últimos días antes del envío.

Paso 6 — Programar la ejecución automática

El backup manual funciona mientras te acuerdas; el backup automático funciona mientras el servidor esté encendido. En Windows, usa el Programador de Tareas apuntando al script:

1. Abre el Programador de Tareas (taskschd.msc).
2. Crea una tarea con desencadenador diario en la madrugada (ejemplo: 03:00).
3. Acción: iniciar powershell.exe con argumentos -NonInteractive -ExecutionPolicy Bypass -File "D:\Scripts\gera-pacote.ps1".
4. Marca "Ejecutar aunque el usuario no haya iniciado sesión" y usa el usuario de servicio dedicado.
5. En la configuración, activa "Ejecutar la tarea lo antes posible si se pierde un inicio programado".

En Linux, una línea en crontab -e lo resuelve:

# 03:00 todos los dias: genera paquete y envia
0 3 * * * /opt/scripts/backup-mu.sh >> /var/log/backup-mu.log 2>&1

Paso 7 — Alertas de falla

Necesitas saber cuándo un backup no ocurrió, y no descubrirlo el día del desastre. Agrega una alerta al final del flujo, disparada solo en caso de error. Un ejemplo simple por e-mail en PowerShell:

if ($LASTEXITCODE -ne 0) {
    Send-MailMessage -SmtpServer "smtp.seuprovedor.com" -Port 587 -UseSsl `
        -From "[email protected]" -To "[email protected]" `
        -Subject "FALLA en el backup externo del MU" `
        -Body "El backup externo fallo en $(Get-Date). Verifica el log." `
        -Encoding UTF8
}

Muchos administradores prefieren un webhook para el Discord del equipo — el concepto es el mismo: transformar un error silencioso en una notificación que alguien va a ver.

Errores comunes y soluciones

Lista de verificación de lanzamiento

• Backup de la base generado con comando nativo (con compresión y checksum)
• Carpeta GameServer\Data y configs del ConnectServer/JoinServer incluidas en el paquete
• Destino externo en máquina/infraestructura diferente de la de origen
• Envío automático con límite de banda configurado
• Verificación de integridad (RESTORE VERIFYONLY / rclone check) en el flujo
• Rotación y retención en capas (diario/semanal/mensual) activas
• Rotación local del disco del VPS activa
• Programación automática corriendo bajo usuario de servicio dedicado
• Alerta de falla por e-mail o Discord funcionando
• Prueba de restauración mensual en base separada programada

Con ese flujo dejas de depender de tu propia memoria y pasas a tener un sistema que protege el servidor incluso mientras duermes: base y configuraciones empaquetadas, enviadas fuera de la máquina, verificadas, rotadas y monitoreadas. Es la diferencia entre que un imprevisto de hardware sea un susto de una hora o el fin de tu servidor.

Preguntas frecuentes