Fallos de MT4 y VPS: copias de seguridad y recuperación segura

Recupera el entorno de negociación, no una antigua imagen de la cuenta

El procedimiento principal se dirige a un VPS Windows convencional con MT4. El alojamiento virtual integrado de MetaTrader tiene controles distintos; se explica en una sección independiente. Distingue en el plan la cuenta del bróker, la configuración local del terminal y el estado de ejecución del EA.

Restaurar una carpeta no revierte transacciones que el bróker ya ha procesado. Tampoco un gráfico guardado demuestra que su EA pueda retomar de forma segura una cesta tras reiniciarse. El objetivo es un entorno verificado y una gestión de órdenes identificada, no un escritorio de aspecto idéntico. La recuperación reduce las interrupciones operativas; no elimina el riesgo de mercado ni garantiza la ejecución.

Primera respuesta: evita agravar el incidente

1. Registra el incidente. Anota la hora de detección y su zona horaria, la cuenta, el servidor y el terminal afectados, el último funcionamiento normal confirmado y los cambios recientes. La ausencia de una alerta o la pérdida de RDP son síntomas, no un diagnóstico.
2. Comprueba la exposición de la cuenta. Usa una vista autorizada de la cuenta del bróker o un terminal de observación separado, sin EAs o con estos incapaces de operar. Confirma posiciones, órdenes pendientes y niveles de protección aceptados; acude al bróker si el estado no está claro.
3. Identifica todas las copias operativas. Incluye VPS principal, ordenador doméstico, terminales de reserva, alojamiento integrado y servicios de copia de operaciones. No arranques otra copia automatizada solo porque no puedes acceder a la principal.
4. Elige una intervención delimitada. Conserva las pruebas, identifica la capa afectada y sigue el plan de incidentes documentado. Antes de reiniciar o apagar, determina quién se hará cargo de las posiciones que dependen del EA local.

En MT4 convencional, desactivar AutoTrading bloquea las operaciones del EA en ese terminal; no cierra posiciones, elimina órdenes del bróker ni detiene otro servidor. También puede interrumpir las salidas gestionadas por el EA. Reiniciar es, por tanto, una decisión operativa con consecuencias para la cuenta, no un botón de diagnóstico inocuo.

Localiza el fallo antes de reinstalar

Para ajustes concretos y errores de órdenes, consulta la guía de errores de EAs. Esta tabla identifica la capa afectada; no promete que cada síntoma tenga una única causa.

Un EA adjunto puede seguir sin poder gestionar órdenes

Confirma símbolo y periodo previstos, versión del EA, Inputs aprobados e inicialización correcta. Revisa los requisitos de cuenta y licencia sin sustituirlos por valores supuestos. Un cambio de perfil, un indicador ausente o una dependencia DLL/WebRequest pueden alterar el comportamiento aunque sigan llegando cotizaciones.

• Distingue errores de permisos del terminal o del EA de restricciones de la cuenta o del bróker. El código 133 indica que la negociación está deshabilitada; no identifica un botón local concreto que debas pulsar.
• El código 6 indica falta de conexión con el servidor de negociación; el 146, un contexto de negociación ocupado. Investiga el mensaje y los hechos que lo rodean en lugar de reiniciar o enviar peticiones repetidamente.
• Con el código 128, o una respuesta perdida o incierta, contrasta el resultado del servidor antes de repetir. No tener confirmación local no demuestra que el bróker rechazara la petición.

No retires filtros de spread, horario, posición o riesgo para forzar una operación de diagnóstico. Si no hay señal válida, una recuperación correcta puede no producir posiciones nuevas. Gestionar las órdenes existentes y disponer de datos recientes son pruebas de aceptación más útiles que forzar una entrada.

Contrasta las órdenes del bróker antes de reactivar la automatización

En un entorno de observación conectado, revisa Trade para posiciones abiertas y órdenes pendientes. Consulta Account History para las operaciones del incidente y selecciona un periodo que lo abarque. Si los registros discrepan o el acceso es incompleto, pide aclaraciones al bróker antes de dar la reconstrucción por terminada.

