Cómo crear un plan de recuperación ante desastres (DR) para el servidor de MU

Todo administrador de MU Online que estuvo el tiempo suficiente en el área tiene una historia de terror: el VPS que murió sin aviso, la base que se corrompió después de una actualización, el proveedor que suspendió la cuenta, el disco que falló llevándose también el backup que estaba en él. En esos momentos, lo que separa un susto del fin de un proyecto es una sola cosa: que exista, probado y al alcance de la mano, un plan de recuperación ante desastres. Este tutorial muestra cómo construir un plan de DR de verdad para un servidor de MU — no una carpeta de backups que rezas por nunca tener que abrir, sino un procedimiento con metas claras, redundancia en capas, un camino de recuperación y, lo más importante, pruebas que demuestran que funciona. Los valores, proveedores y tiempos citados son ejemplo y varían según el proveedor/versión de tu infraestructura.

Requisitos previos

El DR presupone algo que proteger: un servidor en producción con datos que duele perder. Si todavía estás montando la base, empieza por cómo crear un servidor de MU Online y vuelve para blindarlo. Para un plan de DR serio necesitas:

• Un inventario completo de lo que compone el servidor: base de datos, archivos de configuración del GameServer, sitio/panel, launcher, y las personalizaciones que no están en la base (spots, drops, eventos editados en archivo).
• Backups ya funcionando — el DR los organiza y prueba, pero deben existir. Si todavía no tienes una rutina de backup, esa es la base y viene antes de todo.
• Un segundo lugar de almacenamiento independiente del servidor principal: nube, otro datacenter, una máquina física tuya. La regla de oro es que la copia de seguridad no puede morir junto con el original.
• Decisión de negocio sobre RTO y RPO (cuánto tiempo offline y cuántos datos perdidos toleras). Sin eso, no sabes cuánto invertir.
• Acceso a un VPS o máquina de reemplazo para las pruebas de restauración — restaurar sobre el servidor de producción está prohibido.

Paso 1 — Definir RTO y RPO (las metas del plan)

Antes de cualquier tecnología, define dos metas, porque ellas dictan todo el resto del plan:

• RTO (Recovery Time Objective): el tiempo máximo aceptable de servidor offline después de un desastre. Es la respuesta a "cayó — ¿en cuánto tiempo necesita volver?".
• RPO (Recovery Point Objective): la pérdida máxima aceptable de datos. Es la respuesta a "¿de cuánto tiempo atrás puede ser el dato que sobrevive?". Un RPO de 6 horas significa aceptar perder hasta 6 horas de progreso de los jugadores.

Estas son decisiones de negocio, no técnicas. La tabla de abajo muestra perfiles típicos de servidor de MU y metas plausibles — todas ejemplo, varían según el proveedor/versión y por el apetito de riesgo del proyecto:

El RTO y el RPO que elijas determinan el costo. Volver en 15 minutos exige un segundo servidor corriendo; volver en un día exige apenas backups y un buen procedimiento. No existe un DR "correcto" universal — existe el DR adecuado a las metas que el proyecto puede y quiere pagar.

Paso 2 — Mapear los activos y clasificar por criticidad

No recuperas lo que no sabes que existe. Haz el inventario completo del servidor y clasifica cada activo por criticidad y por RPO propio:

## Inventario de activos (ejemplo — varía según proveedor/versión)

CRÍTICO (RPO corto — perderlo duele mucho):
- Base de datos SQL (cuentas, personajes, inventario, gremios)
- Configs del GameServer NO en la base:
    Data\Monster\ (spots y drops personalizados)
    Data\Item\ (atributos de ítems editados)
    archivos .ini/.txt de eventos personalizados

IMPORTANTE (RPO medio — recreable con esfuerzo):
- Sitio/panel web y su base
- Launcher y archivos de parche del cliente
- Scripts de automatización (D:\Scripts\)

