MT4 and VPS Failures: Backup and Safe Recovery

Recover the trading environment, not an old account snapshot

The main procedure is for an ordinary Windows VPS running MT4. Integrated MetaTrader virtual hosting has different controls; its separate section below explains the distinction. Keep the broker account, local terminal configuration and EA runtime state separate in your plan.

A restored folder cannot undo transactions already processed by the broker. Nor does a saved chart prove that its EA can safely resume a basket after a restart. The goal is a verified operating state with known order ownership, not an identical-looking desktop. Recovery reduces operational disruption; it cannot remove market risk or guarantee execution.

First response: avoid making the incident larger

1. Record the incident. Note the detection time and time zone, affected account/server and terminal, last confirmed normal behavior and recent changes. A missing alert or lost RDP session is a symptom, not a diagnosis.
2. Check account exposure. Use an authorized broker account view or a separate observation terminal with EAs absent or unable to trade. Confirm current positions, pending orders and accepted protection levels; involve the broker if the account state is unclear.
3. Identify every trading copy. Include the primary VPS, a home computer, standby terminals, integrated hosting and trade-copying services. Do not start another automated copy just because the primary cannot be reached.
4. Choose a bounded intervention. Preserve evidence, identify the failed layer and follow the documented incident plan. Decide responsibility for positions that depend on local EA management before a restart or shutdown.

In ordinary MT4, disabling AutoTrading blocks EA trade operations in that terminal; it does not close positions, remove broker orders or stop another host. It can also interrupt EA-managed exits. A restart is therefore an operating decision with account consequences, not a harmless diagnostic button.

Locate the failure before reinstalling anything

For individual settings and order errors, use the EA error guide. This decision table identifies the affected layer; it is not a promise that a particular symptom has only one cause.

An attached EA can still be unable to manage orders

Confirm the intended symbol and timeframe, EA version, approved Inputs and successful initialization. Check account and license requirements without replacing them with guessed values. A profile change, a missing custom indicator or a DLL/WebRequest dependency can change behavior even while quotes continue.

• Separate terminal or EA permission errors from broker/account restrictions. Code 133 means trading is disabled; it does not identify which local button to press.
• Code 6 indicates no trade-server connection; code 146 indicates a busy trade context. Investigate the actual message and surrounding events rather than repeatedly restarting or sending requests.
• With code 128, or any lost/uncertain trade response, reconcile the server result before retrying. Missing local confirmation is not proof that the broker rejected the request.

Do not remove spread, session, position or risk filters to force a diagnostic trade. If the EA has no valid signal, successful recovery may produce no new position. Existing-order management and fresh data are more useful acceptance evidence than forcing an entry.

Reconcile broker orders before resuming automation

In a connected observation environment, inspect Trade for open positions and pending orders. Inspect Account History for operations during the incident; choose a date range that actually covers it. If records disagree or access is incomplete, ask the broker to clarify before treating the reconstruction as complete.

• Match ticket, exact symbol, direction, volume, entry time and accepted Stop Loss/Take Profit with the incident record. A stopped terminal does not erase broker-held orders; pending orders may trigger during the outage.
• Identify the management owner using the EA’s documented symbol and Magic Number rules. Do not change identifiers to make an old order disappear from the EA’s view.
• Check whether orders closed or changed while the terminal was unavailable. Do not recreate an old position merely because it appears in a backup or log.
• Confirm how this EA reconstructs its basket, trailing logic, virtual exits or other state. Where reconstruction is unsupported or uncertain, use the vendor’s recovery procedure before enabling it.

Accepted broker-side Stop Loss/Take Profit levels remain server-side. MT4 Trailing Stop adjustments and EA virtual exits require their managing terminal/EA to operate; the last accepted server stop is distinct from continuing local adjustment. Protection levels do not guarantee an execution price, especially through gaps or broker disruptions.

Preserve the evidence needed to explain the failure

Keep relevant Experts and Journal entries before clearing views, restoring a snapshot or reinstalling. When the terminal responds, use each tab’s Open command to find and flush its logs. EA logs normally reside in MQL4/Logs, terminal logs in logs, under the actual data folder.

Capture the terminal identity, error text/code, affected order tickets, last successful initialization, connection changes and recent Windows or EA changes. Record the clock/time zone used by each source; align Windows, terminal and broker timestamps before inferring event order. See the Experts and Journal guide.