• Contrasta ticket, símbolo exacto, dirección, volumen, hora de entrada y Stop Loss/Take Profit aceptados con el registro del incidente. Un terminal detenido no borra las órdenes del bróker; las pendientes pueden activarse durante la interrupción.
• Identifica quién debe gestionarlas según las reglas documentadas del EA sobre símbolo y Magic Number. No cambies identificadores para que una orden antigua desaparezca de su vista.
• Comprueba si las órdenes se cerraron o modificaron mientras el terminal no estaba disponible. No recrees una posición antigua solo porque figure en una copia o un registro.
• Confirma cómo reconstruye este EA su cesta, lógica de trailing, salidas virtuales u otro estado. Si no admite la reconstrucción o hay dudas, sigue el procedimiento del desarrollador antes de habilitarlo.

Los Stop Loss/Take Profit aceptados permanecen en el servidor del bróker. Los ajustes de Trailing Stop de MT4 y las salidas virtuales del EA necesitan que funcione el terminal o EA que los gestiona; el último stop aceptado no equivale a seguir ajustándolo localmente. Los niveles de protección no garantizan un precio de ejecución, sobre todo ante gaps o problemas del bróker.

Conserva las pruebas necesarias para explicar el fallo

Guarda las entradas relevantes de Experts y Journal antes de vaciar las vistas, restaurar una imagen o reinstalar. Si responde el terminal, usa Open en cada pestaña para localizar y volcar sus registros al disco. Los del EA suelen estar en MQL4/Logs y los del terminal en logs, dentro de la carpeta de datos real.

Recoge identidad del terminal, texto y código del error, tickets afectados, última inicialización correcta, cambios de conexión y cambios recientes de Windows o del EA. Registra el reloj y la zona horaria de cada fuente; alinea las horas de Windows, terminal y bróker antes de deducir el orden de los hechos. Consulta la guía de Experts y Journal.

Envía a soporte solo el fragmento y la configuración necesarios, sin credenciales ni datos de cuenta ajenos al problema. El proveedor puede necesitar eventos de la VM; el bróker, datos de órdenes y servidor; el desarrollador, errores de inicialización o estado. Abrir repetidamente el terminal antes de investigar puede confundir el fallo original con los efectos de la recuperación.

Prepara un paquete de recuperación con sus dependencias

Para cada terminal previsto, registra ruta de instalación y usuario Windows; usa File → Open Data Folder para localizar los datos reales. Guarda un inventario junto a la copia: un atajo o una carpeta con el nombre del bróker no son un mapa fiable.

Las órdenes reales del bróker se contrastan tras conectar; no se restauran desde este paquete. Conserva configuración y pruebas de forma segura, con las credenciales fuera de listas públicas y envíos a soporte.

Usa presets, plantillas y perfiles para su función propia

En Inputs del EA, Save conserva los parámetros externos compatibles y Load aplica un preset guardado. Registra la versión del EA correspondiente: entradas renombradas o valores predeterminados distintos en otra versión pueden alterar el resultado. Verifica los valores cargados, no solo un nombre de archivo conocido.

Una plantilla .tpl guarda ajustes del gráfico y puede incluir un EA con sus parámetros; un perfil describe un conjunto de gráficos. Ninguno sustituye a ejecutables, dependencias o estado específico del desarrollador. Los cambios del perfil se guardan conforme cambia el espacio de trabajo, por lo que un cambio accidental también puede pasar a ser el perfil actual.

• Asigna nombres con fecha o versión a presets, plantillas y registros de perfiles validados.
• Mantén un registro separado de símbolos exactos, periodos y reglas previstas de gestión de órdenes.
• Aplica gráficos restaurados solo en un entorno controlado, sin posibilidad de iniciar negociación automática hasta verificarlo. Los ajustes recuperados pueden incluir permisos que no querías activar.

Averigua qué sobrevive al reinicio y qué debe reconstruirse

Un EA puede deducir su estado de las órdenes del bróker, escribir archivos locales o compartidos, usar variables globales del terminal o guardar información solo en memoria. Pregunta al desarrollador qué estado es esencial, cómo persiste y cómo se recuperan órdenes abiertas después de la copia. No todos los EAs se comportan igual.

Las variables globales del terminal son distintas de las variables del código del EA. Las persistentes pueden sobrevivir a reinicios, pero caducan tras 4 semanas sin acceso; las temporales solo existen durante la sesión actual del terminal. Una lista de variables o un preset copiado no son una copia universal del EA. Consérvalas mediante un procedimiento documentado y contrasta su vigencia con las órdenes actuales.