RECREABLE (RPO largo — se puede rearmar desde el instalador):
- Binarios del emulador (GameServer.exe, ConnectServer.exe...)
- Runtime, dependencias, cliente base

Esta clasificación es el corazón del DR. La base de datos es insustituible y necesita el backup más frecuente. En cambio, los binarios del emulador los reobtienes del instalador, así que no necesitan backup constante — pero deben estar documentados para la reconstrucción. El error clásico es tratar todo por igual: o sobreproteges binarios recreables, o (peor) subproteges las configs en archivo creyendo que "el backup de la base cubre todo".

Paso 3 — Montar backups en capas (la regla 3-2-1)

Con los activos mapeados, estructura los backups siguiendo la regla 3-2-1, el estándar del mercado para la resiliencia:

• 3 copias de los datos (el original + 2 backups).
• 2 medios/lugares diferentes (ej.: disco local + nube).
• 1 copia fuera del sitio (offsite), inmune a un desastre físico en el datacenter.

En la práctica, para un servidor de MU:

## Capas de backup (ejemplo — varía según proveedor/versión)

Capa 1 — Local, rápida (para restauración común):
- Backup de la base SQL cada 6h en un disco separado de la base
- Retención: 3 días

Capa 2 — Nube, offsite (para desastre del VPS):
- Envío diario del backup a almacenamiento en la nube
- Incluye: base + carpeta Data\ + configs del sitio
- Retención en capas: 7 diarios, 4 semanales, 6 mensuales

Capa 3 — Copia fría, independiente del proveedor:
- Copia semanal a otro proveedor o máquina física tuya
- Protege contra: que el proveedor suspenda/pierda la cuenta

La capa 3 es la que mucha gente se saltea y es justamente la que salva en el escenario "el proveedor desapareció con mi cuenta". Mantener todo en un solo proveedor de nube significa que una suspensión de cuenta borra el original y el backup de una sola vez. Distribuye el riesgo.

Paso 4 — Elegir la estrategia de contingencia según el RTO

El backup responde "¿los datos sobrevivieron?". La contingencia responde "¿dónde vuelven a correr?". La elección depende del RTO definido en el Paso 1:

1. Reconstrucción manual (RTO holgado, horas a un día): tienes un procedimiento documentado para montar un servidor nuevo desde cero en un VPS de reemplazo, restaurar la base y las configs, apuntar el DNS y subir. Más barato, más lento. Exige que el procedimiento esté escrito y probado.
2. VPS de reemplazo preconfigurado (RTO medio, 1-4 h): un segundo VPS con el emulador ya instalado y configurado, esperando. En el desastre, solo restauras el backup más reciente y subes. Cuesta un VPS parado, pero recorta horas del RTO.
3. Servidor standby con replicación (RTO corto, minutos): un segundo servidor que recibe copias frecuentes de la base y puede asumir rápidamente. Es el más caro y complejo, justificable solo para servidores grandes con ingresos que la indisponibilidad compromete.

Para la mayoría de los servidores de MU de porte medio, la opción 2 es el punto ideal de costo-beneficio: un VPS de reemplazo barato, mantenido actualizado, transforma un desastre de un día entero en uno de pocas horas.

Paso 5 — Escribir el procedimiento de failover

El plan necesita un procedimiento de recuperación paso a paso, escrito para ser seguido bajo estrés. Ejemplo para el escenario "el VPS principal murió, recuperar en el VPS de reemplazo":

### DR-01 — Recuperación total en el VPS de reemplazo

**Disparador:** VPS principal inaccesible y sin previsión de retorno.

**Meta:** RTO 3h, RPO 6h (ejemplo).

**Pasos:**
1. Confirmar que el principal está realmente perdido (no es una caída pasajera).
   Avisar a la comunidad que hay mantenimiento de emergencia.
2. Acceder al VPS de reemplazo (credenciales en el cofre X).
3. Descargar de la nube el backup más reciente de la base + carpeta Data\.
4. Restaurar la base en el SQL del VPS de reemplazo (ver DR-02).
5. Copiar la carpeta Data\ restaurada al GameServer.
6. Verificar las configs de conexión (IPs internos, puertos).
7. Subir los componentes en el orden: base > DataServer >
   ConnectServer > JoinServer > GameServer.
8. Actualizar el DNS/IP para apuntar al VPS de reemplazo.
9. Probar el login con una cuenta de prueba; validar que el personaje carga.
10. Comunicar el retorno a la comunidad.

**Si el backup más reciente falla:** usar el anterior (se pierde más RPO).
**Escalar a:** el dueño del proyecto si supera las 3h.

El paso 1 (confirmar que es un desastre de verdad) evita el error costoso de iniciar un failover por una caída de 10 minutos que se resolvería sola. El paso 3 y el paso 4 son donde la mayoría de los planes no probados falla — por eso el próximo paso es el más importante de todos.

Paso 6 — Probar el plan (el simulacro de DR)

Un plan de DR nunca probado es un documento de esperanza. La prueba, el simulacro, es lo que revela los agujeros antes de que el desastre lo haga por ti. Hazlo periódicamente:

1. Prueba de restauración aislada (mensual): restaura el backup más reciente en un entorno separado — nunca en producción — y confirma que la base se monta, los personajes cargan y las configs están presentes. Cronométralo.
2. Simulacro de failover completo (trimestral): ejecuta el procedimiento DR-01 entero en el VPS de reemplazo, desde cero, siguiendo únicamente el texto del plan. Cronométralo y compáralo con el RTO objetivo. Cada vacilación es un agujero por corregir.
3. Prueba del peor caso (semestral): simula el escenario "el proveedor desapareció": recupera usando solamente la capa 3 de backup, la copia fría independiente. Es la prueba que valida si realmente sobrevives a la pérdida del proveedor entero.

Anota los resultados de cada simulacro: tiempo real vs. RTO objetivo, qué falló, qué faltaba en el plan. El DR no es un documento que escribes una sola vez — es un ciclo de probar, encontrar agujeros y corregir, que solo madura con la repetición.

Errores comunes y soluciones

El error del backup solo de la base es especialmente cruel porque da una falsa sensación de seguridad: tienes "el backup", restauras, los personajes están ahí — y solo entonces te das cuenta de que meses de configuración de drops y eventos, que vivían en archivos, se perdieron. Un backup de DR es del servidor entero, no solo de la tabla de personajes.

Lista de verificación de lanzamiento

• RTO y RPO definidos como decisión de negocio y documentados
• Inventario completo de activos, clasificado por criticidad
• Carpeta Data\ y configs en archivo incluidas en el backup (no solo la base)
• Backups en capas siguiendo la regla 3-2-1
• Al menos una copia offsite, independiente del proveedor principal
• Copia fría en proveedor/lugar separado (escenario "el proveedor desapareció")
• Estrategia de contingencia elegida según el RTO (reconstrucción, reemplazo o standby)
• Procedimiento de failover (DR-01) escrito, con pasos numerados y tiempos
• Procedimiento de restauración de la base (DR-02) escrito y validado
• Credenciales de recuperación guardadas en un cofre accesible al equipo
• Prueba de restauración aislada ejecutada y cronometrada
• Simulacro de failover completo ejecutado, comparado con el RTO objetivo
• Prueba del peor caso (solo copia fría) ejecutada al menos una vez
• Resultados de los simulacros registrados y agujeros corregidos
• Calendario de pruebas recurrentes definido (mensual/trimestral/semestral)

Con un plan de DR real, probado y en capas, tu servidor de MU deja de estar a un disco fallido de distancia del fin. El desastre que derriba servidores no preparados se convierte, para ti, en un procedimiento cronometrado con un resultado previsible. Es el trabajo invisible que nadie elogia mientras todo funciona — y el único que importa el día en que todo se detiene.

Preguntas frecuentes