Gestión de copia de seguridad y recuperación de bases de datos en Oracle Exadata Database Service en infraestructura de Exascale

Descubra cómo trabajar con las funciones de copia de seguridad y recuperación proporcionadas por Oracle Exadata Database Service en la infraestructura de Exascale.

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. A partir del 06 de agosto de 2025, para los arrendamientos creados en las regiones FRA, PHX o NRT, Autonomous Recovery Service será el único destino de copia de seguridad cuando active la copia de seguridad automática en las bases de datos.

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 las 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. Al utilizar 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. La recomendación es 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.

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.

Almacenamiento de objetos

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 usar 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 a demanda completa, puede volver a intentar la operación cuando se haya restablecido la disponibilidad de la base de datos y la instancia de Oracle Exadata Database Service on Exascale 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

Los períodos de retención (en días) son 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 a. m. y la siguiente de 6:00 a 8:00 a. m.). 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 de copia de seguridad que especifique son de dos horas.

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. Sin embargo, las copias de seguridad automáticas de esa base de datos no se crearán hasta que esta asuma el rol principal.
  • 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 realizó a partir de dbaastools versión 21.4.1.1.0.

Comportamiento de destino de copia de seguridad al activar copias de seguridad automáticas y copias de seguridad independientes mediante la consola de OCI

Copias de seguridad automáticas

A partir del 06 de agosto de 2025, cuando active las copias de seguridad automáticas en la consola de OCI, Autonomous Recovery Service será el único destino de copia de seguridad disponible en las siguientes condiciones:

  • El arrendamiento se creó a partir del 06 de agosto de 2025.
  • La base de datos se despliega en las regiones de OCI, Frankfurt (FRA), Phoenix (PHX) y Tokio (NRT).
  • La versión de Oracle Database es posterior a la 19.18 o la 23.4.
  • Hay capacidad disponible y límites de copia de seguridad en la región.

    Nota: Si los límites o la capacidad no están disponibles, se le pedirá que envíe una solicitud de aumento de límite.

Cuando OCI Object Storage aún está disponible como opción de copia de seguridad

Seguirá viendo OCI Object Storage como destino de copia de seguridad en los siguientes escenarios:

  • El arrendamiento se creó antes del 06 de agosto de 2025.
  • La versión de la base de datos es anterior a 19.18 o 23.4.
  • La región no es FRA, PHX ni NRT.
  • La incorporación de Autonomous Recovery Service falla debido a la insuficiente capacidad regional para soportar el tamaño de la base de datos.

Escenarios adicionales

  • Configuración de Data Guard entre regiones: si la base de datos principal está ubicada en una región fuera de FRA, PHX o NRT, y la base de datos en espera está en una de estas regiones, solo se puede realizar una copia de seguridad de la base de datos en espera mediante Autonomous Recovery Service. OCI Object Storage no está soportado en FRA, PHX o NRT para nuevos arrendamientos.
  • Regiones de arrendamiento mixto: si opera en dos regiones, una con un arrendamiento existente (no en FRA, PHX ni NRT) y otra con un nuevo arrendamiento en FRA, PHX o NRT, experimentará una configuración de copia de seguridad dividida, con OCI Object Storage en la región existente y Autonomous Recovery Service en la nueva región.
  • Despliegue de varias regiones después del 06 de agosto de 2025: para los nuevos arrendamientos creados después del 06 de agosto de 2025, con despliegues en FRA, PHX, NRT e IAD, la configuración de copia de seguridad será diferente: FRA, PHX y NRT utilizarán Autonomous Recovery Service, mientras que IAD seguirá admitiendo OCI Object Storage.

Copias de seguridad autónomas

En el caso de los nuevos arrendamientos creados en las regiones FRA, PHX y NRT, el comportamiento existente para las copias de seguridad independientes no cambia tanto en la consola de OCI como en la API de OCI.

