DBADati e Oracle

Copia, replica e ripristino del database Oracle: che cosa deve sapere la direzione

Copia di sicurezza, replica e ripristino proteggono da guasti diversi. Che cosa copre ciascuno in un database Oracle, che cosa resta scoperto e quali scelte spettano alla direzione prima che servano.

Redazione Strategic 20 ottobre 2026 8 min di lettura

Copertina: «Copia, replica, ripristino: tre cose diverse», Dati e Oracle

Copia di sicurezza, replica e ripristino non sono tre nomi della stessa cosa. La copia (backup) conserva il database com’era in momenti precisi e permette di tornare indietro nel tempo. La replica è un secondo database, allineato di continuo, pronto a prendere il posto del primo se si guasta un server o un intero sito. Il ripristino è l’operazione che trasforma una copia in un database di nuovo funzionante, ed è l’unica prova che le altre due servono davvero. In ambiente Oracle si realizzano di solito con RMAN, con Data Guard e con prove a calendario. Chi ne ha solo una è protetto da alcuni guasti e scoperto su altri: sapere quali, prima che accada, è una decisione della direzione.

Documentazione Oracle consultata il 16 settembre 2026. Le funzioni citate dipendono da versione ed edizione del database.

Che cosa si intende per copia, replica e ripristino?

	Che cos’è	Strumento Oracle tipico	Domanda a cui risponde
Copia di sicurezza	I file del database salvati in un momento preciso e conservati altrove, con i log delle modifiche successive	RMAN (Recovery Manager)	«Possiamo tornare a com’era martedì alle 10?»
Replica	Un secondo database, su un altro server o in un altro sito, che riceve e applica le modifiche della produzione	Data Guard, con un database di riserva (standby)	«Se si ferma il server, dove si lavora tra pochi minuti?»
Ripristino	Il recupero dei file dalla copia e l’applicazione delle modifiche fino all’istante scelto	RMAN, con una procedura scritta	«Quanto ci mettiamo davvero, e fino a quale momento recuperiamo i dati?»

Oracle distingue due passaggi: il restore riprende i file dalla copia, il recover applica le modifiche registrate nei log fino all’istante scelto. Per copiare il database mentre lavora serve la modalità ARCHIVELOG, che conserva i log; senza, vale solo la copia fatta a database chiuso, e ciò che è avvenuto dopo va perso.

Da che cosa protegge ciascuna?

Evento	Copia con RMAN	Replica con Data Guard
Guasto del server o dei dischi	Sì, ma ripartire richiede il tempo del ripristino	Sì: il database di riserva prende il ruolo della produzione (failover)
Sito inutilizzabile	Sì, se la copia è conservata altrove	Sì, se la replica sta in un altro sito
Blocchi di dati danneggiati	Sì, con il recupero dai file di copia	Oracle indica che le corruzioni fisiche non passano alla replica, perché i dati ricevuti vengono verificati
Dati cancellati o modificati per errore	Sì: si torna a un istante precedente	Di norma no: la replica applica anche l’errore
Attacco con credenziali da amministratore	Sì, se la copia è isolata e ha credenziali proprie	Solo se la replica non è raggiungibile con le stesse credenziali
Manutenzione pianificata	È la rete di sicurezza prima di ogni intervento	Lo scambio di ruoli (switchover) riduce il fermo, senza perdita di dati

La replica protegge la continuità del servizio, la copia protegge la storia dei dati. Una non sostituisce l’altra.

Perché la replica non basta?

Perché copia fedelmente anche ciò che non si vorrebbe. Un’elaborazione lanciata con un parametro sbagliato, una tabella cancellata per errore, un aggiornamento difettoso del gestionale: sono operazioni valide per il database, e il database di riserva le applica come tutte le altre. La documentazione di Data Guard indica due rimedi, da decidere prima. Il primo è ritardare l’applicazione delle modifiche sulla replica, con un compromesso dichiarato: in caso di guasto il passaggio richiede più tempo, perché il database di riserva deve prima recuperare il ritardo. Il secondo è usare Flashback Database sulla replica per riportarla indietro ed estrarre i dati buoni.

La replica, inoltre, conserva solo il presente. Se un errore viene scoperto dopo tre settimane, servono copie conservate per almeno tre settimane. Quanto a lungo tenerle, e con quali copie isolate, lo spiega l’Osservatorio nell’articolo sulla regola dei tre cassetti.

Anche la replica ha le sue scelte. Data Guard lavora in tre modalità. In massime prestazioni, la predefinita, la produzione non aspetta la replica: in caso di guasto possono mancare le ultime transazioni. In massima disponibilità non si perdono dati se almeno una replica è sincronizzata. In massima protezione la produzione si ferma piuttosto che lavorare senza protezione, e Oracle raccomanda almeno due database di riserva. È una scelta d’impresa, non solo tecnica.

Scenario tipico. Un’azienda di logistica ha il gestionale su Oracle Enterprise Edition e un database di riserva in un secondo sito. Un venerdì sera un’elaborazione lanciata con un parametro sbagliato azzera le giacenze di un magazzino, e il database di riserva applica subito la stessa modifica. Le giacenze si recuperano dalla copia della notte precedente e dai log, fino a un minuto prima dell’errore: in Enterprise Edition RMAN può recuperare anche singole tabelle. Riesce perché i log erano conservati e la procedura era già stata provata.

