Guasti MT4 e VPS: backup e ripristino sicuro

Ripristina l’ambiente di trading, non un vecchio stato del conto

La procedura principale riguarda un normale VPS Windows con MT4. L’hosting virtuale integrato di MetaTrader usa controlli diversi; una sezione dedicata più avanti spiega la distinzione. Nel piano tieni separati il conto presso il broker, la configurazione locale del terminale e lo stato di esecuzione dell’EA.

Ripristinare una cartella non annulla le transazioni già elaborate dal broker. Né un grafico salvato dimostra che il suo EA possa riprendere in sicurezza la gestione di un paniere dopo un riavvio. L’obiettivo è uno stato operativo verificato, con una responsabilità chiara per gli ordini, non un desktop dall’aspetto identico. Il ripristino riduce l’interruzione operativa; non elimina il rischio di mercato e non garantisce l’esecuzione.

Prima risposta: evita di aggravare l’incidente

1. Registra l’incidente. Annota ora di rilevamento e fuso orario, conto/server e terminale interessati, ultimo comportamento normale confermato e modifiche recenti. Un avviso mancante o una sessione RDP persa è un sintomo, non una diagnosi.
2. Controlla l’esposizione del conto. Usa una vista autorizzata del conto del broker o un terminale di osservazione separato, senza EA o con EA impossibilitati a operare. Conferma posizioni attuali, ordini pendenti e livelli di protezione accettati; coinvolgi il broker se lo stato del conto non è chiaro.
3. Identifica tutte le istanze di trading. Includi VPS principale, computer di casa, terminali di riserva, hosting integrato e servizi di copia delle operazioni. Non avviare un’altra istanza automatica solo perché quella principale è irraggiungibile.
4. Scegli un intervento circoscritto. Conserva le prove, identifica il livello guasto e segui il piano documentato per gli incidenti. Prima di un riavvio o arresto, assegna la responsabilità delle posizioni che dipendono dalla gestione dell’EA locale.

In MT4 ordinario, disabilitare AutoTrading blocca le operazioni di trading degli EA in quel terminale; non chiude le posizioni, non elimina gli ordini del broker e non ferma un altro host. Può anche interrompere le uscite gestite dall’EA. Un riavvio è quindi una decisione operativa con conseguenze sul conto, non un innocuo pulsante diagnostico.

Localizza il guasto prima di reinstallare

Per singole impostazioni ed errori degli ordini, consulta la guida agli errori degli EA. Questa tabella identifica il livello interessato; non promette che un sintomo abbia una sola causa.

Un EA collegato può comunque non gestire gli ordini

Conferma simbolo e timeframe previsti, versione dell’EA, Inputs approvati e inizializzazione riuscita. Controlla i requisiti del conto e della licenza senza sostituirli con valori ipotizzati. Un cambio di profilo, un indicatore personalizzato mancante o una dipendenza DLL/WebRequest può cambiare il comportamento anche mentre arrivano le quotazioni.

• Distingui gli errori di permesso del terminale o dell’EA dalle restrizioni del broker/conto. Il codice 133 significa che il trading è disabilitato; non indica quale pulsante locale premere.
• Il codice 6 indica assenza di connessione al server di trading; il codice 146 indica un contesto di trading occupato. Esamina il messaggio effettivo e gli eventi circostanti invece di riavviare o inviare richieste ripetutamente.
• Con il codice 128, o qualsiasi risposta di trading persa o incerta, verifica l’esito sul server prima di riprovare. L’assenza di conferma locale non prova che il broker abbia rifiutato la richiesta.

Non rimuovere filtri su spread, sessione, posizioni o rischio per forzare un’operazione diagnostica. Se l’EA non ha un segnale valido, un ripristino riuscito può non generare nuove posizioni. La gestione degli ordini esistenti e dati aggiornati sono criteri di accettazione più utili di un ingresso forzato.

Verifica gli ordini del broker prima di riprendere l’automazione

In un ambiente di osservazione connesso, consulta Trade per posizioni aperte e ordini pendenti. Consulta Account History per le operazioni durante l’incidente; scegli un intervallo di date che lo copra davvero. Se i registri non coincidono o l’accesso è incompleto, chiedi chiarimenti al broker prima di considerare conclusa la ricostruzione.

• Confronta ticket, simbolo esatto, direzione, volume, ora di ingresso e Stop Loss/Take Profit accettati con il registro dell’incidente. Un terminale fermo non cancella gli ordini detenuti dal broker; gli ordini pendenti possono attivarsi durante il guasto.
• Identifica chi gestisce gli ordini usando le regole documentate dell’EA per simbolo e Magic Number. Non modificare gli identificatori per nascondere un vecchio ordine all’EA.
• Controlla se gli ordini siano stati chiusi o modificati mentre il terminale era indisponibile. Non ricreare una vecchia posizione solo perché compare in un backup o log.
• Conferma come questo EA ricostruisce il paniere, la logica di trailing, le uscite virtuali o altro stato. Se la ricostruzione non è supportata o è incerta, segui la procedura del fornitore prima di abilitarlo.

