Oracle RMAN para Backup y Recovery

By FrankDatabases, Oracle

Oracle RMAN (Recovery Manager) es una de las herramientas fundamentales para administrar respaldos, restauración y recuperación de bases de datos Oracle.

Si trabajas como DBA, Production Support, SRE o administrador de infraestructura Oracle, conocer RMAN puede ser fundamental cuando necesitas responder preguntas como:

  • ¿Tenemos un backup válido?
  • ¿Cuándo fue el último backup?
  • ¿Podemos recuperar la base de datos?
  • ¿Falta algún archive log?
  • ¿Cómo restauramos un datafile?
  • ¿Cómo recuperamos una base completa?
  • ¿Cómo validamos los backups sin restaurarlos?

En esta guía veremos algunos de los comandos RMAN más utilizados en operaciones diarias.

Importante: Los ejemplos son educativos. Los procedimientos reales dependen de la versión de Oracle, arquitectura, FRA, ASM/filesystem, Recovery Catalog, política de retención, encryption, RAC y estrategia de recuperación de cada organización. Antes de ejecutar RESTORE, RECOVER, DELETE, CROSSCHECK o cambios de configuración en producción, valida el procedimiento correspondiente.

1. Conectarse a RMAN

Para conectarnos a la base de datos local:

rman target /

También podemos especificar un servicio:

rman target sys@PROD

RMAN mostrará información similar a:

connected to target database: PROD

Si utilizamos Recovery Catalog:

rman target / catalog rman@RCAT

Conceptualmente:

RMAN
 ↓
Target Database
 ↓
Control File

Opcionalmente:

RMAN
 ↓
Target Database
 +
Recovery Catalog

2. Revisar la configuración de RMAN

Uno de los primeros comandos que debemos conocer:

RMAN> SHOW ALL;

Este comando muestra la configuración persistente de RMAN.

Podemos encontrar parámetros relacionados con:

Retention Policy
Device Type
Controlfile Autobackup
Parallelism
Compression
Encryption
Backup Optimization
Archivelog Deletion Policy

Antes de modificar una estrategia de backup, conviene entender primero la configuración existente.

3. Mostrar información de los backups

Para listar todos los backups conocidos por RMAN:

RMAN> LIST BACKUP;

Mostrar un resumen:

RMAN> LIST BACKUP SUMMARY;

Esta es una de las consultas más prácticas para operaciones diarias.

También podemos consultar:

RMAN> LIST BACKUP OF DATABASE;

Controlfile:

RMAN> LIST BACKUP OF CONTROLFILE;

SPFILE:

RMAN> LIST BACKUP OF SPFILE;

Archive logs:

RMAN> LIST BACKUP OF ARCHIVELOG ALL;

4. Generar un backup completo de la base

Un backup básico:

RMAN> BACKUP DATABASE;

Para incluir archive logs:

RMAN> BACKUP DATABASE PLUS ARCHIVELOG;

Este último es un comando muy conocido porque permite respaldar la base junto con los archive logs necesarios para recuperación.

5. Backup comprimido

Podemos generar backupsets comprimidos:

RMAN> BACKUP AS COMPRESSED BACKUPSET DATABASE;

Base de datos y archive logs:

RMAN> BACKUP AS COMPRESSED BACKUPSET DATABASE PLUS ARCHIVELOG;

La compresión puede reducir almacenamiento, aunque también puede incrementar consumo de CPU.

6. Backup de un tablespace

No siempre necesitamos respaldar toda la base.

Por ejemplo:

RMAN> BACKUP TABLESPACE USERS;

Otro tablespace:

RMAN> BACKUP TABLESPACE APP_DATA;

7. Backup de un datafile

Podemos respaldar un datafile específico:

RMAN> BACKUP DATAFILE 5;

También es posible identificar datafiles desde SQL:

SELECT
    file_id,
    tablespace_name,
    file_name
FROM dba_data_files
ORDER BY file_id;

8. Backup del Control File

El control file es crítico para la recuperación.

RMAN> BACKUP CURRENT CONTROLFILE;

También podemos configurar:

RMAN> CONFIGURE CONTROLFILE AUTOBACKUP ON;

