Como restaurar personagem e itens de backup no MU Online
Aprenda a restaurar personagens e itens perdidos de um backup no MU Online de forma cirúrgica — sem sobrescrever o servidor inteiro, sem criar dupes e sem quebrar a economia.
Mais cedo ou mais tarde, todo administrador de MU Online ouve a mesma frase: "perdi meu personagem" ou "sumiu meu set Excellent". Pode ter sido um rollback após uma queda do servidor, um bug de item, um dupe que forçou uma reversão, ou até um erro do próprio jogador. A capacidade de restaurar person
Mais cedo ou mais tarde, todo administrador de MU Online ouve a mesma frase: "perdi meu personagem" ou "sumiu meu set Excellent". Pode ter sido um rollback após uma queda do servidor, um bug de item, um dupe que forçou uma reversão, ou até um erro do próprio jogador. A capacidade de restaurar personagem e itens de backup é o que separa um servidor confiável de um servidor onde perder progresso é definitivo. Mas restaurar bem é uma operação delicada: feita errado, ela apaga o progresso de outros jogadores, cria itens duplicados ou quebra a economia inteira. Este tutorial avançado mostra como fazer restauração cirúrgica — trazendo de volta exatamente o que foi perdido, sem colateral.
O erro conceitual mais comum é achar que restaurar um personagem significa restaurar o backup inteiro. Restaurar o backup completo sobre a produção é o equivalente a apagar todo o progresso que aconteceu desde que aquele backup foi feito — cada jogador que subiu de nível, cada item conquistado, cada Zen farmado nas últimas horas desaparece. Isso resolve o problema de um jogador criando o problema de mil. A restauração correta é sempre seletiva: o backup é aberto em um banco separado e paralelo, apenas os dados necessários são extraídos, e esses dados são inseridos no banco de produção atual, que continua vivo com todo o progresso recente intacto.
Pré-requisitos
- Acesso administrativo ao banco de dados de produção (SQL Server ou MySQL, conforme o emulador) com permissão para inserir e atualizar.
- Um backup íntegro e recente do banco, no formato do seu SGBD (
.bak, dump SQL, etc.). - Espaço e permissão para restaurar o backup em um banco separado (ex.:
MuOnline_Restore) na mesma instância ou em outra. - Conhecimento do esquema do emulador: tabelas de conta, personagem, inventário e warehouse, e como os itens são codificados.
- Capacidade de forçar logout de uma conta ou de colocar o servidor em manutenção breve para a inserção final.
- Ferramenta de consulta SQL (SSMS, HeidiSQL, DBeaver) e, idealmente, uma tabela de log de auditoria para registrar cada restauração.
> Aviso: todos os nomes de tabela e coluna abaixo (Character, AccountCharacter, warehouse, Inventory, T_ItemSerial, Money) são exemplos da linha Season 6 e derivados. Nomes e formatos variam por season e emulador. Confirme o mapeamento antes de executar qualquer comando que altere dados.
Se você ainda está montando a infraestrutura e a rotina de backup do servidor, o guia de como criar servidor de MU Online cobre a instalação do banco e a configuração inicial antes de você precisar restaurar qualquer coisa.
Os três cenários de restauração
Nem toda restauração é igual. Antes de tocar no banco, identifique em qual dos três cenários você está, porque cada um tem um procedimento e um risco diferente.
| Cenário | O que foi perdido | Risco principal |
|---|---|---|
| Personagem inteiro | Char deletado ou corrompido | Sobrescrever conta ativa |
| Item específico | Item sumiu do inventário/baú | Criar dupe do item |
| Rollback parcial | Progresso perdido em janela de tempo | Perder progresso de terceiros |
O cenário de item específico é o mais perigoso justamente por parecer o mais simples: é onde nasce a maioria dos dupes acidentais criados pelo próprio administrador. Trate cada cenário com o cuidado que ele exige.
Passo 1: restaure o backup em um banco separado
A regra de ouro: nunca restaure o backup sobre a produção. Restaure-o em um banco paralelo, isolado, de onde você vai apenas ler.
-- SQL Server: restaurar backup em banco separado
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;
Com o backup vivo em MuOnline_Restore, você tem uma fotografia do passado ao lado da produção do presente. Agora pode comparar os dois estados, extrair o que precisa e nunca correr o risco de sobrescrever o servidor inteiro. Confirme que a restauração terminou íntegra antes de prosseguir — um backup que não restaura direito não serve de nada.
Passo 2: localize e compare os dados
Antes de restaurar qualquer coisa, entenda exatamente o que mudou entre o backup e a produção. Compare o estado do personagem nos dois bancos.
-- Estado no backup
SELECT Name, cLevel, Money, Strength, Dexterity, Vitality, Energy
FROM MuOnline_Restore.dbo.Character
WHERE Name = @personagem;
-- Estado na produção atual
SELECT Name, cLevel, Money, Strength, Dexterity, Vitality, Energy
FROM MuOnline.dbo.Character
WHERE Name = @personagem;
Esta comparação é o coração de uma restauração responsável. Ela te diz se o personagem ainda existe na produção (e você só precisa devolver um item) ou se sumiu por completo (e você precisa recriá-lo). Também revela quanto progresso legítimo houve entre o backup e agora — progresso que você não quer apagar. Anote as diferenças; elas guiam qual dos próximos passos aplicar.
Passo 3A: restaurar um personagem inteiro
Se o personagem foi deletado ou corrompido e não existe mais na produção, você o recria a partir do backup. O ponto crítico é reinserir na tabela de personagens e religar o personagem à conta na tabela de vínculo, sem tocar em outras contas.
-- 1) Reinsere o personagem (se ele não existe mais na produção)
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) Religa o personagem ao slot da conta
UPDATE MuOnline.dbo.AccountCharacter
SET GameID1 = @personagem -- slot correto varia por emulador
WHERE Id = @conta;
Se o personagem ainda existe na produção mas está com atributos corrompidos, prefira um UPDATE cirúrgico das colunas afetadas em vez de apagar e reinserir — assim você não perde nada que não precise perder. Nunca faça um DELETE seguido de INSERT sem antes confirmar que não há dependências (guild, marketplace, eventos) apontando para aquele personagem.
Passo 3B: restaurar um item específico (sem dupe)
Este é o cenário de maior risco. O objetivo é devolver uma cópia de um item que sumiu — e apenas uma. A defesa contra dupe é uma sequência de verificações antes de inserir.
- Confirme que o item não existe na produção. Se o emulador usa serial, verifique que aquele serial não está ativo:
SELECT Serial, Active, OwnerChar
FROM MuOnline.dbo.T_ItemSerial
WHERE Serial = @serialItem;
Se o serial voltar como Active = 1, pare: o item ainda existe e restaurar criaria um dupe. Se voltar vazio ou Active = 0, prossiga.
- Extraia o item do backup (o formato — blob no inventário ou linha normalizada — varia por emulador).
- Insira uma única cópia no inventário ou warehouse de destino, no slot correto, e reative o serial:
-- Reativa o serial e devolve o item ao dono (exemplo)
UPDATE MuOnline.dbo.T_ItemSerial
SET Active = 1, OwnerChar = @personagem
WHERE Serial = @serialItem;
- Registre a restauração em uma tabela de auditoria com serial, dono, motivo e timestamp. Se algum dia esse item aparecer em uma auditoria de dupe, o registro prova que a segunda origem foi uma restauração legítima, não uma fraude.
Se o emulador não usa serial e guarda itens como blob no inventário, o cuidado é o mesmo em espírito: confirme visualmente ou por consulta que o item não está mais no baú/inventário do jogador antes de reinserir o blob, para não acabar com duas cópias.
Passo 4: evite o save automático sobrescrever seu trabalho
Aqui mora um erro clássico que faz administradores repetirem a restauração três vezes sem entender por quê. Se o jogador-alvo está logado durante a inserção, o GameServer mantém o estado do personagem em memória e o grava periodicamente no banco. No próximo save automático, ele sobrescreve exatamente as linhas que você acabou de restaurar, desfazendo tudo.
A solução é garantir que a conta esteja fora do jogo na hora da inserção final: force o logout da conta, ou coloque o servidor em uma janela de manutenção breve. Faça a inserção com o alvo offline, confirme que os dados persistiram, e só então libere o login. Este único cuidado resolve a maior parte das "restaurações que não funcionam".
Passo 5: valide e comunique
Depois de inserir, valide antes de declarar vitória. Consulte a produção e confirme que o personagem/item está lá com os atributos corretos. Peça ao jogador para logar (agora que a inserção persistiu) e confirmar visualmente. Registre a operação na sua tabela de auditoria. Uma restauração só está completa quando o dado está no banco, sobreviveu a um save automático e foi confirmado pelo dono.
Passo a passo resumido
- Identifique o cenário: personagem inteiro, item específico ou rollback parcial.
- Restaure o backup em um banco separado (
MuOnline_Restore), nunca sobre a produção. - Compare o estado do backup com o da produção e anote as diferenças.
- Verifique dupe: confirme que o item/serial não está ativo na produção.
- Coloque o alvo offline (logout forçado ou manutenção breve).
- Insira cirurgicamente o personagem ou o item, no slot correto.
- Registre a operação na tabela de auditoria.
- Valide que os dados persistiram após um save automático.
- Libere o login e confirme com o jogador.
- Arquive o dossiê da restauração.
Erros comuns e soluções
| Erro | Sintoma | Solução |
|---|---|---|
| Restaurar backup inteiro sobre produção | Progresso de todos os jogadores apagado | Restaurar em banco separado e extrair só o necessário |
| Inserir item já existente | Dupe criado pelo próprio admin | Verificar serial/inventário antes de inserir |
| Alvo logado durante a inserção | Restauração desfeita pelo save automático | Forçar logout ou manutenção antes da inserção final |
| DELETE + INSERT sem checar dependências | Vínculos de guild/market quebrados | Preferir UPDATE cirúrgico; checar dependências |
| Não registrar a restauração | Item legítimo confundido com dupe depois | Logar serial, dono, motivo e timestamp |
| Backup nunca testado | Restauração falha na hora crítica | Testar restauração periodicamente em ambiente isolado |
Checklist de lançamento
- Backup íntegro e recente disponível e testado
- Cenário de restauração identificado (personagem/item/rollback)
- Backup restaurado em banco separado, não na produção
- Estado do backup comparado com o da produção
- Verificação de dupe (serial/inventário) concluída
- Alvo colocado offline antes da inserção final
- Inserção cirúrgica feita no slot correto
- Operação registrada na tabela de auditoria
- Dados validados após save automático
- Restauração confirmada pelo jogador e dossiê arquivado
Restaurar personagem e itens é um ato de confiança: o jogador entrega a você a esperança de recuperar o que perdeu, e a comunidade confia que você fará isso sem quebrar a economia. Faça sempre cirúrgico, sempre offline, sempre registrado — e teste seus backups antes de precisar deles. Um backup que restaura é um seguro; um que você nunca testou é só um arquivo grande ocupando disco.
Perguntas frequentes
Restaurar um personagem significa restaurar o servidor inteiro do backup?
Não, e quase nunca deveria. Restaurar o backup completo joga todo o servidor de volta ao passado, apagando o progresso de todos os outros jogadores desde então. Uma restauração bem feita é cirúrgica: você abre o backup em um banco separado, extrai apenas o personagem ou item necessário e o insere no banco de produção atual.
Como restaurar um item sem criar um dupe?
O risco de dupe existe porque a mesma cópia pode acabar viva no backup e na produção. Antes de reinserir, confirme que o item realmente não existe mais na produção atual e, se o emulador usa serial, verifique que o serial não está ativo. Reinsira uma única cópia e registre a operação para auditoria.
Preciso derrubar o servidor para restaurar um personagem?
Idealmente sim, ao menos tirar o jogador-alvo do ar durante a operação. Restaurar dados de um personagem que está logado pode ser sobrescrito pelo save automático do GameServer, desfazendo seu trabalho. Force o logout da conta ou coloque o servidor em manutenção breve para a inserção final.
Com que frequência devo fazer backup para conseguir restaurar bem?
Depende do movimento. Servidores ativos merecem backup completo diário e backups incrementais ou de log de transação a cada poucas horas. Quanto menor o intervalo entre backups, menor o progresso perdido na restauração. Backup que você nunca testou restaurar não é backup, é esperança.
As instruções deste tutorial servem para qualquer emulador de MU?
Os conceitos servem, os nomes não. Cada emulador organiza personagem, inventário e warehouse em tabelas próprias, e alguns guardam itens como blob hexadecimal. Os exemplos usam nomes comuns da linha Season 6; adapte tabelas, colunas e formato ao seu esquema antes de executar.