Pannes MT4 et VPS : sauvegarde et reprise en sécurité

Restaurer l’environnement de trading, pas un ancien état du compte

La procédure principale concerne un VPS Windows classique exécutant MT4. L’hébergement virtuel intégré de MetaTrader utilise d’autres commandes ; une section dédiée ci-dessous explique cette différence. Distinguez dans votre plan le compte chez le courtier, la configuration locale du terminal et l’état de fonctionnement de l’EA.

Restaurer un dossier ne peut pas annuler les transactions déjà traitées par le courtier. Un graphique sauvegardé ne prouve pas non plus que son EA peut reprendre sans risque la gestion d’un panier après redémarrage. L’objectif est un état de fonctionnement vérifié, avec une responsabilité claire pour chaque ordre, et non un bureau visuellement identique. La reprise réduit la perturbation opérationnelle ; elle ne supprime pas le risque de marché et ne garantit pas l’exécution.

Premières mesures : ne pas aggraver l’incident

1. Consignez l’incident. Notez l’heure de détection et le fuseau horaire, le compte/serveur et le terminal concernés, le dernier fonctionnement normal confirmé et les changements récents. Une alerte manquante ou une session RDP perdue est un symptôme, pas un diagnostic.
2. Vérifiez l’exposition du compte. Utilisez une vue autorisée du compte chez le courtier ou un terminal d’observation distinct, sans EA ou avec des EA incapables de trader. Confirmez les positions, les ordres en attente et les niveaux de protection acceptés ; contactez le courtier si l’état du compte reste incertain.
3. Identifiez toutes les instances de trading. Incluez le VPS principal, l’ordinateur personnel, les terminaux de secours, l’hébergement intégré et les services de copie de trades. Ne démarrez pas une autre instance automatisée simplement parce que la principale est inaccessible.
4. Choisissez une intervention limitée. Conservez les éléments de preuve, identifiez la couche défaillante et suivez le plan d’incident documenté. Avant un redémarrage ou un arrêt, définissez qui gère les positions dépendant de l’EA local.

Dans MT4 classique, désactiver AutoTrading bloque les opérations de trading des EA de ce terminal ; cela ne clôture pas les positions, ne supprime pas les ordres chez le courtier et n’arrête pas un autre hôte. Cela peut aussi interrompre les sorties gérées par l’EA. Un redémarrage est donc une décision opérationnelle avec des conséquences sur le compte, pas un simple bouton de diagnostic.

Localiser la panne avant toute réinstallation

Pour les paramètres précis et les erreurs d’ordre, consultez le guide des erreurs d’EA. Ce tableau identifie la couche concernée ; il ne garantit pas qu’un symptôme donné n’a qu’une seule cause.

Un EA attaché peut rester incapable de gérer les ordres

Confirmez le symbole et l’unité de temps prévus, la version de l’EA, les Inputs approuvés et la réussite de l’initialisation. Vérifiez les exigences du compte et de la licence sans les remplacer par des valeurs supposées. Un changement de profil, un indicateur personnalisé manquant ou une dépendance DLL/WebRequest peut modifier le comportement même si les cotations continuent.

• Distinguez les erreurs d’autorisation du terminal ou de l’EA des restrictions du courtier/compte. Le code 133 signifie que le trading est désactivé ; il ne désigne pas le bouton local à utiliser.
• Le code 6 indique l’absence de connexion au serveur de trading ; le code 146 indique un contexte de trading occupé. Analysez le message réel et les événements voisins au lieu de répéter les redémarrages ou les demandes.
• Avec le code 128, ou toute réponse de trading perdue ou incertaine, vérifiez le résultat côté serveur avant de réessayer. L’absence de confirmation locale ne prouve pas que le courtier a rejeté la demande.

Ne retirez pas les filtres de spread, de session, de position ou de risque pour forcer un trade de diagnostic. Si l’EA n’a aucun signal valide, une reprise réussie peut ne produire aucune nouvelle position. La gestion des ordres existants et des données à jour constituent de meilleurs critères de validation qu’une entrée forcée.

