Servicio de copia de seguridad y recuperación tras fallos para Oracle

La base de datos de Oracle es una base de datos empresarial popular que admite aplicaciones esenciales. En esta página se presenta el servicio de copia de seguridad y recuperación tras fallos para entornos de bases de datos Oracle. La arquitectura asociada proporciona copias de seguridad incrementales y permanentes para las aplicaciones en Google Cloud, así como recuperación y clonación instantáneas para bases de datos de Oracle de varios terabytes.

Cómo funciona

En las siguientes secciones se describe el proceso de captura y recuperación de datos.

Captura de datos

  1. El agente de copia de seguridad y recuperación tras fallos se implementa en el servidor de Oracle.

  2. Monta el disco de almacenamiento provisional en el servidor de la base de datos.

  3. Invoca la API incremental de RMAN para copiar los bloques modificados.

  4. Invoca la combinación incremental de RMAN para crear una copia completa virtual.

  5. Desmonta el disco de almacenamiento provisional del servidor de la base de datos.

  6. Copia de seguridad y recuperación tras fallos hace una captura interna. La copia completa sintética de un momento dado está lista.

Recuperación de datos

Copia de seguridad y recuperación ante desastres monta al instante un disco de almacenamiento temporal regrabable a través de iSCSI o NFS y pone la base de datos online.

APIs de copias de seguridad de Oracle

Backup and DR usa las siguientes APIs de Oracle:

  • Copia de imagen de RMAN: una copia de imagen de un archivo de datos es mucho más rápida de restaurar porque la estructura física del archivo de datos ya existe. La directiva BACKUP AS COPY de RMAN crea copias de imagen de todos los archivos de datos de toda la base de datos y conserva el formato de los archivos de datos.

  • API de ASM y CRS: el grupo de discos de copia de seguridad de ASM se gestiona mediante la API de ASM y CRS.

  • API de copia de seguridad de registros de archivo de RMAN: los registros de archivo generados se copian en el disco de almacenamiento provisional y se eliminan de la ubicación de archivo de producción.

Minimizar los conflictos al usar el servicio de Backup y DR con otros productos de copia de seguridad

El servicio de copia de seguridad y recuperación ante desastres puede coexistir con productos antiguos que capturen datos de bases de datos de producción. Las siguientes prácticas recomendadas pueden ayudarle a mejorar su experiencia:

Frecuencia de las copias de seguridad de bases de datos de Oracle

Práctica recomendada Programa las tareas de copia de seguridad de la base de datos del servicio de copia de seguridad y recuperación ante desastres para que se inicien cuando el software de copia de seguridad antiguo haya finalizado. No programes el software de copias de seguridad antiguo para que se ejecute inmediatamente después de que se complete un trabajo de copia de seguridad de la base de datos del servicio Backup y DR.
Motivo Si los trabajos de copia de seguridad antiguos y los trabajos de copia de seguridad de la base de datos del servicio de copia de seguridad y recuperación tras fallos se ejecutan simultáneamente, puede que el rendimiento del servidor de la base de datos se vea gravemente afectado, lo que puede provocar inestabilidad y, posiblemente, una interrupción del servicio. Además, en el caso de Oracle, esto puede provocar que las imágenes de copia de seguridad no sean válidas en una o en ambas soluciones.

Gestión de registros de archivo de Oracle

Oracle usa los registros de archivo generados durante una copia de seguridad de la base de datos para asegurar la coherencia y la capacidad de recuperación de esa copia de seguridad. Por lo tanto, si los registros de archivo se purgan durante una tarea de copia de seguridad de la base de datos, esa copia de seguridad no se podrá recuperar.

Requisito Solo un sistema puede gestionar (capturar o truncar/purgar) los registros: el software de copia de seguridad antiguo o el servicio Backup y DR.
Práctica recomendada No permitas que los registros de archivo de Oracle se purguen durante un trabajo de Backup y DR, y no permitas que el servicio de Backup y DR purgue los registros de archivo durante un trabajo de copia de seguridad antiguo de RMAN.
Si el software antiguo gestiona el registro de archivo, inhabilita los trabajos de purga de registros de archivo en el software de copia de seguridad antiguo al inicio del trabajo de copia de seguridad de Backup y DR, y reanuda los trabajos de purga al final o conserva el registro de archivo durante un mínimo de 24 horas antes de purgarlo.
Motivo Si los registros de archivo se purgan durante una tarea de copia de seguridad de la base de datos, es posible que la imagen de copia de seguridad de la base de datos no se pueda recuperar.

Conflicto de metadatos de RMAN con copias de seguridad antiguas que hacen que las copias de seguridad del servicio de copia de seguridad y recuperación tras desastres queden obsoletas