El comportamiento es el siguiente:

  • Si se configuran copias de seguridad automáticas en OCI Object Storage, las copias de seguridad independientes se almacenarán en OCI Object Storage.
  • Si las copias de seguridad automáticas se configuran en Autonomous Recovery Service, las copias de seguridad independientes se almacenarán en Autonomous Recovery Service.
  • Si no se configuran las copias de seguridad automáticas, las copias de seguridad independientes se establecerán por defecto en OCI Object Storage.

Copia de Seguridad de Retención a Largo Plazo con Servicio de Recuperación

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 en días (90 - 3.650) o años (1 - 10) desde el momento en que se creó 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 Para crear una base de datos a partir de una copia del sistema.

Al finalizar 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: todas las copias de seguridad, incluidas las copias de seguridad a largo plazo, se suprimirán.
  • 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 finalizar una base de datos para garantizar que se retengan 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.
  • La restauración in situ no se admite para LTR.
  • Para las bases de datos de una configuración de Data Guard, la copia de seguridad a largo plazo solo se creará 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 del 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 sin soporte, se restaurará a una versión principal con soporte, después de lo cual la base de datos se debe actualizar a cualquiera de las versiones principales con soporte.

Asignación de canal de copia de seguridad por defecto

Estos son los valores 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 núcleos del nodo. En la siguiente tabla se proporcionan los valores utilizados y el rango de núcleos, tanto el núcleo 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.

Núcleos 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 Núcleos <= 12 2 4
Mayor que 12 y menor o igual que 24 Núcleos > 12 y Núcleos <= 24 4 8
Mayor que 24 Núcleos > 24 8 16

Si es necesario, se puede definir un valor estático por nodo mediante el comando getConfig/configure de DBAASCLI para generar un archivo bckup cfg 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 principal.

Para suprimir instantáneas de máquinas virtuales

Para suprimir instantáneas de una máquina virtual (VM), utilice el menú Acción de la instantánea de VM.

  1. Navegue a la página principal del cluster de VM.
  2. En la lista de clusteres de VM, busque el cluster que desea gestionar y haga clic en su nombre resaltado para ver la página de detalles del cluster.
  3. Haga clic en el separador Máquinas virtuales.
  4. En la tabla Máquinas virtuales, haga clic en el nombre de la máquina virtual para la que desea suprimir una instantánea.
  5. Haga clic en el separador Instantáneas del sistema de archivos de VM.
  6. En la fila correspondiente a la instantánea que desea suprimir, haga clic en el menú Acción (...).
  7. Haga clic en Suprimir.

    Lea el mensaje y confirme que desea suprimir la instantánea.

Requisitos para copias de seguridad en Oracle Exadata Database Service en la infraestructura de Exascale

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

Permisos necesarios para que las bases de datos Oracle de OCI utilicen el servicio de recuperación

necesario

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

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

necesario

Crear políticas de protección

Creación de una política de protección

Opcional

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

Almacenamiento de objetos

  • 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 Oracle Exadata Database Service en instancias de infraestructura de Exascale. 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 copias 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

Nota

El almacenamiento de objetos crea una copia de seguridad completa de la base de datos mientras que el servicio de recuperación crea una copia de seguridad incremental.
  1. Abra el menú de navegación. Haga clic en Oracle Database y, a continuación, en Exadata Database Service on Exascale Infrastructure
  2. Seleccione su compartimento.
  3. Navegue hasta el cluster de VM en la nube que contiene la base de datos de la que desea realizar una copia de seguridad:

    En Oracle Exadata Database Service on Exascale Infrastructure, haga clic en los clusters de VM deExadata. En la lista de clústeres de VM, busque el clúster de VM al que desea acceder y haga clic en los nombres resaltados para ver la página de detalles del cluster.

  4. En la lista de bases de datos, busque la base de datos para la que desea crear una copia de seguridad completa bajo demanda y haga clic en su nombre para mostrar los detalles.
  5. En Recursos, haga clic en Copias de seguridad.

    Se mostrará una lista de copias de seguridad.

  6. Haga clic en Crear copia de seguridad.
  7. En la ventana de creación de copia de seguridad resultante, realice lo siguiente:
    • Nombre: proporcione un nombre descriptivo para la copia de seguridad.
    • Seleccione una opción de retención de copias de seguridad:
      • Retener copias de seguridad por período de retención de copia de seguridad: seleccione esta opción para utilizar el período de retención de política de protección para esta copia de seguridad.
      • Especificar período de retención de copia de seguridad a largo plazo: seleccione esta opción para especificar un período de LTR con Autonomous Recovery Service. 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.
    • Haga clic en Crear.

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, Exadata Database Service en la infraestructura de Exascale.
  2. Seleccione su compartimento.
  3. Vaya al cluster o el sistema de base de datos de VM en la nube que contiene la base de datos que desea cambiar el período de retención de copia de seguridad:

    En Exadata Database Service on Exascale 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.

  4. En la lista de bases de datos, haga clic en el nombre de la base del 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 el que desea cambiar el período de retención.
  7. Haga clic en Cambiar período de retención.
  8. En el período de retención de cambios 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 las últimas versiones: restablece la base de datos al estado bueno más conocido con la menor pérdida posible de datos.
  • Restaurar a un registro de hora: restablece la base de datos al registro de hora especificado.
  • Restaurar a SCN: restaura la base del sistema mediante 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 ve en la consola no incluye ninguna copia de seguridad no gestionada (copias de seguridad creadas directamente mediante dbaascli).

Restauración de una base de datos

Utilice este procedimiento para restaurar Oracle Database de Exadata Database Service en la infraestructura de Exascale.

  1. Abra el menú de navegación. Haga clic en Oracle Database y, a continuación, en Exadata Database Service on Exascale Infrastructure
  2. Haga clic en Clusters de VM de Exadata.
  3. En la lista de clusters de VM, busque el cluster que está en contacto con la base de datos que desea restaurar y haga clic en su nombre resaltado para ver la página de detalles del cluster.
  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 del restauración, la base de datos tendrá un estado "Fallo de restauración". Puede intentar realizar una nueva restauración utilizando otra opción de restauración. 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 subdirectorio /var/opt/oracle/log.

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

Puede utilizar la utilidad de copia de seguridad de Exadata, dbaascli, para realizar copias de seguridad de bases de datos en una instancia de Oracle Exadata Database Service on Exascale Infrastructure en un cubo existente en el 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 los 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 realiza 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.

Configuración de copia de seguridad por defecto

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

La configuración de la copia de seguridad por defecto sigue una serie 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: activada

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

Nota

El siguiente procedimiento se debe realizar en el primer nodo a partir del cluster Exadata Cloud Infrastructure de VM. 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.

  1. Utilice SSH para conectarse a uno de los nodos configurados de la base de datos en el cluster de VM.
    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.
    Nota

    A partir del 06 de agosto de 2025, para los arrendamientos creados en las regiones FRA, PHX o NRT, Autonomous Recovery Service será el único destino de copia de seguridad cuando active la copia de seguridad automática en las bases de datos.

    Acerca del uso del servicio de recuperación para realizar copias de seguridad y recuperar bases de datos de Oracle Cloud

    Parámetro Descripción
    bkup_disk=[yes|no] Indica si se realizará una copia de seguridad local en el disco (área de recuperación rápida).
    bkup_oss=[yes|no] 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.
    bkup_oss_url=<swift_url>

    Necesario si bkup_oss=yes.

    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úscula) que especifique al conectarse a la consola
    • <bucket>: nombre del cubo existente que desea utilizar para las copias de seguridad.
    bkup_oss_user=<oci_user_name>

    Necesario si bkup_oss=yes.

    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.

    bkup_oss_passwd=<auth_token>

    Necesario si bkup_oss=yes.

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

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

    bkup_oss_recovery_window=n

    Necesario si bkup_oss=yes.

    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.

    bkup_daily_time=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.
    bkup_archlog_cron_entry=[yes|no] Si no se configura ninguna copia de seguridad mediante dbaastools, al definir bkup_archlog_cron_entry=no se eliminará el trabajo de limpieza de logs de archivo de crontab. El valor por defecto es "yes".
  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 si se utilizan copias que se basan en una 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 - Parámetros de programación para dbaascli

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

Nombre antiguo: bkup_cron_entry

Nuevo nombre: scheduleBackups

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

Los valores válidos son yes y no.

No

Nombre antiguo: bkup_archlog_cron_entry

Nuevo nombre: 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.

La configuración de manageArchivelogs en no desactiva los trabajos de limpieza automática de archive log. Este valor solo es válido cuando la base de datos asociada no tiene configuradas copias de seguridad automáticas de la base de datos.

No

Nombre antiguo: bkup_l0_day

Nuevo nombre: 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 y sun. También están soportados formatos más largos, por ejemplo, Monday, Tuesday.

Valor por defecto: sun.

No

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

Nuevo nombre: 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

Nuevo nombre: 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

Nuevo nombre: 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

Nuevo nombre: 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

Nuevo nombre: backupDestination

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

Nombre antiguo: bkup_filesperset_regular

Nuevo nombre: 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

Nuevo nombre: filesPerSetAL

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

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 que reduce la cantidad de datos de los que se deben realizar copias de seguridad, transferir y restaurar. El valor recomendado es ON.

Nombre antiguo: rmanFraCleanupChannels

Nuevo nombre: numberOfChannelsForFraCleanup

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

Nombre antiguo: Compress_Archive_Logs

Nuevo nombre: 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

Nuevo nombre: archivelogRetentionDays

Especifica el número de días que se debe retener 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.

No

Nombre antiguo: bkup_oss_recovery_window

Nuevo nombre: 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 cuando bkup_oss está definido en yes o backupdestination está definido en OSS.

El Valor por Defecto es 30.

No

Nombre antiguo: bkup_oss_url

Nuevo nombre: ossURL

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

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

No

Nombre antiguo: bkup_oss_user

Nuevo nombre: 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 cuando bkup_oss está definido en yes o backupdestination está definido en OSS.

No

Nombre antiguo: bkup_oss_passwd

Nuevo nombre: 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 cuando bkup_oss está definido en yes o backupdestination está definido en OSS.

No

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

Nuevo nombre: 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

Nuevo nombre: 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

Nuevo nombre: catalogPassword

Contraseña del usuario del catálogo que se ha especificado en
bkup_rcat_user
.

Solo se aplica cuando bkup_use_rcat está definido en yes.

Nombre antiguo: bkup_rcat_conn

Nuevo nombre: 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 manera segura los parámetros anteriores marcado con Compatible with Console Automatic Backups = Yes junto con las copias del sistema automáticas basadas en esta 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. Utilice SSH para acceder a uno de los nodos de base de datos configurados en el recurso de cluster de VM o del 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. Utilice SSH para acceder a uno de los nodos de base de datos configurados en el recurso de cluster de VM o del 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.

Supresión de una copia de seguridad local

Para suprimir una copia de seguridad en Object Storage

Puede suprimir una copia de seguridad de archivado o a largo plazo de Object Storage.

# 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 de Object Store.

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

Uso de la API para gestionar copias de seguridad

Descubra cómo utilizar la API para copias de seguridad de bases de datos en Oracle Exadata Database Service en la infraestructura de Exascale.

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

Si bien el uso de RMAN para restaurar bases de datos de las que se ha realizado una copia de seguridad mediante cualquiera de los métodos que se describen en este documento se considera seguro, RMAN NUNCA se debe utilizar 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 manualmente 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 bkup_api de Exadata Cloud Service, funcionan para una variedad de casos de uso de copia de seguridad y recuperación.

Las copias de seguridad, configuradas en la consola, la API o bkup_api de Oracle Exadata Database Service en la infraestructura de Exascale funcionan para una variedad de casos prácticos 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 Oracle Database Backup and Recovery User's Guide.

La gestión de la copia de seguridad y la recuperación, mediante RMAN, en Oracle Exadata Database Service en la infraestructura de Exascale 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 bkup_api para desactivar las copias de seguridad gestionadas en la nube, incluida la desactivación del trabajo de depuración automática de archive logs, siguiendo este procedimiento:

Nota

Si ejecuta estos pasos, la automatización ya no depurará ni realizará una copia de seguridad de los archive logs en el FRA de la base de datos.
  1. Conéctese como el usuario opc al primer nodo de recursos informáticos.

    Para obtener instrucciones detalladas, consulte Conexión a un nodo de recursos informáticos mediante SSH.

  2. Inicie un shell de comandos de usuario root:
    sudo -s
  3. Utilice el comando bkup_api get config para generar un archivo que contenga la configuración de copia de seguridad actual para el despliegue de la base de datos:
    /var/opt/oracle/bkup_api/bkup_api get config [--file=filename] --dbname=dbname
    Donde:
    • filename es un parámetro opcional que se utiliza para especificar un nombre para el archivo que se genera
    • dbname es el nombre de la base de datos sobre la que desea actuar
  4. Edite los valores de parámetros en el archivo generado para cambiar los siguientes parámetros.
    Esto eliminará las entradas crontab de copia de seguridad y desactivará todas las copias de seguridad automáticas. Si los valores están definidos en yes, defínalos en no.
    bkup_cron_entry=no
    bkup_archlog_cron_entry=no
    bkup_nfs=no
    bkup_oss=no
    bkup_local=no
  5. Utilice el comando bkup_api set config para actualizar la configuración de copia de seguridad mediante el archivo que contiene la configuración de copia de seguridad actualizada:
    /var/opt/oracle/bkup_api/bkup_api set config --file=filename --dbname=dbname
    Donde:
    • filename es un parámetro opcional que se utiliza para especificar un nombre para el archivo que se genera
    • dbname es el nombre de la base de datos sobre la que desea actuar

    El trabajo para definir la configuración tardará varios minutos.

  6. Puede utilizar el comando bkup_api configure_status para comprobar el estado de la actualización de la configuración:
    /var/opt/oracle/bkup_api/bkup_api configure_status --dbname=dbname
    Donde:
    • dbname es el nombre de la base de datos sobre la que desea actuar

    El estado de Configuración de copias de seguridad comienza como En ejecución y, posteriormente, pasa a Finalizada cuando se completa.

  7. Vuelva a ejecutar el comando bkup_api get config y verifique que la configuración mostrada anteriormente está definida en no.
    /var/opt/oracle/bkup_api/bkup_api get config [--file=filename] --dbname=dbname
    Donde:
    • filename es un parámetro opcional que se utiliza para especificar un nombre para el archivo que se genera
    • dbname es el nombre de la base de datos sobre la que desea actuar
    Nota

    Después de realizar estos cambios, la automatización en la nube no realizará ninguna copia de seguridad, incluidas las copias de seguridad de archive log. Asegúrese de que existen copias de seguridad manuales de RMAN para evitar que se llene la ubicación del archive log.
    Nota

    Los cambios realizados mediante el comando bkup_api no se reflejan en la consola de Oracle Exadata Database Service en la infraestructura de Exascale.
  8. Salga del shell de comandos de usuario root:
    exit

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 bkup_api, puede restaurarla manualmente mediante la utilidad Oracle Recovery Manager (RMAN).

Si ha realizado una copia de seguridad de la base de datos utilizando bkup_api, 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 copia de seguridad y recuperación de Oracle Database.

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 backup_api o junto con las copias de seguridad automatizadas de la consola. Si lo hace, podrían producirse condiciones en conflicto o sobrescripciones de la configuración, y es posible que las copias de seguridad no se ejecuten correctamente.