Vérifier les ordres chez le courtier avant de reprendre l’automatisation

Dans un environnement d’observation connecté, consultez Trade pour les positions ouvertes et les ordres en attente. Consultez Account History pour les opérations pendant l’incident ; choisissez une plage de dates qui le couvre réellement. Si les données divergent ou si l’accès est incomplet, demandez au courtier une clarification avant de considérer la reconstitution comme terminée.

• Comparez ticket, symbole exact, sens, volume, heure d’entrée et Stop Loss/Take Profit acceptés avec le relevé de l’incident. Un terminal arrêté n’efface pas les ordres conservés chez le courtier ; les ordres en attente peuvent se déclencher pendant la panne.
• Identifiez le responsable de la gestion selon les règles de symbole et de Magic Number documentées par l’EA. Ne modifiez pas les identifiants pour faire disparaître un ancien ordre de la vue de l’EA.
• Vérifiez si des ordres ont été clôturés ou modifiés pendant l’indisponibilité du terminal. Ne recréez pas une ancienne position simplement parce qu’elle figure dans une sauvegarde ou un journal.
• Confirmez comment cet EA reconstitue son panier, sa logique de suivi, ses sorties virtuelles ou tout autre état. Si cette reconstitution n’est pas prise en charge ou reste incertaine, suivez la procédure du fournisseur avant de l’activer.

Les niveaux Stop Loss/Take Profit acceptés par le courtier restent côté serveur. Les ajustements du Trailing Stop de MT4 et les sorties virtuelles de l’EA nécessitent le fonctionnement du terminal/EA qui les gère ; le dernier stop accepté par le serveur est distinct des ajustements locaux ultérieurs. Les niveaux de protection ne garantissent pas un prix d’exécution, notamment lors de gaps ou d’interruptions chez le courtier.

Conserver les éléments nécessaires pour expliquer la panne

Conservez les entrées pertinentes d’Experts et de Journal avant de vider les vues, de restaurer un instantané ou de réinstaller. Si le terminal répond, utilisez la commande Open de chaque onglet pour retrouver les journaux et vider leur tampon sur disque. Les journaux des EA se trouvent normalement dans MQL4/Logs, ceux du terminal dans logs, sous le véritable dossier de données.

Relevez l’identité du terminal, le texte/code d’erreur, les tickets concernés, la dernière initialisation réussie, les changements de connexion et les changements récents de Windows ou de l’EA. Notez l’horloge et le fuseau de chaque source ; rapprochez les horodatages Windows, du terminal et du courtier avant de déduire l’ordre des événements. Consultez le guide Experts et Journal.

N’envoyez au support que l’extrait pertinent et la configuration nécessaire à l’analyse, sans identifiants secrets ni informations de compte sans rapport. Le fournisseur peut avoir besoin des événements de la VM, le courtier des détails d’ordre/serveur et le développeur de l’EA des erreurs d’initialisation ou d’état. Relancer à répétition avant d’enquêter peut brouiller la distinction entre la panne initiale et les effets de la reprise.

Préparer une sauvegarde de reprise avec les dépendances

Pour chaque terminal prévu, notez son chemin d’installation et son utilisateur Windows, puis utilisez File → Open Data Folder pour localiser ses données réelles. Conservez un inventaire avec la sauvegarde ; un raccourci ou un nom de dossier portant la marque du courtier n’est pas une cartographie fiable.

Le registre réel des ordres du courtier est vérifié après reconnexion ; il n’est pas restauré depuis cette sauvegarde. Conservez configuration et preuves en sécurité, et gardez les identifiants de reprise hors des listes publiques ou des envois au support.

Respecter le rôle des préréglages, modèles et profils

Dans l’onglet Inputs de l’EA, Save conserve les paramètres externes pris en charge et Load applique un préréglage sauvegardé. Notez la version correspondante de l’EA : des paramètres renommés ou d’autres valeurs par défaut dans une version de remplacement peuvent modifier le résultat. Vérifiez les valeurs chargées au lieu de vous fier à un nom de fichier familier.