Che cosa cambia con l’edizione e le licenze?

Standard Edition 2. RMAN c’è, ma il manuale delle licenze riserva alla Enterprise Edition funzioni come il backup in parallelo, il recupero dei singoli blocchi e delle singole tabelle, la prova di recupero. Data Guard e Flashback Database non sono inclusi: la continuità si progetta con copie più frequenti e procedure di ripartenza provate.
Enterprise Edition. Data Guard e Flashback Database sono compresi nella licenza.
Active Data Guard. È un’opzione a pagamento. Permette, tra l’altro, di consultare il database di riserva mentre riceve le modifiche e di riparare in automatico i blocchi danneggiati.

Nelle architetture di riferimento di Oracle, al livello base si riparte dalla copia e si possono perdere i dati prodotti dopo l’ultima; i livelli superiori aggiungono il cluster e poi la replica. La stessa guida consiglia di trattare i database collegati tra loro secondo le esigenze del più severo.

Che cosa decide la direzione, e che cosa l’IT?

La direzione stabilisce che cosa proteggere e fino a che punto. L’IT traduce quelle scelte in tecnologia e le dimostra con le prove.

Tempi e perdite accettabili, database per database: per quanto si può restare fermi e quanti dati si accetta di perdere.
Gli eventi da coprire: guasto del server, perdita del sito, errore umano, attacco informatico.
Quanto indietro nel tempo: la durata di conservazione delle copie, decisa con l’amministrazione e con chi si occupa della protezione dei dati.
Chi decide il passaggio sulla replica e chi decide il ritorno a un istante precedente, sapendo che in quel caso una parte del lavoro va rifatta.
Il budget: edizione, secondo sito, opzioni a licenza, ore di prova.
Le prove: cadenza, perimetro e destinatari del verbale.

Come si dimostra che il ripristino funziona?

Con prove di complessità crescente:

Verifica delle copie. RESTORE ... VALIDATE legge tutti i blocchi delle copie come in un ripristino vero, ma senza scrivere i file. Dice se le copie sono leggibili, non quanto tempo serve.
Prova di recupero. In Enterprise Edition, RECOVER ... TEST applica i log in memoria e annulla tutto alla fine.
Ripristino completo su un server separato. Si cronometra, si apre l’applicazione e si chiede a un utente di controllare dati che conosce, come il totale delle fatture del mese.
Scambio di ruoli con la replica, in una finestra concordata, per verificare che applicazioni e utenti trovino il database di riserva.

Ogni prova finisce in un verbale con data, copia usata, tempo effettivo ed esito, e si ripete dopo ogni cambiamento rilevante: nuova versione, nuovo storage, nuovo sito. Il 20 ottobre 2026 Oracle pubblica anche le patch trimestrali: prima di applicarle in produzione, una copia verificata è la prima condizione della finestra di manutenzione.

In sintesi

La copia conserva la storia dei dati, la replica tiene in piedi il servizio, il ripristino dimostra che entrambe funzionano.
La replica applica anche gli errori: senza copie conservate nel tempo, un dato cancellato per sbaglio può non tornare.
Data Guard offre tre modalità di protezione, con compromessi diversi tra perdita di dati e continuità.
Le istantanee dello storage valgono come copie solo se rispettano i requisiti di Oracle; in Standard Edition 2 Data Guard e Flashback Database non ci sono.
Tempi, perdite accettabili ed eventi da coprire li decide la direzione; le prove a verbale dicono se la tecnica li rispetta.

Domande frequenti

Con Data Guard servono ancora le copie?

Sì. Data Guard protegge dai guasti di server e sito, ma di norma applica anche cancellazioni e modifiche sbagliate. Per tornare a un momento precedente all’errore servono copie conservate nel tempo, o soluzioni come il ritardo di applicazione e Flashback Database, decise in anticipo.

Un’istantanea dello storage o della macchina virtuale basta?

Solo a condizioni precise. Oracle chiede che durante l’istantanea il database sia coerente come dopo un arresto improvviso, che l’ordine delle scritture sia preservato per ogni file e che l’ora dell’istantanea sia registrata; altrimenti i file vanno messi in modalità backup prima della copia. In ogni caso l’istantanea va provata con un ripristino vero.

Il database di riserva può servire anche per i report?

Con l’opzione Active Data Guard sì: il database di riserva resta consultabile mentre riceve le modifiche, e alleggerisce la produzione. Senza l’opzione, il database di riserva si può aprire in sola lettura solo sospendendo l’applicazione delle modifiche, e intanto resta indietro rispetto alla produzione.

Scegliere le protezioni giuste per ogni database, progettare copie e repliche coerenti con le licenze e ripetere le prove di ripristino a verbale è il lavoro che la divisione Oracle & Database Engineering svolge in outsourcing o accanto al team interno. Per chi prepara anche un cambio di versione, le decisioni sono riassunte nell’articolo sull’aggiornamento del database Oracle.