Approfondimenti
RPO e RTO: calcolarli nel tuo DR plan

Quando si parla di Disaster Recovery, due metriche diventano fondamentali per misurare la resilienza di un sistema: RPO (Recovery Point Objective) e RTO (Recovery Time Objective).
Entrambe definiscono in modo concreto quanto un’azienda può sopportare in termini di perdita di dati e tempo di inattività, e costituiscono la base per costruire un piano di continuità realmente efficace.
Che cosa sono RPO e RTO
RPO – Recovery Point Objective
Il Recovery Point Objective (RPO) rappresenta il punto massimo di perdita dati tollerabile, espresso in tempo.
Se un sistema ha un RPO di 30 minuti, significa che, in caso di guasto o incidente, l’azienda può accettare di perdere al massimo i dati degli ultimi 30 minuti di attività.
Esempi pratici di RPO:
- E-commerce internazionale: un ordine perso può significare migliaia di euro di fatturato. In questo caso, l’RPO deve essere molto basso, anche pochi minuti.
- PMI amministrativa: la perdita di alcuni documenti contabili può essere recuperata manualmente. Qui l’RPO può essere più ampio, anche alcune ore.
In sintesi, più critici sono i dati, più l’RPO deve essere stringente.
RTO – Recovery Time Objective
Il Recovery Time Objective (RTO) rappresenta il tempo massimo accettabile per ripristinare un servizio o un’applicazione.
Se il tuo ERP ha un RTO di 2 ore, dovrai assicurarti che torni operativo entro quel tempo, pena impatti critici su produzione e fatturazione.
Esempi pratici di RTO:
- Banca online: se i clienti non possono accedere al proprio conto per più di 30 minuti, l’impatto reputazionale e regolatorio può essere devastante → RTO molto basso.
- Software gestionale interno: se i dipendenti non possono usarlo per 4 ore, l’impatto è significativo ma gestibile → RTO più ampio.
In sintesi, più business-critical è il servizio, più l’RTO deve essere ridotto.
RPO vs RTO: la differenza chiave
Spesso si tende a confondere RPO e RTO, ma la differenza è semplice e fondamentale:
- RPO = Quanto puoi perdere (dati)
- RTO = Quanto puoi stare fermo (tempo)
Entrambe le metriche devono essere calcolate in base agli obiettivi di business, non solo agli aspetti tecnici.
Per un approfondimento più ampio sul tema e su come inserirli in una strategia completa, puoi leggere la guida dedicata al Disaster Recovery Plan e alla sua importanza.
Perché RPO e RTO sono fondamentali in un piano di Disaster Recovery
Stabilire RPO e RTO non è un esercizio teorico, ma una parte critica di ogni Disaster Recovery Plan (DRP).
Questi due parametri determinano il livello di continuità operativa che un’azienda può garantire in caso di guasti, attacchi informatici o eventi imprevisti.
L’impatto sul business continuity
Ogni minuto di downtime ha un costo.
Secondo un report del Ponemon Institute, il costo medio di un minuto di fermo per le aziende può arrivare fino a oltre 9.000 dollari, a seconda della dimensione e del settore.
- Un RPO troppo alto espone al rischio di perdita dati critici, con conseguenze economiche e legali.
- Un RTO troppo lungo implica un blocco prolungato dei servizi, con calo di produttività e danni reputazionali.
In poche parole, RPO e RTO traducono la continuità aziendale in numeri concreti.
Esempi pratici: downtime, perdita di dati e costi
- Settore e-commerce: un sito offline per 2 ore durante il Black Friday può generare perdite di fatturato enormi e clienti insoddisfatti. RTO e RPO devono quindi essere minimi.
- Settore sanitario: la perdita di cartelle cliniche anche per pochi minuti può comportare gravi conseguenze etiche e legali. L’RPO deve essere quasi pari a zero.
- Manifattura: un fermo impianto di 4 ore può rallentare la catena di produzione, ma spesso l’azienda può recuperare. In questo caso, RTO e RPO possono essere più ampi, senza compromettere la business continuity.
RPO e RTO come metriche strategiche
Molte aziende cadono nell’errore di definire RPO e RTO solo come parametri tecnici, lasciando la loro valutazione all’IT. In realtà, sono metriche strategiche di business, che devono coinvolgere anche:
- il management (per valutare rischi e costi),
- il finance (per stimare l’impatto economico dei downtime),
- la compliance (per rispettare normative come GDPR o ISO 22301).
Per questo motivo, RPO e RTO vanno definiti con un approccio multidisciplinare, come parte integrante della Business Impact Analysis (BIA).
Collegamento con il Disaster Recovery Plan
Un DR plan senza RPO e RTO chiari rischia di essere solo un documento teorico, non applicabile in pratica.
Definendo valori concreti, invece, l’azienda può:
- stabilire le priorità sui sistemi più critici,
- allocare budget in modo mirato,
- predisporre infrastrutture cloud di backup con SLA garantiti.
Vuoi approfondire come costruire un piano efficace? Leggi la guida su come funziona un Disaster Recovery Plan e perché è fondamentale.
Come calcolare RPO e RTO nel tuo DR Plan
Il calcolo di RPO e RTO è un passaggio chiave per trasformare il Disaster Recovery Plan da documento teorico a strumento concreto. Non si tratta solo di definire numeri casuali: è necessario analizzare l’impatto che perdita dati e downtime avrebbero sui processi aziendali.
I fattori da considerare
Per stabilire valori realistici, un’azienda deve valutare diversi aspetti:
- Tipologia di dati: i database transazionali richiedono RPO più stringenti rispetto a file di archiviazione.
- Applicazioni critiche: ERP, CRM o sistemi di pagamento online hanno priorità assoluta.
- Obblighi normativi e SLA: contratti con clienti e partner possono imporre tempi di ripristino ben precisi.
- Budget e risorse: valori molto bassi di RTO e RPO richiedono soluzioni tecnologiche più complesse e costose.
Un buon calcolo non si limita alla parte tecnica, ma tiene conto anche di business continuity, compliance e sostenibilità economica.
Esempi numerici semplificati
- E-commerce internazionale:
- RPO → massimo 5 minuti, perché ogni ordine perso ha un impatto diretto sui ricavi.
- RTO → massimo 30 minuti, perché oltre quel limite i clienti potrebbero abbandonare la piattaforma.
- Azienda manifatturiera:
- RPO → 2 ore, perché alcuni dati possono essere reinseriti manualmente senza impatti critici.
- RTO → 4 ore, sufficiente a ripristinare la produzione senza danni irreversibili.
Questi esempi mostrano come RPO e RTO non siano valori universali, ma vadano calibrati sul singolo contesto aziendale.
L’importanza del supporto specializzato
Definire RPO e RTO corretti non significa fare calcoli astratti: richiede analisi, simulazioni e test periodici.
Per questo motivo, molte aziende scelgono di affidarsi a partner specializzati.
Con Epiclink e i suoi servizi di Disaster Recovery, puoi definire RPO e RTO su misura per i tuoi processi, con infrastrutture cloud sicure e team di esperti che ti supportano nella progettazione del DR Plan.
Esempio pratico di RPO e RTO in un’azienda
Per capire meglio il ruolo di RPO e RTO, immaginiamo il caso di un’azienda di e-commerce che gestisce migliaia di ordini al giorno.
Lo scenario di guasto
Un attacco ransomware blocca i server principali, impedendo ai clienti di completare acquisti e accedendo allo storico ordini. L’impatto potenziale è enorme: perdita immediata di fatturato, danni di immagine e rischio di reclami.
Il ruolo dell’RPO
Grazie a un sistema di backup continuo, l’azienda ha fissato un RPO di 10 minuti. Significa che, anche se i sistemi vanno in crash, al massimo perderà i dati relativi agli ordini degli ultimi 10 minuti. Questa perdita è tollerabile rispetto ai volumi complessivi e può essere gestita manualmente dal customer care.
Il ruolo dell’RTO
Il DR plan dell’azienda prevede un RTO di 1 ora. In caso di disastro, l’obiettivo è riportare online la piattaforma entro 60 minuti. Un tempo che permette di ridurre al minimo i reclami e di non compromettere il fatturato della giornata.
Cosa sarebbe successo senza RPO e RTO definiti?
- Con un RPO di 12 ore, l’azienda avrebbe perso migliaia di ordini, con danni economici e reputazionali irreparabili.
- Con un RTO di 6 ore, i clienti avrebbero abbandonato la piattaforma, preferendo competitor più affidabili.
Questo esempio dimostra come RPO e RTO non siano concetti teorici, ma veri e propri “numeri di sopravvivenza” per il business.
Best practice per definire RPO e RTO efficaci
Stabilire valori realistici e sostenibili per RPO e RTO è un passaggio strategico. Non basta fissare obiettivi ambiziosi: serve un approccio metodico che tenga conto sia della tecnologia che del business.
Condurre una Business Impact Analysis (BIA)
La BIA è lo strumento che permette di stimare le conseguenze economiche e operative di un’interruzione. Analizzando ogni processo aziendale si può capire quali sistemi sono davvero mission-critical e quali, invece, possono tollerare un fermo più lungo.
Ad esempio: un gestionale HR può sopportare un downtime di 12 ore senza gravi conseguenze, mentre un sistema di fatturazione elettronica deve essere sempre disponibile.
Definire priorità diverse per applicazioni e dati
Non tutti i sistemi hanno lo stesso livello di criticità. È importante classificare le applicazioni in base a impatto sul business, frequenza di utilizzo e valore dei dati trattati.
- Applicazioni mission-critical → RPO e RTO molto bassi
- Applicazioni di supporto → valori più flessibili
Questo approccio evita sprechi di budget e consente di destinare le risorse dove servono davvero.
Testare regolarmente il piano di Disaster Recovery
Un DR Plan che non viene testato rischia di rimanere solo sulla carta.
Le simulazioni periodiche (es. esercitazioni di failover) servono a verificare se i valori di RPO e RTO definiti sono davvero raggiungibili in condizioni reali.
👉 Molti fallimenti nei piani di DR non derivano da tecnologie inadeguate, ma da test mai eseguiti.
Aggiornare RPO e RTO in base all’evoluzione aziendale
L’infrastruttura IT e i processi di business cambiano rapidamente. Un RTO adeguato oggi potrebbe non esserlo tra un anno.
Per questo è fondamentale rivedere periodicamente i parametri e adeguarli a:
- nuovi servizi online,
- normative aggiornate,
- variazioni nei volumi di dati gestiti.
Collaborare con partner specializzati
Infine, la definizione di RPO e RTO non deve essere un esercizio solitario dell’IT interno. Affidarsi a un partner specializzato come Epiclink significa poter contare su:
- infrastrutture cloud sicure,
- soluzioni di disaster recovery certificate,
- un team di esperti che supporta nella valutazione e nel monitoraggio costante.
👉 Scopri le soluzioni di Disaster Recovery di Epiclink, progettate per aiutare le aziende a definire obiettivi concreti e raggiungibili.
FAQ su RPO e RTO
Qual è la differenza tra RPO e RTO?
L’RPO (Recovery Point Objective) indica quanti dati un’azienda può permettersi di perdere, mentre l’RTO (Recovery Time Objective) rappresenta il tempo massimo entro cui i sistemi devono essere ripristinati. In sintesi: RPO = perdita dati, RTO = tempo di fermo.
Come si calcola l’RPO?
L’RPO si calcola valutando la frequenza dei backup o delle repliche dei dati e analizzando quanto la perdita di dati influisce sul business. Ad esempio, se un’azienda può tollerare di perdere solo gli ultimi 15 minuti di dati, l’RPO sarà fissato a 15 minuti.
Come si calcola l’RTO?
L’RTO si definisce stimando il tempo massimo di inattività accettabile per ogni servizio critico. Per stabilirlo bisogna considerare i processi aziendali, gli SLA verso i clienti e i costi di un downtime prolungato.
Quali sono esempi concreti di RPO e RTO?
- E-commerce: RPO di 5 minuti e RTO di 30 minuti, per non perdere ordini e garantire vendite.
- Manifattura: RPO di 2 ore e RTO di 4 ore, tollerabili senza bloccare la produzione.
- Banca online: RPO quasi pari a zero e RTO di pochi minuti, per garantire la sicurezza delle transazioni.
Cosa succede se RPO e RTO non sono rispettati?
Il mancato rispetto degli obiettivi porta a perdita di dati, downtime prolungato, calo di produttività e danni reputazionali. Nei settori regolamentati, come quello finanziario o sanitario, può comportare anche sanzioni legali.
Chi definisce RPO e RTO in azienda?
La definizione di RPO e RTO è una responsabilità condivisa: il reparto IT valuta gli aspetti tecnici, il management stabilisce le priorità di business e il reparto finance analizza l’impatto economico. Molte aziende scelgono di affidarsi a partner specializzati per definire parametri realistici e sostenibili.
Come abbiamo già detto più volte, RPO e RTO non sono semplici sigle tecniche: rappresentano la capacità concreta di un’azienda di resistere a incidenti, attacchi informatici o guasti imprevisti senza compromettere la continuità operativa.
Definirli correttamente nel tuo Disaster Recovery Plan significa:
- ridurre al minimo la perdita di dati,
- garantire tempi di ripristino compatibili con le esigenze del business,
- proteggere fatturato, reputazione e fiducia dei clienti.
Molte aziende cadono nell’errore di sottovalutare questi parametri, salvo poi rendersi conto dell’impatto reale solo quando si verifica un incidente. Prevenire è l’unica strategia efficace.
Con le soluzioni di Disaster Recovery di Epiclink, puoi contare su infrastrutture cloud sicure, team di esperti e SLA garantiti per definire e rispettare RPO e RTO su misura per il tuo business.
Non aspettare che un imprevisto metta alla prova la tua azienda: contatta il nostro team commerciale e costruisci oggi la resilienza digitale di domani.
Articoli recenti