Un modèle .tpl conserve les paramètres du graphique et peut inclure un EA attaché avec ses paramètres ; un profil décrit un groupe de graphiques. Aucun ne remplace les exécutables correspondants, les dépendances ou l’état propre au fournisseur. Les modifications du profil sont enregistrées à mesure que l’espace de travail change ; une modification accidentelle peut donc aussi devenir le profil courant.

• Donnez aux préréglages, modèles et relevés de profils validés des noms datés et versionnés.
• Conservez séparément les symboles exacts, unités de temps et règles prévues de gestion des ordres.
• Appliquez les graphiques restaurés uniquement dans un environnement contrôlé où le trading automatique ne peut pas démarrer avant vérification. Les paramètres restaurés peuvent contenir des autorisations que vous ne souhaitiez pas activer.

Déterminer ce qui survit au redémarrage et ce qui doit être reconstruit

Un EA peut déduire son état des ordres du courtier, écrire des fichiers locaux ou partagés, utiliser des variables globales du terminal ou garder des informations uniquement en mémoire. Demandez au développeur quel état est essentiel, comment il est conservé et comment la reprise traite les ordres ouverts après la sauvegarde. Ne supposez jamais que tous les EA fonctionnent de la même manière.

Les variables globales du terminal diffèrent des variables du code de l’EA. Les variables globales persistantes peuvent survivre aux redémarrages, mais expirent après 4 semaines sans accès ; les variables temporaires n’existent que pour la session courante du terminal. Une liste de variables globales ou un préréglage copié n’est donc pas une sauvegarde universelle d’EA. Utilisez une procédure documentée et vérifiez que l’état est à jour par rapport aux ordres actuels.

Un ancien état local peut contredire les nouvelles données du courtier. Ne transférez pas les fichiers d’état d’un panier réel vers un compte démo, ne supprimez pas l’état pour « réinitialiser » des trades existants et ne modifiez pas les Magic Numbers sans la correspondance documentée du fournisseur. Si l’EA ne peut pas reconstruire sa gestion de façon sûre, laissez l’automatisation désactivée et résolvez l’écart.

Conserver des versions restaurables hors du VPS défaillant

Conservez des versions datées de la configuration approuvée et une copie protégée hors du VPS principal. Un ZIP sur la même VM peut disparaître avec elle. Un instantané du fournisseur est un autre outil de reprise, mais sa durée de conservation, son périmètre, sa cohérence et sa disponibilité doivent être confirmés ; ce n’est pas une sauvegarde indépendante du compte chez le courtier.

• Sauvegardez après les changements approuvés de configuration, de version ou de dépendances, et planifiez les sauvegardes d’état selon la quantité de changements irrécupérables que l’EA peut tolérer.
• Utilisez une méthode de capture cohérente et testée. Copier des fichiers pendant que l’EA y écrit peut réunir des versions incompatibles. Coordonnez toute pause ou fermeture ordonnée requise avec la gestion des positions ; n’interrompez pas un gestionnaire actif uniquement pour faciliter la copie.
• Vérifiez que les archives s’ouvrent, que les fichiers requis sont présents et qu’un exercice de restauration réussit. Protégez l’accès et gardez des versions antérieures utilisables pour qu’une corruption ou une erreur ne remplace pas toutes les copies.

Une somme de contrôle peut détecter une modification inattendue des octets par rapport à une référence fiable ; elle ne prouve pas que l’état de l’EA est actuel ou logiquement cohérent. Une sauvegarde réussie se mesure à sa restaurabilité, pas simplement au statut de fin d’une tâche planifiée.

Fixer des objectifs distincts pour l’interruption et la perte d’état

L’objectif de temps de reprise (RTO) est la durée d’interruption que vous visez à tolérer avant le rétablissement du service prévu. L’objectif de point de reprise (RPO) est la quantité de changements d’état passés dont vous jugez la perte acceptable. Choisissez-les selon les besoins réels de gestion de l’EA, puis testez si la procédure et la fréquence des sauvegardes permettent de les respecter.

Ces horaires sont hypothétiques, pas une mesure de reprise ni une promesse de RTO. Les 20 minutes concernent les changements d’état local potentiellement manquants ; les ordres acceptés par le courtier restent vérifiés dans ses données actuelles. Les 12 minutes concernent l’interruption. Une politique de sauvegarde respectant un intervalle peut encore échouer si l’EA ne peut pas rapprocher cet état du compte.

Restaurer dans un environnement contrôlé

1. Confirmez que l’instance source ne peut plus trader. Arrêtez-la ou isolez-la à l’aide d’un contrôle vérifié et empêchez sa réactivation automatique. Si elle est simplement inaccessible, levez cette incertitude avant de lancer l’automatisation de remplacement.
2. Préparez un terminal propre d’observation ou de préparation. Utilisez le MT4 prévu par le courtier et le bon utilisateur Windows. Désactivez le trading automatique avant d’introduire des profils ou paramètres d’EA restaurés. Pendant la vérification initiale, n’ajoutez pas d’identifiants de compte réel ou utilisez une connexion d’observation en lecture seule prise en charge ; confirmez ses restrictions effectives.
3. Localisez le nouveau dossier de données. Utilisez File → Open Data Folder. Gardez la sauvegarde d’origine intacte et restaurez les fichiers sélectionnés et documentés plutôt que d’écraser aveuglément toute la nouvelle configuration.
4. Restaurez les programmes et paramètres approuvés. Vérifiez versions, symboles/unités de temps exacts, dépendances et licence. Gardez l’automatisation désactivée ; un ancien fichier de paramètres ne doit pas remplacer silencieusement les contrôles d’autorisation vérifiés.
5. Validez l’état et les ordres. Suivez la procédure documentée pour comparer l’état persistant avec les positions actuelles chez le courtier, les ordres en attente et l’historique de l’incident. Résolvez les écarts avant de reprendre la gestion.
6. Terminez les contrôles d’acceptation. Vérifiez données requises, initialisation, autorisations, responsabilité des ordres, journaux, alertes et contexte de démarrage. Validez la procédure à l’avance sur démo ; ne copiez pas l’état du compte réel vers le compte d’exercice.
7. Autorisez une seule instance de trading prévue. Suivez le transfert documenté et confirmez que l’ancienne instance reste incapable de trader. Établissez la connexion de trading autorisée prévue, revérifiez les protections lors du changement de compte et les autorisations finales, puis activez uniquement le remplacement validé. Observez la gestion des ordres existants et notez l’heure et le résultat.

Si l’état essentiel, la responsabilité des ordres, l’accès au courtier ou l’arrêt de la source ne peut pas être confirmé, la procédure est incomplète. Gardez l’automatisation de remplacement désactivée et transmettez le problème précis non résolu au bon interlocuteur ; un processus terminal.exe actif ou un beau graphique restauré ne suffit pas.

Préparer un secours sans créer un second gestionnaire actif

Un VPS de secours peut réduire la préparation si sa configuration, ses dépendances et son accès ont déjà été testés. Gardez-le incapable de trader jusqu’à ce que les conditions de transfert soient satisfaites. Un second VPS sur le même compte chez le courtier n’empêche pas les ordres en double.

• Recensez le serveur principal, le secours et tout autre hôte, ainsi que la façon d’arrêter chacun et d’empêcher son redémarrage automatique.
• Confirmez que le principal est arrêté ou effectivement isolé du trading. Des commandes d’alimentation confirmées par le fournisseur ou un arrêt vérifié sont des preuves plus solides qu’une seule perte de RDP ou de signal de présence.
• Vérifiez les ordres chez le courtier et l’état de l’EA, puis terminez les contrôles du remplacement avant de l’activer. Au retour du principal, conservez un seul responsable actif ; ne laissez pas les deux procédures de démarrage réactiver le trading.

