Backup incremental vs. completo para servidores de MU Online: cuál elegir

Perder la base de datos de un servidor de MU Online —cuentas, personajes, ítems, guildas, historial de ranking— es el tipo de incidente que puede terminar con un proyecto de la noche a la mañana, especialmente si la comunidad ya invirtió tiempo y dinero en él. La pregunta "backup incremental o completo" no tiene una respuesta única: la elección correcta depende del tamaño de la base, de la frecuencia de cambio de los datos y del tiempo aceptable de recuperación en caso de desastre. Este tutorial explica las diferencias técnicas entre los tipos de backup, muestra cómo combinarlos en la práctica para un servidor de MU, y presenta un plan de recuperación comprobable, porque un backup que nunca se restauró es solo una suposición.

Los tres tipos de backup

Antes de decidir una estrategia, hay que entender exactamente qué hace cada tipo:

La elección entre incremental y diferencial es el punto más confundido: el incremental es más liviano para generar, pero más riesgoso para restaurar, porque toda la cadena (completo + incremental 1 + incremental 2 + ... + incremental N) debe estar intacta. Si un archivo intermedio se corrompe, todo lo que viene después queda inservible.

Qué necesita entrar en el backup de un servidor de MU

Muchos administradores hacen backup solo de la base de datos y se olvidan de archivos esenciales para la recuperación completa:

Estrategia recomendada según el tamaño del servidor

No existe una estrategia única: el tamaño de la base de datos y el volumen de jugadores activos cambian el cálculo de costo-beneficio.

Ejemplo de script de backup completo (MySQL/MariaDB)

La mayoría de los emuladores de MU (MuEmu, IGCN) usa MySQL o MariaDB. Un script básico de backup completo, programado vía cron:

#!/bin/bash
DATA=$(date +%Y%m%d_%H%M%S)
DESTINO="/backup/mu/completo"
BANCO="mu_online"

mysqldump --single-transaction --routines --triggers \
  -u backup_user -p"SENHA_AQUI" "$BANCO" | gzip > "$DESTINO/full_${BANCO}_${DATA}.sql.gz"

# Elimina backups completos con más de 30 días
find "$DESTINO" -name "full_${BANCO}_*.sql.gz" -mtime +30 -delete

El parámetro --single-transaction es esencial en bases InnoDB: garantiza una foto consistente de la base sin bloquear las tablas durante el dump, evitando un impacto perceptible para los jugadores online en el momento del backup.

Ejemplo de backup incremental vía binlog (MySQL)

Para un incremental real (no un "completo pequeño"), habilitá el binary log de MySQL y hacé backup de él periódicamente:

# my.cnf — habilitar binlog
[mysqld]
log-bin = /var/log/mysql/mu-bin
binlog_expire_logs_seconds = 604800
server-id = 1

#!/bin/bash
# Copia los binlogs generados desde el último backup completo
DESTINO="/backup/mu/incremental"
mysqladmin -u backup_user -p"SENHA_AQUI" flush-logs
cp /var/log/mysql/mu-bin.* "$DESTINO/"

Restaurar con binlog exige aplicar el completo más reciente y luego "reproducir" los binlogs en el orden exacto; por eso documentá siempre el orden cronológico de los archivos en el nombre o en un índice separado.

Rotación y política de retención (3-2-1)

La regla clásica de backup 3-2-1 se aplica bien a servidores de MU: 3 copias de los datos, en 2 medios distintos, con 1 copia fuera del lugar físico del servidor (otra ciudad, otro proveedor de nube). Un VPS que aloja el backup en la misma máquina del servidor de producción no es un backup real: es solo una copia que muere junto con el mismo incidente (falla de disco, intrusión, baneo de la cuenta del proveedor).

Cifrado y seguridad del backup

Un backup con datos de cuentas de jugadores (aunque las contraseñas estén hasheadas) es un activo sensible: si se filtra, expone correos, IPs de login e historial de compras de la tienda. Cifrá el archivo antes de enviarlo a la nube:

gpg --symmetric --cipher-algo AES256 --output "full_mu_online_${DATA}.sql.gz.gpg" "full_mu_online_${DATA}.sql.gz"

Guardá la contraseña de cifrado en un gestor de contraseñas separado de la infraestructura del servidor: si el servidor se ve comprometido, el backup cifrado sigue protegido incluso si el atacante tiene acceso a la máquina.

Probando la restauración (el paso que todos se saltean)

Un cronograma de prueba de restauración debe existir independientemente de lo "confiable" que parezca el proceso:

1. Reservá un ambiente aislado (VPS de prueba o contenedor) sin acceso a la red de producción.
2. Restaurá el backup completo más reciente desde cero.
3. Aplicá los incrementales/binlogs en el orden correcto, si corresponde.
4. Levantá el GameServer apuntando a esa base restaurada y validá el login, personaje e inventario de una cuenta de prueba conocida.
5. Documentá el tiempo total empleado; ese número es tu RTO real (tiempo de recuperación), no una estimación teórica.

Monitoreo y alertas de falla de backup

Un backup que falla silenciosamente es peor que no tener backup, porque crea una falsa sensación de seguridad. Configurá una alerta automática (webhook en Discord, correo) cuando el script de backup termine con error o cuando el archivo generado tenga un tamaño anormalmente pequeño comparado con el histórico:

TAMANHO=$(stat -c%s "$DESTINO/full_${BANCO}_${DATA}.sql.gz")
if [ "$TAMANHO" -lt 1000000 ]; then
  curl -H "Content-Type: application/json" -d '{"content":"⚠️ ¡El backup de MU generó un archivo sospechosamente pequeño!"}' "$WEBHOOK_DISCORD"
fi

Errores comunes y soluciones

Lista de verificación de estrategia de backup

• Backup completo programado con frecuencia adecuada al tamaño del servidor.
• Incremental o diferencial configurado si el volumen de cambio lo justifica.
• Regla 3-2-1 aplicada (copia fuera del servidor de producción).
• Archivos cifrados antes de cualquier envío a la nube.
• Alerta automática de falla de backup configurada.
• Prueba de restauración completa realizada en ambiente aislado en el último mes.
• Documentación del orden de restauración (completo + incrementales) actualizada.

Con la estrategia de backup validada y probada, el siguiente paso natural es revisar la infraestructura general del servidor —desde el aprovisionamiento hasta la configuración de seguridad— descrita con más detalle en el tutorial de creación de servidor de MU Online.

Preguntas frecuentes