MT4 与 VPS 故障：备份与安全恢复

恢复交易环境，而不是旧账户快照

主要流程适用于运行 MT4 的普通 Windows VPS。MetaTrader 集成虚拟托管具有不同控制方式；下方专节说明其区别。在计划中，应区分经纪商账户、本地终端配置及 EA 运行状态。

还原文件夹不能撤销经纪商已经处理的交易。保存的图表也不能证明其 EA 在重启后能安全恢复订单组合。目标是具有明确订单归属、经过验证的运行状态，而不是看起来一样的桌面。恢复可以减少运行中断，但不能消除市场风险或保证执行结果。

首次响应：避免扩大事故

1. 记录事故。 记录发现时间及时区、受影响的账户与服务器及终端、最后确认正常的行为，以及近期变更。告警缺失或 RDP 会话丢失是症状，不是诊断。
2. 检查账户风险敞口。 使用获授权的经纪商账户视图，或不含 EA、或 EA 无法交易的独立观察终端。确认当前持仓、挂单及已接受的保护价位；账户状态不明确时，请经纪商协助。
3. 识别所有交易副本。 包括主 VPS、家用电脑、备用终端、集成托管及交易复制服务。不要仅因无法访问主实例就启动另一个自动交易副本。
4. 选择有边界的干预措施。 保留证据、识别故障层级，并遵循已有的事故处理计划。重启或关闭前，先明确依赖本地 EA 管理的持仓由谁负责。

在普通 MT4 中，禁用 AutoTrading 会阻止该终端内 EA 的交易操作；不会平仓、删除经纪商订单或停止其他主机。它也可能中断 EA 管理的退出。因此，重启是会影响账户的运行决策，并非无害的诊断按钮。

重新安装之前，先定位故障

具体设置和订单错误请参阅 EA 错误指南。此决策表用于识别受影响的层级，并不保证某种症状只有一个原因。

EA 已挂载，仍可能无法管理订单

确认目标品种与周期、EA 版本、获准的 Inputs 及初始化成功。检查账户与许可要求，不要用猜测数值替代。即使报价继续到达，配置文件变化、自定义指标缺失，或 DLL/WebRequest 依赖项问题，也可能改变程序行为。

• 区分终端或 EA 权限错误与经纪商或账户限制。代码 133 表示交易被禁用；它并不指明应该点击哪个本地按钮。
• 代码 6 表示没有交易服务器连接；代码 146 表示交易上下文忙碌。调查实际消息和周围事件，不要反复重启或发送请求。
• 出现代码 128或任何丢失或不确定的交易响应时，重试前先核对服务器结果。缺少本地确认，不能证明经纪商拒绝了请求。

不要通过移除点差、时段、持仓或风险过滤条件来强制产生诊断交易。如果 EA 没有有效信号，成功恢复后也可能没有新持仓。现有订单管理和新鲜数据，比强制入场更适合作为验收证据。

恢复自动交易之前，先核对经纪商订单

在已连接的观察环境中，通过 Trade 检查持仓与挂单。通过 Account History 检查事故期间的操作；选择实际覆盖事故的日期范围。如果记录不一致或访问不完整，应先请经纪商澄清，再将重建视为完整。

• 将订单编号、准确品种、方向、交易量、入场时间及已接受的 Stop Loss/Take Profit 与事故记录匹配。终端停止不会删除经纪商端订单；故障期间挂单可能触发。
• 按 EA 文档规定的品种和 Magic Number 规则确认管理者。不要更改识别码，让旧订单从 EA 的视野中消失。
• 检查终端不可用期间，订单是否平仓或变化。不要仅因备份或日志中有一笔旧持仓，就重新创建它。
• 确认该 EA 如何重建订单组合、移动止损逻辑、虚拟退出或其他状态。如果不支持重建或情况不明确，启用前应遵循供应商恢复流程。

已接受的经纪商端 Stop Loss/Take Profit 价位仍留在服务器端。MT4 Trailing Stop 调整及 EA 虚拟退出需要负责管理的终端或 EA 运行；最后被接受的服务器端止损，不等于本地调整仍在继续。保护价位不保证执行价格，尤其在跳空或经纪商中断时。

保留解释故障所需的证据

清空视图、还原快照或重新安装前，保留相关的 Experts 与 Journal 记录。终端能响应时，使用各标签页的 Open 命令找到日志，并将当前记录写入磁盘。EA 日志通常位于 MQL4/Logs，终端日志位于 logs，均在实际数据文件夹内。

记录终端身份、错误文本或代码、受影响订单编号、最后成功初始化、连接变化，以及近期 Windows 或 EA 变更。记录各来源使用的时钟与时区；推断事件顺序前，先统一 Windows、终端和经纪商时间戳。请参阅 Experts 与 Journal 日志指南。

只向支持人员发送调查所需的相关片段和配置，并删除凭据及无关账户信息。服务商可能需要虚拟机事件，经纪商可能需要订单和服务器详情，EA 开发者可能需要初始化或状态错误。先反复重启，可能使原始故障与恢复副作用难以区分。

创建包含依赖项的恢复包

为每个预定终端记录安装路径和 Windows 用户，再使用 File → Open Data Folder 定位其实际数据。将清单与备份一起保留；快捷方式或带经纪商品牌的文件夹名称，不能可靠地标明位置。

重新连接后，应核对实际经纪商订单记录；它不是从此恢复包还原的。安全保留配置和证据，不要将恢复凭据放入公开检查清单或支持上传文件。

按各自用途使用参数预设、模板和配置文件

在 EA 的 Inputs 标签页中， Save 保存受支持的外部参数， Load 应用已保存的预设。记录对应 EA 版本：替代版本中参数更名或默认值变化，可能改变结果。应验证加载的数值，不要仅因文件名熟悉就接受。

.tpl 模板保存图表设置，也可以包含已挂载的 EA 及其参数；配置文件描述一组图表。两者都不能代替对应的可执行文件、依赖项或供应商专有状态。工作区变化时，配置文件也会保存，因此意外修改可能成为当前配置文件的一部分。

• 为已确认有效的参数预设、模板及配置文件记录，使用带日期或版本的名称。
• 另行记录准确品种、周期及预定订单管理规则。
• 只在受控环境中应用还原的图表，确保完成验证前自动交易无法启动。还原的设置可能带有您无意启用的权限。

确认哪些状态能在重启后保留，哪些需要重建

EA 可能从经纪商订单推导状态、写入本地或共享文件、使用终端全局变量，或只把信息保存在内存中。向开发者确认哪些状态必要、如何持久保存，以及恢复时如何处理备份后新开的订单。不要假设所有 EA 行为相同。

终端全局变量不同于 EA 代码中的变量。持久终端全局变量可以在重启后保留，但如果连续 4 周 未被访问，就会过期；临时全局变量仅在当前终端会话中存在。因此，全局变量列表或复制的参数预设并不是通用 EA 备份。应按明确的文档流程保留，并结合当前订单验证状态是否仍然有效。

旧的本地状态可能与新的经纪商记录不一致。不要将实盘账户的订单组合状态文件移植到模拟账户，不要删除状态来“重置”现有交易，也不要在缺少供应商规定映射的情况下修改 Magic Number。如果 EA 无法安全重建管理，应保持自动交易禁用并解决不一致。

在故障 VPS 之外保存可恢复版本

保留带日期的获准配置版本，并在主 VPS 之外保存受保护副本。同一虚拟机上的 ZIP 可能与虚拟机一起丢失。服务商快照是另一种恢复工具，但需确认保留期限、范围、一致性和可用性；它不是独立的经纪商账户备份。

• 获准的配置、版本或依赖项变化后进行备份，并根据 EA 可以承受多少不可恢复变化，安排状态备份。
• 采用经过测试且一致的采集方式。在 EA 写入文件时复制，可能得到版本不匹配的文件。任何必要暂停或有序关闭，都应与持仓管理协调；不要仅为方便复制而中断实盘管理程序。
• 检查压缩包能否打开、所需文件是否齐全，以及恢复演练是否成功。保护访问权限，并保留较早的可用版本，避免损坏或意外变更覆盖全部副本。

校验和可以发现相对于可信参考的意外字节变化，但不能证明 EA 状态是最新的或逻辑一致。备份成功意味着可恢复，而不仅是计划任务报告已完成。

分别定义停机时间与状态丢失目标

恢复时间目标（RTO）是恢复预定服务前，计划容忍的停机时间。恢复点目标（RPO）是计划容忍丢失的历史状态变化量。根据 EA 的实际管理需求选择，再测试流程及备份频率是否支持这些目标。

这些是假设时间，并非测得的恢复结果或承诺的 RTO。其中， 20 分钟 涉及可能缺失的本地状态变化；经纪商已接受的订单仍需从其当前记录核对。而 12 分钟 涉及停机时间。即使备份政策满足时间间隔要求，如果 EA 无法将状态与账户核对一致，恢复仍可能失败。

在受控环境中还原