I livelli Stop Loss/Take Profit accettati dal broker restano sul server. Gli aggiornamenti del Trailing Stop di MT4 e le uscite virtuali dell’EA richiedono il funzionamento del terminale/EA che li gestisce; l’ultimo stop accettato dal server è distinto dal continuo aggiornamento locale. I livelli di protezione non garantiscono un prezzo di esecuzione, soprattutto in presenza di gap o interruzioni del broker.

Conserva le prove necessarie a spiegare il guasto

Conserva le voci pertinenti di Experts e Journal prima di svuotare le viste, ripristinare uno snapshot o reinstallare. Quando il terminale risponde, usa il comando Open di ogni scheda per individuare i log e scaricarne il buffer su disco. I log degli EA si trovano normalmente in MQL4/Logs, quelli del terminale in logs, nella cartella dati effettiva.

Registra identità del terminale, testo/codice dell’errore, ticket interessati, ultima inizializzazione riuscita, cambiamenti di connessione e modifiche recenti a Windows o all’EA. Annota orologio e fuso orario di ogni fonte; allinea i timestamp di Windows, terminale e broker prima di dedurre l’ordine degli eventi. Consulta la guida a Experts e Journal.

Invia all’assistenza solo l’estratto pertinente e la configurazione necessaria all’indagine, rimuovendo credenziali e informazioni del conto non correlate. Il provider può aver bisogno degli eventi della VM, il broker dei dettagli di ordini/server e lo sviluppatore dell’EA degli errori di inizializzazione o stato. Riavviare ripetutamente prima dell’indagine può confondere il guasto originale con gli effetti del ripristino.

Prepara un pacchetto di ripristino con le dipendenze

Per ogni terminale previsto, registra percorso di installazione e utente Windows, poi usa File → Open Data Folder per individuare i dati effettivi. Conserva un inventario con il backup; un collegamento o una cartella con il nome del broker non è una mappa affidabile.

Il registro effettivo degli ordini del broker si verifica dopo la riconnessione; non viene ripristinato dal pacchetto. Conserva configurazione e prove in modo sicuro, tenendo le credenziali di ripristino fuori dalle checklist pubbliche e dagli invii all’assistenza.

Usa preset, template e profili secondo il loro ruolo

Nella scheda Inputs dell’EA, Save salva i parametri esterni supportati e Load applica un preset salvato. Registra la versione corrispondente dell’EA: input rinominati o valori predefiniti diversi in una versione sostitutiva possono cambiare il risultato. Verifica i valori caricati invece di fidarti di un nome di file familiare.

Un template .tpl salva le impostazioni del grafico e può includere un EA collegato con i suoi parametri; un profilo descrive un gruppo di grafici. Nessuno dei due sostituisce gli eseguibili corrispondenti, le dipendenze o lo stato specifico del fornitore. Le modifiche al profilo vengono salvate mentre cambia l’area di lavoro, quindi anche una modifica accidentale può diventare il profilo corrente.

• Assegna nomi con data/versione a preset, template e registri dei profili già verificati.
• Conserva separatamente simboli esatti, timeframe e regole previste di gestione degli ordini.
• Applica i grafici ripristinati solo in un ambiente controllato dove il trading automatico non possa partire prima della verifica. Le impostazioni ripristinate possono contenere permessi che non intendevi abilitare.

Chiedi cosa sopravvive al riavvio e cosa va ricostruito

Un EA può ricavare lo stato dagli ordini del broker, scrivere file locali o condivisi, usare variabili globali del terminale oppure mantenere informazioni solo in memoria. Chiedi allo sviluppatore quale stato sia essenziale, come venga salvato e come il ripristino gestisca gli ordini aperti dopo il backup. Non presumere mai che tutti gli EA si comportino allo stesso modo.

Le variabili globali del terminale sono diverse dalle variabili nel codice dell’EA. Quelle persistenti possono sopravvivere ai riavvii, ma scadono dopo 4 settimane senza accesso; quelle temporanee esistono solo per la sessione corrente del terminale. Un elenco di variabili globali o un preset copiato non è quindi un backup universale dell’EA. Usa una procedura documentata e verifica l’attualità dello stato rispetto agli ordini correnti.

Un vecchio stato locale può essere in contrasto con i nuovi registri del broker. Non trasferire file di stato del paniere di un conto reale su un conto demo, non eliminare lo stato per “azzerare” operazioni esistenti e non cambiare i Magic Number senza la mappatura documentata del fornitore. Se l’EA non può ricostruire la gestione in sicurezza, lascia l’automazione disabilitata e risolvi la discrepanza.

Conserva versioni ripristinabili fuori dal VPS guasto

Conserva versioni datate della configurazione approvata e una copia protetta fuori dal VPS principale. Un ZIP sulla stessa VM può andare perso insieme alla VM. Uno snapshot del provider è un altro strumento di ripristino, ma occorre confermarne conservazione, ambito, coerenza e disponibilità; non è un backup indipendente del conto del broker.

• Esegui il backup dopo modifiche approvate a configurazione, versioni o dipendenze, e pianifica i backup dello stato secondo la quantità di cambiamenti irrecuperabili che l’EA può tollerare.
• Usa un metodo di acquisizione coerente e collaudato. Copiare file mentre l’EA li scrive può raccogliere versioni discordanti. Coordina eventuali pause o arresti ordinati con la gestione delle posizioni; non interrompere un gestore attivo solo per semplificare la copia.
• Controlla che gli archivi si aprano, che contengano i file richiesti e che una prova di ripristino riesca. Proteggi l’accesso e conserva versioni precedenti utilizzabili, così una corruzione o una modifica accidentale non sostituisce tutte le copie.

Un checksum può rilevare un cambiamento inatteso dei byte rispetto a un riferimento attendibile; non dimostra che lo stato dell’EA sia attuale o logicamente coerente. Il successo di un backup significa poterlo ripristinare, non soltanto ricevere un messaggio di completamento dal processo pianificato.

Definisci obiettivi distinti per interruzione e perdita di stato

L’obiettivo di tempo di ripristino (RTO) è la durata dell’interruzione che punti a tollerare prima di ristabilire il servizio previsto. L’obiettivo del punto di ripristino (RPO) è la quantità di modifiche storiche allo stato la cui perdita intendi tollerare. Sceglili secondo le reali esigenze di gestione dell’EA, poi verifica se procedura e frequenza dei backup li supportano.

Gli orari sono ipotetici, non un risultato di ripristino misurato né un RTO promesso. I 20 minuti riguardano modifiche allo stato locale potenzialmente mancanti; gli ordini accettati dal broker vanno comunque verificati nei suoi registri attuali. I 12 minuti riguardano l’interruzione. Una politica di backup che rispetta un intervallo può comunque fallire se l’EA non riesce a riconciliare quello stato con il conto.

Ripristina in un ambiente controllato

1. Conferma che l’istanza originale non possa operare. Fermala o isolala tramite un controllo verificato e impedisci la riattivazione automatica. Se è soltanto irraggiungibile, risolvi l’incertezza prima di avviare l’automazione sostitutiva.
2. Prepara un terminale pulito di osservazione o preparazione. Usa il MT4 previsto dal broker e l’utente Windows corretto. Disabilita il trading automatico prima di introdurre profili o impostazioni dell’EA ripristinati. Durante la verifica iniziale, lascia assenti le credenziali del conto reale oppure usa un accesso di osservazione in sola lettura supportato; conferma le sue restrizioni effettive.
3. Individua la nuova cartella dati. Usa File → Open Data Folder. Mantieni intatto il backup originale e ripristina i file selezionati e documentati invece di sovrascrivere alla cieca tutta la nuova configurazione.
4. Ripristina programmi e input approvati. Verifica versioni, simboli/timeframe esatti, dipendenze e licenza. Mantieni disabilitata l’automazione; un vecchio file di impostazioni non deve sostituire silenziosamente i controlli dei permessi verificati.
5. Valida stato e ordini. Segui la procedura documentata per confrontare lo stato persistente con le posizioni attuali del broker, gli ordini pendenti e la cronologia dell’incidente. Risolvi le discrepanze prima di riprendere la gestione.
6. Completa i controlli di accettazione. Verifica dati richiesti, inizializzazione, permessi, responsabilità degli ordini, log, avvisi e contesto di avvio. Valida prima la procedura in demo; non copiare lo stato del conto reale nel conto usato per la prova.
7. Autorizza una sola istanza di trading prevista. Segui il passaggio documentato e conferma che la vecchia istanza resti impossibilitata a operare. Imposta l’accesso di trading autorizzato previsto, ricontrolla la protezione al cambio di conto e i permessi finali, poi abilita soltanto il sostituto verificato. Osserva la gestione degli ordini esistenti e registra ora ed esito.

Se non puoi confermare lo stato essenziale, chi gestisce gli ordini, l’accesso al broker o l’arresto della sorgente, la procedura è incompleta. Mantieni disabilitata l’automazione sostitutiva e inoltra il problema specifico irrisolto a chi può gestirlo; un processo terminal.exe attivo o un bel grafico ripristinato non basta.

