Falhas no MT4 e VPS: backup e recuperação segura

Recupere o ambiente de negociação, não um estado antigo da conta

O procedimento principal se aplica a um VPS Windows comum executando o MT4. A hospedagem virtual integrada do MetaTrader tem controles diferentes; a seção específica abaixo explica essa distinção. No planejamento, separe a conta na corretora, a configuração local do terminal e o estado do EA em execução.

Restaurar uma pasta não desfaz transações que a corretora já processou. Um gráfico salvo também não comprova que o EA possa retomar com segurança o gerenciamento de um conjunto de posições após reiniciar. O objetivo é um estado operacional verificado, com responsabilidade definida pelas ordens, e não um desktop com a mesma aparência. A recuperação reduz a interrupção operacional; não elimina o risco de mercado nem garante a execução.

Primeira resposta: evite ampliar o incidente

1. Registre o incidente. Anote o horário de detecção e o fuso, a conta/servidor e o terminal afetados, o último comportamento normal confirmado e as mudanças recentes. Um alerta ausente ou uma sessão RDP perdida é um sintoma, não um diagnóstico.
2. Confira a exposição da conta. Use uma visualização autorizada da conta na corretora ou um terminal de observação separado, sem EAs ou com EAs impossibilitados de negociar. Confirme posições atuais, ordens pendentes e níveis de proteção aceitos; envolva a corretora se o estado da conta não estiver claro.
3. Identifique todas as instâncias de negociação. Inclua VPS principal, computador de casa, terminais de reserva, hospedagem integrada e serviços de cópia de operações. Não inicie outra instância automatizada só porque a principal está inacessível.
4. Escolha uma intervenção delimitada. Preserve as evidências, identifique a camada com falha e siga o plano de incidentes documentado. Antes de reiniciar ou desligar, defina quem será responsável pelas posições que dependem do gerenciamento do EA local.

No MT4 comum, desativar AutoTrading bloqueia as operações de negociação dos EAs naquele terminal; não fecha posições, não remove ordens da corretora nem para outro host. Também pode interromper saídas gerenciadas pelo EA. Portanto, reiniciar é uma decisão operacional com consequências para a conta, não um simples botão de diagnóstico sem efeitos.

Localize a falha antes de reinstalar

Para configurações individuais e erros de ordens, use o guia de erros de EA. Esta tabela identifica a camada afetada; não promete que um sintoma tenha apenas uma causa.

Um EA anexado ainda pode estar impedido de gerenciar ordens

Confirme símbolo e período gráfico previstos, versão do EA, Inputs aprovados e inicialização bem-sucedida. Verifique os requisitos de conta e licença sem substituí-los por valores presumidos. Uma mudança de perfil, um indicador personalizado ausente ou uma dependência DLL/WebRequest pode alterar o comportamento mesmo com cotações chegando.

• Separe erros de permissão do terminal ou do EA das restrições da corretora/conta. O código 133 significa que a negociação está desativada; não indica qual botão local pressionar.
• O código 6 indica ausência de conexão com o servidor de negociação; o código 146 indica contexto de negociação ocupado. Investigue a mensagem real e os eventos próximos em vez de reiniciar ou enviar solicitações repetidamente.
• Com o código 128, ou qualquer resposta de negociação perdida ou incerta, confira o resultado no servidor antes de tentar novamente. A falta de confirmação local não comprova que a corretora rejeitou a solicitação.

Não remova filtros de spread, sessão, posição ou risco para forçar uma operação de diagnóstico. Se o EA não tiver sinal válido, uma recuperação bem-sucedida pode não gerar posição nova. O gerenciamento das ordens existentes e dados atualizados são evidências de aceitação mais úteis do que forçar uma entrada.

Confira as ordens da corretora antes de retomar a automação

Em um ambiente de observação conectado, consulte Trade para posições abertas e ordens pendentes. Consulte Account History para operações durante o incidente; escolha um intervalo de datas que realmente o cubra. Se os registros divergirem ou o acesso estiver incompleto, peça esclarecimentos à corretora antes de considerar a reconstrução concluída.

• Compare ticket, símbolo exato, direção, volume, horário de entrada e Stop Loss/Take Profit aceitos com o registro do incidente. Um terminal parado não apaga ordens mantidas pela corretora; ordens pendentes podem ser acionadas durante a interrupção.
• Identifique o responsável pelo gerenciamento conforme as regras documentadas do EA para símbolo e Magic Number. Não altere identificadores para esconder uma ordem antiga do EA.
• Verifique se ordens foram fechadas ou alteradas enquanto o terminal estava indisponível. Não recrie uma posição antiga só porque ela aparece em um backup ou log.
• Confirme como esse EA reconstrói seu conjunto de posições, lógica de trailing, saídas virtuais ou outros estados. Se a reconstrução não for suportada ou estiver incerta, siga o procedimento de recuperação do fornecedor antes de habilitá-lo.

