Gestión de copia de seguridad y recuperación de bases de datos en Oracle Exadata Database Service on Dedicated Infrastructure

Descubra cómo trabajar con las funciones de copia de seguridad y recuperación proporcionadas por Oracle Exadata Database Service on Dedicated Infrastructure.

Opciones recomendadas por Oracle para realizar operaciones de copia de seguridad y recuperación

Oracle ofrece las siguientes opciones para las operaciones de copia de seguridad y recuperación de Oracle Database. Estas opciones se excluyen mutuamente.

Nota

La configuración híbrida, es decir, la combinación de opciones, no está soportada. La combinación de opciones interrumpirá la automatización.

Opción 1: copias de seguridad gestionadas por Oracle

Las copias de seguridad gestionadas por Oracle se gestionan completamente mediante Exadata Cloud Infrastructure (ExaDB-D) o Exadata Cloud at Customer (ExaDB-Cloud at Customer) basándose en una configuración puntual. Además de estar totalmente integradas en el plano de control de los servicios en la nube ExaDB-D o ExaDB-C@C, también se puede acceder a estas copias de seguridad a través de API de OCI. Oracle recomienda este enfoque.

  • Los comandos dbaascli database backup y dbaascli database recover se pueden utilizar junto con las copias de seguridad automatizadas para determinadas operaciones. Para obtener más información, consulte dbaascli database backup y dbaascli database recover.
  • Los clientes pueden consultar las vistas de RMAN o emitir comandos de recuperación y restauración de RMAN, por ejemplo, comandos de recuperación de tabla, archivo de datos o tablespace.
    Nota

    No utilice la configuración de RMAN para cambiar ninguno de los valores de RMAN en la nube ajustados previamente.

Opción 2: copias de seguridad configuradas por el usuario

Los clientes también pueden configurar copias de seguridad desde el host mediante los comandos dbaascli database backup y dbaascli database recover. Sin embargo, estas copias de seguridad no están sincronizadas con el plano de control ni están integradas con las API de OCI. Además, las operaciones de gestión y de ciclo de vida de estas copias de seguridad no están soportadas desde la consola de plano de control del servicio. Por ello, este no es un enfoque recomendado.

Este enfoque es útil cuando se requiere acceso directo a destinos de copia de seguridad para realizar determinadas tareas. Acceso al cubo de OSS, por ejemplo, para replicar copias de seguridad entre regiones o supervisar destinos de copia de seguridad.

Si los clientes configuran copias de seguridad en Object Storage mediante RMAN sin utilizar el plano de control de OCI ni las API de OCI, los clientes son responsables de configurar manualmente las copias de seguridad de la cartera de TDE. Por defecto, la automatización en la nube de Oracle limpia los archivos archive log cada 24 horas. Cuando se utiliza RMAN para realizar copias de seguridad manuales, existe el riesgo de que se supriman los archive logs. Consulte dbaascli database backup para obtener información sobre cómo configurar la limpieza de archive log. Se recomienda utilizar copias de seguridad gestionadas por Oracle.

Para obtener más información, consulte Copia de seguridad configurada por el usuario.

Opción 3: copias de seguridad mediante RMAN

Las copias de seguridad se pueden realizar directamente mediante RMAN con scripts personalizados propiedad del cliente. Sin embargo, Oracle no recomienda este enfoque.

No se recomienda utilizar copias de seguridad de RMAN junto con copias de seguridad gestionadas por Oracle o copias de seguridad configuradas por el usuario.

Quiénes pueden utilizar esta opción:
  • Los clientes que deseen mantener sus scripts de copia de seguridad/restauración de RMAN existentes.
  • Clientes que desean configurar copias de seguridad de la base de datos en espera en entornos de Data Guard para descargar la carga de trabajo de copia de seguridad en la base de datos en espera.

ExaDB-D:

Si tiene previsto realizar una copia de seguridad mediante RMAN, debe anular el registro de la base de datos de la automatización de copias de seguridad. Para obtener más información, consulte Desactivación de las copias de seguridad automáticas para facilitar la gestión manual de las copias de seguridad y la recuperación.

Gestión de copias de seguridad de bases de datos de Exadata

Las copias de seguridad automáticas de bases de datos de Exadata se gestionan mediante Oracle Cloud Infrastructure. Esto se configura mediante la consola o la API.

Para las copias de seguridad no gestionadas, consulte Gestión de copias de seguridad de base de datos de Exadata con dbaascli.

Hay dos destinos posibles para las copias de seguridad automáticas de la base de datos de Exadata: Autonomous Recovery Service u Oracle Object Storage.

La función de copias de seguridad automáticas gestionadas por Oracle es el método preferido para realizar copias de seguridad de bases de datos de Oracle Cloud, ya que le permite configurar fácilmente los valores de copia de seguridad mediante la consola. La función de copias de seguridad automáticas soporta Recovery Service y Object Storage como destino de copia de seguridad para proporcionarle una solución de copia de seguridad en la nube totalmente automatizada con el mismo costo. No es necesario que realice copias de seguridad manuales ni tareas de administración de almacenamiento de copia de seguridad. También puede almacenar las copias de seguridad en el almacenamiento local. Cada destino de copia de seguridad tiene sus ventajas y requisitos que debe tener en cuenta, como se describe a continuación.

Recovery Service (recomendado)

Un servicio totalmente gestionado basado en la tecnología local de Zero Data Loss Recovery Appliance de Oracle que ofrece una protección de ciberseguridad moderna para las bases de datos de Oracle. Las capacidades únicas y automatizadas protegen los cambios de Oracle Database en tiempo real, validan las copias de seguridad sin sobrecarga de la base de datos de producción y permiten una recuperación rápida y predecible en cualquier momento.

Si las copias de seguridad están configuradas actualmente con Object Storage, puede realizar una transición fluida al servicio de recuperación para lograr capacidades avanzadas con el mismo costo.

Para obtener más información sobre Recovery Service, consulte Acerca de Oracle Database Autonomous Recovery Service.

Object Storage

Una solución de almacenamiento bajo demanda, segura y ampliable para bases de datos.

Nota

Si anteriormente ha utilizado dbaascli para configurar copias de seguridad y, a continuación, pasa a utilizar la consola o la API para copias de seguridad:

  • Se crea una nueva configuración de copia de seguridad y se asocia a la base de datos. Esto significa que ya no podrá confiar en las copias de seguridad no gestionadas y previamente configuradas para proteger la base de datos.

Tipos de copias de seguridad gestionadas e información de uso

Hay dos tipos de copias de seguridad automáticas de bases de datos de Exadata: Autonomous Recovery Service y Oracle Object Storage.

La base de datos y la infraestructura (el cluster de VM o el sistema de base de datos) deben tener el estado "Disponible" para que la operación de copia de seguridad se ejecute correctamente. Oracle recomienda que evite realizar acciones que puedan interferir con la disponibilidad (como operaciones de aplicación de parches) mientras la operación de copia de seguridad está en curso. Si falla una operación de copia de seguridad automática, el servicio Database vuelve a intentar la operación durante la ventana de copia de seguridad del día siguiente. Si falla una copia de seguridad completa bajo demanda, puede volver a intentar realizar la operación cuando se haya restablecido la disponibilidad de la base de datos y la instancia de Exadata Cloud Infrastructure.

Al activar la función Copia de seguridad automática, cualquiera de los servicios crea copias de seguridad incrementales diarias de la base de datos en el destino de copia de seguridad seleccionado.

Si decide activar las copias de seguridad automáticas, puede controlar el período de retención. El sistema suprime automáticamente las copias de seguridad cuando caduca el período de retención asignado.

Período de retención de copia de seguridad de Object Storage: 7, 15, 30, 45, 60. Valor por defecto: 30 días.

El proceso de copia de seguridad automática comienza en cualquier momento durante la ventana de copia de seguridad diaria. Opcionalmente, puede especificar una ventana de programación de 2 horas para la base de datos durante la cual comenzará el proceso de copia de seguridad automática. Hay 12 ventanas de programación entre las que elegir, y cada una comienza en una hora par (por ejemplo, una ventana se ejecuta de 4:00 a 6:00 AM y la siguiente de 6:00 a 8:00 AM). Los trabajos de copia de seguridad no se completan necesariamente dentro de la ventana de programación.

Si no especifica una ventana, se asigna a la base de datos la ventana de copia de seguridad por defecto de 00:00 a 06:00 en la zona horaria de la región de la instancia de Exadata Cloud Infrastructure. Tenga en cuenta que la ventana de programación de copia de seguridad por defecto es de seis horas, mientras que las ventanas que especifique son de dos horas de duración.

Política de protección de Autonomous Recovery Service:
  • Bronce:14 días
  • Plata: 35 días
  • Oro: 65 días
  • Platinum de 95 días
  • Personalizado definido por usted
  • Valor por defecto: plata - 35 días

El proceso de copia de seguridad automática se inicia en cualquier momento o dentro de la ventana asignada.

Nota

  • Data Guard: puede activar la función de copia de seguridad automática en una base de datos con el rol en espera en una asociación de Data Guard.
  • Cambios en la retención de copias de seguridad: si reduce el período de retención de copias de seguridad de la base de datos o la política de protección en el futuro, el sistema suprimirá las copias de seguridad existentes que se encuentren fuera del período de retención actualizado.
  • Costos de almacenamiento de copia de seguridad: las copias de seguridad automáticas conllevan costos de uso de almacenamiento para Autonomous Recovery Service o Object Storage según el destino de copia de seguridad seleccionado.

Puede crear una copia de seguridad completa de la base de datos en cualquier momento mediante cualquiera de los servicios.

Al terminar una base de datos de instancia de Exadata Cloud Service, se suprimen todos sus recursos. Las copias de seguridad gestionadas que utilizan el destino Object Storage se suprimirán y las que utilizan Autonomous Recovery Service se suprimirán en función de la opción de supresión seleccionada. Las copias de seguridad independientes creadas en Object Storage permanecerán una vez terminada la base de datos y se deben suprimir manualmente. Puede utilizar una copia de seguridad independiente para crear una nueva base de datos.

Para alinearse con la práctica recomendada por Oracle de utilizar el privilegio administrativo SYSBACKUP para operaciones de copia de seguridad y recuperación, la automatización en la nube crea un usuario administrativo común C##DBLCMUSER con el rol SYSBACKUP en el nivel de contenedor CDB$ROOT. Por lo tanto, las operaciones de copia de seguridad y recuperación se realizan con el usuario que tiene el menor número de privilegios necesarios. Las credenciales de este usuario se generan aleatoriamente y se gestionan de forma segura mediante la automatización en la nube. Si el usuario no se encuentra o está LOCKED y EXPIRED, la automatización en la nube volverá a crear o a desbloquear este usuario durante la operación de copia de seguridad o recuperación. Este cambio en la automatización en la nube se realiza a partir de dbaastools versión 21.4.1.1.0.

Copia de Seguridad de Retención a Largo Plazo con Recovery Service

La copia de seguridad de retención a largo plazo (LTR) le permite almacenar copias de seguridad completas durante períodos de hasta diez años para satisfacer las necesidades de cumplimiento, normativas u otras necesidades empresariales con una gestión completa del ciclo de vida de LTR e inmutabilidad.

Para LTR con Recovery Service, el período de retención debe ser de días (90 - 3.650) o años (1 - 10) a partir de la creación de la copia de seguridad.

Para crear una copia de seguridad de LTR con el período de retención necesario, Recovery Service no necesita crear una nueva copia de seguridad de producción completa, sino que lo hace mediante el uso de copias de seguridad operativas ya existentes en el sistema dentro de la ventana de recuperación definida en la política. Para obtener más información, consulte Creación de una copia de seguridad bajo demanda de una base de datos.

Puede cambiar el período de retención para una copia de seguridad de LTR existente específica dentro del período de retención. Para obtener más información, consulte Para cambiar el período de retención de una copia de seguridad de LTR con Recovery Service.

Puede restaurar una copia de seguridad de LTR para crear una nueva base de datos dentro del período de retención. Para obtener más información, consulte Creación de una base de datos a partir de una copia de seguridad.

Al terminar una base de datos, las copias de seguridad de LTR se suprimirán según el valor 'Opciones de supresión después de la terminación de la base de datos'.

  • Suprimir copias de seguridad en 72 horas: se suprimirán todas las copias de seguridad, incluidas las copias de seguridad a largo plazo.
  • Suprimir según política: las copias de seguridad de LTR se conservarán según la política de retención de cada copia de seguridad de LTR.

Nota: Oracle recomienda seleccionar la opción "Suprimir según política" al terminar una base de datos para asegurarse de que se mantienen las copias de seguridad a largo plazo.

Tenga en cuenta los siguientes factores adicionales para las copias de seguridad a largo plazo:

  • Las copias de seguridad de LTR seguirán existiendo independientemente de las copias de seguridad automáticas configuradas en la base de datos.
  • Las copias de seguridad de LTR se suprimirán automáticamente una vez que finalice el período de retención especificado.
  • No se admite la restauración en el lugar para LTR.
  • Para las bases de datos en una configuración de Data Guard, la copia de seguridad a largo plazo se creará solo para la base de datos en la que se solicite.
  • La base de datos debe tener el estado DISPONIBLE para crear un LTR.
  • LTR está soportado para bases de datos con almacenes de claves basados en KMS o TDE basados en archivos.
  • Las claves de cifrado se mantendrán durante todo el período de retención de LTR.
  • Una copia de seguridad de LTR se puede cancelar mientras está en estado 'creando'.
  • Una copia de seguridad de LTR se puede suprimir en cualquier momento después de crearla.
  • Durante la restauración:
    • Si la copia de seguridad es de una versión principal DBHome soportada, se restaurará a la última RU de esa versión.
    • Si la copia de seguridad es de una versión principal DBHome no soportada, se restaurará a una versión principal soportada, después de lo cual la base de datos se debe actualizar a cualquiera de las versiones principales soportadas.

Asignación de canal de copia de seguridad por defecto

Configuración por defecto para los canales de copia de seguridad de la base de datos al utilizar "Copia de seguridad gestionada por Oracle" o "Copia de seguridad configurada por el usuario"

Cuando se configura una base de datos para la copia de seguridad mediante "Copia de seguridad gestionada por Oracle" o "Copia de seguridad configurada por el usuario", las herramientas utilizan el "valor por defecto" para los canales de copia de seguridad. Cuando se utiliza el valor por defecto, dbaas determinará el número de canales que se van a asignar en el momento en que se ejecuta el comando de copia de seguridad o restauración. El número de canales asignados viene determinado por el recuento de OCPU del nodo. En la siguiente tabla se proporcionan los valores utilizados y el rango de OCPU, tanto la OCPU como los valores de canal por nodo. Se priorizan las operaciones de restauración. El recuento total de canales de todo el cluster es el valor por nodo multiplicado por el número de nodos. La automatización utiliza SCAN para distribuir los canales de RMAN en todos los nodos del cluster.

OCPU por nodo Fórmula Asignación de canales de copia de seguridad por nodo Asignación de canales de restauración por nodo
Menor o Igual que 12 OCPU <= 12 2 4
Mayor que 12 y menor o igual que 24 OCPU > 12 y OCPU <= 24 4 8
Mayor que 24 OCPU > 24 8 16

Si es necesario, se puede definir un valor estático por nodo mediante getConfig/configure de DBAASCLI para generar una configuración bckup y definir el parámetro bkup_channels_node en el número de canales por nodo deseado.

Los valores válidos son de 1 a 32: el recuento total de canales será el valor multiplicado por el número de nodos. Este valor no puede exceder el límite de 255 canales. Un valor default para bkup_channels_node define la asignación basada en canal de OCPU.

Requisitos para copias de seguridad en Exadata Cloud Infrastructure

Recovery Service

Asegúrese de que su arrendamiento está configurado para utilizar Recovery Service.

Tabla 5-4 Revise las tareas previas necesarias antes de utilizar Recovery Service como destino de copia de seguridad automática

Tarea Más información Necesaria u opcional

Creación de políticas de IAM

Políticas para permitir el acceso al servicio de recuperación y los recursos relacionados

necesario

Configure los recursos de red y registre una subred de Recovery Service

Creación de una subred del servicio de recuperación en la VCN de base de datos

necesario

Crear políticas de protección

Revisión de políticas de protección para la retención de copia de seguridad de base de datos

Opcional

Para obtener más información sobre Recovery Service, consulte Visión general de Oracle Database Autonomous Recovery Service.

Almacenamiento de objetos

  • La instancia de Exadata Cloud Service requiere acceso a Oracle Cloud Infrastructure Object Storage. Oracle recomienda utilizar un gateway de servicio con la VCN para activar este acceso. Para obtener más información, consulte Configuración de red para instancias de Exadata Cloud Infrastructure. En ese tema, debe prestar especial atención a:
  • Un cubo de Object Storage existente para utilizarlo como destino de copia de seguridad. Puede utilizar la consola o la API de Object Storage para crear el cubo. Para obtener más información, consulte Gestión de cubos.
  • Un token de autenticación generado por Oracle Cloud Infrastructure. Puede utilizar la consola o la API de IAM para generar la contraseña. Para obtener más información, consulte Trabajar con tokens de autenticación.
  • El nombre de usuario especificado en el archivo de configuración de copia de seguridad debe tener acceso de nivel de arrendamiento a Object Storage. Una forma sencilla de hacerlo es agregar el nombre de usuario al grupo de administradores. Sin embargo, esto permite el acceso a todos los servicios en la nube. En su lugar, un administrador debe crear una política como la siguiente que limite el acceso solo a los recursos necesarios en Object Storage para realizar la copia de seguridad de la base de datos y restaurarla:
    Allow group <group_name> to manage objects in compartment <compartment_name> where target.bucket.name = '<bucket_name>'
    Allow group <group_name> to read buckets in compartment <compartment_name>

    Para obtener más información sobre cómo agregar un usuario a un grupo, consulte Gestión de grupos. Para obtener más información sobre las políticas, consulte Introducción a las políticas.

Uso de la consola para gestionar copias de seguridad

Puede utilizar la consola para activar copias de seguridad incrementales automáticas, crear copias de seguridad completas bajo demanda y ver la lista de copias de seguridad gestionadas para una base de datos. También puede utilizar la consola para suprimir copias de seguridad manuales (bajo demanda).

Nota

  • Todas las copias de seguridad se cifran con la misma clave maestra que se utiliza para el cifrado de cartera de cifrado de datos transparente (TDE).
  • Las copias de seguridad de una base de datos concreta se muestran en la página de detalles de esa base de datos. La columna Clave de cifrado muestra la clave gestionada por Oracle o un nombre de clave si utiliza sus propias claves de cifrado para proteger la base de datos. Consulte Copia de seguridad de almacenes y claves para obtener más información.
Nota

No suprima ninguna clave de cifrado necesaria del almacén porque esto hace que las bases de datos y las copias de seguridad protegidas por la clave dejen de estar disponibles.

Configuración de copias de seguridad automáticas para una base de datos

Creación de una copia de seguridad bajo demanda de una base de datos

Para ver el estado de copia de seguridad

Para cancelar una copia de seguridad

Supresión de copias de seguridad completas de Object Storage

Supresión de las copias de seguridad independientes de Object Storage

  1. Abra el menú de navegación. Haga clic en Oracle Database y, a continuación, en Copias de seguridad independientes, en Recursos.
  2. En la lista de copias de seguridad independientes, busque la copia de seguridad que desea suprimir.
  3. Haga clic en el menú Acciones de la copia de seguridad en la que está interesado y, a continuación, haga clic en Suprimir.
  4. En el cuadro de diálogo Suprimir, haga clic en Suprimir para confirmar la supresión de la copia de seguridad.

Para cambiar el período de retención de una copia de seguridad de LTR con Recovery Service

  1. Abra el menú de navegación. Seleccione Oracle Database y, a continuación, seleccione Oracle Exadata Database Service on Dedicated Infrastructure.
  2. Seleccione su compartimento.
  3. Acceda al cluster de VM en la nube o al sistema de base de datos que contiene la base de datos que desea cambiar el período de retención de la copia de seguridad:

    Cluster de VM en la nube ( nuevo modelo de recursos): en Oracle Exadata Database Service on Dedicated Infrastructure, haga clic en Clusters de VM de Exadata. En la lista de clusters de VM, busque el cluster de VM al que desea acceder y haga clic en el nombre resaltado para ver la página de detalles del cluster.

    Sistemas de base de datos: en Hardware dedicado, VM y Exadata, haga clic en Sistemas de base de datos. En la lista de sistemas de base de datos, busque el sistema de base de datos de Exadata al que desea acceder y, a continuación, haga clic en su nombre para mostrar los detalles.

  4. En la lista de bases de datos, haga clic en el nombre de la base de datos para la que desea cambiar el período de retención.
  5. En Recursos, haga clic en Copias de seguridad.

    Se mostrará una lista de copias de seguridad.

  6. En la lista de copias de seguridad, haga clic en el menú Acciones de la copia de seguridad con el tipo Copia de seguridad a largo plazo para la que desea cambiar el período de retención.
  7. Haga clic en Cambiar período de retención.
  8. En el cambio del período de retención resultante, cambie el período de retención.
    Nota

    El período de retención se debe introducir en Días (90 - 3.650) o Años (1 - 10) a partir de la creación de la copia de seguridad.
  9. Haga clic en Guardar.

Designación de Autonomous Recovery Service como destino de copia de seguridad para una base de datos existente

Recuperación de una base de datos de Exadata desde un destino de copia de seguridad

En este tema se explica cómo recuperar una base de datos de Exadata a partir de una copia de seguridad almacenada en Object Storage o Autonomous Recovery Service mediante la consola o la API.

  • El servicio de almacenamiento de objetos es una solución de almacenamiento segura, escalable y a demanda de Exadata Cloud Infrastructure.
  • OracleDatabase Autonomous Recovery Service es una solución de copia de seguridad centralizada, totalmente gestionada e independiente para bases de datos de Oracle Cloud Infrastructure (OCI).

Para obtener más información sobre la copia de seguridad de bases de datos en Object Storage, consulte Gestión de copias de seguridad de bases de datos de Exadata.

Uso de la consola para restaurar una base de datos

Puede utilizar la consola para restaurar la base de datos a partir de una copia de seguridad en un destino de copia de seguridad creado mediante la consola.

Nota

Las copias de seguridad de LTR representan un único punto en el tiempo para la base de datos, por lo que las siguientes opciones no están soportadas al restaurar.

Puede restaurar a:

  • Restaurar a la última versión: restablece la base de datos al estado correcto más reciente conocido con la menor pérdida de datos posible.
  • Restaurar a un registro de hora: restablece la base de datos al registro de hora especificado.
  • Restaurar a SCN: restaura la base de datos utilizando el SCN especificado. Este SCN debe ser válido.
    Nota

    Puede determinar el número SCN que se va a utilizar mediante el acceso y la consulta del host de la base de datos, o mediante el acceso a cualquier log archivado o en línea.
Nota

La lista de copias de seguridad que se ve en la consola no incluye copias de seguridad no gestionadas (copias de seguridad creadas directamente mediante dbaascli).

Restauración de una base de datos
  1. Abra el menú de navegación. Haga clic en Oracle Database y, a continuación, en Oracle Exadata Database Service on Dedicated Infrastructure.
  2. Seleccione su compartimento.
  3. Vaya al cluster de VM en la nube o al sistema de base de datos que contiene la base de datos que desea restaurar:

    Cluster de VM en la nube (el nuevo modelo de recursos de Exadata Cloud Infrastructure): en Oracle Exadata Database Service on Dedicated Infrastructure, haga clic en Clusters de VM de Exadata. En la lista de clusters de VM, busque el cluster de VM al que desea acceder y haga clic en el nombre resaltado para ver la página de detalles del cluster.

    Sistemas de base de datos: en Base de datos base de Oracle, haga clic en Sistemas de base de datos. En la lista de sistemas de base de datos, busque el sistema de base de datos de Exadata al que desea acceder y, a continuación, haga clic en su nombre para mostrar los detalles.

  4. En la lista de bases de datos, busque la base de datos que desea restaurar y, haga clic en su nombre para mostrar los detalles.
  5. Haga clic en Restaurar.
  6. Seleccione una de las siguientes opciones y haga clic en Restaurar base de datos:
    • Restaurar a la última versión: restablece la base de datos al estado correcto más reciente conocido con la menor pérdida de datos posible.
    • Restaurar a registro de hora: restablece la base de datos al registro de hora especificado.
    • Restaurar a número de cambio del sistema (SCN): restaura la base de datos utilizando el SCN especificado. Este SCN debe ser válido.

      Nota

      Puede determinar el número SCN que se va a utilizar mediante el acceso y la consulta del host de la base de datos, o mediante el acceso a cualquier log archivado o en línea.
  7. Confirme cuando se le solicite.

    Si falla la operación de restauración, la base de datos tendrá el estado "Fallo de restauración". Puede intentar de nuevo la restauración utilizando una opción de restauración diferente. No obstante, Oracle recomienda revisar los logs de RMAN en el host y corregir las incidencias antes de volver a intentar restaurar la base de datos. Estos archivos de registro se encuentran en el directorio /var/opt/oracle/log.

Gestión de copias de seguridad de bases de datos Exadata con dbaascli

Puede usar la utilidad de copia de seguridad de Exadata, dbaascli, para realizar copias de seguridad de bases de datos en una instancia de Exadata Cloud Infrastructure en un cubo existente del servicio Oracle Object Storage.

Para obtener más información sobre las copias de seguridad gestionadas por Oracle Cloud Infrastructure, consulte Gestión de copias de seguridad de bases de datos de Exadata.

En este tema se explica cómo:

  • Cree un archivo de configuración de copia de seguridad por defecto y modifique los parámetros para que coincidan con sus requisitos para realizar una copia de seguridad de la base de datos en el servicio de almacenamiento de objetos.
  • Asocie el archivo de configuración de copia de seguridad a una base de datos. Una vez que la configuración se haya realizado correctamente, se realizará una copia de seguridad de la base de datos según lo programado o puede crear una copia de seguridad bajo demanda con una etiqueta.
Nota

Debe actualizar las herramientas específicas de la nube en todos los nodos de cálculo de la instancia de Exadata Cloud Infrastructure antes de realizar los siguientes procedimientos. Para obtener más información, consulte Aplicación de parches y actualización manuales de un sistema Exadata Cloud Infrastructure.

Configuración de copia de seguridad por defecto

Instrucciones de mejores prácticas de Oracle para la configuración de copia de seguridad por defecto.

La configuración de copia de seguridad por defecto sigue un juego de directrices de mejores prácticas de Oracle:

  • Cifrado: todas las copias de seguridad en Object Storage están cifradas.
  • Compresión para copias de seguridad: LOW
  • Compresión predeterminada para archive logs: false
  • Algoritmo de cifrado de RMAN: AES256
  • Optimización para copias de seguridad: ON

Obtener la configuración de copia de seguridad por defecto para una base de datos recién aprovisionada

  1. Establezca SSH en uno de los nodos configurados de base de datos en el recurso de cluster de VM o sistema de base de datos.
  2. Conéctese como opc y, a continuación, utilice sudo para el usuario root.
  3. Utilice el comando dbaascli database backup --getConfig para generar un archivo que contenga los valores de copia de seguridad por defecto para el despliegue de la base de datos recién aprovisionada.
    # dbaascli database backup --getConfig [--configFile <file_name>] --dbname <database_name>
    Donde:
    • --getConfig: devuelve la configuración de copia de seguridad de base de datos.
    • --configFile: especifica el archivo de configuración de la copia de seguridad de la base de datos.

Creación de un archivo de configuración de copia de seguridad

Nota

El siguiente procedimiento se debe realizar en el primer nodo de cálculo del recurso de cluster de VM o de sistema de base de datos de Exadata Cloud Infrastructure. Para determinar el primer nodo de cálculo, conéctese a cualquier nodo de cálculo como usuario grid y ejecute el siguiente comando:
$ $ORACLE_HOME/bin/olsnodes -n

El primer nodo tiene el número 1 junto al nombre del nodo.

Nota

En dbaascli versión 25.1.2.0.0, se ha cambiado el nombre de los parámetros de configuración de copia de seguridad. Sin embargo, aún puede utilizar los nombres de parámetros antiguos, ya que se conservan para la compatibilidad con versiones anteriores.
  1. Establezca SSH en uno de los nodos configurados de base de datos en el recurso de cluster de VM o sistema de base de datos.
    ssh -i <private_key_path> opc@<node_1_ip_address>
  2. Conéctese como opc y, a continuación, utilice sudo para el usuario root.
    login as: opc [opc@dbsys ~]
    $ sudo su -
  3. Utilice el comando dbaascli database backup --getConfig para generar un archivo que contenga la configuración de copia de seguridad actual para el despliegue de la base de datos:
    # dbaascli database backup --getConfig [--configFile <file_name>] --dbname <database_name>
  4. Modifique los parámetros del archivo para que cumplan los requisitos.
    Parámetro Descripción
    backupDestination=oss Indica si se realizará una copia de seguridad en Object Storage. En caso afirmativo, también debe proporcionar los parámetros bkup_oss_url, bkup_oss_user, bkup_oss_passwd y bkup_oss_recovery_window.

    Nombre antiguo: bkup_oss_url=<swift_url>

    Nuevo nombre: ossURL=<swift_url>

    Necesario si backupDestination=oss.

    URL de Object Storage, incluido el inquilino y el cubo que se desea utilizar. La URL es:

    https://swiftobjectstorage.<region_name>.oraclecloud.com/v1/<tenant>/<bucket>

    Donde:

    • <tenant>: nombre del inquilino en minúsculas (aunque contenga caracteres en mayúsculas) que especifique al conectarse a la consola
    • <bucket>: nombre del cubo existente que desea utilizar para las copias de seguridad.

    Nombre antiguo: bkup_oss_user=<oci_user_name>

    Nuevo nombre: ossUserName=<oci_user_name>

    Necesario si backupDestination=oss.

    El nombre de usuario de la cuenta de usuario de Oracle Cloud Infrastructure. Es el nombre de usuario que utiliza para conectarse a la consola de Oracle Cloud Infrastructure.

    Por ejemplo, jsmith@example.com para un usuario local o <identity_provider>/jsmith@example.com para un usuario federado.

    Para determinar qué tipo de usuario tiene, consulte los siguientes temas:

    Tenga en cuenta que el usuario debe ser miembro del grupo Administradores, como se describe en Requisitos para copias de seguridad en Exadata Cloud Infrastructure.

    Nombre antiguo: bkup_oss_passwd=<auth_token>

    Nuevo nombre: ossAuthToken=<auth_token>

    Necesario si backupDestination=oss.

    El token de autenticación generado mediante la consola o la API de IAM, como se describe en Requisitos.

    Esta no es la contraseña del usuario de Oracle Cloud Infrastructure.

    Nombre antiguo: bkup_oss_recovery_window=n

    Nuevo nombre: ossRecoveryWindow=n

    Necesario si backupDestination=oss.

    El número de días que se mantienen las copias de seguridad y los redo logs archivados en el cubo de Object Storage. Especifique de 7 a 90 días.

    Nombre antiguo: bkup_daily_time=hh:mm

    Nuevo nombre: autoBackupTime=hh:mm

    Hora a la que está programada la copia de seguridad diaria, especificada en horas y minutos (hh:mm), en formato de 24 horas.
  5. Utilice dbaascli database backup --configure para asociar esta configuración de copia de seguridad a un nombre de base de datos.
    # dbaascli database backup --configure --configFile <file_name> --dbname <database_name>
  6. Utilice dbaascli database backup --status para comprobar el estado del UUID generado para este comando.
    # dbaascli database backup --status --uuid <uuid> --dbname <database_name>
    Nota

    Un archivo de configuración de copia de seguridad puede contener las credenciales para acceder al cubo de Object Storage. Por este motivo, es posible que desee eliminar el archivo después de configurar correctamente la copia de seguridad.

Se pueden modificar los siguientes parámetros para personalizar la configuración de copia de seguridad:

Nota

Compatible with Console Automatic Backups=Yes indica que es seguro cambiar el parámetro, incluso cuando se utilizan copias de seguridad automáticas basadas en la consola. Si utiliza parámetros con Compatible with Console Automatic Backups=No, no active las copias de seguridad mediante la consola.

Tabla 5-5 Parámetros de configuración de copia de seguridad: programación de parámetros en dbaascli

Parámetro Descripción Compatible con las copias de seguridad automáticas de la consola*

Nombre antiguo: bkup_cron_entry

Nombre nuevo: scheduleBackups

Activa la configuración de copia de seguridad automática.

Los valores válidos son yes y no.

Número

Nombre antiguo: bkup_archlog_cron_entry

Nombre nuevo: manageArchivelogs

Activa las copias de seguridad automáticas de los archivos log de la base de datos archivada.

Los valores válidos son yes y no.

Si se define manageArchivelogs en No, se desactivan los trabajos de limpieza automática de archive log. Este valor solo es válido cuando la base de datos asociada no tiene ninguna copia de seguridad automática de la base de datos configurada.

Número

Nombre antiguo: bkup_l0_day

Nombre nuevo: L0BackupDay

Este parámetro controla el día de la semana de nivel 0.

Día de la semana en que se realiza una copia de seguridad de nivel 0.

Los valores válidos son mon, tue,wed,thu,fri,sat ysun. También están soportados formatos más largos, por ejemplo, Monday, Tuesday.

Valor por defecto: sun.

Número

Tabla 5-6 Parámetros de configuración de copia de seguridad: parámetros generales de configuración de RMAN (válido para todos los destinos de copia de seguridad excepto Almacenamiento local [FRA])

Parámetro Descripción Compatible con las copias de seguridad automáticas de la consola*

Nombre antiguo: bkup_rman_compression

Nombre nuevo: compressionLevel

Nivel de compresión aplicado a las copias de seguridad automáticas.

Los valores válidos son NONE, basic, low, medium y high.

El valor por defecto es low.

El valor NONE desactiva la compresión de RMAN.

Si la compresión de RMAN está activada, todos los archivo de datos cifrados mediante TDE se descifrarán, comprimirán y cifrarán mediante RMAN.

Nombre antiguo: bkup_section_size

Nombre nuevo: sectionSize

Tamaño de sección de RMAN que se utiliza para las copias de seguridad automáticas.

El valor por defecto es 64G.

Nombre antiguo: bkup_channels_node

Nombre nuevo: channelsPerNode

Número de canales de RMAN por nodo utilizados para copias de seguridad automáticas.

Los valores válidos están entre 1 y 32.

El valor por defecto es 2.

Nombre antiguo: bkup_daily_time

Nombre nuevo: autoBackupTime

Hora de inicio de la copia de seguridad diaria automática expresada en formato de 24 horas de la siguiente forma: hh:mm.

Nombre antiguo: bkup_archlog_frequency

Nuevo nombre: backupFrequencyAL

Intervalo en minutos entre las copias de seguridad automáticas de los archivos log de base de datos archivados.

Los valores válidos son 15, 20, 30, 60, y de 120 a 1440 en intervalos de una hora expresados en minutos.

El valor por defecto es 30 para ExaDB-D.

Nombre antiguo: bkup_type

Nombre nuevo: backupDestination

Tipo de ubicación en la que reside la copia de seguridad. Especifique OSS como destino de copia de seguridad, que es la opción por defecto y única.

Nombre antiguo: bkup_filesperset_regular

Nombre nuevo: filesPerSet

Especifica el número máximo de archivos de datos que se pueden incluir en un juego de copias de seguridad para copias de seguridad normales/de archivo.

Nombre antiguo: bkup_filesperset_al

Nombre nuevo: filesPerSetAL

Especifica el número máximo de archivos archive log que se pueden incluir en un juego de copias de seguridad para Copias de Seguridad de Archivelog.

Nombre antiguo: bkup_encryption

Nuevo nombre: encryption

El cifrado especifica si las copias de seguridad se deben cifrar o no.

Por defecto, el cifrado está activado para OSS y Recovery Service, y este valor no se puede cambiar.

Nombre antiguo: rmanBackupOptimization

Nuevo nombre: optimization

La optimización es una función en la que se reduce la cantidad de datos de los que se debe realizar una copia de seguridad, transferir y restaurar. El valor recomendado es ON.

Nombre antiguo: rmanFraCleanupChannels

Nombre nuevo: numberOfChannelsForFraCleanup

Especifica el número de canales utilizados para el trabajo de limpieza de FRA.

Nombre antiguo: Compress_Archive_Logs

Nombre nuevo: compressionAL

Especifica si no se comprimen las copias de seguridad de archive log.

No se aplica al servicio de recuperación.

Nombre antiguo: bkup_archlog_fra_retention

Nombre nuevo: archivelogRetentionDays

Especifica el número de días que se conservará el archive log en FRA.

Tabla 5-7 Parámetros de configuración de copia de seguridad: parámetros del servicio Object Storage (OSS)

Parámetro Descripción Compatible con las copias de seguridad automáticas de la consola*
backupDestination=oss

Activa las copias de seguridad en el almacenamiento en la nube.

Los valores válidos son yes y no.

Número

Nombre antiguo: bkup_oss_recovery_window

Nombre nuevo: ossRecoveryWindow

Período de retención para las copias de seguridad en el almacenamiento en la nube, expresado como un número de días hasta un máximo de 90.

Solo se aplica si bkup_oss está definido en yes o si backupdestination está definido en OSS.

El valor por defecto es el 30.

Número

Nombre antiguo: bkup_oss_url

Nombre nuevo: ossURL

Ubicación del contenedor de almacenamiento que se utiliza para las copias de seguridad en el almacenamiento en la nube.

Solo se aplica si bkup_oss está definido en yes o si backupdestination está definido en OSS.

Número

Nombre antiguo: bkup_oss_user

Nombre nuevo: ossUserName

Nombre de usuario del usuario de Oracle Cloud que tiene privilegios de escritura en el contenedor de almacenamiento en la nube especificado en bkup_oss_url.

Solo se aplica si bkup_oss está definido en yes o si backupdestination está definido en OSS.

Número

Nombre antiguo: bkup_oss_passwd

Nombre nuevo: ossAuthToken

Contraseña del usuario de Oracle Cloud que tiene privilegios de escritura en el contenedor de almacenamiento en la nube especificado en bkup_oss_url.

Solo se aplica si bkup_oss está definido en yes o si backupdestination está definido en OSS.

Número

Tabla 5-8 Parámetros de configuración de copia de seguridad: parámetros de soporte del catálogo de RMAN

Parámetro Descripción Compatible con las copias de seguridad automáticas de la consola*

Nombre antiguo: bkup_use_rcat

Nombre nuevo: useCatalog

Activa el uso de un catálogo de recuperación de RMAN existente.

Los valores válidos son yes y no.

Nombre antiguo: bkup_rcat_user

Nombre nuevo: catalogUserName

Nombre de usuario del catálogo de recuperación.

Solo se aplica cuando bkup_use_rcat está definido en yes.

Nombre antiguo: bkup_rcat_passwd

Nombre nuevo: catalogPassword

Contraseña del usuario del catálogo de recuperación especificado en
bkup_rcat_user
.

Solo se aplica cuando bkup_use_rcat está definido en yes.

Nombre antiguo: bkup_rcat_conn

Nombre nuevo: catalogConnectionString

Cadena de conexión para el catálogo de recuperación de RMAN.

Solo se aplica cuando bkup_use_rcat está definido en yes.

Nota

Solo se pueden modificar de forma segura los parámetros anteriores marcados con Compatible with Console Automatic Backups = Yes junto con las copias de seguridad automáticas basadas en la consola. Si se va a modificar algún otro parámetro, no active las copias de seguridad mediante la consola.

Creación de una copia de seguridad bajo demanda

Puede utilizar dbaascli para crear una copia de seguridad bajo demanda de una base de datos.

  1. Establezca SSH en uno de los nodos configurados de base de datos en el recurso de cluster de VM o sistema de base de datos.
    ssh -i <private_key_path> opc@<node_1_ip_address>

    Para determinar el primer nodo de cálculo, conéctese a cualquier nodo de cálculo como usuario grid y ejecute el siguiente comando:

    $ $ORACLE_HOME/bin/olsnodes -n

    El primer nodo tiene el número 1 junto al nombre del nodo.

  2. Conéctese como opc y, a continuación, utilice sudo para el usuario root.
    login as: opc [opc@dbsys ~]
    $ sudo su -
  3. Puede permitir que la copia de seguridad siga la política de retención actual o puede crear una copia de seguridad a largo plazo que se mantenga hasta que la suprima:
    • Para crear una copia de seguridad que siga la política de retención actual, introduzca el siguiente comando:
      # dbaascli database backup --start --dbname <database_name>
    • Para crear una copia de seguridad a largo plazo, introduzca el siguiente comando:
      # dbaascli database backup --start --archival --dbname --tag <archival_tag>
  4. Salga del shell de comandos de usuario root y desconéctese del nodo de recursos informáticos:
    # exit
    $ exit
  5. Utilice dbaascli database backup --status para comprobar el estado del UUID generado para el comando de copia de seguridad
    # dbaascli database backup --status --uuid <uuid> --dbname <database_name>

Eliminación de la configuración de copia de seguridad

  1. Establezca SSH en uno de los nodos configurados de base de datos en el recurso de cluster de VM o sistema de base de datos.
  2. Conéctese como opc y, a continuación, utilice sudo para el usuario root.
  3. Cree un archivo temp con los siguientes parámetros:
    • bkup_oss=no
    • bkup_cron_entry=no
    • bkup_archlog_cron_entry=no
  4. Utilice el archivo anterior con dbaascli database backup --configure para eliminar la configuración de copia de seguridad de una base de datos.
    # dbaascli database backup --configure --configFile <file_name> --dbname <database_name>
  5. Utilice dbaascli database backup --status para comprobar el estado del UUID generado para este comando.
    # dbaascli database backup --status --uuid <uuid> --dbname <database_name>

Esto desactivará todas las copias de seguridad automáticas.

Para suprimir una copia de seguridad en Object Storage

Puede suprimir una copia de seguridad de archivado o a largo plazo del almacenamiento de objetos.

# dbaascli database backup --delete --backupTag --dbname <database_name>

Donde:

  • --dbname: especifica el nombre de la instancia de Oracle Database
  • --delete: suprime la copia de seguridad de archivo.
  • --backupTag: especifica la etiqueta de copia de seguridad que suprimir.

Las copias de seguridad basadas en políticas se suprimen con copias de seguridad diarias programadas. También puede utilizar el comando de supresión de copia de seguridad de RMAN para suprimir una copia de seguridad del almacén de objetos.

Uso de la API para gestionar la copia de seguridad y la recuperación

Uso de la API para gestionar copias de seguridad

Para obtener más información sobre el uso de la API y la firma de solicitudes, consulte API de REST y Credenciales de seguridad. Para obtener información sobre los SDK, consulte Software development kits e interfaz de línea de comandos.

Utilice estas operaciones de API para gestionar copias de seguridad de bases de datos:

Para obtener la lista completa de las API para el servicio Database, consulte API del servicio Database.

Métodos de copia de seguridad alternativos

Obtenga información sobre los métodos de copia de seguridad alternativos disponibles además de la consola de OCI.

Las copias de seguridad de bases de datos en Exadata Cloud Infrastructure se pueden realizar mediante varios métodos, además de las copias de seguridad automáticas configuradas en la consola. Por lo general, la consola (o la API/CLI de OCI que le corresponde) es el método preferido, ya que proporciona el método más sencillo y automatizado. En general, es preferible aprovechar la consola de OCI, la API de OCI o la línea de comandos de OCI mediante métodos de gestión alternativos. Sin embargo, si las acciones necesarias no se pueden completar mediante los métodos preferidos, existen otras dos opciones disponibles para configurar manualmente las copias de seguridad: dbaascli y Oracle Recovery Manager (RMAN).

Nota

Utilice los comandos dbaascli database backup, dbaascli pdb backup, dbaascli database recovery y dbaascli pdb recovery para realizar copias de seguridad y recuperar bases de datos de contenedores y bases de datos conectables. Para obtener más información, consulte Copia de seguridad configurada por el usuario en Opciones recomendadas por Oracle para realizar operaciones de copia de seguridad y recuperación.

RMAN es la herramienta de copia de seguridad que se incluye con Oracle Database. Para obtener información sobre el uso de RMAN, consulte la Guía del usuario de copia de seguridad y recuperación de Oracle Database para la versión 19. El uso de RMAN para realizar copias de seguridad de bases de datos en Exadata Cloud Infrastructure proporciona la mayor flexibilidad en términos de opciones de copia de seguridad, pero también la mayor complejidad.

Nota

Al utilizar RMAN para restaurar bases de datos de las que se ha realizado una copia de seguridad mediante uno cualquiera de los métodos descritos en este documento, RMAN no se debe utilizar nunca para configurar copias de seguridad junto con la consola (y la API/CLI de OCI), ni junto con dbaascli. Si decide organizar las copias de seguridad de forma manual mediante RMAN, no debe utilizar las copias de seguridad automatizadas de la consola ni debe utilizar dbaascli. Primero debe desactivar por completo las copias de seguridad automatizadas basadas en la consola. Para obtener más información, consulte Desactivación de las copias de seguridad automáticas para facilitar la gestión manual de las copias de seguridad y la recuperación.

El método dbaascli ofrece un punto medio entre las copias de seguridad automatizadas de la consola y de RMAN en términos de flexibilidad y simplicidad. Utilice dbaascli si la funcionalidad necesaria no está soportada con las copias de seguridad automatizadas de la consola, pero desea evitar la complejidad de utilizar RMAN directamente. En algunos casos, dbaascli se puede utilizar para modificar la configuración de copia de seguridad automatizada de la consola, pero no suele ser el caso. Por lo general, se debe utilizar dbaascli en lugar de activar las copias de seguridad en la consola.

Desactivación de las copias de seguridad automáticas para facilitar la gestión manual de las copias de seguridad y la recuperación

Las copias de seguridad, configuradas en la consola, la API o dbaascli de Exadata Cloud Infrastructure, funcionan para una variedad de casos de uso de copia de seguridad y recuperación. Si necesita casos de uso no soportados por las copias de seguridad gestionadas en la nube, puede gestionar manualmente la copia de seguridad y la recuperación de bases de datos mediante la utilidad Oracle Recovery Manager (RMAN). Para obtener información sobre el uso de RMAN, consulte la Guía del usuario de copia de seguridad y recuperación de Oracle Database para la versión 19.

La gestión de la copia de seguridad y la recuperación, mediante RMAN, en Exadata Cloud Infrastructure requiere adquirir la propiedad completa de las copias de seguridad tanto de la base de datos como de archive log, y las copias de seguridad gestionadas por la nube ya no se deben utilizar. Antes de iniciar copias de seguridad manuales, es necesario desactivar la funcionalidad de copia de seguridad gestionada en la nube. Esto es necesario para que los trabajos de copia de seguridad en la nube no depuren los archive logs antes de que se realice una copia de seguridad manual de ellos y no entren en conflicto con las copias de seguridad manuales.

Puede utilizar la utilidad dbaascli para desactivar las copias de seguridad gestionadas en la nube, incluida la desactivación del trabajo de depuración automática de archive logs.

Recuperación de una base de datos mediante Oracle Recovery Manager (RMAN)

Si ha realizado una copia de seguridad de la base de datos utilizando dbaascli, puede restaurarla manualmente mediante la utilidad Oracle Recovery Manager (RMAN). Para obtener información sobre el uso de RMAN, consulte la Guía del usuario de Oracle Database Backup and Recovery para la versión 19.

Nota

Si bien la recuperación mediante RMAN es segura, no debe utilizar RMAN para iniciar copias de seguridad ni para editar la configuración de copia de seguridad junto con el uso de dbaascli o junto con las copias de seguridad automatizadas de la consola. Si lo hace, podrían producirse condiciones en conflicto o sobrescrituras de la configuración, y es posible que las copias de seguridad no se ejecuten correctamente.