Cómo restaurar personaje e ítems desde backup en MU Online

Tarde o temprano, todo administrador de MU Online escucha la misma frase: "perdí mi personaje" o "desapareció mi set Excellent". Pudo haber sido un rollback tras una caída del servidor, un bug de ítem, un dupe que forzó una reversión, o hasta un error del propio jugador. La capacidad de restaurar personaje e ítems desde backup es lo que separa un servidor confiable de un servidor donde perder progreso es definitivo. Pero restaurar bien es una operación delicada: hecha mal, borra el progreso de otros jugadores, crea ítems duplicados o rompe la economía entera. Este tutorial avanzado muestra cómo hacer una restauración quirúrgica — trayendo de vuelta exactamente lo que se perdió, sin colateral.

El error conceptual más común es creer que restaurar un personaje significa restaurar el backup entero. Restaurar el backup completo sobre la producción equivale a borrar todo el progreso que ocurrió desde que aquel backup fue hecho — cada jugador que subió de nivel, cada ítem conquistado, cada Zen farmeado en las últimas horas desaparece. Eso resuelve el problema de un jugador creando el problema de mil. La restauración correcta es siempre selectiva: el backup se abre en una base separada y paralela, solo se extraen los datos necesarios, y esos datos se insertan en la base de producción actual, que sigue viva con todo el progreso reciente intacto.

Requisitos previos

• Acceso administrativo a la base de datos de producción (SQL Server o MySQL, según el emulador) con permiso para insertar y actualizar.
• Un backup íntegro y reciente de la base, en el formato de tu SGBD (.bak, dump SQL, etc.).
• Espacio y permiso para restaurar el backup en una base separada (ej.: MuOnline_Restore) en la misma instancia o en otra.
• Conocimiento del esquema del emulador: tablas de cuenta, personaje, inventario y warehouse, y cómo se codifican los ítems.
• Capacidad de forzar logout de una cuenta o de poner el servidor en mantenimiento breve para la inserción final.
• Herramienta de consulta SQL (SSMS, HeidiSQL, DBeaver) e, idealmente, una tabla de log de auditoría para registrar cada restauración.

> Aviso: todos los nombres de tabla y columna abajo (Character, AccountCharacter, warehouse, Inventory, T_ItemSerial, Money) son ejemplos de la línea Season 6 y derivados. Nombres y formatos varían según season y emulador. Confirma el mapeo antes de ejecutar cualquier comando que altere datos.

Si todavía estás montando la infraestructura y la rutina de backup del servidor, la guía de cómo crear un servidor de MU Online cubre la instalación de la base y la configuración inicial antes de que necesites restaurar cualquier cosa.

Los tres escenarios de restauración

No toda restauración es igual. Antes de tocar la base, identifica en cuál de los tres escenarios estás, porque cada uno tiene un procedimiento y un riesgo diferente.

El escenario de ítem específico es el más peligroso justamente por parecer el más simple: es donde nace la mayoría de los dupes accidentales creados por el propio administrador. Trata cada escenario con el cuidado que exige.

Paso 1: restaura el backup en una base separada

La regla de oro: nunca restaures el backup sobre la producción. Restáuralo en una base paralela, aislada, de donde solo vas a leer.

-- SQL Server: restaurar backup en base separada
RESTORE DATABASE MuOnline_Restore
FROM DISK = 'D:\Backups\MuOnline_20260710.bak'
WITH MOVE 'MuOnline'     TO 'D:\SQLData\MuOnline_Restore.mdf',
     MOVE 'MuOnline_log' TO 'D:\SQLData\MuOnline_Restore_log.ldf',
     REPLACE;

Con el backup vivo en MuOnline_Restore, tienes una fotografía del pasado al lado de la producción del presente. Ahora puedes comparar los dos estados, extraer lo que necesitas y nunca correr el riesgo de sobrescribir el servidor entero. Confirma que la restauración terminó íntegra antes de proseguir — un backup que no restaura bien no sirve de nada.

Paso 2: localiza y compara los datos

Antes de restaurar cualquier cosa, entiende exactamente qué cambió entre el backup y la producción. Compara el estado del personaje en las dos bases.

-- Estado en el backup
SELECT Name, cLevel, Money, Strength, Dexterity, Vitality, Energy
FROM MuOnline_Restore.dbo.Character
WHERE Name = @personagem;

-- Estado en la producción actual
SELECT Name, cLevel, Money, Strength, Dexterity, Vitality, Energy
FROM MuOnline.dbo.Character
WHERE Name = @personagem;

Esta comparación es el corazón de una restauración responsable. Te dice si el personaje todavía existe en la producción (y solo necesitas devolver un ítem) o si desapareció por completo (y necesitas recrearlo). También revela cuánto progreso legítimo hubo entre el backup y ahora — progreso que no quieres borrar. Anota las diferencias; ellas guían cuál de los próximos pasos aplicar.

Paso 3A: restaurar un personaje entero

Si el personaje fue borrado o corrompido y ya no existe en la producción, lo recreas a partir del backup. El punto crítico es reinsertar en la tabla de personajes y revincular el personaje a la cuenta en la tabla de vínculo, sin tocar otras cuentas.