Verificar:

RMAN> SHOW CONTROLFILE AUTOBACKUP;

En muchos ambientes productivos, mantener habilitado el autobackup del control file es una parte importante de la estrategia de recuperación.

9. Backup del SPFILE

RMAN> BACKUP SPFILE;

También podemos respaldar SPFILE y controlfile juntos:

RMAN> BACKUP CURRENT CONTROLFILE;
RMAN> BACKUP SPFILE;

Cuando CONTROLFILE AUTOBACKUP está habilitado, RMAN puede proteger automáticamente información crítica relacionada con controlfile y SPFILE en determinados escenarios de backup.

10. Backup de Archive Logs

Todos los archive logs:

RMAN> BACKUP ARCHIVELOG ALL;

Podemos respaldarlos y posteriormente eliminarlos, según la política establecida:

RMAN> BACKUP ARCHIVELOG ALL DELETE INPUT;

Mucho cuidado con DELETE INPUT.

Este comando elimina archive logs respaldados conforme RMAN procesa la operación.

Antes de utilizarlo debemos comprender:

  • Data Guard;
  • políticas de retención;
  • replicas;
  • necesidades de recuperación;
  • FRA;
  • archive destinations.

No deberíamos borrar archive logs únicamente porque el filesystem está lleno.

11. Forzar generación de Archive Log antes del backup

Desde SQL:

ALTER SYSTEM ARCHIVE LOG CURRENT;

También RMAN puede manejar archive logs dentro de operaciones como:

RMAN> BACKUP DATABASE PLUS ARCHIVELOG;

12. Revisar qué backups existen

Resumen:

RMAN> LIST BACKUP SUMMARY;

Por base:

RMAN> LIST BACKUP OF DATABASE;

Por archive logs:

RMAN> LIST BACKUP OF ARCHIVELOG ALL;

También:

RMAN> LIST COPY;

La diferencia conceptual importante es:

Backup Set
vs.
Image Copy

Un backupset utiliza el formato interno de RMAN.

Una image copy es una copia de un archivo de base de datos administrada por RMAN.

13. Reportar backups obsoletos

RMAN> REPORT OBSOLETE;

RMAN utiliza la política de retención configurada para determinar qué backups considera obsoletos.

Podemos revisar la política:

RMAN> SHOW RETENTION POLICY;

Por ejemplo:

CONFIGURE RETENTION POLICY TO REDUNDANCY 2;

o una Recovery Window:

CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS;

No debemos confundir:

OBSOLETE

con:

EXPIRED

Son conceptos diferentes.

14. Eliminar backups obsoletos

Primero:

RMAN> REPORT OBSOLETE;

Después, si la política y el procedimiento lo permiten:

RMAN> DELETE OBSOLETE;

RMAN solicitará confirmación.

Existe también:

RMAN> DELETE NOPROMPT OBSOLETE;

pero automatizar eliminaciones requiere todavía más cuidado.

15. CROSSCHECK

Uno de los comandos fundamentales:

RMAN> CROSSCHECK BACKUP;

También:

RMAN> CROSSCHECK ARCHIVELOG ALL;

CROSSCHECK compara la información que RMAN tiene registrada con la disponibilidad física de los archivos.

Conceptualmente:

RMAN Repository
      ↓
¿Existe físicamente?
      ↓
Backup / Archive Log

16. Backup EXPIRED

Después de un CROSSCHECK, RMAN puede marcar determinados objetos como:

EXPIRED

Podemos consultar:

RMAN> LIST EXPIRED BACKUP;

Para archive logs:

RMAN> LIST EXPIRED ARCHIVELOG ALL;

Eliminar las referencias expiradas:

RMAN> DELETE EXPIRED BACKUP;

o:

RMAN> DELETE EXPIRED ARCHIVELOG ALL;

Esto elimina registros del repositorio RMAN correspondientes a objetos que ya no se encuentran disponibles; no es lo mismo que eliminar un backup físico válido.

17. Validar un backup

Que un backup aparezca en:

LIST BACKUP

no significa que debamos asumir automáticamente que todo está perfecto.

RMAN proporciona mecanismos de validación.