1. 确认源副本无法交易。 通过经验证的控制措施停止或隔离它，并防止自动重新启用。如果它只是无法访问，应先解决这一不确定性，再启动替代自动交易程序。
2. 准备干净的观察或暂存终端。 使用经纪商指定的 MT4 及正确 Windows 用户。引入还原的 EA 配置文件或设置之前，先确保自动交易已禁用。初步验证时，不提供实盘凭据，或使用受支持的只读观察登录；确认其实际访问限制。
3. 定位新的数据文件夹。 使用 File → Open Data Folder。保持原备份完整，只还原所选、文档规定的文件，不要盲目覆盖整个新配置。
4. 还原获准的程序与输入参数。 验证版本、准确品种与周期、依赖项和许可。保持自动交易禁用；旧设置文件不能悄悄覆盖已验证的权限控制。
5. 验证状态与订单。 按文档流程，将持久状态与当前经纪商持仓、挂单及事故期间历史进行比较。恢复管理前，解决差异。
6. 完成验收检查。 验证所需数据、初始化、权限、归属、日志、告警及启动环境。提前在模拟环境验证流程；不要把实盘账户状态复制到演练账户。
7. 授权一个预定交易副本。 遵循文档规定的移交流程，并确认旧副本仍无法交易。建立预定的获授权交易登录，重新检查账户变化保护及最终权限，只启用已验证的替代实例。观察现有订单管理，记录时间与结果。

如果无法确认关键状态、订单归属、经纪商访问或源实例关闭，流程就尚未完成。保持替代自动交易程序禁用，并针对具体未解决问题升级处理；仅有运行中的 terminal.exe 或漂亮的还原图表，仍然不足。

准备备用实例，但不要创建第二个活动管理者

如果配置、依赖项和访问方式已测试，备用 VPS 可以减少准备工作。在移交条件满足前，保持它无法交易。同一经纪商账户上的第二台 VPS，并不能锁住重复订单。

• 记录主实例、备用实例及其他主机，以及如何停止每个实例并防止自动重启。
• 确认主实例已停止，或已有效隔离交易。服务商确认的电源控制或经验证的停止，比单纯 RDP 失败或心跳缺失提供更强证据。
• 核对经纪商订单与 EA 状态，再完成替代实例检查，之后才启用。当主实例恢复时，保留一个活动管理者；不要让两套启动流程都重新启用交易。

更换 VPS 不能修复不可用的经纪商服务器，也不能保证大范围故障期间仍能访问。如果主实例交易状态仍然未知，不要将未经验证的故障切换视为安全。解决状态问题时，遵循账户事故管理计划。

使用 MetaTrader 虚拟托管的正确控制功能

MetaTrader 集成托管不是 Windows VPS 桌面。使用远程状态及请求获取的终端和 Experts 日志进行调查。 Stop Server 会停止虚拟终端；在其他位置启用替代实例前，确认其报告为已停止。本地的 AutoTrading 开关不会停止托管 EA。

迁移方向是从本地环境到虚拟终端，不能反向导出用于恢复。即使本地交易权限关闭，托管环境仍允许自动交易。因此，不要迁移一个已准备但被禁用的实盘恢复副本，并期待它在远端也保持禁用。同步前应验证目标环境和账户背景；该环境不支持 DLL 调用。

演练流程，并记录验收

使用独立且获授权的模拟部署，演练终端关闭、操作系统重启、依赖项缺失、从保存的恢复包还原，以及受控的主实例向备用实例移交。区分模拟与实盘账户、许可及状态文件。记录实际测试内容、局限和结果；桌面演练不能确认未来实盘执行。

事故后，记录原因、恢复操作、已核对的差异，以及下一次演练的改进。请使用 指南 2 修正资源或启动问题，不要通过改变策略风险规则来掩盖技术问题。

备份与恢复常见问题

还原 VPS 快照，会还原我的交易账户吗？

不会。它仅在服务商文档规定的范围内还原快照中的本地环境。经纪商交易仍以当前经纪商记录为准。必须将旧的本地 EA 状态与这些记录核对。

一个 .set 文件足以备份 EA 吗？

不够。它保存受支持的外部输入参数。还应保留对应程序版本、所需指标与文件、许可信息及 EA 文档规定的状态恢复流程。

远程桌面连接失败时，可以启动备用 VPS 吗？

可以调查并准备，但应让自动交易无法运行。在主实例交易能力及现有订单归属明确之前，不要启用替代实例。远程访问丢失不能证明主实例已停止。

交易请求超时后，应重新发送吗？

先检查服务器结果。核对持仓、挂单、相关历史及日志；结果仍不明确时，请经纪商协助。盲目重复可能复制已经被接受的请求。

官方参考资料与适用范围

平台行为已依据 MetaQuotes 官方文档核对。事故流程、备份政策、备用实例控制及验收检查属于实用建议，并不是经过测试的通用 MT4 恢复工具。界面名称可能因终端语言或版本而异；请确认实际标签及 EA 供应商说明。

• MetaTrader 4： 数据文件夹， 模板与配置文件，以及 EA 输入参数与权限。
• MetaTrader 4： 经纪商端订单 与 终端移动止损。
• MQL4 参考： 交易返回代码 与 终端全局变量。
• MetaTrader 4： 远程托管控制 与 迁移规则。