Prepara una riserva senza creare un secondo gestore attivo

Un VPS di riserva può ridurre il lavoro di preparazione se configurazione, dipendenze e accesso sono già stati collaudati. Impediscigli di operare finché le condizioni del passaggio non sono soddisfatte. Un secondo VPS sullo stesso conto del broker non impedisce ordini duplicati.

• Registra server principale, riserva e ogni altro host, insieme al metodo per fermarli e impedirne il riavvio automatico.
• Conferma che il principale sia fermo o effettivamente isolato dal trading. Controlli di alimentazione confermati dal provider o un arresto verificato sono prove più solide della sola perdita di RDP o del segnale di presenza.
• Verifica ordini del broker e stato dell’EA, poi completa i controlli del sostituto prima di abilitarlo. Al ritorno del principale, mantieni un solo gestore attivo; non permettere a entrambe le procedure di avvio di riabilitare il trading.

Cambiare VPS non ripara un server del broker indisponibile e non garantisce l’accesso durante un’interruzione più ampia. Se lo stato di trading del principale resta sconosciuto, non considerare sicuro un passaggio non verificato. Segui il piano per gli incidenti del conto mentre chiarisci quello stato.

Usa i controlli corretti per l’hosting virtuale MetaTrader

L’hosting integrato di MetaTrader non è un desktop VPS Windows. Per indagare usa lo stato remoto e i log richiesti del terminale/Experts. Stop Server ferma il terminale virtuale; conferma lo stato di arresto riportato prima di abilitare un sostituto altrove. Il pulsante locale AutoTrading non ferma l’EA ospitato.

La migrazione va dall’ambiente locale al terminale virtuale, non torna indietro come esportazione di ripristino. Il trading automatico ospitato è consentito anche quando i permessi locali sono stati disabilitati. Non migrare quindi un’istanza di ripristino reale preparata ma disabilitata aspettandoti che rimanga disabilitata da remoto. Valida ambiente previsto e contesto del conto prima della sincronizzazione; le chiamate DLL non sono supportate lì.

Prova la procedura e registra l’accettazione

Usa una configurazione demo separata e autorizzata per provare chiusura del terminale, riavvio del sistema, dipendenza mancante, ripristino da un pacchetto salvato e passaggio controllato dal principale alla riserva. Mantieni distinti conti, licenze e file di stato demo e reali. Registra cosa è stato davvero testato, limiti ed esiti; una prova sul desktop non dimostra l’esecuzione futura sul conto reale.

Dopo l’incidente, documenta causa, azioni di ripristino, discrepanze risolte e miglioramenti per la prossima prova. Usa la Guida 2 per correggere debolezze di risorse o avvio senza modificare le regole di rischio della strategia per nascondere il problema tecnico.

Domande frequenti su backup e ripristino

Ripristinare uno snapshot VPS ripristina il conto di trading?

No. Ripristina l’ambiente locale dello snapshot entro l’ambito documentato dal provider. Le transazioni del broker vengono comunque ricostruite dai suoi registri attuali. Il vecchio stato locale dell’EA deve essere riconciliato con questi.

Un file .set basta per il backup di un EA?

No. Salva gli input esterni supportati. Conserva anche la versione corrispondente del programma, indicatori/file richiesti, informazioni sulla licenza e procedura documentata di ripristino dello stato dell’EA.

Posso avviare un VPS di riserva quando Desktop remoto non funziona?

Puoi esaminarlo e prepararlo con l’automazione impossibilitata a operare. Non abilitare il sostituto finché non hai chiarito la capacità di trading del principale e la gestione degli ordini esistenti. Perdere l’accesso remoto non prova che il principale si sia fermato.

Devo reinviare una richiesta di trading dopo un timeout?

Non prima di controllare l’esito sul server. Verifica posizioni aperte e ordini pendenti, cronologia pertinente e log, e coinvolgi il broker se il risultato resta incerto. Ripetere alla cieca può duplicare una richiesta già accettata.

Riferimenti ufficiali e ambito pratico

Il comportamento della piattaforma è stato verificato nella documentazione ufficiale MetaQuotes. Il flusso di gestione degli incidenti, la politica di backup, i controlli della riserva e le verifiche di accettazione sono raccomandazioni pratiche, non uno strumento universale di ripristino MT4 collaudato. I nomi dell’interfaccia possono variare con lingua o edizione del terminale; conferma le etichette effettive e le istruzioni del fornitore dell’EA.

• MetaTrader 4: cartelle dati, template e profili, e input e permessi degli EA.
• MetaTrader 4: ordini detenuti dal broker e Trailing Stop del terminale.
• Riferimento MQL4: codici di risposta del trading e variabili globali del terminale.
• MetaTrader 4: controlli dell’hosting remoto e regole di migrazione.