Os níveis de Stop Loss/Take Profit aceitos pela corretora permanecem no servidor. Os ajustes do Trailing Stop do MT4 e as saídas virtuais do EA exigem que o terminal/EA responsável esteja funcionando; o último stop aceito no servidor é diferente do ajuste local contínuo. Os níveis de proteção não garantem um preço de execução, especialmente em gaps ou interrupções da corretora.

Preserve as evidências necessárias para explicar a falha

Guarde as entradas relevantes de Experts e Journal antes de limpar as visualizações, restaurar um snapshot ou reinstalar. Se o terminal responder, use o comando Open de cada aba para localizar os logs e gravar o buffer em disco. Os logs de EA normalmente ficam em MQL4/Logs, e os do terminal em logs, dentro da pasta de dados real.

Registre identidade do terminal, texto/código do erro, tickets afetados, última inicialização bem-sucedida, mudanças de conexão e alterações recentes no Windows ou EA. Anote o relógio/fuso usado por cada fonte; alinhe os horários do Windows, terminal e corretora antes de inferir a sequência dos eventos. Consulte o guia de Experts e Journal.

Envie ao suporte apenas o trecho relevante e a configuração necessária à investigação, sem credenciais ou informações de conta sem relação com o caso. O provedor pode precisar dos eventos da VM, a corretora dos detalhes de ordens/servidor e o desenvolvedor do EA dos erros de inicialização ou estado. Reiniciar repetidamente antes de investigar pode confundir a falha original com os efeitos da recuperação.

Monte um pacote de recuperação com as dependências

Para cada terminal previsto, registre o caminho de instalação e o usuário Windows, depois use File → Open Data Folder para localizar os dados reais. Guarde um inventário junto ao backup; um atalho ou uma pasta com o nome da corretora não é um mapa confiável.

O registro real das ordens da corretora é conferido após reconectar; não é restaurado a partir desse pacote. Mantenha configuração e evidências protegidas, deixando as credenciais de recuperação fora de checklists públicos e envios ao suporte.

Use presets, templates e perfis para suas funções específicas

Na aba Inputs do EA, Save preserva os parâmetros externos suportados e Load aplica um preset salvo. Registre a versão correspondente do EA: parâmetros renomeados ou valores padrão diferentes em uma versão substituta podem alterar o resultado. Confira os valores carregados em vez de confiar em um nome de arquivo conhecido.

Um template .tpl guarda as configurações do gráfico e pode incluir um EA anexado com seus parâmetros; um perfil descreve um grupo de gráficos. Nenhum substitui os executáveis correspondentes, as dependências ou o estado específico do fornecedor. As mudanças do perfil são salvas conforme a área de trabalho muda, então uma alteração acidental também pode virar o perfil atual.

• Use nomes com data/versão para presets, templates e registros de perfil já validados.
• Guarde um registro separado dos símbolos exatos, períodos gráficos e regras previstas de gerenciamento das ordens.
• Aplique gráficos restaurados apenas em um ambiente controlado, onde a negociação automática não possa começar antes da verificação. As configurações restauradas podem trazer permissões que você não pretendia habilitar.

Descubra o que sobrevive ao reinício e o que precisa ser reconstruído

Um EA pode derivar o estado das ordens da corretora, gravar arquivos locais ou compartilhados, usar variáveis globais do terminal ou manter informações apenas em memória. Pergunte ao desenvolvedor qual estado é essencial, como ele é persistido e como a recuperação trata ordens abertas após o backup. Nunca presuma que todos os EAs se comportam da mesma forma.

As variáveis globais do terminal são diferentes das variáveis no código do EA. As globais persistentes podem sobreviver a reinicializações, mas expiram após 4 semanas sem acesso; as temporárias existem apenas na sessão atual do terminal. Uma lista de variáveis globais ou um preset copiado não é, portanto, um backup universal de EA. Preserve o estado por um procedimento documentado e confira se está atualizado em relação às ordens atuais.

Um estado local antigo pode divergir dos novos registros da corretora. Não transfira arquivos de estado de um conjunto de posições de conta real para uma conta demo, não exclua o estado para “zerar” operações existentes nem mude Magic Numbers sem o mapeamento documentado do fornecedor. Se o EA não conseguir reconstruir o gerenciamento com segurança, mantenha a automação desativada e resolva a divergência.