Changer de VPS ne répare pas un serveur de courtier indisponible et ne garantit pas l’accès pendant une panne plus large. Si l’état de trading du principal reste inconnu, ne considérez pas un basculement non vérifié comme sûr. Suivez le plan de gestion d’incident du compte pendant que vous clarifiez cet état.

Employer les bonnes commandes pour l’hébergement virtuel MetaTrader

L’hébergement intégré de MetaTrader n’est pas un bureau VPS Windows. Examinez son état distant et les journaux du terminal/Experts demandés. Stop Server arrête le terminal virtuel ; confirmez l’état arrêté signalé avant d’activer un remplacement ailleurs. Le bouton local AutoTrading n’arrête pas l’EA hébergé.

La migration va de l’environnement local vers le terminal virtuel, et non en sens inverse comme export de reprise. Le trading automatique hébergé est autorisé même si les autorisations locales ont été désactivées. Ne migrez donc pas une instance de reprise réelle préparée mais désactivée en supposant qu’elle restera désactivée à distance. Validez l’environnement prévu et le contexte du compte avant la synchronisation ; les appels DLL n’y sont pas pris en charge.

Répéter la procédure et consigner l’acceptation

Utilisez une configuration démo distincte et autorisée pour répéter la fermeture du terminal, le redémarrage du système, une dépendance manquante, la restauration d’une sauvegarde et un transfert contrôlé du principal vers le secours. Séparez comptes, licences et fichiers d’état démo et réels. Notez les essais effectivement réalisés, leurs limites et leurs résultats ; un exercice sur bureau ne démontre pas l’exécution future en réel.

Après l’incident, documentez sa cause, les actions de reprise, les écarts résolus et les améliorations du prochain exercice. Utilisez le Guide 2 pour corriger les faiblesses de ressources ou de démarrage sans changer les règles de risque de la stratégie pour masquer le problème technique.

Questions fréquentes sur les sauvegardes et la reprise

Restaurer un instantané VPS restaure-t-il mon compte de trading ?

Non. Cela restaure l’environnement local de l’instantané dans le périmètre documenté du fournisseur. Les transactions sont toujours établies à partir des données actuelles du courtier. L’ancien état local de l’EA doit être rapproché de ces données.

Un fichier .set suffit-il pour sauvegarder un EA ?

Non. Il conserve les paramètres externes pris en charge. Gardez aussi la version correspondante du programme, les indicateurs/fichiers requis, les informations de licence et la procédure documentée de reprise de l’état de l’EA.

Puis-je démarrer un VPS de secours si le Bureau à distance ne fonctionne plus ?

Vous pouvez l’examiner et le préparer avec l’automatisation incapable de trader. N’activez pas le remplacement avant d’avoir clarifié la capacité de trading du principal et la responsabilité des ordres existants. La perte d’accès distant ne prouve pas que le principal est arrêté.

Dois-je renvoyer une demande de trading après un délai d’attente dépassé ?

Pas avant d’avoir vérifié le résultat côté serveur. Rapprochez positions ouvertes, ordres en attente, historique pertinent et journaux, et contactez le courtier si le résultat reste incertain. Une répétition aveugle peut doubler une demande déjà acceptée.

Références officielles et portée pratique

Le comportement de la plateforme a été vérifié dans la documentation officielle de MetaQuotes. La gestion d’incident, la politique de sauvegarde, les contrôles du secours et les critères d’acceptation sont des recommandations pratiques, pas un outil universel de reprise MT4 testé. Les noms d’interface peuvent varier selon la langue ou l’édition du terminal ; vérifiez les libellés réels et les instructions du fournisseur de l’EA.

• MetaTrader 4 : dossiers de données, modèles et profils, et paramètres et autorisations des EA.
• MetaTrader 4 : ordres conservés chez le courtier et Trailing Stop du terminal.
• Référence MQL4 : codes de retour du trading et variables globales du terminal.
• MetaTrader 4 : commandes d’hébergement distant et règles de migration.