Oracle RMAN: Backup e Restore del Database, Guida Pratica

Oracle RMAN: Backup e Recovery in Produzione (Guida 2026)

Mercoledì pomeriggio. 14:30. Un database Oracle da 800GB in produzione si blocca. Corruzione di dati. Il panico è un lusso che non ci si può permettere. La differenza tra un ripristino che richiede ore di lavoro frenetico e uno che si risolve in 45 minuti è spesso legata a un unico fattore: la corretta implementazione di Oracle Recovery Manager (RMAN). Un cliente enterprise, con un database critico di queste dimensioni, si affidava ancora a procedure di backup basate su export/import. Il CTO ha capito subito la differenza quando, dopo l’incidente, la stima per il recovery con i vecchi metodi era di 7 ore, mentre con un approccio RMAN ben congegnato avremmo potuto ripristinare al punto esatto del guasto in meno di un’ora. Questo articolo è una guida pratica per configurare e gestire RMAN, trasformando un potenziale disastro in un inconveniente gestibile.

Prerequisiti / Ambiente di test

Per seguire questa guida, avrai bisogno di un ambiente Oracle Database (versione 12c o successiva, preferibilmente 19c o 23c) installato su un sistema Linux. Assicurati di avere accesso a un utente con privilegi SYSDBA e che il database sia in esecuzione, almeno in modalità MOUNT. La disponibilità di spazio su disco per i backup e, idealmente, di un sistema di storage esterno (NAS, SAN) o un media management layer (come Oracle Secure Backup o un’integrazione SBT) è fondamentale per una soluzione di produzione robusta. Per i test, è sufficiente uno spazio disco locale o una VM dedicata.

RMAN vs export/import: perché RMAN in produzione

Molti amministratori meno esperti si affidano ancora a expdp/impdp (Data Pump) per il backup e il ripristino. Sebbene utile per migrazioni di schemi o tabelle, Data Pump non è una soluzione di Disaster Recovery per un database completo. Non gestisce la corruzione a livello di blocco, non permette un recovery point-in-time preciso e richiede che il database sia online e accessibile. RMAN, al contrario, opera a livello di blocco dati, consentendo backup e ripristini granulari e veloci. Permette di recuperare il database a qualsiasi momento specifico (point-in-time recovery) e può rilevare e gestire blocchi corrotti. Secondo Oracle, l’85% delle installazioni database enterprise di fascia alta utilizza RMAN per i backup e i recovery critici (Oracle Database Admin Guide 2025).

Archivelog mode: prerequisito per backup consistenti

Per poter eseguire un recovery point-in-time, è imperativo che il database sia in ARCHIVELOG MODE. Questa modalità garantisce che tutti i redo log (che registrano ogni transazione) vengano archiviati su disco prima di essere riutilizzati. Senza ARCHIVELOG MODE, è possibile eseguire solo recovery completi all’ultimo backup, perdendo tutte le transazioni successive. Questo non è accettabile in un ambiente di produzione.

Per abilitare l’archivelog mode:

SHUTDOWN IMMEDIATE;
STARTUP MOUNT;
ALTER DATABASE ARCHIVELOG;
ALTER DATABASE OPEN;

Verifica lo stato con ARCHIVE LOG LIST; in SQL*Plus. Una volta abilitato, RMAN potrà gestire backup consistenti e recovery flessibili.

Configurare RMAN: canali, policy, retention

Prima di iniziare i backup, è fondamentale configurare RMAN. Questo include la definizione dei canali (devices) per i backup, la policy di retention e altre impostazioni globali. I canali sono le interfacce che RMAN utilizza per leggere e scrivere i dati. Per i backup su disco, si usano canali DISK; per i backup su nastro tramite un media management software (MMS), si usano canali SBT_TAPE.

Esempio di configurazione:

RMAN>
CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS;
CONFIGURE CONTROLFILE AUTOBACKUP ON;
CONFIGURE DEVICE TYPE DISK PARALLELISM 2 BACKUP TYPE TO DISK;
CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT '/u01/app/oracle/backup/%U';

RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS;: RMAN manterrà i backup necessari per recuperare il database a qualsiasi momento negli ultimi 7 giorni.
CONTROLFILE AUTOBACKUP ON;: Assicura che il control file e lo SPFILE vengano automaticamente backuppati ogni volta che la struttura del database cambia o dopo ogni backup riuscito. Cruciale per il recovery.
DEVICE TYPE DISK PARALLELISM 2;: Configura RMAN per usare 2 canali paralleli per i backup su disco, migliorando le performance.

Backup incrementale livello 0 e 1