Un estado local antiguo puede discrepar de los registros actuales del bróker. No trasplantes archivos de una cesta de cuenta real a una demo, borres estado para «reiniciar» operaciones existentes ni cambies Magic Numbers sin el mapeo documentado del desarrollador. Si no se puede reconstruir la gestión de forma segura, deja la automatización desactivada y resuelve la discrepancia.

Mantén versiones recuperables fuera del VPS afectado

Conserva versiones fechadas de la configuración aprobada y una copia protegida fuera del VPS principal. Un ZIP en la misma VM puede perderse con ella. Una imagen del proveedor es otra herramienta, pero hay que confirmar retención, alcance, consistencia y disponibilidad; no es una copia independiente de la cuenta del bróker.

• Haz una copia después de cambios aprobados de configuración, versión o dependencias, y programa las del estado según los cambios irrecuperables que pueda tolerar el EA.
• Usa una captura consistente y ensayada. Copiar mientras el EA escribe puede reunir versiones incompatibles. Coordina las pausas o cierres ordenados necesarios con la gestión de posiciones; no interrumpas el gestor real solo para facilitar la copia.
• Comprueba apertura del archivo, presencia de los ficheros necesarios y éxito de un ensayo de restauración. Protege el acceso y conserva versiones utilizables anteriores para que la corrupción o un cambio accidental no sobrescriban todas las copias.

Una suma de comprobación puede detectar cambios inesperados de bytes frente a una referencia fiable; no demuestra que el estado del EA esté actualizado ni sea coherente. El éxito de la copia es su recuperabilidad, no que una tarea programada haya anunciado su finalización.

Distingue los objetivos de interrupción y pérdida de estado

El objetivo de tiempo de recuperación (RTO) es la interrupción que se pretende tolerar antes de restablecer el servicio previsto. El objetivo de punto de recuperación (RPO) es la cantidad de cambios históricos de estado que se pretende tolerar perder. Defínelos para la gestión real del EA y verifica si el procedimiento y la frecuencia de copias los permiten.

Son horas hipotéticas, no un resultado medido ni un RTO prometido. Los 20 minutos corresponden a posibles cambios de estado local ausentes; las órdenes aceptadas siguen contrastándose con los registros actuales del bróker. Los 12 minutos corresponden a la interrupción. Cumplir un intervalo de copia no basta si el EA no puede conciliar ese estado con la cuenta.

Restaura en un entorno controlado

1. Confirma que la copia de origen no puede operar. Detenla o aíslala mediante un control verificado e impide su reactivación automática. Si simplemente no puedes acceder, resuelve esa incertidumbre antes de arrancar la automatización de sustitución.
2. Prepara un terminal limpio de observación o preparación. Usa el MT4 previsto por el bróker y el usuario Windows correcto. Deshabilita la automatización antes de introducir perfiles o ajustes del EA recuperados. En la verificación inicial, no añadas credenciales reales o usa un acceso de observación de solo lectura compatible; confirma sus restricciones efectivas.
3. Localiza la nueva carpeta de datos. Usa File → Open Data Folder. Conserva intacta la copia original y restaura los archivos seleccionados y documentados, no toda la configuración nueva a ciegas.
4. Restaura programas y parámetros aprobados. Verifica versiones, símbolos y periodos exactos, dependencias y licencia. Mantén desactivada la automatización; un archivo antiguo no debe sustituir silenciosamente los controles de permisos verificados.
5. Valida estado y órdenes. Sigue el procedimiento documentado para comparar el estado persistente con posiciones, pendientes e historial del incidente actuales del bróker. Resuelve discrepancias antes de retomar la gestión.
6. Completa la aceptación. Verifica datos necesarios, inicialización, permisos, gestión de órdenes, registros, alertas y contexto de inicio. Ensaya previamente en demo; no copies estado de cuenta real a la cuenta de ensayo.
7. Autoriza una única copia operativa. Sigue el traspaso documentado y confirma que la copia anterior sigue sin poder operar. Establece el acceso de negociación autorizado previsto, revisa las protecciones ante cambios de cuenta y los permisos finales y habilita solo la sustitución verificada. Observa la gestión de órdenes existentes y registra hora y resultado.

Sin confirmar estado crítico, gestión de órdenes, acceso al bróker o parada de origen, el procedimiento sigue incompleto. Mantén desactivada la automatización de sustitución y escala el problema concreto; un terminal.exe en marcha o un gráfico restaurado atractivo no bastan.