De forma predeterminada, el parámetro DO NOT UNCATALOG en los detalles y ajustes de la aplicación del servicio de Backup y DR se define como No. Se cataloga una copia de seguridad de los datos de Backup y DR al inicio de la copia de seguridad y se descataloga al final de la tarea. Si se define este valor como Sí, se optimiza el tiempo de creación de copias de seguridad de las bases de datos con un gran número de archivos de datos, ya que se mantiene el catálogo de copias de seguridad de archivos de datos de RMAN después de cada tarea de copia de seguridad. Sin embargo, interfiere con otros productos de copia de seguridad.

Requisito Define los detalles de la aplicación de copia de seguridad y recuperación ante desastres y el parámetro de configuración Do not uncatalog en No.
Práctica recomendada Las copias de seguridad de la base de datos del servicio de Backup y DR son incrementales para siempre. Esto se consigue mediante la copia de imagen de RMAN con la API de combinación incremental de RMAN. La primera copia de seguridad de RMAN es una copia de imagen completa del archivo de datos de la base de datos en el disco de copia de seguridad de Backup and DR con una instantánea interna del disco de copia de seguridad. Las ejecuciones posteriores de copias de seguridad incrementales de RMAN con la combinación incremental de RMAN en el disco de copia de seguridad de Backup and DR actualizan la copia de seguridad completa más reciente con los cambios incrementales antes de la creación de la instantánea. Sin embargo, si se realiza una copia de seguridad de la base de datos de un tercero o una comprobación cruzada de las copias de seguridad después de la copia de seguridad de la base de datos de Backup and DR, todos los archivos de datos de la copia de seguridad de Backup and DR se marcarán como obsoletos en los metadatos de RMAN. Detalles de la aplicación de copia de seguridad y recuperación tras desastres, y parámetro de configuración Do not uncatalog si se define como Sí, se produce el siguiente error: No se han podido catalogar las copias de imágenes del dispositivo de almacenamiento provisional y se produce un error en la copia de seguridad. Mantén Do not uncatalog en No para que coexista con otros productos de copia de seguridad antiguos.
Motivo De forma predeterminada, el parámetro Do not uncatalog> in Backup and DR application details & settings is set to No. Setting this to Yes interferes with other backup products.

Seguimiento de cambios de bloques (BCT) de bases de datos de Oracle

El seguimiento de cambios de bloques de Oracle permite realizar copias de seguridad de bases de datos rápidamente, ya que identifica los bloques que han cambiado. En la operación de copia de seguridad solo se incluyen los bloques modificados.

  • La función incremental-forever del servicio de copia de seguridad y recuperación tras fallos admite bases de datos que se ejecutan con BCT habilitado o inhabilitado. Si BCT no está habilitado, el tiempo de copia de seguridad incremental aumenta.

  • El seguimiento de bloques modificados está habilitado a nivel de base de datos.

  • Oracle registra los bloques modificados de cada archivo de datos en un archivo de seguimiento, que es un pequeño archivo binario almacenado en el área de la base de datos.

  • Con BCT habilitado, RMAN usa el archivo BCT para obtener los bloques modificados de la copia de seguridad incremental.

  • RMAN analiza cada bloque de un archivo de datos de todos los archivos de datos de la base de datos durante la copia de seguridad incremental cuando la función de seguimiento de bloques modificados de la base de datos no está habilitada.

Proteger bases de datos Oracle en un grupo de coherencia de copias de seguridad y recuperación tras desastres

En la mayoría de las configuraciones, un grupo de coherencia puede contener una sola aplicación de base de datos de Oracle y cualquier número de aplicaciones de sistema de archivos del servidor de Oracle. Un grupo de coherencia es la opción recomendada para las bases de datos de Oracle en entornos de prueba y desarrollo, así como en otros casos prácticos de agilidad empresarial.

Bases de datos de Oracle con TDE

El servicio Backup and DR admite varios métodos de captura y presentación para bases de datos Oracle con diferentes configuraciones. Esto incluye las operaciones de copia de seguridad, recuperación y montaje de la base de datos Oracle con cifrado de datos transparente (TDE) configurado.

En el caso de las bases de datos de Oracle con TDE, los archivos de cartera del host de copia de seguridad de origen deben estar disponibles para el host de destino de cualquier montaje Application Aware. Esto se puede hacer de varias formas.

  • Los archivos de cartera se pueden copiar del servidor de origen de la copia de seguridad al servidor de montaje de destino y Oracle se puede configurar para acceder a ellos.
  • Si los archivos de cartera de Oracle se almacenan en un dispositivo central compartido en la red, la instancia de Oracle de destino de montaje de Appaware debe configurarse para acceder a ellos.

  • Si los archivos de cartera de Oracle se capturaron durante la copia de seguridad del servicio Backup and DR al definir el ajuste avanzado Ubicación del archivo de configuración de Oracle, los archivos de cartera se pueden recuperar siguiendo estos pasos:

    1. Realiza un montaje estándar de la base de datos en el host de destino.
    2. Copia los archivos de cartera del montaje de la base de datos estándar en el host de destino y configura Oracle para que los use.
    3. Desmonta la base de datos del host de destino.
    4. Realiza un montaje compatible con aplicaciones de la base de datos en el host de destino.