I backup incrementali sono la spina dorsale di una strategia di recovery efficiente. Un backup di livello 0 è un backup completo di tutti i blocchi usati. I backup di livello 1, invece, salvano solo i blocchi che sono stati modificati dall’ultimo backup di livello 0 o 1. Questo riduce notevolmente lo spazio occupato e i tempi di esecuzione dei backup quotidiani.

Esempio di backup di livello 0 (completo):

RMAN>
BACKUP INCREMENTAL LEVEL 0 DATABASE PLUS ARCHIVELOG;

Questo comando esegue un backup completo del database e include anche i redo log archiviati. È tipicamente eseguito una volta a settimana.

Esempio di backup di livello 1 (differenziale o cumulativo):

RMAN>
BACKUP INCREMENTAL LEVEL 1 DATABASE PLUS ARCHIVELOG;

Per un backup differenziale, RMAN salverà solo i blocchi modificati dall’ultimo backup di livello 0 o 1. Per un backup cumulativo (salva tutti i blocchi modificati dall’ultimo livello 0), si usa BACKUP INCREMENTAL LEVEL 1 CUMULATIVE DATABASE PLUS ARCHIVELOG;. I backup cumulativi sono più rapidi da ripristinare ma occupano più spazio dei differenziali.

Backup to disk e to tape (SBT)

RMAN offre flessibilità per archiviare i backup. Su disco (DISK) è la soluzione più comune per i backup veloci e i recovery a breve termine. Per la conservazione a lungo termine o per ambienti con requisiti di offsite storage, il backup su nastro tramite un Media Management Software (MMS) utilizzando l’interfaccia SBT (System Backup to Tape) è lo standard. Molti prodotti di backup (come Veritas NetBackup, Commvault, Veeam) offrono plugin SBT per Oracle.

Esempio di backup su disco:

RMAN>
BACKUP DATABASE PLUS ARCHIVELOG;

Questo comando, con la configurazione CONFIGURE CHANNEL DEVICE TYPE DISK, scriverà i backup nelle directory specificate.

Per il backup su nastro, la configurazione RMAN includerebbe un canale SBT:

RMAN>
CONFIGURE CHANNEL DEVICE TYPE SBT PARMS 'SBT_LIBRARY=/path/to/your/sbt_library.so';
BACKUP DEVICE TYPE SBT DATABASE PLUS ARCHIVELOG;

Validare i backup: VALIDATE e CROSSCHECK

Un backup non testato è un backup inutile. Non fidarti ciecamente che i tuoi backup funzionino. RMAN offre comandi per verificare l’integrità dei backup e la loro disponibilità.

VALIDATE verifica che i file di backup possano essere letti e che non siano corrotti. Non esegue il ripristino, ma simula il processo per rilevare problemi.

RMAN>
VALIDATE DATABASE;

Questo comando può essere esteso per validare specifici backup set o datafiles.

CROSSCHECK verifica che i file di backup registrati nel repository RMAN (o nel control file) siano effettivamente presenti e accessibili sul media di backup. Se un file non è trovato, RMAN lo segna come EXPIRED.

RMAN>
CROSSCHECK BACKUP;
CROSSCHECK ARCHIVELOG ALL;
LIST BACKUP SUMMARY;

Eseguire regolarmente queste operazioni è cruciale per la salute del tuo sistema di backup. Si stima che il 20% dei backup aziendali non sia recuperabile a causa di errori non rilevati (Symantec Data Protection Report 2024).

Recovery point-in-time: ripristino a un’ora specifica

Il recovery point-in-time (PITR) è una delle funzionalità più potenti di RMAN. Ti permette di recuperare il database allo stato esatto in un momento specifico prima di un errore logico (es. cancellazione accidentale di dati) o un crash. Questo richiede l’ARCHIVELOG MODE abilitato.

Esempio di PITR a un momento specifico:

RMAN>
RUN {
  SET UNTIL TIME "TO_DATE('2026-06-11 14:20:00', 'YYYY-MM-DD HH24:MI:SS')";
  RESTORE DATABASE;
  RECOVER DATABASE;
}

In questo scenario, stiamo ripristinando il database allo stato delle 14:20:00 del 11 giugno 2026. RMAN selezionerà automaticamente i backup necessari e applicherà i redo log archiviati fino al punto specificato.

Automazione con crontab e script shell

L’automazione è fondamentale per garantire che i backup vengano eseguiti regolarmente e senza errori umani. Un approccio comune è combinare script shell con crontab su sistemi Linux.

Crea uno script shell (es. backup_full.sh):

#!/bin/bash

ORACLE_HOME=/u01/app/oracle/product/19.0.0/dbhome_1
ORACLE_SID=ORCL
export ORACLE_HOME ORACLE_SID