-- 1) Reinserta el personaje (si ya no existe en la producción)
INSERT INTO MuOnline.dbo.Character
SELECT * FROM MuOnline_Restore.dbo.Character
WHERE Name = @personagem
  AND NOT EXISTS (
    SELECT 1 FROM MuOnline.dbo.Character WHERE Name = @personagem
  );

-- 2) Revincula el personaje al slot de la cuenta
UPDATE MuOnline.dbo.AccountCharacter
SET GameID1 = @personagem   -- el slot correcto varía por emulador
WHERE Id = @conta;

Si el personaje todavía existe en la producción pero tiene atributos corruptos, prefiere un UPDATE quirúrgico de las columnas afectadas en vez de borrar y reinsertar — así no pierdes nada que no necesites perder. Nunca hagas un DELETE seguido de INSERT sin antes confirmar que no hay dependencias (guild, marketplace, eventos) apuntando a ese personaje.

Paso 3B: restaurar un ítem específico (sin dupe)

Este es el escenario de mayor riesgo. El objetivo es devolver una copia de un ítem que desapareció — y solo una. La defensa contra el dupe es una secuencia de verificaciones antes de insertar.

1. Confirma que el ítem no existe en la producción. Si el emulador usa serial, verifica que ese serial no esté activo:

SELECT Serial, Active, OwnerChar
FROM MuOnline.dbo.T_ItemSerial
WHERE Serial = @serialItem;

Si el serial vuelve como Active = 1, detente: el ítem todavía existe y restaurar crearía un dupe. Si vuelve vacío o Active = 0, prosigue.

1. Extrae el ítem del backup (el formato — blob en el inventario o fila normalizada — varía por emulador).

1. Inserta una única copia en el inventario o warehouse de destino, en el slot correcto, y reactiva el serial:

-- Reactiva el serial y devuelve el ítem al dueño (ejemplo)
UPDATE MuOnline.dbo.T_ItemSerial
SET Active = 1, OwnerChar = @personagem
WHERE Serial = @serialItem;

1. Registra la restauración en una tabla de auditoría con serial, dueño, motivo y timestamp. Si algún día ese ítem aparece en una auditoría de dupe, el registro prueba que el segundo origen fue una restauración legítima, no un fraude.

Si el emulador no usa serial y guarda ítems como blob en el inventario, el cuidado es el mismo en espíritu: confirma visualmente o por consulta que el ítem ya no está en el baúl/inventario del jugador antes de reinsertar el blob, para no acabar con dos copias.

Paso 4: evita que el save automático sobrescriba tu trabajo

Aquí vive un error clásico que hace que los administradores repitan la restauración tres veces sin entender por qué. Si el jugador objetivo está logueado durante la inserción, el GameServer mantiene el estado del personaje en memoria y lo graba periódicamente en la base. En el próximo save automático, sobrescribe exactamente las filas que acabas de restaurar, deshaciendo todo.

La solución es garantizar que la cuenta esté fuera del juego a la hora de la inserción final: fuerza el logout de la cuenta, o pon el servidor en una ventana de mantenimiento breve. Haz la inserción con el objetivo offline, confirma que los datos persistieron, y solo entonces libera el login. Este único cuidado resuelve la mayor parte de las "restauraciones que no funcionan".

Paso 5: valida y comunica

Después de insertar, valida antes de declarar victoria. Consulta la producción y confirma que el personaje/ítem está ahí con los atributos correctos. Pide al jugador que se loguee (ahora que la inserción persistió) y confirme visualmente. Registra la operación en tu tabla de auditoría. Una restauración solo está completa cuando el dato está en la base, sobrevivió a un save automático y fue confirmado por el dueño.

Paso a paso resumido

1. Identifica el escenario: personaje entero, ítem específico o rollback parcial.
2. Restaura el backup en una base separada (MuOnline_Restore), nunca sobre la producción.
3. Compara el estado del backup con el de la producción y anota las diferencias.
4. Verifica dupe: confirma que el ítem/serial no esté activo en la producción.
5. Pon el objetivo offline (logout forzado o mantenimiento breve).
6. Inserta quirúrgicamente el personaje o el ítem, en el slot correcto.
7. Registra la operación en la tabla de auditoría.
8. Valida que los datos persistieron después de un save automático.
9. Libera el login y confirma con el jugador.
10. Archiva el dossier de la restauración.

Errores comunes y soluciones

Lista de verificación de lanzamiento

• Backup íntegro y reciente disponible y probado
• Escenario de restauración identificado (personaje/ítem/rollback)
• Backup restaurado en base separada, no en la producción
• Estado del backup comparado con el de la producción
• Verificación de dupe (serial/inventario) concluida
• Objetivo puesto offline antes de la inserción final
• Inserción quirúrgica hecha en el slot correcto
• Operación registrada en la tabla de auditoría
• Datos validados después del save automático
• Restauración confirmada por el jugador y dossier archivado

Restaurar personaje e ítems es un acto de confianza: el jugador te entrega la esperanza de recuperar lo que perdió, y la comunidad confía en que lo harás sin romper la economía. Hazlo siempre quirúrgico, siempre offline, siempre registrado — y prueba tus backups antes de necesitarlos. Un backup que restaura es un seguro; uno que nunca probaste es solo un archivo grande ocupando disco.

Preguntas frecuentes