Send support only the relevant excerpt and configuration needed to investigate, with credentials and unrelated account information removed. A provider may need VM events, a broker order/server details, and an EA developer initialization or state errors. Repeatedly relaunching first can erase the distinction between the original failure and recovery side effects.

Build a recovery package that includes dependencies

For every intended terminal, record its installation path and Windows user, then use File → Open Data Folder to locate its real data. Preserve an inventory alongside the backup; a shortcut or broker-branded folder name is not a reliable map.

The actual broker order record is reconciled after reconnecting; it is not restored from this package. Retain configuration and evidence securely, keeping recovery credentials outside public checklists or support uploads.

Use presets, templates and profiles for their own roles

In the EA’s Inputs tab, Save preserves supported external parameters and Load applies a saved preset. Record the corresponding EA version: renamed inputs or different defaults in a replacement version may change the result. Verify loaded values rather than accepting a familiar filename.

A .tpl template stores chart settings and can include an attached EA with parameters; a profile describes a group of charts. Neither is a substitute for the corresponding executables, dependencies or vendor-specific state. Profile changes are saved as the workspace changes, so an accidental change can become the current profile too.

• Give known-good presets, templates and profile records dated/versioned names.
• Keep a separate record of exact symbols, timeframes and the intended order-management rules.
• Apply restored charts only in a controlled environment with automated trading unable to start until verification. Restored settings can carry permissions you did not intend to enable.

Ask what survives a restart and what must be rebuilt

An EA may derive state from broker orders, write local or shared files, use terminal global variables, or keep information only in memory. Ask the developer which state is essential, how it is persisted and how recovery handles orders opened after the backup. Never assume all EAs behave the same way.

Terminal global variables differ from variables inside EA code. Persistent terminal globals can survive restarts, but expire after 4 weeks without access; temporary globals exist only for the current terminal session. A global-variable list or copied preset is therefore not a universal EA backup. Preserve only through a documented procedure and verify freshness against current orders.

Old local state may disagree with new broker records. Do not transplant a live account’s basket-state files into a demo account, delete state to “reset” existing trades, or change Magic Numbers without the vendor’s documented mapping. If the EA cannot reconstruct management safely, leave automation disabled and resolve the mismatch.

Keep recoverable versions outside the failed VPS

Keep dated versions of the approved configuration and a protected copy outside the primary VPS. A ZIP on the same VM can be lost with that VM. A provider snapshot is another recovery tool, but its retention, scope, consistency and availability must be confirmed; it is not an independent broker-account backup.

• Back up after approved configuration, version or dependency changes, and schedule state backups according to how much unrecoverable change the EA can tolerate.
• Use a tested, consistent capture method. Copying files while the EA writes them may collect mismatched versions. Coordinate any required pause or orderly shutdown with position management; do not interrupt a live manager merely to make copying easier.
• Check that archives can be opened, required files are present and a restoration rehearsal succeeds. Protect access and retain earlier usable versions so corruption or an accidental change does not overwrite every copy.

A checksum can detect an unexpected byte change against a trusted reference; it does not prove the EA state is current or logically consistent. Backup success means recoverability, not merely that a scheduled job reported completion.

Set separate objectives for downtime and lost state

The recovery time objective (RTO) is the downtime you aim to tolerate before restoring the intended service. The recovery point objective (RPO) is the amount of historical state change you aim to tolerate losing. Choose them for the EA’s actual management needs, then test whether the procedure and backup frequency support them.

These are hypothetical times, not a measured recovery result or a promised RTO. The 20 minutes concern potentially missing local-state changes; orders accepted by the broker are still checked from its current records. The 12 minutes concern downtime. A backup policy that meets a time interval can still fail if the EA cannot reconcile that state with the account.

Restore into a controlled environment

