Continuità · Backup / DR

Backup e disaster recovery: RPO, RTO e test di restore

Un backup senza RPO/RTO definiti e test di restore è solo costo disco. Un disaster recovery senza procedura e finestre di comunicazione è un piano di carta. Nel modello gestito entrambe le layer devono far parte dello SLA — non un extra « quando c'è tempo ».

RPO e RTO — in parole chiare

• RPO (Recovery Point Objective) — quanta perdita di dati è accettabile (ad esempio 15 minuti, 4 ore),
• RTO (Recovery Time Objective) — in quanto tempo l'ambiente deve tornare in esercizio.

Valori più bassi implicano un'architettura più costosa: snapshot più frequenti, replica, warm/hot standby, sito separato. Non ogni applicazione ha bisogno di un RPO quasi zero. In BaseCloud RPO/RTO valgono solo se contrattuali dopo la valutazione. Non pubblichiamo una data di « ultimo restore » come promessa di prodotto.

Errori frequenti nella pratica

• backup sullo stesso array / nella stessa AZ della produzione,
• nessun test di restore (o un test « ogni due anni »),
• poco chiaro chi approva il restore e chi comunica con i clienti,
• retention troppo breve per contabilità o requisiti di settore.

Cosa include il DR gestito in BaseCloud

Nei pacchetti Professional ed Enterprise le procedure di backup e ripristino fanno parte dell'esercizio: calendari, monitoraggio dei job, retention e partecipazione ai test DR. Il perimetro RPO/RTO si precisa dopo la valutazione — non promettiamo « zero downtime » senza un'architettura che lo consenta davvero.

Checklist prima di firmare lo SLA

• elenco dei sistemi critici e dei rispettivi owner di business,
• obiettivi RPO/RTO per sistema (non un unico numero per tutta l'azienda),
• frequenza e forma dei test di restore,
• percorso di escalation e report post-incidente.

Vedi i pacchetti · DORA e continuità operativa · Altri articoli