Il vostro esperto di backup e protezione dei dati!La soluzione su misura per le vostre esigenze
Come mantenere disponibile un'applicazione aziendale durante un guasto?
Un’applicazione aziendale resta disponibile durante un guasto se una seconda istanza, già aggiornata e già raggiungibile dalle postazioni, subentra senza che ogni utente debba modificare un parametro. Se l’emergenza esiste ma nessuno sa come collegarsi, l’applicazione è tecnicamente «salvata» e in pratica ferma.
In sintesi
- Quattro condizioni: dati coerenti, emergenza dimensionata, percorso di rete pronto, verifica operativa.
- Il database deve essere salvato con un metodo che lo conosca (log delle transazioni, messa in quiescenza), non come semplici file.
- Mantenere lo stesso indirizzo IP è più trasparente di una modifica DNS, ma presuppone un apparato ancora funzionante sul sito.
- Verificate la licenza del software sull’ambiente di emergenza prima del guasto.
- Se le quattro condizioni non sono soddisfatte, dichiarate un DRP e mettete per iscritto la modalità di servizio ridotto.
Le quattro condizioni
I dati sono coerenti. L’applicazione e il suo database devono essere copiati insieme, in uno stato che il motore del database accetti di aprire. Una copia di file effettuata nel mezzo di una scrittura può avviarsi su un database che il produttore del software considererà corrotto. Lo strumento di backup o di replica deve conoscere il database (messa in quiescenza, log delle transazioni), non solo il disco. Per SQL Server, Microsoft raccomanda inoltre di collocare i backup in una posizione fisica distinta dai file del database, e ricorda che non si ha una strategia di ripristino finché non si è ripristinata una copia su un sistema di prova e ne è stata verificata l’integrità.
L’emergenza è dimensionata per lavorare, non solo per «dimostrare che si avvia». Un’istanza troppo piccola per dieci utenti simultanei crea un guasto software al posto del guasto hardware.
Il percorso di rete è pronto. Due tecniche comuni:
- mantenere lo stesso indirizzo IP visto dalle postazioni, grazie a un apparato in sede che reindirizza verso l’emergenza;
- cambiare un nome DNS, accettando il tempo di propagazione e le cache delle postazioni.
La prima è più trasparente. Presuppone un agente o un’appliance ancora funzionante sul sito. Se l’intero sito viene distrutto (incendio), non c’è più alcun agente locale: gli utenti remoti passano allora per un indirizzo pubblico di emergenza, a condizione che sia stato riservato e testato. Il BCP di sito e il BCP di un singolo server non si preparano allo stesso modo.
Qualcuno verifica l’applicazione, non solo il sistema. Aprire la schermata di accesso non basta. Un utente autorizzato esegue l’operazione abituale: cercare una pratica, emettere un documento, stampare.
Confrontare i due percorsi di rete
| Stesso indirizzo IP tramite un apparato locale | Modifica del nome DNS | |
|---|---|---|
| Azione lato postazioni | Nessuna | A volte svuotare la cache o riavviare |
| Tempo di failover | Breve | Dipende dalla durata di validità (TTL) dei record DNS |
| Funziona se il sito è distrutto | No | Sì, se l’accesso remoto è pronto |
| Punto di attenzione | L’apparato locale deve sopravvivere | Gli indirizzi scritti nel codice dei software |
Prima del guasto: la checklist
- Il metodo di backup del database è documentato e ha già dato luogo a un ripristino riuscito.
- La dimensione dell’emergenza è stata convalidata con il numero di utenti previsto.
- Il percorso di rete è stato testato da una postazione ordinaria, non dalla postazione dell’amministratore.
- La licenza funziona sull’emergenza.
- Un utente operativo ha eseguito un’operazione reale sull’emergenza durante l’ultimo test. Vedere Come testare un DRP?.
Modalità di servizio ridotto
Se le quattro condizioni non sono soddisfatte, la cosa onesta è dichiarare un DRP (ripresa dopo un’interruzione) e mettere per iscritto la modalità di servizio ridotto: quali operazioni possono attendere, quali si annotano su carta, chi le reinserisce in seguito. Un’applicazione «indispensabile» la cui modalità ridotta regge mezza giornata non ha necessariamente bisogno di un’emergenza accesa tutto l’anno. L’ANSSI, agenzia nazionale francese per la cybersicurezza, raccomanda di prevedere queste soluzioni alternative in anticipo, perché una crisi di origine informatica può durare diverse settimane.
Licenze e produttori di software
Alcuni software aziendali legano la licenza a un identificativo hardware, oppure vietano l’hosting esterno. Verificatelo prima del guasto. Un’emergenza che si avvia e poi si chiude per mancanza di licenza non è un’emergenza.
Con WeDoBack
Il BCP è pensato per questo caso: istanze cloud sempre accese, agente sulla rete del cliente, collegamento VPN IPsec, subentro senza cambio di indirizzo IP. Mantiene quindi l’applicazione raggiungibile dalle postazioni del sito finché esistono l’agente e la rete locale. Perché il database dell’applicazione sia aggiornato sull’istanza, e perché i dati inseriti durante il guasto tornino poi sul server riparato, serve un processo di replica o di sincronizzazione specifico: non è nativo, e WeDoBack può implementarlo su preventivo. Le istanze partono da 50,22 € IVA esclusa al mese, lo storage da 8,75 € IVA esclusa al mese per 50 GB. Se l’edificio viene distrutto, questo meccanismo locale non basta più: servono indirizzi pubblici e un accesso remoto, che rientrano piuttosto nel DRP con indirizzi IP pubblici (0,54 € IVA esclusa per indirizzo al mese). WeDoBack esegue il backup di SQL Server, Exchange e dei software aziendali, e ripristina il server e l’applicazione se sono stati salvati in modo coerente. Non corregge un database copiato in modo approssimativo: il metodo di backup del database fa parte dell’implementazione, da testare prima.
Domande frequenti
Si possono copiare i file del database come gli altri file?
Non basta. Una copia effettuata nel mezzo di una scrittura può produrre un database che il motore si rifiuterà di aprire. Serve un backup che conosca il database (backup nativo, log delle transazioni o messa in quiescenza). Microsoft ricorda inoltre che una strategia di ripristino esiste solo dopo aver testato i backup su un sistema di prova.
L’emergenza deve essere potente quanto il server di produzione?
Deve sostenere il numero di utenti simultanei previsto durante il guasto. Un’emergenza sottodimensionata trasforma un guasto hardware in un problema di prestazioni. Si può accettare un’emergenza un po’ più modesta se la modalità di servizio ridotto riduce il numero di utenti, a condizione di averlo misurato.
Cosa succede se l’intero edificio viene distrutto?
I meccanismi che si basano su un apparato locale (agente, appliance) scompaiono con il sito. Gli utenti devono allora raggiungere l’emergenza dall’esterno, tramite un indirizzo pubblico e un accesso remoto riservati e testati in anticipo. È uno scenario diverso dal guasto di un server.
Per approfondire
Fonti
Documenti consultati a ottobre 2026.
- Back up and Restore of SQL Server Databases — Microsoft Learn
- Crise cyber, les clés d’une gestion opérationnelle et stratégique (dicembre 2021), guida sulla gestione delle crisi cyber — ANSSI (agenzia francese)
- Offerta BCP: continuità operativa immediata — WeDoBack
- Offerta DRP: ripresa dell’attività dopo un disastro — WeDoBack
Un progetto di backup, DRP o BCP?
Oltre 20 anni di esperienza nella protezione dei dati aziendali.
Richiedi un preventivo+33 9 72 50 78 28Protegga i Suoi dati con WeDoBack
Backup cifrato fuori sede, storage immutabile, DRP e BCP: ci descriva i Suoi server e Le proporremo la combinazione più adatta.