1. Confirm the source copy cannot trade. Stop or isolate it through a verified control and prevent automatic reactivation. If it is merely unreachable, resolve that uncertainty before starting replacement automation.
2. Prepare a clean observation/staging terminal. Use the broker’s intended MT4 and correct Windows user. Establish disabled automated trading before introducing restored EA profiles or settings. During initial verification, keep live credentials absent or use a supported read-only observation login; confirm its actual access restrictions.
3. Locate the new data folder. Use File → Open Data Folder. Keep the original backup intact and restore the selected, documented files rather than overwriting the entire new configuration blindly.
4. Restore approved programs and inputs. Verify versions, exact symbols/timeframes, dependencies and licensing. Keep automation disabled; an old settings file must not silently replace the verified permission controls.
5. Validate state and orders. Use the documented procedure to compare persistent state with current broker positions, pending orders and incident-period history. Resolve discrepancies before resuming management.
6. Complete acceptance checks. Verify required data, initialization, permissions, ownership, logs, alerts and the startup context. Validate the procedure on demo in advance; do not copy live-account state into the rehearsal account.
7. Authorize one intended trading copy. Follow the documented handover and confirm the old copy remains unable to trade. Establish the intended authorized trading login, recheck account-change protection and the final permissions, and enable only the verified replacement. Observe existing-order management and record the time and result.

If critical state, order ownership, broker access or source shutdown cannot be confirmed, the procedure is incomplete. Keep replacement automation disabled and escalate the specific unresolved issue; a running terminal.exe or an attractive restored chart is insufficient.

Prepare a standby without creating a second active manager

A standby VPS can reduce preparation work when its configuration, dependencies and access have already been tested. Keep it unable to trade until the handover conditions are satisfied. A second VPS on the same broker account is not a lock against duplicate orders.

• Record the primary, standby and any other host, plus how each is stopped and prevented from automatically restarting.
• Confirm the primary is stopped or effectively isolated from trading. Provider-confirmed power controls or a verified stop are stronger evidence than failed RDP or missing heartbeat alone.
• Reconcile broker orders and EA state, then complete the replacement checks before enabling it. When the primary returns, retain one active owner; do not allow both startup procedures to re-enable trading.

Changing a VPS cannot repair an unavailable broker server or guarantee access during a wider outage. If the primary’s trading status remains unknown, do not treat an unverified failover as safe. Follow the account’s incident-management plan while resolving that status.

Use the correct controls for MetaTrader virtual hosting

Integrated MetaTrader hosting is not a Windows VPS desktop. Use its remote status and requested terminal/Experts journals to investigate. Stop Server stops the virtual terminal; confirm its reported stopped state before enabling a replacement elsewhere. A local AutoTrading toggle does not stop the hosted EA.

Migration goes from the local environment to the virtual terminal, not back as a recovery export. Hosted automated trading is allowed even when local trading permissions were disabled. Therefore do not migrate a prepared-but-disabled live recovery copy expecting it to remain disabled remotely. Validate the intended environment and account context before synchronization; DLL calls are not supported there.

Rehearse the procedure and record acceptance

Use a separate authorized demo setup to rehearse terminal closure, OS restart, missing dependency, restoration from a saved package and a controlled primary-to-standby handover. Keep demo and live accounts, licenses and state files distinct. Record what was actually tested, the limitations and the result; a desktop rehearsal does not establish future live execution.

After the incident, document its cause, recovery actions, reconciled discrepancies and improvements to the next rehearsal. Use Guide 2 to correct resource or startup weaknesses without changing the strategy’s risk rules to hide the technical problem.

Common backup and recovery questions

Does restoring a VPS snapshot restore my trading account?

No. It restores the snapshot’s local environment within the provider’s documented scope. Broker transactions continue to be established from current broker records. Old local EA state must be reconciled with them.

Is a .set file enough to back up an EA?

No. It preserves supported external inputs. Keep the corresponding program version, required indicators/files, licensing information and the EA’s documented state-recovery procedure too.

Can I start a spare VPS when Remote Desktop fails?

You can investigate and prepare it with automation unable to trade. Do not enable the replacement until the primary’s trading ability and existing-order ownership have been resolved. Lost remote access does not prove the primary stopped.

Should I resend a trade request after a timeout?

Not before checking the server result. Reconcile open and pending orders, relevant history and logs, and involve the broker if the result is still unclear. Blind repetition can duplicate a request already accepted.

Official references and practical scope

Platform behavior was checked against official MetaQuotes documentation. The incident workflow, backup policy, standby controls and acceptance checks are practical recommendations, not a tested universal MT4 recovery tool. UI names can vary with terminal language or edition; confirm the actual labels and the EA vendor’s instructions.

• MetaTrader 4: data folders, templates and profiles, and EA inputs and permissions.
• MetaTrader 4: broker-held orders and terminal Trailing Stop.
• MQL4 Reference: trade return codes and terminal global variables.
• MetaTrader 4: remote hosting controls and migration rules.