Mantenha versões recuperáveis fora do VPS que falhou

Mantenha versões datadas da configuração aprovada e uma cópia protegida fora do VPS principal. Um ZIP na mesma VM pode ser perdido junto com ela. Um snapshot do provedor é outra ferramenta de recuperação, mas é preciso confirmar sua retenção, abrangência, consistência e disponibilidade; ele não é um backup independente da conta na corretora.

• Faça backup após mudanças aprovadas de configuração, versão ou dependências, e programe backups do estado conforme a quantidade de mudanças irrecuperáveis que o EA pode tolerar.
• Use um método de captura consistente e testado. Copiar arquivos enquanto o EA grava neles pode reunir versões incompatíveis. Coordene qualquer pausa ou encerramento ordenado necessário com o gerenciamento das posições; não interrompa um gerenciador ativo apenas para facilitar a cópia.
• Confira se os arquivos compactados abrem, se contêm os arquivos necessários e se um ensaio de restauração funciona. Proteja o acesso e mantenha versões anteriores utilizáveis para que corrupção ou alteração acidental não substitua todas as cópias.

Um checksum pode detectar uma mudança inesperada de bytes em relação a uma referência confiável; não comprova que o estado do EA esteja atual ou logicamente consistente. Um backup bem-sucedido significa capacidade de recuperação, não apenas uma tarefa agendada informando conclusão.

Defina objetivos separados para indisponibilidade e perda de estado

O objetivo de tempo de recuperação (RTO) é o período de indisponibilidade que você pretende tolerar antes de restaurar o serviço previsto. O objetivo de ponto de recuperação (RPO) é a quantidade de mudanças históricas de estado cuja perda você pretende tolerar. Defina-os conforme as necessidades reais de gerenciamento do EA e teste se o procedimento e a frequência dos backups os atendem.

Os horários são hipotéticos, não um resultado de recuperação medido nem uma promessa de RTO. Os 20 minutos dizem respeito a mudanças de estado local potencialmente ausentes; ordens aceitas pela corretora continuam sendo verificadas nos registros atuais dela. Os 12 minutos dizem respeito à indisponibilidade. Uma política de backup que cumpre um intervalo ainda pode falhar se o EA não conseguir reconciliar aquele estado com a conta.

Restaure em um ambiente controlado

1. Confirme que a instância de origem não pode negociar. Pare ou isole essa instância por um controle verificado e impeça a reativação automática. Se ela estiver apenas inacessível, resolva essa incerteza antes de iniciar a automação substituta.
2. Prepare um terminal limpo de observação ou preparação. Use o MT4 previsto pela corretora e o usuário Windows correto. Desative a negociação automática antes de introduzir perfis ou configurações restauradas do EA. Na verificação inicial, mantenha ausentes as credenciais de conta real ou use um login de observação somente leitura suportado; confirme suas restrições reais de acesso.
3. Localize a nova pasta de dados. Use File → Open Data Folder. Preserve o backup original e restaure os arquivos selecionados e documentados em vez de sobrescrever às cegas toda a nova configuração.
4. Restaure programas e parâmetros aprovados. Verifique versões, símbolos/períodos exatos, dependências e licença. Mantenha a automação desativada; um arquivo antigo de configurações não deve substituir silenciosamente os controles de permissão já verificados.
5. Valide estado e ordens. Use o procedimento documentado para comparar o estado persistente com posições atuais da corretora, ordens pendentes e histórico do período do incidente. Resolva as divergências antes de retomar o gerenciamento.
6. Conclua as verificações de aceitação. Confira dados necessários, inicialização, permissões, responsabilidade pelas ordens, logs, alertas e contexto de inicialização. Valide o procedimento em demo antecipadamente; não copie o estado da conta real para a conta de ensaio.
7. Autorize uma única instância de negociação prevista. Siga a transferência documentada e confirme que a instância antiga continua impedida de negociar. Estabeleça o login de negociação autorizado previsto, confira novamente a proteção na mudança de conta e as permissões finais, e habilite somente a substituição verificada. Observe o gerenciamento das ordens existentes e registre horário e resultado.

Se não for possível confirmar estado crítico, responsabilidade pelas ordens, acesso à corretora ou parada da origem, o procedimento está incompleto. Mantenha a automação substituta desativada e encaminhe o problema específico não resolvido; um processo terminal.exe ativo ou um gráfico restaurado com boa aparência não é suficiente.