Por ejemplo:

RMAN> VALIDATE DATABASE;

También:

RMAN> BACKUP VALIDATE DATABASE;

Estas operaciones pueden utilizarse para comprobar la capacidad de RMAN para leer bloques y detectar determinados problemas sin crear necesariamente un backup normal.

18. Validar una restauración sin restaurar realmente

Uno de los comandos más útiles:

RMAN> RESTORE DATABASE VALIDATE;

Esto permite verificar si RMAN encuentra los backups necesarios para realizar la restauración, sin efectuar la restauración real de la base.

También podemos usar:

RMAN> RESTORE DATAFILE 5 VALIDATE;

Este concepto es muy importante:

Tener backups no es lo mismo que demostrar que podemos restaurarlos.

19. RESTORE vs RECOVER

Esta diferencia debe quedar muy clara.

RESTORE

RMAN obtiene los archivos desde el backup.

Backup
  ↓
RESTORE
  ↓
Datafile

RECOVER

Oracle aplica redo/archive logs para llevar esos archivos hacia un estado consistente.

Restored Datafile
      ↓
Archive Logs / Redo
      ↓
RECOVER
      ↓
Recovered Datafile

Por eso normalmente hablamos de:

RESTORE
+
RECOVER

20. Restaurar un datafile

Supongamos que perdimos el datafile 5.

Podemos identificarlo:

SELECT
    file_id,
    tablespace_name,
    file_name
FROM dba_data_files
WHERE file_id = 5;

Conceptualmente, el procedimiento puede involucrar:

RMAN> RESTORE DATAFILE 5;

seguido por:

RMAN> RECOVER DATAFILE 5;

Los pasos exactos de disponibilidad/offline/online dependen del escenario y de la versión.

21. Restaurar un tablespace

RMAN> RESTORE TABLESPACE USERS;

Después:

RMAN> RECOVER TABLESPACE USERS;

Una recuperación real puede requerir colocar temporalmente el tablespace offline dependiendo del escenario.

22. Restaurar toda la base

Un procedimiento conceptual típico es:

SHUTDOWN IMMEDIATE;
STARTUP MOUNT;

Después:

RMAN> RESTORE DATABASE;

Y:

RMAN> RECOVER DATABASE;

Finalmente, dependiendo del tipo de recuperación:

ALTER DATABASE OPEN;

o podría ser necesario:

ALTER DATABASE OPEN RESETLOGS;

RESETLOGS no debe ejecutarse automáticamente.

Su necesidad depende del escenario de recuperación, especialmente en recuperaciones incompletas o determinadas restauraciones del controlfile.

23. Point-in-Time Recovery

RMAN puede recuperar una base hasta un momento específico.

Por ejemplo:

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

Después de una recuperación incompleta normalmente existe un procedimiento específico para abrir la base, frecuentemente involucrando RESETLOGS.

Este tipo de recuperación debe estar cuidadosamente planificado.

24. Recovery por SCN

También podemos recuperar hasta un SCN:

RMAN> RUN {
    SET UNTIL SCN 123456789;
    RESTORE DATABASE;
    RECOVER DATABASE;
}

25. Recovery por sequence

En determinados escenarios:

RMAN> RUN {
    SET UNTIL SEQUENCE 10500;
    RESTORE DATABASE;
    RECOVER DATABASE;
}

En ambientes RAC debemos considerar también los redo threads correspondientes.

26. Restaurar Control File

Si perdimos el controlfile y tenemos autobackup:

Primero podemos iniciar la instancia:

STARTUP NOMOUNT;

Después:

RMAN> RESTORE CONTROLFILE FROM AUTOBACKUP;

Posteriormente:

ALTER DATABASE MOUNT;

y continuar con el procedimiento de recuperación correspondiente.

La recuperación del controlfile es uno de los motivos por los que:

CONFIGURE CONTROLFILE AUTOBACKUP ON;

es una configuración tan importante.

27. Restaurar SPFILE

Si se pierde el SPFILE, dependiendo del escenario podemos arrancar la instancia con los parámetros mínimos necesarios y utilizar RMAN.

Conceptualmente:

RMAN> RESTORE SPFILE FROM AUTOBACKUP;