Prepara la reserva sin crear un segundo gestor activo

Un VPS de reserva reduce preparación si ya se han probado configuración, dependencias y acceso. Mantenlo sin capacidad de operar hasta cumplir el traspaso. Otro VPS en la misma cuenta del bróker no bloquea órdenes duplicadas.

• Registra servidor principal, reserva y otros equipos, y cómo detener cada uno e impedir sus reinicios automáticos.
• Confirma que el principal se ha detenido o está efectivamente aislado de la negociación. Un apagado confirmado por el proveedor o una parada verificada aportan más evidencia que un RDP fallido o una señal periódica ausente.
• Contrasta órdenes y estado del EA y completa los controles de sustitución antes de activarlo. Cuando vuelva el principal, mantén un único gestor activo; no permitas que ambos inicios reactiven la negociación.

Cambiar de VPS no repara un servidor del bróker no disponible ni garantiza acceso durante un fallo general. Si se desconoce si la instancia principal puede operar, no des por seguro un traspaso sin verificar. Sigue el plan de incidentes de la cuenta mientras aclaras ese estado.

Usa los controles propios del alojamiento virtual de MetaTrader

El alojamiento integrado no es un escritorio VPS Windows. Investiga con el estado remoto y los registros solicitados del terminal y Experts. Stop Server detiene el terminal virtual; confirma su estado detenido antes de habilitar una sustitución en otro lugar. El AutoTrading local no detiene el EA alojado.

La migración pasa del entorno local al virtual, no vuelve como una exportación de recuperación. El alojamiento permite negociación automática incluso si los permisos locales estaban desactivados. No migres una copia de recuperación real preparada pero desactivada esperando que continúe así remotamente. Valida el entorno y el contexto de cuenta antes de sincronizar; las llamadas DLL no son compatibles allí.

Ensaya el procedimiento y registra la aceptación

Usa un entorno demo autorizado separado para ensayar cierre del terminal, reinicio del sistema, una dependencia ausente, restauración del paquete y un traspaso controlado del principal a la reserva. Separa cuentas, licencias y archivos de estado reales y demo. Registra pruebas realizadas, límites y resultados; un ensayo del escritorio no demuestra la ejecución real futura.

Tras el incidente, documenta causa, acciones, discrepancias conciliadas y mejoras del siguiente ensayo. Usa la Guía 2 para corregir recursos o inicio sin cambiar las reglas de riesgo de la estrategia para ocultar el problema técnico.

Preguntas frecuentes sobre copias y recuperación

¿Restaurar una imagen del VPS restaura mi cuenta de trading?

No. Recupera el entorno local dentro del alcance documentado por el proveedor. Las transacciones se determinan con los registros actuales del bróker. El estado antiguo del EA debe contrastarse con ellos.

¿Basta un archivo .set para respaldar un EA?

No. Conserva parámetros externos compatibles. Guarda también versión del programa, indicadores y archivos necesarios, información de licencia y procedimiento documentado de recuperación de estado.

¿Puedo arrancar un VPS de reserva si falla Escritorio remoto?

Puedes investigarlo y prepararlo con la automatización sin capacidad de operar. No habilites la sustitución hasta resolver si el principal puede operar y quién gestiona las órdenes existentes. Perder acceso remoto no demuestra que se haya detenido.

¿Debo reenviar una petición tras agotarse el tiempo de espera?

No antes de comprobar el resultado del servidor. Contrasta órdenes abiertas y pendientes, historial y registros relevantes, y acude al bróker si sigue sin aclararse. Repetir a ciegas puede duplicar una petición ya aceptada.

Referencias oficiales y alcance práctico

El comportamiento de la plataforma se ha contrastado con documentación oficial de MetaQuotes. El flujo de incidentes, las copias, el control de reserva y la aceptación son recomendaciones prácticas, no una herramienta universal de recuperación MT4 probada. Los nombres varían por idioma o edición; confirma los reales y las instrucciones del desarrollador.

• MetaTrader 4: carpetas de datos, plantillas y perfiles, y parámetros y permisos del EA.
• MetaTrader 4: órdenes del bróker y Trailing Stop del terminal.
• Referencia MQL4: códigos de negociación y variables globales del terminal.
• MetaTrader 4: controles del alojamiento remoto y reglas de migración.