Cómo migrar de emulador de MU Online sin perder la base de datos

Cambiar de emulador es uno de los pasos más delicados en la vida de un servidor de MU Online: quieres los recursos del emulador nuevo (mejor anti-cheat, nuevos sistemas, más estabilidad), pero no puedes perder las cuentas, personajes, inventarios y Warehouses que los jugadores construyeron. Una migración mal hecha borra meses de progreso y mata el servidor en un día. Una migración bien hecha es invisible para el jugador: hace login y está todo ahí. Este tutorial recorre el proceso completo — backup, mapeo de tablas, conversión de schema y pruebas — siempre trabajando sobre copias y nunca en la base de datos de producción.

Por qué falla la migración (y cómo evitarlo)

La mayoría de los desastres de migración vienen de tres errores: tocar la base de datos de producción directamente, asumir que los schemas son idénticos entre emuladores, y abrir el servidor sin probar. MU Online, en la abrumadora mayoría de los emuladores (IGCN, MuEMU, X-Team, entre otros), usa Microsoft SQL Server como base de datos. Esa es una buena noticia: las tablas centrales tienen nombres y estructuras parecidas entre emuladores, porque todos descienden de los mismos archivos originales. La mala noticia es que "parecidas" no es "iguales" — los nombres de columnas, tamaños de campo y el formato binario del inventario varían. La migración segura siempre trata la base de datos antigua como fuente de lectura y construye la nueva en paralelo.

Requisitos previos

• El servidor antiguo aún funcional, con acceso al SQL Server (usuario sa o equivalente).
• El nuevo emulador ya instalado y probado con una base de datos limpia (ver el tutorial de creación de servidor).
• SQL Server Management Studio (SSMS) para backup, restore y queries.
• Espacio en disco para al menos dos copias completas de la base de datos.
• Una ventana de mantenimiento con el servidor offline (nada de migrar en vivo).
• Backup validado antes de cualquier alteración — esto es innegociable.

Entiende las tablas centrales de MU

Antes de mover cualquier dato, sabe qué necesita sobrevivir. Los nombres varían por emulador, pero el núcleo es siempre este:

El inventario del personaje normalmente no es una tabla separada: vive dentro de un campo binario (Inventory) en la tabla Character. Ese detalle es el corazón de la migración — volveremos a él en el Paso 4.

Paso 1 — Backup completo de la base de datos antigua

Con el GameServer y el ConnectServer detenidos, haz un backup full desde el SSMS o por T-SQL. Nunca empieces nada sin esta etapa concluida y verificada:

-- Backup completo de la base de datos de produccion antigua
BACKUP DATABASE [MuOnline]
TO DISK = N'D:\Backups\MuOnline_pre_migracao.bak'
WITH FORMAT, INIT,
     NAME = N'MuOnline - backup pre-migracao',
     STATS = 10;
GO

-- Verifica la integridad del archivo de backup
RESTORE VERIFYONLY
FROM DISK = N'D:\Backups\MuOnline_pre_migracao.bak';
GO

El RESTORE VERIFYONLY confirma que el archivo .bak está íntegro y es restaurable. Si falla, detén todo — tu backup no sirve y no puedes arriesgar la migración.

Paso 2 — Restaurar una copia de trabajo

Nunca migres en la base de datos original. Restaura el backup con un nombre nuevo, que será tu entorno de conversión. Así, la base de datos de producción sigue intacta si algo sale mal:

-- Restaura como base de datos de trabajo separada (MuOnline_MIGRACAO)
RESTORE DATABASE [MuOnline_MIGRACAO]
FROM DISK = N'D:\Backups\MuOnline_pre_migracao.bak'
WITH MOVE 'MuOnline'     TO N'D:\SQLData\MuOnline_MIGRACAO.mdf',
     MOVE 'MuOnline_log' TO N'D:\SQLData\MuOnline_MIGRACAO_log.ldf',
     RECOVERY, STATS = 10;
GO

Los nombres lógicos (MuOnline, MuOnline_log) los obtienes con RESTORE FILELISTONLY FROM DISK = '...'. A partir de aquí, todo el trabajo ocurre en MuOnline_MIGRACAO.

Paso 3 — Mapear el schema: antiguo vs. nuevo

Aquí está el trabajo intelectual de la migración. Instala el nuevo emulador con su base de datos limpia y compara la estructura de cada tabla central entre los dos. Para listar las columnas de una tabla:

-- Ejecuta en las dos bases de datos y compara columna a columna
SELECT COLUMN_NAME, DATA_TYPE, CHARACTER_MAXIMUM_LENGTH, IS_NULLABLE
FROM INFORMATION_SCHEMA.COLUMNS
WHERE TABLE_NAME = 'Character'
ORDER BY ORDINAL_POSITION;

Arma un mapa de diferencias. Las tres categorías de divergencia que vas a encontrar:

Las columnas nuevas en el emulador destino que no existían en el antiguo deben recibir un valor por defecto coherente (0 para el nivel de master, NULL donde esté permitido). Las columnas que existían en el antiguo y desaparecieron en el nuevo simplemente se descartan.

Paso 4 — El inventario y el Warehouse (el campo binario)

Este es el punto donde la mayoría de las migraciones falla silenciosamente. El inventario y el Warehouse se almacenan como un blob hexadecimal, donde cada ítem ocupa un bloque fijo de bytes (típicamente 16 bytes por slot en muchas seasons: código del ítem, nivel, opciones, serial, socket, etc.). Si los dos emuladores usan el mismo layout de bytes, el campo se copia tal cual y todo se preserva. Si el nuevo emulador cambió el layout (por ejemplo, amplió el bloque para soportar nuevos sockets o harmony), necesitas convertir cada bloque.

Regla práctica: antes de confiar, toma un personaje de prueba con ítems conocidos, mira el hex del inventario en los dos formatos y confirma que los campos coinciden. Nunca asumas compatibilidad de blob binario — valida con un caso real. Si el layout diverge, escribe un script de conversión que lea el blob antiguo, reorganice cada bloque de ítem al nuevo tamaño y lo grabe de vuelta.

Paso 5 — Migrar las cuentas y personajes

Con el schema mapeado, mueve los datos en orden de dependencia: cuentas primero, luego personajes, después vínculos y Warehouse. Si el schema es compatible, un INSERT directo entre bases de datos lo resuelve; si hay renombrado de columnas, listas las columnas explícitamente:

-- Ejemplo: copiar cuentas a la base de datos del nuevo emulador
-- (los nombres de columnas varian por emulador — ajusta a tu schema)
INSERT INTO [MuOnline_NOVO].dbo.MEMB_INFO
    (memb___id, memb__pwd, mail_addr, appl_days, bloc_code, ctl1_code)
SELECT
    memb___id, memb__pwd, mail_addr, appl_days, bloc_code, ctl1_code
FROM [MuOnline_MIGRACAO].dbo.MEMB_INFO;
GO

Repite el patrón para Character, AccountCharacter, warehouse, Guild y GuildMember, respetando siempre el orden para no violar claves foráneas. Migra primero un lote pequeño (10–20 cuentas de prueba) antes de correr la base entera.

Paso 6 — Ajustar identidades, seeds y constraints

Después de insertar los datos, arregla lo que el INSERT no cubre: las columnas IDENTITY necesitan tener el seed reajustado, o el próximo personaje creado colisiona con un ID existente. Verifica también que no haya personajes huérfanos (en Character sin entrada en AccountCharacter) ni duplicidad de nombres:

-- Reajusta el contador de identidad tras la carga masiva
DBCC CHECKIDENT ('Character', RESEED);
GO

-- Personajes huerfanos (existen pero no pertenecen a ninguna cuenta)
SELECT c.Name
FROM Character c
LEFT JOIN AccountCharacter ac ON c.Name = ac.GameID1 OR c.Name = ac.GameID2
WHERE ac.Id IS NULL;
GO

La query de huérfanos varía según el emulador guarde los personajes en columnas (GameID1..5) o en filas — adáptala a tu estructura. Cualquier huérfano encontrado es un personaje que el jugador no va a ver en el login.

Paso 7 — Apuntar el nuevo emulador y levantar

Configura la connection string del nuevo GameServer/ConnectServer hacia la base de datos migrada (archivo de config del emulador — .ini, .xml o .dat, varía por emulador). Levanta los servicios uno a la vez y sigue los logs. Un error común aquí es que el emulador no arranca porque una tabla auxiliar que espera (config de eventos, ranking, cash shop) no existe en la base de datos migrada — en ese caso, crea la tabla vacía a partir del script de la base de datos limpia del nuevo emulador.

Paso 8 — Probar en el juego antes de abrir

Nunca abras a los jugadores sin esta batería de pruebas con cuentas reales migradas:

1. Login: entra con una cuenta antigua migrada y confirma que autentica.
2. Selección de personaje: todos los personajes aparecen, con nivel, clase y resets correctos.
3. Stats: fuerza, agilidad, vida y maná coinciden con el valor antiguo.
4. Inventario y Warehouse: ítems presentes, con opciones y sockets íntegros.
5. Zen: el Zen del personaje y del Warehouse está correcto.
6. Guild: guilds, marcas y miembros preservados; ranking coherente.
7. Crear personaje nuevo: confirma que no colisiona con IDs migrados (valida el Paso 6).

Solo después de que todos los ítems pasen apuntas el servidor de producción a la base de datos nueva y comunicas a los jugadores.

Errores comunes y soluciones

Lista de verificación de migración

• Servidor antiguo offline (GameServer y ConnectServer detenidos).
• Backup full hecho y validado con RESTORE VERIFYONLY.
• Copia de trabajo restaurada con nombre separado.
• Schema de las tablas centrales comparado (antiguo vs. nuevo).
• Formato del inventario/Warehouse verificado con un caso real.
• Lote pequeño de cuentas migrado y probado antes de la base entera.
• IDENTITY reajustado y huérfanos verificados.
• Nuevo emulador apuntando a la base de datos migrada y arrancando limpio.
• Batería completa de pruebas en el juego aprobada.
• Base de datos de producción original preservada hasta el cambio final.

Con la migración validada, guarda el .bak pre-migración durante semanas: si algún jugador reporta pérdida de un ítem que pasó desapercibida en las pruebas, tienes la fuente original para comprobar y corregir. Una migración de emulador bien documentada se vuelve un guion reutilizable — en el próximo cambio de versión, repites los mismos pasos con mucho menos riesgo.

Preguntas frecuentes