Después podremos continuar con el procedimiento de startup correspondiente.

28. Revisar fallos detectados

Dependiendo de la versión y funcionalidad disponible:

RMAN> LIST FAILURE;

También:

RMAN> ADVISE FAILURE;

Y en escenarios soportados:

RMAN> REPAIR FAILURE;

Estas funciones pertenecen al Data Recovery Advisor, cuya disponibilidad y uso dependen de la versión/edición.

29. Revisar el FRA

Muchas instalaciones Oracle utilizan Fast Recovery Area.

Desde SQL:

SELECT
    name,
    space_limit/1024/1024/1024 AS limit_gb,
    space_used/1024/1024/1024 AS used_gb,
    space_reclaimable/1024/1024/1024 AS reclaimable_gb
FROM v$recovery_file_dest;

También:

SELECT *
FROM v$flash_recovery_area_usage;

Un FRA lleno puede provocar problemas importantes con:

Archive Logs
RMAN Backups
Flashback Logs
Database availability

No debemos resolver automáticamente un FRA lleno eliminando archivos desde Linux.

RMAN debe mantener consistencia entre:

Archivos físicos
        ↕
RMAN Repository

30. Revisar jobs de RMAN desde Oracle

Podemos consultar:

SELECT
    session_key,
    input_type,
    status,
    start_time,
    end_time
FROM v$rman_backup_job_details
ORDER BY start_time DESC;

Para revisar duración:

SELECT
    input_type,
    status,
    start_time,
    end_time,
    elapsed_seconds
FROM v$rman_backup_job_details
ORDER BY start_time DESC;

Esto resulta muy útil para monitoring y Production Support.

31. Revisar progreso de una operación

Para determinadas operaciones de larga duración:

SELECT
    sid,
    serial#,
    opname,
    sofar,
    totalwork,
    units
FROM v$session_longops
WHERE totalwork > 0
AND sofar <> totalwork;

Puede ayudarnos a identificar operaciones RMAN activas y su progreso.

32. Configurar paralelismo

Ejemplo:

RMAN> CONFIGURE DEVICE TYPE DISK PARALLELISM 4;

El paralelismo puede mejorar rendimiento, pero también puede aumentar:

CPU
I/O
Storage throughput
Network utilization

Más channels no significan automáticamente backups más rápidos.

33. Configurar compresión

Podemos revisar:

RMAN> SHOW COMPRESSION ALGORITHM;

Y configurar un algoritmo soportado por nuestra versión/licenciamiento.

La decisión debe balancear:

Menor almacenamiento
        ↕
Mayor consumo CPU

34. Backup Optimization

Podemos habilitar:

RMAN> CONFIGURE BACKUP OPTIMIZATION ON;

Consultar:

RMAN> SHOW BACKUP OPTIMIZATION;

La optimización puede evitar determinados backups redundantes cuando RMAN determina que ya existe una copia apropiada según sus reglas.

35. Crear un backup con TAG

Los tags ayudan muchísimo a identificar backups.

RMAN> BACKUP DATABASE TAG 'WEEKLY_FULL';

Archive logs:

RMAN> BACKUP ARCHIVELOG ALL TAG 'ARCH_DAILY';

Después:

RMAN> LIST BACKUP TAG 'WEEKLY_FULL';

36. Un bloque RUN

RMAN permite agrupar comandos:

RMAN> RUN {
    BACKUP DATABASE;
    BACKUP ARCHIVELOG ALL;
    BACKUP CURRENT CONTROLFILE;
}

Esto es muy común en scripts automatizados.

37. Ejemplo de script de backup

Un ejemplo conceptual:

#!/bin/bash

export ORACLE_SID=PROD
export ORACLE_HOME=/u01/app/oracle/product/19c/dbhome_1
export PATH=$ORACLE_HOME/bin:$PATH

rman target / <<EOF

RUN {
    BACKUP AS COMPRESSED BACKUPSET DATABASE
        TAG 'PROD_DB_BACKUP';

    BACKUP ARCHIVELOG ALL
        TAG 'PROD_ARCH_BACKUP';

    BACKUP CURRENT CONTROLFILE
        TAG 'PROD_CONTROLFILE';
}