Copia de seguridad y recuperación ante desastres con la base de datos Oracle Exadata u Oracle ExaCC

Los dispositivos de copia de seguridad y recuperación admiten la captura y la presentación de datos de Exadata a través de los protocolos iSCSI u Oracle dNFS.

  • El dispositivo de copia de seguridad o recuperación está conectado a través de iSCSI u Oracle dNFS en la red (no en la ruta de datos).

  • La copia de seguridad de RMAN usa RMAN para escribir directamente en el almacén de datos de copia presentado por Backup and DR como un sistema de archivos o como un grupo de discos ASM.

  • Formatos de captura de datos: en Grupo de discos ASM (solo iSCSI) o en Sistema de archivos (dNFS o iSCSI).

  • La copia de seguridad incremental para siempre de Backup y DR usa copias de seguridad actualizadas de forma incremental de RMAN, que son copias de seguridad de imágenes que se van actualizando.

Copia de seguridad y recuperación tras fallos de datos de Exadata y ExaCC

El agente de copia de seguridad y recuperación ante desastres debe instalarse en el servidor Exadata para facilitar la comunicación con el dispositivo de copia de seguridad y recuperación, así como para invocar la API de RMAN para la copia de seguridad de la base de datos.

El agente de copias de seguridad y recuperación ante desastres expone y asigna discos de copias de seguridad y recuperación ante desastres al servidor Exadata como destino iSCSI. El formato de captura de datos puede estar en Grupo de discos ASM o en Sistema de archivos.

Instala el agente de copia de seguridad y recuperación tras desastres en cada host de Exadata en el espacio de usuario para facilitar la comunicación con el dispositivo de copia de seguridad y recuperación, e invoca la API de RMAN para crear copias de seguridad de la base de datos.

Formato de captura en el grupo de discos de ASM

Durante una copia de seguridad, el agente de copia de seguridad y recuperación tras fallos hace lo siguiente:

  1. Mapea y expón el disco lógico al servidor de Exadata como un destino iSCSI.

  2. Añade la ruta del disco de copia de seguridad y recuperación ante desastres a la cadena de disco de ASM.

  3. Asegúrese de que la cadena de disco de ASM se haya añadido al archivo de parámetros y no exista en el perfil de CRS.

  4. Crea un grupo de discos de ASM como redundancia externa con el disco de Backup and DR.

    • Copia de seguridad de RMAN que usa RMAN para escribir directamente en el almacén de datos de copia presentado por el dispositivo de copia de seguridad o recuperación como grupo de discos de ASM o como sistema de archivos.

    • Copia de seguridad incremental para siempre con copias de seguridad incrementales actualizadas con RMAN y copias de seguridad de imágenes de restauración.

Formato de captura en el sistema de archivos mediante dNFS

Oracle direct NFS (dNFS) es un cliente NFS (sistema de archivos de red) optimizado que proporciona un acceso más rápido y escalable al almacenamiento NFS ubicado en dispositivos de almacenamiento NAS (accesible a través de TCP/IP). Direct NFS está integrado directamente en el kernel de la base de datos, al igual que ASM.

El protocolo dNFS se puede usar para la copia de seguridad basada en el sistema de archivos como un recurso compartido de NFS.

El agente de copias de seguridad y recuperación tras fallos expone y asigna discos de copias de seguridad y recuperación tras fallos al servidor de Exadata como recurso compartido NFS.

Requisitos previos para dNFS en el servidor Exadata:

  • Habilita dNFS en el servidor Exadata:

    cd $ORACLE_HOME/rdbms/lib make -f ins_rdbms.mk nfs on

  • Reinicia la base de datos.

    Usa la API RMAN para crear una copia de seguridad de la base de datos en el sistema de archivos de un recurso compartido dNFS presentado por el dispositivo de copia de seguridad o recuperación.

Volver a poner online los grupos de discos de ASM protegidos por Backup and DR después de reiniciar un servidor de base de datos de destino

Después de reiniciar cualquier servidor de base de datos en el que esté montada la copia de seguridad y recuperación tras desastres, o si se están realizando copias de seguridad y recuperación tras desastres de la base de datos en el momento del reinicio o del fallo, sigue estos pasos para volver a montar el grupo de discos de copia de seguridad y recuperación tras desastres:

  1. Comprueba que el servidor de la base de datos de destino esté activo y que los sistemas ASM y RAC también lo estén.

  2. Reinicia el agente de Backup y DR (desde la raíz).

  3. Define el entorno de ASM.

  4. Inicia sesión en ASM sqlplus y comprueba el estado del grupo de discos:

    select name, state from v$asm_diskgroup where name = '<dg name>';)

  5. Si no está montado, monta el grupo de discos: alter diskgroup <dg name> mount;

  6. Inicia sesión en el SO de Oracle, define el entorno de la base de datos y, a continuación, inicia la base de datos.

Siguientes pasos

Consulta los requisitos previos para crear copias de seguridad de una base de datos de Oracle.

Otra documentación sobre Backup y DR para Oracle