LOG_FILE=/u01/app/oracle/backup/rman_full_$(date +%Y%m%d%H%M).log

$ORACLE_HOME/bin/rman target / << EOF > $LOG_FILE 2>&1
RUN {
  ALLOCATE CHANNEL c1 DEVICE TYPE DISK FORMAT '/u01/app/oracle/backup/full/%U';
  ALLOCATE CHANNEL c2 DEVICE TYPE DISK FORMAT '/u01/app/oracle/backup/full/%U';
  BACKUP INCREMENTAL LEVEL 0 DATABASE PLUS ARCHIVELOG;
  RELEASE CHANNEL c1;
  RELEASE CHANNEL c2;
}
EXIT;
EOF

# Aggiungi qui logica di notifica email o monitoraggio

Quindi, aggiungi una voce a crontab (eseguito come utente oracle):

# Esegui backup completo ogni domenica a mezzanotte
0 0 * * 0 /path/to/backup_full.sh

# Esegui backup incrementale ogni giorno alle 2:00
0 2 * * * /path/to/backup_incremental.sh

L’automazione riduce la probabilità di errori e garantisce la conformità alle policy di backup. Un’organizzazione con 2.000 endpoint e 300+ VM VMware deve automatizzare il 90% delle operazioni di routine per mantenere gli SLA (Service Level Agreement).

Errori comuni e troubleshooting

Spazio su disco insufficiente: Il problema più comune. Monitora lo spazio e implementa policy di retention aggressive o trasferisci i backup su storage esterno.
Archivelog mode disabilitato: Impossibile eseguire PITR. Verificare e abilitare immediatamente.
Backup non validati: Non dare per scontato che i backup funzionino. Esegui VALIDATE e CROSSCHECK regolarmente.
Problemi di connettività SBT: Se usi backup su nastro, verifica che il Media Management Software sia configurato correttamente e che la libreria SBT sia accessibile.
Problemi di performance: Utilizza più canali paralleli (PARALLELISM) e considera l’uso di sezioni per i datafiles di grandi dimensioni (SECTION SIZE).

FAQ — Domande Frequenti

D: Qual è la differenza principale tra RMAN e Data Pump (expdp/impdp)?

R: RMAN è uno strumento di backup e recovery a basso livello (blocchi dati) progettato per il Disaster Recovery completo del database, inclusi i blocchi corrotti e il recovery point-in-time. Data Pump opera a livello logico (oggetti di schema) ed è più adatto per migrazioni di dati o backup di oggetti specifici, non per un recovery completo del database in caso di guasto hardware o corruzione grave.

D: Posso eseguire un backup RMAN mentre il database è online e in uso?

R: Sì, RMAN è progettato per eseguire backup online (hot backup) senza interrompere l’attività del database. Questo è possibile grazie all’uso degli archivelog e del meccanismo di consistenza di Oracle. È la modalità consigliata per gli ambienti di produzione per minimizzare il downtime.

D: Quanto spesso dovrei eseguire i backup incrementali di livello 0 e 1?

R: La frequenza dipende dal tuo Recovery Point Objective (RPO) e Recovery Time Objective (RTO). Tipicamente, un backup di livello 0 (completo) viene eseguito settimanalmente. I backup di livello 1 (differenziali o cumulativi) vengono eseguiti quotidianamente o anche più volte al giorno per minimizzare la perdita di dati in caso di guasto. Gli archivelog vengono backuppati continuamente o ogni poche ore.

D: Come posso testare un recovery RMAN senza influenzare il database di produzione?

R: Il modo migliore è creare un ambiente di test separato con una copia del tuo database di produzione (usando RMAN DUPLICATE o un ripristino su una nuova macchina). Esegui il recovery in questo ambiente di test per verificare che le tue procedure e i tuoi backup funzionino come previsto. Questo è un passaggio critico che molti trascurano.

Conclusioni con takeaway operativi

La gestione dei backup e del recovery di un database Oracle in produzione non è un’opzione, ma una necessità critica. RMAN è lo strumento definitivo per questo scopo, offrendo flessibilità, granularità e affidabilità. La chiave è una configurazione proattiva, una strategia di backup incrementale ben definita, una validazione costante e, soprattutto, l’automazione. Non aspettare che si verifichi un disastro per scoprire che la tua strategia di backup è inadeguata. Investi tempo nella comprensione e nell’implementazione corretta di RMAN oggi stesso, e sarai pronto quando il tuo team IT avrà bisogno di ripristinare il servizio in tempi record. La differenza tra ore e minuti di downtime può costare milioni.

Aggiornato: giugno 2026