EXIT;

EOF

En producción debemos agregar aspectos como:

Logging
Error handling
Monitoring
Exit codes
Notifications
Retention
Security
Scheduling

38. Comandos que deberías memorizar

Si estás comenzando con RMAN, yo empezaría por estos:

rman target /

SHOW ALL;

LIST BACKUP SUMMARY;

LIST BACKUP OF DATABASE;

LIST BACKUP OF ARCHIVELOG ALL;

BACKUP DATABASE;

BACKUP DATABASE PLUS ARCHIVELOG;

BACKUP AS COMPRESSED BACKUPSET DATABASE;

BACKUP ARCHIVELOG ALL;

BACKUP CURRENT CONTROLFILE;

CROSSCHECK BACKUP;

REPORT OBSOLETE;

LIST EXPIRED BACKUP;

VALIDATE DATABASE;

RESTORE DATABASE VALIDATE;

RESTORE DATABASE;

RECOVER DATABASE;

Y desde SQL:

SELECT *
FROM v$rman_backup_job_details
ORDER BY start_time DESC;

39. Flujo de troubleshooting de backups

Supongamos que recibimos la alerta:

“El backup nocturno de Oracle falló.”

En lugar de volver a ejecutar inmediatamente el backup, podemos investigar:

¿La base está disponible?
        ↓
Revisar estado de DB
        ↓
¿RMAN puede conectarse?
        ↓
rman target /
        ↓
¿Dónde falló el job?
        ↓
V$RMAN_BACKUP_JOB_DETAILS
        ↓
Revisar RMAN log
        ↓
Identificar ORA-/RMAN- errors
        ↓
¿Hay espacio disponible?
        ↓
Filesystem / ASM / FRA
        ↓
¿Archive destination está lleno?
        ↓
FRA / Archive Logs
        ↓
¿Existe problema de I/O?
        ↓
Storage
        ↓
¿Backup repository está consistente?
        ↓
CROSSCHECK
        ↓
Corregir causa
        ↓
Ejecutar / validar backup

40. Flujo conceptual de recuperación

Cuando existe pérdida de un archivo, piensa primero en:

¿Qué se perdió?
      ↓
Datafile?
Controlfile?
SPFILE?
Toda la base?
      ↓
¿Qué backups tenemos?
      ↓
LIST BACKUP
      ↓
¿Son utilizables?
      ↓
RESTORE ... VALIDATE
      ↓
¿Hasta qué punto debemos recuperar?
      ↓
Latest?
Time?
SCN?
Sequence?
      ↓
RESTORE
      ↓
RECOVER
      ↓
Validación
      ↓
OPEN / RESETLOGS si corresponde
      ↓
Validación funcional

La regla más importante de RMAN

Existe una diferencia enorme entre decir:

“Tenemos backups.”

y poder decir:

“Sabemos que podemos restaurar la base.”

Un backup exitoso es solamente una parte de una estrategia de recuperación.

Una estrategia madura debería considerar:

Backup
   ↓
Monitoring
   ↓
Retention
   ↓
Validation
   ↓
Restore Testing
   ↓
Recovery Testing
   ↓
RTO / RPO
   ↓
Documentación

RPO y RTO

Dos conceptos fundamentales:

RPO — Recovery Point Objective

¿Cuántos datos podemos permitirnos perder?

RTO — Recovery Time Objective

¿Cuánto tiempo podemos permitirnos estar sin servicio?

Estos dos objetivos deberían influir directamente en la estrategia de RMAN.

Por ejemplo, tener un backup completo diario puede parecer suficiente técnicamente, pero si el negocio exige:

RPO = 15 minutos
RTO = 1 hora

la arquitectura de recuperación necesita diseñarse específicamente para cumplir esos objetivos.

El verdadero objetivo de RMAN no es crear archivos de backup.

Es garantizar que, cuando ocurra una falla, podamos restaurar los datos correctos, recuperar hasta el punto requerido y devolver el servicio dentro de los objetivos establecidos por el negocio.

¿Cuándo fue la última vez que validaste una restauración de tus backups de Oracle?

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *