Un backup non garantisce la continuità. Può essere incompleto, inaccessibile durante un attacco, troppo lungo da ripristinare o dipendere da un servizio esso stesso non disponibile. Il piano di ripresa delle attività trasforma gli obiettivi aziendali in procedure, mezzi tecnici ed esercizi misurabili.
Il PCA, piano di continuità operativa, cerca di mantenere un livello di servizio durante la perturbazione. Il PRA, piano di ripresa operativa, organizza il ripristino dopo un'interruzione. Per un'applicazione web, entrambi coprono il codice, i dati, l'infrastruttura, i servizi di terzi, i team e la convalida aziendale.
Partire dall'impatto sul lavoro
La domanda iniziale non è « quante copie di sicurezza vogliamo? », ma « cosa succede se questo percorso non è disponibile o se i suoi ultimi dati scompaiono? ». Gli impatti possono essere finanziari, operativi, contrattuali, normativi o reputazionali.
Ogni capacità è classificata: consultazione, inserimento, pagamento, calcolo, importazione, notifica, amministrazione. Alcune possono funzionare in modalità degradata; altre richiedono un'interruzione per proteggere l'integrità.
Questa analisi definisce le priorità di ripresa. Ripristinare l'intero sito prima della funzione che riceve gli ordini può essere tecnicamente comodo ma dal punto di vista del lavoro scorretto.
Comprendere RTO, RPO, MTPD e WRT
Il RTO è il tempo obiettivo tra l’interruzione e il ripristino del servizio tecnico accettabile. Il RPO rappresenta la quantità massima di dati che l’organizzazione accetta di perdere, espressa in tempo.
Il MTPD indica la durata massima tollerabile di interruzione prima che le conseguenze diventino inaccettabili. Il WRT, o tempo di ripresa del lavoro, copre ciò che i team aziendali devono fare dopo il ritorno tecnico: controlli, riconciliazioni, recupero e comunicazione.
Si impone una coerenza semplice: il RTO più il WRT deve rimanere inferiore al termine massimo tollerabile. Il RPO deve essere compatibile con la frequenza di backup o di replica effettivamente ottenuta.
La cronologia parte dai backup disponibili prima dell’incidente. Il periodo tra l’ultimo punto recuperabile e l’incidente rappresenta la perdita di dati delimitata dal RPO. Dopo l’incidente, l’RTO copre la decisione, la ricostruzione e il ripristino fino al ritorno a un servizio tecnico accettabile. Il WRT prolunga questa durata fino alla convalida e alla piena ripresa del lavoro da parte dei team di business. L’insieme RTO più WRT deve rimanere inferiore al MTPD, la durata massima tollerabile della perturbazione.
Una strategia di backup completa
Una strategia precisa:
- i dati coperti ;
- la frequenza ;
- la ritenzione ;
- le copie offline o immutabili;
- la separazione dei conti e dei diritti;
- la cifratura ;
- la sorveglianza dei fallimenti;
- la procedura di ripristino;
- le prove del test.
La regola detta 3-2-1 — più copie, su supporti diversi, di cui una separata — costituisce un punto di partenza, non una garanzia universale. I backup devono includere basi, file, configurazioni, chiavi necessarie e versioni di codice compatibili.
Ripristinare l'insieme coerente
Una base ripristinata senza i file associati, o un codice recente con uno schema vecchio, può rendere l’applicazione incoerente. Il PRA definisce un punto di coerenza e l’ordine: infrastruttura, segreti, base, archiviazione, indice, worker, cache e servizi.
Le migrazioni e gli script devono essere versionati. Le chiavi di crittografia e i certificati necessari alla lettura dei dati sono protetti separatamente ma disponibili durante la crisi.
Scegliere il livello di soccorso
Backup e ricostruzione
Adatta quando il RTO si misura in ore o giorni. L'infrastruttura viene ricreata e poi i dati ripristinati. Questo approccio è economico ma dipende dall'automazione e dalla disponibilità dei componenti.
Ambiente di emergenza freddo o tiepido
Risorse sono preparate, con una parte dell’infrastruttura o dei dati già disponibili. Il costo aumenta, il tempo di ripresa diminuisce.
Soccorso caldo e replicazione
Un'infrastruttura pronta riceve i dati continuamente o quasi. Il passaggio può essere rapido, ma bisogna controllare la replicazione degli errori, i conflitti e i test di ripristino.
Continuità attiva
Diverse zone o siti servono il traffico. Questa architettura mira a una forte disponibilità, senza eliminare la necessità di backup: una cancellazione logica o una compromissione può diffondersi ovunque.
Mappare le dipendenze
L'applicazione dipende spesso da DNS, identità, e-mail, pagamento, archiviazione, API aziendali e fornitori. Il PRA deve precisare il comportamento di ciascuno: attesa, messa in coda, modalità degradata, altro fornitore o sospensione controllata.
Un'architettura ridondante perde il suo interesse se l'account DNS, il fornitore di identità o una chiave unica rimangono un punto di guasto. Contano anche le dipendenze organizzative: chi può accedere agli account, prendere una decisione e comunicare?
Definire gli scenari di crisi
Un piano generico non basta. Testate degli scenari:
- cancellazione o corruzione dei dati;
- indisponibilità di una regione cloud;
- compromissione di account amministratore;
- ransomware ;
- certificato o dominio scaduto;
- dispiegamento difettoso;
- interruzione di un servizio di terzi;
- indisponibilità di una persona chiave.
Ogni scenario specifica attivatore, ambito, decisione, isolamento, ripristino, convalida e uscita dalla crisi.
Scrivere un runbook utilizzabile sotto pressione
Il runbook deve essere breve, versionato e accessibile anche se il sistema principale non è disponibile. Indica i contatti, i prerequisiti, i comandi, i risultati attesi e i punti di arresto. I segreti non sono scritti in chiaro; il loro caveau e la loro procedura di accesso sono testati.
I ruoli sono separati: direzione della crisi, intervento tecnico, validazione professionale, comunicazione e collegamento con i fornitori. La stessa persona può accumulare ruoli in una piccola struttura, ma la responsabilità rimane esplicita.
Testare il ripristino
Un test di backup verifica che un file esista. Un test di ripristino dimostra che può essere utilizzato. L'esercizio deve misurare:
- tempo di recupero degli accessi;
- tempo di ricostruzione;
- tempo di trasferimento e di ripristino;
- controlli di integrità;
- validazione dei percorsi ;
- scostamenti dal RTO/RPO;
- operazioni manuali ed errori.
Gli esercizi possono iniziare con un tavolo, poi un ambiente isolato, poi una ripetizione completa. Devono produrre azioni con scadenza.
Preparare la comunicazione
La continuità include gli utenti, i partner e i team. Modelli di messaggi spiegano ciò che è noto, l'impatto, le misure e il prossimo aggiornamento. Bisogna evitare promesse di tempi non confermati e proteggere le informazioni di sicurezza.
Un diario di crisi datato conserva decisioni, azioni e prove. Facilita il ritorno d'esperienza e gli eventuali obblighi di notifica.
Mantenere il piano vivo
Il PRA viene rivisto quando cambiano l'architettura, i volumi, i fornitori o l'organizzazione. I contatti scadono, gli ordini evolvono e gli obiettivi aziendali si irrigidiscono. Una revisione annuale è il minimo per una piattaforma importante; i test possono essere più frequenti a seconda della criticità.
Gli indicatori seguono il tasso di successo dei backup, l’età dell’ultimo test, il tempo misurato di ripristino, le variazioni e le azioni non chiuse.
Una capacità, non un documento
Il livello di continuità deve essere proporzionato. Un RTO di pochi minuti comporta un’architettura e un’organizzazione costose. Un obiettivo di diverse ore può essere perfettamente accettabile se viene assunto e testato.
Partitech assicura l'hosting, l'infogestione, la supervisione e la manutenzione di piattaforme digitali. Possiamo mappare le dipendenze, definire gli obiettivi, automatizzare il ripristino e condurre esercizi affinché il PRA corrisponda a una capacità reale.
Per approfondire l'approccio, inquadrare i livelli di servizio e la manutenzione applicativa, iniziate con un audit tecnico dell'applicazione e preparateli strategie di switch di un'applicazione. Scoprite anche l’offerta Manutenzione, evoluzioni, hosting e outsourcing IT di Partitech.
Riferimenti ufficiali
Riferimenti consultati il 17 agosto 2026: