Copia de seguridad y recuperación en Base Database Service

La realización de una copia de seguridad de la base de datos es fundamental para garantizar la seguridad de los datos. Oracle ofrece varios métodos para realizar copias de seguridad de la base de datos.

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.

Para obtener más información sobre Object Storage, consulte Visión general de Object Storage.

Almacenamiento local

  • Las copias de seguridad se almacenan localmente en el área de recuperación rápida del sistema de base de datos.
  • Durabilidad: baja
  • Disponibilidad: media
  • Ratio de copia de seguridad y recuperación: alta
  • Ventajas: copia de seguridad optimizada y rápida recuperación a un momento dado.
  • Inconvenientes: si el sistema de base de datos deja de estar disponible, la copia de seguridad también deja de estar disponible.

Actualmente, Oracle no proporciona la capacidad de asociar volúmenes de almacenamiento de bloques a un sistema de base de datos, por lo que no se pueden realizar copias de seguridad en volúmenes asociados a la red.

Para las copias de seguridad no gestionadas, puede utilizar RMAN o dbcli, y debe crear y gestionar sus propios cubos de Object Storage para las copias de seguridad.

Note:

Si anteriormente ha utilizado RMAN o dbcli para configurar copias de seguridad y, a continuación, pasa a usar la consola o la API, se creará una nueva configuración de copia de seguridad y se asociará a la base de datos. Esto significa que ya no podrá confiar en las copias de seguridad no gestionadas previamente configuradas para trabajar.

Para obtener más información sobre la creación de copias de seguridad, consulte:

Política de IAM necesaria

Para que pueda utilizar Oracle Cloud Infrastructure, un administrador debe otorgarle acceso de seguridad en una política. Este acceso es necesario tanto si utiliza la Consola como la API de REST con un SDK, una CLI u otra herramienta. Si recibe un mensaje que indica que no tiene permiso o que no está autorizado, verifique con su administrador qué tipo de acceso tiene y en qué compartimento debe trabajar.

Si no está familiarizado con las políticas, consulte Introducción a las políticas y Políticas comunes.

Requisitos

Revise y asegúrese de que se cumplen los siguientes requisitos para la operación de copia de seguridad y recuperación:

Servicio de recuperación

Para obtener información detallada sobre los requisitos de Recovery Service, consulte Configuración de Recovery Service.

Object Storage

  • El sistema de base de datos requiere acceso a Object Storage, incluida la conectividad al punto final de Swift correspondiente. Oracle recomienda utilizar un gateway de servicio con la VCN para activar este acceso. Consulte VCN y subredes.
  • Un cubo de Object Storage existente para utilizar como destino de copia de seguridad. Puede utilizar la consola o la API de Object Storage para crear el cubo. Consulte Gestión de cubos.
  • Token de autenticación generado por OCI. Puede utilizar la consola o la API de IAM para generar la contraseña. Consulte Gestión de credenciales de usuario.
  • 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 Object Storage, consulte Visión general de Object Storage.

Información General

La base de datos y el sistema de base de datos deben tener el estado "Disponible" para que se ejecute correctamente la operación de copia de seguridad. Oracle recomienda evitar realizar acciones que puedan interferir con la disponibilidad (como operaciones de aplicación de parches y de Data Guard) mientras una 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 se produce un fallo en una copia de seguridad completa bajo demanda, puede volver a intentar la operación cuando se haya restablecido la disponibilidad del sistema de base de datos y de la base de datos.

Además de la lista de requisitos, asegúrese de que se cumplan las siguientes condiciones para evitar fallos de copia de seguridad:

  • El modo de archivado de la base de datos está definido en ARCHIVELOG (valor por defecto).
  • El directorio /u01 del sistema de archivos del host de la base de datos tiene suficiente espacio libre para ejecutar los procesos de copia de seguridad.
  • El archivo .bash_profile del usuario oracle no incluye ningún comando interactivo (como oraenv u otro que pudiera generar un mensaje de error o de advertencia).
  • (Para las copias de seguridad automáticas) No se ha realizado ningún cambio en la entrada WALLET_LOCATION por defecto del archivo sqlnet.ora.
  • No se ha realizado ningún cambio en los valores de copia de seguridad de RMAN mediante los comandos de RMAN estándar.

Para obtener más información sobre los problemas que pueden surgir si no se siguen estas directrices, consulte Solución de fallos de copia de seguridad.

Funciones de copia de seguridad gestionadas

La siguiente información se aplica a las copias de seguridad gestionadas configuradas mediante la consola o la API.

Note:

Las bases de datos en un compartimento de zona de seguridad deben tener las copias de seguridad automáticas activadas. Para obtener una lista completa de las políticas que afectan a los recursos de Base Database Service, consulte Políticas de zona de seguridad.

Actualmente, están soportados los dos tipos siguientes de copias de seguridad automáticas:

  • Recovery Service: solución de copia de seguridad centralizada, totalmente gestionada e independiente para bases de datos.
  • Object Storage: solución de almacenamiento bajo demanda, segura y ampliable para bases de datos.

Para alinearse con la práctica recomendada por Oracle de utilizar privilegios administrativos SYSBACKUP para operaciones de copia de seguridad y recuperación, la automatización en la nube crea un usuario administrativo común denominado 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 las operaciones de copia de seguridad o recuperación.

Copias de seguridad automáticas incrementales y archivadas de redo log

Cuando activa la función de copia de seguridad de Object Storage de una base de datos, el servicio crea lo siguiente de forma continua:

  • Copia de seguridad semanal de nivel 0, creada generalmente en un día específico del fin de semana. Una copia de seguridad de nivel 0 equivale a una copia de seguridad completa. Tenga en cuenta que en la consola, las copias de seguridad semanales de nivel 0 aparecen en la lista de copias de seguridad con tipo de copia de seguridad "incremental", al igual que las copias de seguridad diarias de nivel 1.
  • Copias de seguridad diarias de nivel 1, que son copias de seguridad incrementales creadas cada día durante los seis días siguientes al día de la copia de seguridad de nivel 0.
  • Las copias de seguridad de nivel 0 y nivel 1 se almacenan en Object Store y tienen asignado un OCID.
  • Copias de seguridad de redo log archivadas en curso (con una frecuencia mínima de cada 60 minutos). El campo Hora de última copia de seguridad en la página de detalles de base de datos de la consola de OCI muestra la hora de los últimos redo logs archivados. Esta copia de seguridad difiere de las copias de seguridad automáticas de nivel 0 y nivel 1, ya que se basa en datos de log y no tiene un OCID asignado. La última copia de seguridad de redo log archivada se puede utilizar para crear una nueva base de datos o para recuperar una base de datos con una mínima pérdida de datos.

Retención de copia de seguridad

Si decide activar las copias de seguridad automáticas, puede elegir entre uno de los períodos de retención proporcionados o una política personalizada. El sistema suprime automáticamente las copias de seguridad incrementales al final del período de retención seleccionado.

Están disponibles los siguientes períodos de retención para Recovery Service. Los períodos de retención (en días) se definen en la política de protección de Recovery Service.
  • Bronce (14 días)
  • Plata (35 días) (valor por defecto)
  • Oro (65 días)
  • Platino (95 días)
  • Personalizado (política de protección definida por el usuario)
Están disponibles los siguientes períodos de retención para Object Storage.
  • 7 días
  • 15 días
  • 30 días (valor por defecto)
  • 45 días
  • 60 días

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 en días (90 - 3650) 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 sobre los pasos, 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 sobre los pasos, consulte Cambio del período de retención de una copia de seguridad de retención a largo plazo 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 sobre los pasos, consulte Creación de un sistema de base de datos a partir de una copia de seguridad mediante la consola.

Tras la terminación del sistema de 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 de LTR.
  • 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.

Note:

Oracle recomienda seleccionar la opción 'Suprimir según política' al terminar un sistema de base de datos para asegurarse de que se mantienen las copias de seguridad de LTR.

Tenga en cuenta los siguientes factores adicionales para las copias de seguridad de LTR:

  • 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 de una configuración de Data Guard, la copia de seguridad de LTR 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.
  • Todas las claves de cifrado se mantendrán durante todo el período de retención del LTR.
  • Puede cancelar un LTR si tiene el estado 'creando'.
  • Puede suprimir una copia de seguridad de LTR en cualquier momento después de crearla.
  • Durante la restauración, si la copia de seguridad de LTR que se está restaurando es una versión principal del directorio raíz de base de datos soportada, se restaurará a la última RU de esa versión.
  • Durante la restauración, si la copia de seguridad de LTR que se está restaurando no es una versión principal del directorio raíz de base de datos soportada, se restaurará en cualquiera de las versiones principales soportadas, en las que se debe actualizar la base de datos a cualquiera de las versiones principales soportadas.

Opciones de Restauración

Las siguientes opciones de restauración están disponibles para la base de datos. Esta acción no está soportada para LTR.

  • 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 número de cambio del sistema (SCN) especificado. Este SCN debe ser válido.

    Note:

    Puede determinar el número SCN que 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.

Políticas de Protección

Recovery Service utiliza políticas de protección para controlar la retención de copias de seguridad de bases de datos en Oracle Cloud.

Las políticas de protección proporcionan una gestión automatizada de la retención para las bases de datos protegidas, cumpliendo los requisitos para los entornos regulados. Cada base de datos protegida debe estar asociada a una política de protección.

Una política de protección determina el período máximo (en días) permitido para retener las copias de seguridad creadas por Recovery Service. En función de los requisitos de su negocio, puede asignar políticas independientes para cada base de datos protegida o utilizar una única política en todas las bases de datos protegidas de una VCN.

Para obtener más información, consulte Gestión de políticas de protección.

Bases de datos protegidas

Una base de datos protegida hace referencia a una base de datos de Oracle Cloud que utiliza Recovery Service para las operaciones de copia de seguridad.

Para obtener más información, consulte Gestión de bases de datos protegidas.

Protección de datos en tiempo real

Recovery Service ofrece protección de datos en tiempo real para que pueda recuperar una base de datos en unos pocos subsegundos desde un fallo de la base de datos.

La protección en tiempo real es la transferencia continua de cambios de redo de una base de datos protegida a Recovery Service. Esto reduce la pérdida de datos y proporciona un objetivo de punto de recuperación (RPO) cercano a 0. Esta es una opción de costo adicional.

Para obtener más información, consulte Protección de datos en tiempo real.

Opciones de supresión de copia de seguridad tras la terminación de la base de datos

Cuando se termina una base de datos, se suprimen todos sus recursos junto con las copias de seguridad automáticas. Las copias de seguridad gestionadas que utilizan el destino Recovery Service y Object Storage se suprimirán en función de las opciones de política de retención seleccionadas.

Puede utilizar las siguientes opciones para retener copias de seguridad de bases de datos gestionadas una vez terminada la base de datos. Estas opciones también pueden ayudar a restaurar la base de datos a partir de copias de seguridad en caso de daño accidental o malicioso en la base de datos.

  • Conservar copias de seguridad según el período de retención: cuando se termina una base de datos, las copias de seguridad automáticas de la base de datos asociadas a la base de datos terminada y todos sus recursos se eliminarán al final del período de retención especificado.
  • Conservar copias de seguridad durante 72 horas y suprimir después: cuando se termina una base de datos, las copias de seguridad automáticas asociadas a la base de datos terminada y todos sus recursos se conservarán durante 72 horas y, a continuación, se suprimirán. Las copias de seguridad se conservan durante 72 horas para evitar que el usuario las suprima de forma accidental.

Programación de copias de seguridad

Para las copias de seguridad de Recovery Service, el proceso de copia de seguridad automática se inicia en cualquier momento o dentro de la ventana asignada.

Para las copias de seguridad de Object Storage, el proceso de copia de seguridad automática utilizado para crear copias de seguridad de nivel 0 y nivel 1 se puede ejecutar en cualquier momento dentro de la ventana de copia de seguridad diaria (entre medianoche y las 6:00 a. m.). 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.

Para las copias de seguridad de Object Storage, 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 del sistema de base de datos si no especifica una ventana. 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.

Tenga en cuenta los siguientes factores al programar copias de seguridad.

  • Zona horaria de ventana de copia de seguridad: las copias de seguridad automáticas activadas por primera vez después del 20 de noviembre de 2018 en cualquier base de datos se ejecutarán entre medianoche y las 6:00 a. m. en la zona horaria de la región del sistema de base de datos. Si ha activado las copias de seguridad automáticas en una base de datos antes de esta fecha, la ventana de copia de seguridad para la base de datos seguirá siendo entre medianoche y las 6:00 a. m. UTC. Puede crear una solicitud de servicio de My Oracle Support para que las copias de seguridad automáticas se ejecuten en la ventana de copia de seguridad de su elección.
  • Data Guard: en una asociación de Data Guard, puede configurar copias de seguridad automáticas y crear copias de seguridad de la base de datos primaria. Sin embargo, no puede configurar copias de seguridad automáticas ni crear copias de seguridad de la base de datos en espera. Además, después de una operación de switchover, debe volver a configurar las copias de seguridad automáticas para la base de datos que ha asumido el rol principal en la asociación de Data Guard.
  • Cambios en el período de retención: si reduce el período de retención de copia de seguridad automática de la base de datos en el futuro, el sistema suprimirá las copias de seguridad existentes que se encuentren fuera del período de retención actualizado.
  • Costos de Object Storage: las copias de seguridad automáticas generan costos de uso de Object Storage.

Copias de seguridad completas bajo demanda

Puede crear una copia de seguridad completa de la base de datos en cualquier momento, a menos que la base de datos asuma el rol en espera en una asociación de Data Guard.

Copias de seguridad independientes

Cuando se finaliza un sistema de base de datos o una base de datos, se suprimen todos sus recursos junto con todas las copias de seguridad automáticas. Las copias de seguridad gestionadas que utilizan el destino Recovery Service y Object Storage se suprimirán en función de las opciones de política de retención seleccionadas. Las copias de seguridad completas permanecen en Object Storage como copias de seguridad independientes. Puede utilizar una copia de seguridad independiente para crear una nueva base de datos.

Note:

  • La lista de copias de seguridad que se muestra en la consola no incluye las copias de seguridad no gestionadas (copias de seguridad creadas directamente mediante RMAN o dbcli).
  • Todas las copias de seguridad se cifran con la misma clave maestra utilizada para el cifrado de cartera de cifrado de datos transparente (TDE).

Cancelación de una copia de seguridad completa o incremental en ejecución

Puede cancelar una copia de seguridad en curso, lo que le permite liberar recursos del sistema. Como parte del flujo de trabajo Crear base de datos y de forma independiente (una vez creada la base de datos), puede activar la copia de seguridad automática y seleccionar el destino de copia de seguridad deseado. Según el destino de copia de seguridad seleccionado, puede tener una o más copias de seguridad completas y varias copias de seguridad incrementales. Una vez iniciada cualquiera de estas copias de seguridad, tiene la opción de cancelarlas a mitad del proceso. Puede cancelar cualquier copia de seguridad en ejecución (automática o independiente) desde la consola o la API. Puede cancelar una copia de seguridad manual, que se dispara al hacer clic en el botón Crear copia de seguridad. También puede suprimir una copia de seguridad manual cancelada.

Copia de Seguridad y Restauración desde Bases de Datos en Espera en una Asociación de Data Guard

Puede realizar copias de seguridad y restauraciones desde una base de datos en espera en una asociación de Data Guard. Mediante esta función, puede descargar copias de seguridad en la base de datos en espera, liberando así recursos en la base de datos primaria.

Antes de comenzar, tenga en cuenta lo siguiente:

  • Puede utilizar el servicio de recuperación o el almacenamiento de objetos para realizar una copia de seguridad de las bases de datos en espera.
  • Puede programar copias de seguridad automáticas y configurar períodos de retención y programas de copia de seguridad en la base de datos en espera.
  • Puede crear una base de datos en otro dominio de disponibilidad (AD) de la misma región o en una región diferente a la de una copia de seguridad de la base de datos en espera.
  • Las copias de seguridad solo se pueden configurar en la base de datos primaria, solo en la base de datos en espera o en las bases de datos primaria y en espera. Sin embargo, cuando se configura, tanto la base de datos primaria como la base de datos en espera deben tener el mismo destino de copia de seguridad.
  • Para las copias de seguridad del servicio de recuperación, la base de datos primaria se puede restaurar o recuperar a partir de las copias de seguridad de la base de datos en espera o de la base de datos primaria. Del mismo modo, la base de datos en espera se puede restaurar o recuperar a partir de las copias de seguridad de la base de datos principal o de la base de datos en espera.
  • Para las copias de seguridad del almacenamiento de objetos, la base de datos primaria y la base de datos en espera se pueden restaurar o recuperar únicamente a partir de sus respectivas copias de seguridad.
  • El destino de copia de seguridad de la base de datos principal y la base de datos en espera de una asociación de Data Guard debe ser el mismo. Por ejemplo, si el destino de copia de seguridad de la base de datos primaria es Recovery Service, el destino de copia de seguridad de la base de datos en espera también debe ser Recovery Service. Del mismo modo, si el destino de copia de seguridad de la base de datos en espera es Recovery Service, el destino de copia de seguridad de la base de datos primaria también debe ser Recovery Service.
  • El destino de copia de seguridad solo se puede cambiar después de desactivar la copia de seguridad en la base de datos principal o en espera en una asociación de Data Guard. Por ejemplo, si el destino de copia de seguridad de las bases de datos principal y en espera es Object Storage y desea cambiar el destino de copia de seguridad de la base de datos principal a Recovery Service, primero debe desactivar la copia de seguridad en la base de datos en espera.
  • Si se configurara la copia de seguridad automática en la base de datos primaria, al realizar el switchover, las copias de seguridad continuarían en la nueva base de datos en espera.
  • Si se ha configurado la copia de seguridad automática en la base de datos en espera, tras el failover, las copias de seguridad continuarán en la nueva base de datos primaria y las copias de seguridad se desactivarán en la nueva base de datos en espera.

Para obtener más información sobre los pasos para configurar copias de seguridad automáticas mediante la consola, consulte Configuración de copias de seguridad automáticas para una base de datos en espera.

Restauración entre regiones

Puede utilizar una copia de seguridad existente y restaurarla para crear una base de datos (restauración externa) en dominios de disponibilidad de la misma región o en otra diferente mediante una copia de seguridad creada con Object Storage o Autonomous Recovery Service.

También puede restaurar una copia de seguridad realizada en una base de datos configurada mediante carteras basadas en host (carteras locales) u OCI Vault. Para obtener más información sobre las claves de cifrado de base de datos, consulte Gestión de claves de cifrado.

Los siguientes requisitos son necesarios para la restauración entre regiones (en el mismo arrendamiento) para Oracle Database Autonomous Recovery Service.

  1. Intercambio de VCN: tanto las redes virtuales en la nube de las regiones locales como remotas se deben conectar entre regiones.
  2. Agregue reglas de seguridad en las VCN de origen y destino.

    1. Agregue reglas de entrada al origen.
      1. Haga clic en Agregar regla de entrada y agregue estos detalles para configurar una regla que permita el tráfico HTTPS desde cualquier lugar:

        • Tipo de origen: CIDR
        • CIDR de origen: especifique el CIDR de la VCN en la que reside la base de datos.
        • Protocolo IP: TCP
        • Rango de puertos de origen: Todo
        • Rango de puertos de destino: 8005
        • Descripción: especifique una descripción opcional de la regla de entrada para ayudar a gestionar las reglas de seguridad.
      2. Haga clic en Add Ingress Rule y agregue estos detalles para configurar una regla que permita el tráfico SQLNet desde cualquier lugar:

        • Tipo de origen: CIDR
        • CIDR de origen: especifique el CIDR de la VCN en la que reside la base de datos.
        • Protocolo IP: TCP
        • Rango de puertos de origen: Todo
        • Rango de puertos de destino: 2484
        • Descripción: especifique una descripción opcional de la regla de entrada para ayudar a gestionar las reglas de seguridad.
      3. Haga clic en Add Ingress Rule y agregue estos detalles para configurar una regla que permita el tráfico HTTPS desde cualquier lugar:

        • Tipo de origen: CIDR
        • CIDR de origen: especifique el CIDR de la VCN de destino.
        • Protocolo IP: TCP
        • Rango de puertos de origen: Todo
        • Rango de puertos de destino: 8005
        • Descripción: especifique una descripción opcional de la regla de entrada para ayudar a gestionar las reglas de seguridad.
      4. Haga clic en Add Ingress Rule y agregue estos detalles para configurar una regla que permita el tráfico SQLNet desde cualquier lugar:

        • Tipo de origen: CIDR
        • CIDR de origen: especifique el CIDR de la VCN de destino.
        • Protocolo IP: TCP
        • Rango de puertos de origen: Todo
        • Rango de puertos de destino: 2484
        • Descripción: especifique una descripción opcional de la regla de entrada para ayudar a gestionar las reglas de seguridad.
    2. Agregue reglas de salida al destino. Estos son opcionales si el tráfico de salida está abierto para todas las IP y puertos.
      1. Haga clic en Add Egress Rule y agregue estos detalles para configurar una regla que permita el tráfico HTTPS desde cualquier lugar:

        • Tipo de origen: CIDR
        • CIDR de origen: especifique el CIDR de la VCN de origen.
        • Protocolo IP: TCP
        • Rango de puertos de origen: Todo
        • Rango de puertos de destino: 8005
        • Descripción: especifique una descripción opcional de la regla de entrada para ayudar a gestionar las reglas de seguridad.
      2. Haga clic en Add Egress Rule y agregue estos detalles para configurar una regla que permita el tráfico de SQLNet desde cualquier lugar:

        • Tipo de origen: CIDR
        • CIDR de origen: especifique el CIDR de la VCN de origen.
        • Protocolo IP: TCP
        • Rango de puertos de origen: Todo
        • Rango de puertos de destino: 2484
        • Descripción: especifique una descripción opcional de la regla de entrada para ayudar a gestionar las reglas de seguridad.

    Note:

    Asegúrese de que la subred del servicio de recuperación está presente en la región de origen y está asociada a la VCN de origen. Para obtener más información, consulte Creación de una subred del servicio de recuperación en la VCN de base de datos.
  3. Realice el intercambio de DNS entre las redes virtuales en la nube locales y remotas.

Retención de archivos de auditoría y rastreo para bases de datos con copias de seguridad automáticas

Oracle Database escribe archivos de auditoría y rastreo en el almacenamiento local de la base de datos en el directorio /u01. Estos archivos se conservan durante 30 días por defecto, aunque puede cambiar este intervalo. Una vez al día, un trabajo de Oracle Scheduler desecha los archivos de auditoría y rastreo de más de 30 días (o el intervalo especificado por el usuario, si corresponde). También puede desactivar el trabajo de Scheduler si desea conservar estos archivos de forma permanente. Utilice los siguientes comandos dbcli para realizar cambios en este trabajo de Scheduler.

  • Para cambiar el valor por defecto de 30 días del período de retención:

    dbcli update-database -in <dbName> -lr <number_of_days_to_retain_files>

    Por ejemplo:

    dbcli update-database -in inventorydb -lr 15
  • Para desactivar el trabajo de desecho diario de Scheduler para los archivos de auditoría y rastreo antiguos:

    dbcli update-schedule -i <schedulerID> -d

    Por ejemplo:

    dbcli update-schedule -i 5678 -d

Uso de la API

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 las siguientes operaciones de API para gestionar copias de seguridad de base de datos:

  • ListBackups
  • GetBackup
  • CreateBackup
  • DeleteBackup
  • RestoreDatabase
  • UpdateDatabase: para activar y desactivar las copias de seguridad automáticas.
  • CreateDbHome: para crear una base de datos del sistema de base de datos a partir de una copia de seguridad independiente.

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