Prepare uma reserva sem criar um segundo gerenciador ativo

Um VPS reserva pode reduzir o trabalho de preparação quando configuração, dependências e acesso já foram testados. Mantenha-o impedido de negociar até cumprir as condições de transferência. Um segundo VPS na mesma conta da corretora não bloqueia ordens duplicadas.

• Registre principal, reserva e qualquer outro host, além de como parar cada um e impedir sua reinicialização automática.
• Confirme que o principal está parado ou efetivamente isolado da negociação. Controles de energia confirmados pelo provedor ou uma parada verificada são evidências mais fortes do que apenas falha de RDP ou ausência de sinal de atividade.
• Confira ordens da corretora e estado do EA, depois conclua as verificações da substituição antes de habilitá-la. Quando o principal voltar, mantenha um único responsável ativo; não permita que as duas rotinas de inicialização reativem a negociação.

Mudar de VPS não corrige um servidor indisponível da corretora nem garante acesso durante uma interrupção mais ampla. Se o estado de negociação do principal continuar desconhecido, não considere segura uma transferência não verificada. Siga o plano de gerenciamento de incidentes da conta enquanto esclarece esse estado.

Use os controles corretos para a hospedagem virtual MetaTrader

A hospedagem integrada do MetaTrader não é um desktop VPS Windows. Use o status remoto e os logs solicitados do terminal/Experts para investigar. Stop Server para o terminal virtual; confirme o estado de parada informado antes de habilitar uma substituição em outro lugar. O botão local AutoTrading não para o EA hospedado.

A migração vai do ambiente local para o terminal virtual, não volta como exportação de recuperação. A negociação automatizada hospedada é permitida mesmo quando as permissões locais foram desativadas. Portanto, não migre uma instância de recuperação de conta real preparada mas desativada esperando que continue desativada remotamente. Valide o ambiente previsto e o contexto da conta antes da sincronização; chamadas DLL não são suportadas ali.

Ensaie o procedimento e registre a aceitação

Use uma configuração demo separada e autorizada para ensaiar fechamento do terminal, reinicialização do sistema, dependência ausente, restauração de um pacote salvo e transferência controlada do principal para a reserva. Separe contas, licenças e arquivos de estado demo e reais. Registre o que foi efetivamente testado, limitações e resultado; um ensaio no desktop não comprova a execução futura em conta real.

Após o incidente, documente causa, ações de recuperação, divergências resolvidas e melhorias para o próximo ensaio. Use o Guia 2 para corrigir fragilidades de recursos ou inicialização sem alterar as regras de risco da estratégia para esconder o problema técnico.

Perguntas comuns sobre backup e recuperação

Restaurar um snapshot do VPS restaura minha conta de negociação?

Não. Isso restaura o ambiente local do snapshot dentro do escopo documentado pelo provedor. As transações continuam sendo estabelecidas pelos registros atuais da corretora. O estado local antigo do EA precisa ser reconciliado com eles.

Um arquivo .set é suficiente para fazer backup de um EA?

Não. Ele preserva os parâmetros externos suportados. Guarde também a versão correspondente do programa, indicadores/arquivos necessários, informações de licença e o procedimento documentado de recuperação do estado do EA.

Posso iniciar um VPS reserva quando a Área de Trabalho Remota falha?

Você pode investigar e preparar a reserva com a automação impedida de negociar. Não habilite a substituição até esclarecer a capacidade de negociação do principal e a responsabilidade pelas ordens existentes. Perder acesso remoto não comprova que o principal parou.

Devo reenviar uma solicitação de negociação após um timeout?

Não antes de conferir o resultado no servidor. Verifique posições abertas e ordens pendentes, histórico relevante e logs, e envolva a corretora se o resultado ainda não estiver claro. Repetir às cegas pode duplicar uma solicitação já aceita.

Referências oficiais e escopo prático

O comportamento da plataforma foi conferido na documentação oficial da MetaQuotes. O fluxo de incidentes, a política de backup, os controles da reserva e as verificações de aceitação são recomendações práticas, não uma ferramenta universal de recuperação do MT4 testada. Os nomes da interface podem variar conforme idioma ou edição do terminal; confirme os rótulos reais e as instruções do fornecedor do EA.

• MetaTrader 4: pastas de dados, templates e perfis, e parâmetros e permissões dos EAs.
• MetaTrader 4: ordens mantidas pela corretora e Trailing Stop do terminal.
• Referência MQL4: códigos de retorno de negociação e variáveis globais do terminal.
• MetaTrader 4: controles da hospedagem remota e regras de migração.