Mostrando entradas con la etiqueta Copias de Seguridad. Mostrar todas las entradas
Mostrando entradas con la etiqueta Copias de Seguridad. Mostrar todas las entradas

11 febrero 2021

Prácticas recomendadas de copia de seguridad y recuperación de bases de datos

 

La capacidad de restaurar bases de datos a partir de copias de seguridad válidas es una parte vital para garantizar la continuidad del negocio. La integridad de la copia de seguridad y las restauraciones son una pieza importante de los objetivos de control de TI del IT Governance Institute para Sarbanes-Oxley, 2.ª edición. En muchos casos, los auditores de TI simplemente confirman si las copias de seguridad se están realizando en disco o en cinta, sin considerar la integridad o viabilidad de los medios de copia de seguridad.

Este artículo cubre los temas relacionados con la pérdida de datos y los tipos de respaldo y recuperación de bases de datos disponibles. También se proporcionan las mejores prácticas que pueden ayudar a un auditor a evaluar la efectividad de la copia de seguridad y recuperación de la base de datos. Este artículo se centra en las tecnologías y capacidades del sistema de administración de bases de datos relacionales (RDBMS) de Oracle y Microsoft (MS) SQL Server porque, en conjunto, cubren aproximadamente el 40 por ciento de todas las instalaciones de bases de datos. 

Una de las responsabilidades clave de un administrador de bases de datos (DBA) es prepararse para la posibilidad de fallas en los medios, hardware y software, así como recuperar bases de datos durante un desastre. En caso de que ocurra alguna de estas fallas, el objetivo principal es garantizar que la base de datos esté disponible para los usuarios dentro de un período de tiempo aceptable, al tiempo que se asegura que no haya pérdida de datos. Los administradores de bases de datos deben evaluar su preparación para responder eficazmente a tales situaciones respondiendo las siguientes preguntas:

  • ¿Qué tan seguro está el DBA de que los datos de los que depende el negocio de la empresa se hayan respaldado correctamente y que los datos se pueden recuperar de estos respaldos dentro de los límites de tiempo permitidos, según un acuerdo de nivel de servicio (SLA) o el objetivo de tiempo de recuperación, como se especifica en el plan de recuperación ante desastres de la organización?
  • ¿Ha tomado el DBA medidas para redactar y probar los procedimientos para proteger y recuperar las bases de datos de numerosos tipos de fallas?
La siguiente es una lista de verificación para los procedimientos de copia de seguridad y recuperación de la base de datos que se explican a lo largo de este artículo:

  • Desarrolle un plan de respaldo integral.
  • Realice una gestión de copias de seguridad eficaz.
  • Realice pruebas periódicas de restauración de bases de datos.
  • Tener SLA de respaldo y recuperación redactados y comunicados a todas las partes interesadas.
  • Haga que se redacte y documente la parte de la base de datos del plan de recuperación ante desastres (DRP).
  • Mantenga actualizados sus conocimientos y experiencia sobre las herramientas de copia de seguridad y recuperación de bases de datos y sistemas operativos.

Plan de respaldo integral

Los DBA son responsables de elaborar un plan de respaldo integral para las bases de datos de las que son responsables. El plan de respaldo debe incluir todos los tipos de RDBMS dentro de la empresa y debe cubrir las siguientes áreas:

  • Decide qué necesitas respaldar. Es imperativo que el DBA esté al tanto de la base de datos y los componentes de aplicaciones y sistemas operativos relacionados que deben respaldarse, ya sea mediante una copia de seguridad en línea o una copia de seguridad en frío fuera de línea.
          Los siguientes son detalles de lo que se debe respaldar:            
    • Software del sistema operativo: un evento como una falla de hardware requerirá una restauración completa del sistema, comenzando con el sistema operativo, por lo que es necesario realizar una copia de seguridad del sistema operativo del servidor de base de datos inicialmente y después de cualquier actualización del sistema o cambio de configuración.
    • Software RDBMS: se debe realizar una copia de seguridad del software RDBMS inicialmente y después de cualquier parche / actualización.
    • Software de aplicación (cuando corresponda): esto se aplica especialmente a Oracle E-Business Suite, Oracle Application Server y Oracle Enterprise Manager (OEM). El administrador de bases de datos de la aplicación debe completar una copia de seguridad completa inicial de las aplicaciones en el disco utilizando un comando del sistema operativo apropiado y, luego, programar futuras copias de seguridad incrementales, por ejemplo, después de cualquier parche / actualización. Estas copias de seguridad también deben transferirse a cinta.
    • Contraseñas: se deben conservar todas las contraseñas de superusuario que puedan ser necesarias durante la recuperación. Es una buena idea asegurarse de que se cambien las contraseñas predeterminadas que vinieron con la instalación inicial del RDBMS.
    • Todos los componentes de las bases de datos de Oracle:
      • Archivo de parámetros de la base de datos: un archivo de parámetros o un archivo de parámetros del servidor (SPFILE) define los parámetros de inicialización persistentes de una base de datos, incluida la información sobre los archivos de control de la base de datos.
      • Archivo (s) de control de la base de datos: el archivo de control almacena el estado de la estructura física de la base de datos. Si deja de estar disponible, la base de datos no puede funcionar. Es imperativo que se realice una copia de seguridad de estos archivos mientras se realiza una copia de seguridad de otros componentes de la base de datos. En versiones posteriores de Oracle (9i en adelante), el DBA puede configurar la copia de seguridad automática del archivo de parámetros, así como el archivo de control, para garantizar que se realice una copia de seguridad de estos después de cada copia de seguridad y después de cualquier cambio estructural en la base de datos.
      • Archivos de datos de la base de datos: estos deben respaldarse durante la copia de seguridad en frío, así como durante la copia de seguridad en línea, utilizando el Administrador de recuperación de Oracle (RMAN) o, en las versiones de Oracle Database en las que no se introdujo RMAN, colocando los espacios de tabla en modo de copia de seguridad. El DBA debe intentar ejecutar todas las bases de datos de producción en el modo de registro de archivo para que sea posible la recuperación hasta el punto de falla.
      • Rehacer los archivos de registro y los registros de rehacer archivados: mientras realiza una copia de seguridad en frío, el DBA necesita hacer una copia de seguridad de los registros de rehacer. Cuando la base de datos se ejecuta en modo de registro de archivo y realiza una copia de seguridad en línea, el DBA necesita archivar los registros de rehacer de forma manual o automática y luego hacer una copia de seguridad de todos los registros de rehacer del archivo.
      • Archivos de red de Oracle: es importante realizar una copia de seguridad de todos los archivos de red de Oracle inicialmente y después de cualquier cambio.
      • Archivos de contraseña: los archivos de contraseña, cuando se utilizan, deben respaldarse inicialmente y después de cualquier cambio. Wallets, por ejemplo.
    • Bases de datos de MS SQL Server:
      • Realice una copia de seguridad de las bases de datos del sistema y de los usuarios.
      • Tenga un plan de mantenimiento separado para las bases de datos del sistema, es decir, maestro, modelo, msdb. Master solo admite copias de seguridad completas; La copia de seguridad de tempdb no es necesaria, ya que se reconstruye durante el inicio de SQL Server.
      • Realice una copia de seguridad de todas las bases de datos de los usuarios. Configure todas las bases de datos de usuarios para el modelo de recuperación completo y realice una copia de seguridad de los registros de transacciones y de la base de datos.
  • Determine el tipo de copia de seguridad apropiado para usar con sus datos.
    • Bases de datos de Oracle
        1. Copias de seguridad lógicas: este tipo de copia de seguridad se realiza mediante las utilidades de Oracle "exp." A partir de la versión 10g, también se puede utilizar Data Pump. Se puede realizar una copia de seguridad de toda la base de datos, esquemas individuales, tablas o espacios de tabla. La restauración se realiza mediante "imp" o Data Pump. Con tales copias de seguridad, la recuperación hasta el punto de falla no es posible.
          1. Respaldos físicos fuera de línea o en frío: la base de datos se debe cerrar y se debe realizar una copia de todos los archivos de datos esenciales y otros componentes de la base de datos.
            1. Copias de seguridad físicas en línea o en caliente: este método permite realizar copias de seguridad de la base de datos mientras la base de datos está en funcionamiento. Se deben tener en cuenta los siguientes puntos al realizar copias de seguridad en línea:
              • Ponga los espacios de tabla en modo de copia de seguridad y haga una copia de seguridad de los archivos de datos asociados mediante un comando de copia del sistema operativo, o utilice RMAN, una herramienta sólida proporcionada por Oracle para la copia de seguridad y la recuperación con la versión 8.x en adelante. Oracle agrega nueva funcionalidad a esta herramienta con cada versión. RMAN puede usar el archivo de control de la base de datos para mantener su catálogo, o el DBA puede configurar el esquema para cada base de datos, en una base de datos separada para los catálogos de RMAN.
              • El DBA debe revisar y tener en cuenta la matriz de compatibilidad de RMAN para la base de datos que se está respaldando / restaurando, así como el ejecutable de RMAN y la base de datos / esquema del catálogo de RMAN.
              • Los administradores de bases de datos deben familiarizarse con las copias de seguridad completas, incrementales y diferenciales y configurarlas mediante scripts de RMAN. Los DBA deben revisar su edición RDBMS, por ejemplo, las copias de seguridad incrementales no son posibles en las ediciones estándar anteriores a Oracle 10g. Para restaurar / recuperar una base de datos hasta el punto de falla o un punto anterior en el tiempo, el DBA debe poner la base de datos en modo de registro de archivo y hacer una copia de seguridad de todos los registros de rehacer archivados.
              • Es importante no olvidar realizar una copia de seguridad del catálogo de RMAN al final de cada copia de seguridad. Los administradores de bases de datos pueden realizar una copia de seguridad de exportación del esquema de catálogo de RMAN.
          • Base de datos Microsoft SQL Server:
            • Copias de seguridad lógicas: en SQL Server, se pueden realizar copias de seguridad de objetos de esquema individuales en archivos planos en cualquiera de los formatos de archivo admitidos. Luego, los archivos planos se pueden restaurar utilizando herramientas como la utilidad bcp, el Asistente de importación y exportación o las herramientas de SQL Server Integration Services.
            • Copias de seguridad físicas: se recomienda que todas las bases de datos de los usuarios se configuren para el modelo de recuperación completa, y que tanto la base de datos como los registros de transacciones sean respaldados para restaurar / recuperar la base de datos hasta el punto de falla. Los administradores de bases de datos deben familiarizarse a fondo con los modelos de recuperación de bases de datos y las copias de seguridad completas, diferenciales y de registro de transacciones, y configurarlas en consecuencia. La estrategia de copia de seguridad de archivos o grupos de archivos se puede utilizar si las bases de datos de las que se realizará la copia de seguridad son bases de datos muy grandes (VLDB) que están particionadas entre varios archivos.
        • Establezca una estrategia para manejar las copias de seguridad de VLDB: en Oracle, el DBA puede reducir la ventana de copia de seguridad para las VLDB asignando varios canales y ajustando las copias de seguridad, puede ahorrar espacio en disco mediante el uso de copias de seguridad comprimidas y puede bloquear el seguimiento con técnicas de copia de seguridad incrementales con lo último Versiones El DBA debe revisar la versión y edición de la base de datos para confirmar la disponibilidad de esta opción. Si esto no funciona, el DBA puede considerar configurar copias de seguridad de espejo dividido. Para SQL Server, el DBA puede dividir la base de datos entre varios archivos y utilizar la estrategia de copia de seguridad de archivos o grupos de archivos. Además, el uso de varios dispositivos de respaldo en SQL Server permite que los respaldos se escriban en todos los dispositivos en paralelo.
        • Establezca una programación y una ventana de respaldo adecuadas: es una buena práctica seleccionar una ventana de respaldo en un punto en el que la menor cantidad de actividad afecte a la base de datos para que la copia de respaldo no reduzca los recursos disponibles del servidor de base de datos y ralentice la actividad del usuario de la base de datos. El DBA puede ajustar la ventana de respaldo al paralelizar los respaldos utilizando múltiples canales; sin embargo, el DBA debe revisar la versión y edición de la base de datos para confirmar la disponibilidad de esta opción. En la gran mayoría de los casos, es mejor configurar un ciclo de respaldo semanal comenzando con respaldos completos el viernes por la noche o el sábado por la mañana y respaldos incrementales / diferenciales durante los días de semana. Las copias de seguridad del registro de transacciones / archivos se pueden programar para cada pocas horas, dependiendo de la volatilidad de la base de datos.
        • Decida dónde almacenar las copias de seguridad: se pueden realizar copias de seguridad de las bases de datos de Oracle y MS SQL Server directamente en cinta o disco (localmente o en la red), y luego las copias de seguridad se pueden archivar en cinta. Es una buena práctica realizar copias de seguridad en disco, transferirlas a cinta y almacenar cintas fuera del sitio para la recuperación de desastres (DR). Las copias de seguridad en disco son más rápidas; Los administradores de bases de datos tienen más control y pueden monitorearlos mejor y, con este método, los administradores de bases de datos mantienen dos conjuntos de copias de seguridad, una en disco y la otra en cinta. Durante la restauración, si las copias de seguridad aún están en el disco, será una restauración más rápida, reduciendo el tiempo medio de recuperación (MTTR).
        • Desarrolle una política de retención de copias de seguridad: la política de retención de copias de seguridad se relaciona con el programa de rotación del disco y la cinta y debe decidirse según el SLA establecido con la comunidad de usuarios empresariales. El propietario de los datos debe especificar el período de conservación de los datos. El período de retención puede variar de meses a años, según las leyes locales. En consecuencia, el DBA debería eliminar las copias de seguridad antiguas para crear espacio para las copias de seguridad actuales. La política de retención de datos debe elegirse con cuidado, asegurándose de que complementa la política de retención del subsistema de medios de respaldo y los requisitos para la estrategia de recuperación de respaldo. Si no utiliza un catálogo, el DBA debe asegurarse de que el parámetro de instancia de tiempo de mantenimiento de registros del archivo de control coincida con la política de retención.

        Gestión eficaz de copias de seguridad

        Después de hacer un plan de respaldo sólido y completar el trabajo inicial, el DBA debe administrar adecuadamente los respaldos, teniendo en cuenta los siguientes puntos:
        • Automatización de copias de seguridad: para Oracle, configure las copias de seguridad a través de OEM o utilice una herramienta de programación del sistema operativo, y envíe la salida a un archivo de registro que pueda revisarse en busca de errores. En SQL Server, use planes de mantenimiento para programar copias de seguridad.
        • Supervisión de copias de seguridad: configure la supervisión con las herramientas adecuadas para que el administrador de bases de datos reciba un correo electrónico o una alerta a través de un buscapersonas o teléfono celular por cualquier copia de seguridad fallida, que debe volver a ejecutarse lo antes posible.
        • Registros y catálogos de respaldo: revise los registros de respaldo y la información del catálogo de respaldo periódicamente para detectar cualquier problema. Utilice los informes de RMAN para mostrar el estado de la copia de seguridad. Para Oracle, realice una copia de seguridad de la base de datos del catálogo RMAN exportando todos los esquemas del catálogo periódicamente, así como realizando una copia de seguridad de exportación del esquema del catálogo RMAN al final de cada copia de seguridad. Para SQL Server, bases de datos del sistema de respaldo, especialmente master y msdb.
        • Mantenimiento del catálogo de la base de datos: con las bases de datos de Oracle, utilice "eliminar obsoletos" para eliminar las copias de seguridad que están fuera de la política de retención de la organización. Si no se eliminan las copias de seguridad obsoletas, el catálogo seguirá creciendo y el rendimiento se convertirá en un problema. La verificación cruzada (copia de seguridad de verificación cruzada) comprobará que el archivo de catálogo / control coincide con las copias de seguridad físicas.
        • Validación de copias de seguridad: valide y verifique las copias de seguridad sin realizar restauraciones reales.
        • Configuración de dependencias: cuando realice una copia de seguridad en disco, archive estas copias de seguridad en cinta tan pronto como se complete la copia de seguridad en disco.
        Configure un proceso para que las copias de seguridad del disco se transfieran a cinta sin pérdida de tiempo.

        Prueba de restauración de respaldo

        Imagine el siguiente escenario: una inundación ha azotado el área en la que reside la sede de una empresa y toda la infraestructura de TI se ha dañado, pero no se ha destruido. Antes del evento, los administradores de bases de datos realizaron copias de seguridad en los medios de copia de seguridad, siguiendo todos los procesos indicados anteriormente en este artículo, y los almacenaron fuera del sitio. En la auditoría de TI más reciente de la empresa, el auditor calificó el proceso de respaldo como "efectivo".

        Se recuperan y cargan los medios de respaldo del almacenamiento externo. Aparece un mensaje en la pantalla que indica que los medios de respaldo son "ilegibles" debido a problemas de integridad. ¿Lo que podría haber ocurrido?  Pueden haber pasado muchas cosas. Sin embargo, está claro que no se dio un paso crítico. La restauración desde los medios de respaldo nunca se probó realmente. El control se marcó como efectivo porque se había implementado un proceso de respaldo y se estaba realizando. Además, nunca se recibieron errores cuando la empresa realizó una copia de seguridad en los medios de copia de seguridad.

        Las copias de seguridad no sirven de nada si el equipo de TI no puede restaurar los datos en el sistema en el momento en que sea necesario. Un DBA debe formular una estrategia detallada para esta tarea:

        1. Prueba de restauración de bases de datos: debe existir un requisito para probar las restauraciones de la base de datos desde el disco y desde las copias de seguridad en cinta.
        2. Validación de restauraciones siempre que sea posible: el DBA puede validar y verificar las copias de seguridad sin realizar restauraciones reales. La validación de las copias de seguridad mediante el comando "restaurar y validar la base de datos" hará todo, excepto restaurar la base de datos. Este es el mejor método para determinar si la copia de seguridad es buena y utilizable antes de encontrarse en una situación en la que se vuelva crítica.
        3. Actualización de bases de datos que no son de producción a partir de copias de seguridad de producción: es una buena práctica crear periódicamente bases de datos que no son de producción a partir de copias de seguridad de producción utilizando los comandos de la utilidad de copia de seguridad / restauración adecuados como práctica de restauración.
        4. Realización de pruebas de restauración anuales / bianuales desde cinta como parte de la auditoría: el DBA tendrá que explicar el proceso a través de una narrativa, conservar registros y tomar capturas de pantalla para mostrar este tipo de pruebas de restauración.
        5. Restauraciones reales: durante las restauraciones reales, el DBA debe realizar una copia de seguridad de la base de datos antes de realizar la restauración. Según el tipo de pérdida y las copias de seguridad disponibles, el DBA debe decidir si opta por una recuperación completa (en un momento determinado) o incompleta. La recuperación incompleta puede basarse en el tiempo, en la cancelación o en los cambios.
        6. Estrategia para recuperarse de la corrupción de la base de datos: para las bases de datos Oracle, el DBA puede activar la verificación de bloques usando los parámetros apropiados para detectar la presencia de bloques corruptos en la base de datos. Esto tiene una ligera sobrecarga de rendimiento, pero permitirá la detección temprana de bloques corruptos causados ​​por problemas del sistema de entrada / salida (E / S), sistema de almacenamiento o disco subyacente. De forma predeterminada, RMAN también busca bloques corruptos durante la copia de seguridad. En versiones posteriores de Oracle, RMAN se puede utilizar para reparar bloques dañados en la base de datos.

        SLA de respaldo y recuperación

        El equipo de DBA debe redactar un SLA de respaldo y recuperación, que cubra los detalles de los procedimientos de respaldo e incluya un cronograma para la recuperación, y que la administración lo apruebe. El SLA no ayuda en el proceso de recuperación en sí, pero establece las expectativas de la comunidad de usuarios (y de la administración) para el proceso de recuperación, lo que puede proporcionar al equipo más tiempo para completar el proceso de restauración.

        Plan de recuperación en un desastre

        El DBA debe asegurarse de que las bases de datos se incluyan como un elemento clave en el DRP general de la empresa. Todas las partes interesadas deben comprender los elementos del plan de recuperación y en qué orden el equipo de TI restaurará las bases de datos. La empresa debe proporcionar su opinión en esta etapa para que las aplicaciones más críticas para la empresa estén disponibles lo antes posible.

        Herramientas de respaldo y recuperación de bases de datos y sistemas operativos

        Parece obvio, pero los administradores de bases de datos juegan el papel final y más importante en el proceso, ya que deben mantener actualizados sus conocimientos sobre las herramientas de copia de seguridad y recuperación para RDBMS. Durante el evento de restauración real, los administradores de bases de datos no tendrán tiempo para descubrir ningún avance en las herramientas de respaldo y recuperación.

        Conclusión

        La responsabilidad principal del equipo de administración de la base de datos es revisar todos los tipos de RDBMS en la empresa y desarrollar un plan de respaldo integral para llevar a cabo una administración de respaldo efectiva al monitorear de manera proactiva los respaldos, recibir alertas de respaldos fallidos y volver a ejecutarlos sin problemas, sin pérdida de tiempo. Es una buena práctica realizar una copia de seguridad de los datos en un disco físico y luego archivarlos en una cinta para fines de recuperación de desastres.

        Una vez que se ha establecido un enfoque, es imperativo probar la restauración de datos periódicamente como parte de la estrategia de copia de seguridad y restauración, y revisar todas las opciones antes de ejecutar la restauración / recuperación real. Es importante confirmar que el equipo de DBA está al día con las últimas herramientas de respaldo y recuperación y asegurarse de que el equipo tenga un proceso claramente documentado con responsabilidades claras. Si los administradores de bases de datos mantienen copias de seguridad adecuadas, las supervisan de forma proactiva y pueden garantizar la recuperación de los datos hasta el punto requerido por la empresa, han realizado una gran parte del trabajo para el que fueron contratados.

        Los auditores de TI pueden ayudar a los equipos de administración de datos a fortalecer sus controles y procesos de recuperación de datos validando las operaciones del DBA, incluida la prueba de la recuperación de datos. Este esfuerzo continuo, proactivo y cooperativo entre la auditoría interna y el equipo de DBA puede proporcionar seguridad a la gerencia de que, en caso de un desastre, los datos de la empresa se pueden recuperar.

        28 noviembre 2020

        Copias de seguridad gestionadas por el usuario en Oracle

         

        Empezaremos esta entrada en el blog, con la ortodoxia de una definición canónica de copia de seguridad (backup).

        Definición: La copia de seguridad es una copia real y coherente de los datos de la base de datos que podría usarse para reconstruir los datos después de un incidente.

        Hay dos tipos de respaldo
        • Copia de seguridad física
        • Copia de seguridad lógica


        Copia de seguridad física (Physical Backup)

        Copia de todos los archivos de datos físicos necesarios para realizar la restauración y recuperación de la base de datos,
        Este tipo de copia de seguridad incluye una copia de los archivos siguientes
        • Archivos de información
        • Controlar archivos
        • Archivos de parámetros
        • Archivos de registro archivados
        Las diferentes opciones para realizar copias de seguridad físicas son
        • Técnicas gestionadas por el usuario
        • RMAN (Recovery Manager)

        Copia de seguridad lógica (Logical Backup)

        Oracle utiliza la bomba de datos de Oracle para permitirnos generar una copia de seguridad lógica que se puede utilizar para migrar datos, incluso hacer una recuperación parcial o total de la base de datos.
        • exp / expdp
        • imp / impdp

        Diferencia entre restauración y recuperación

        Restaurar: acto que implica la restauración de todos los archivos que serán necesarios para recuperar su base de datos a un estado consistente. por ejemplo, copiando todos los archivos de respaldo desde una ubicación de respaldo como TAPE o DISK

        Recuperar: es un proceso para aplicar todos los registradores de transacciones en el registro de archivo, avanzando su base de datos hasta un punto en el tiempo.

        Copias de seguridad gestionadas por el usuario

        Backpup en Frio

        Esta es la única forma posible para que el DBA realice una copia de seguridad coherente de la base de datos independientemente del modo de la base de datos (archivelog o noarchivelog). A continuación se explican los pasos:
        • Si la base de datos se está ejecutando, bájela completamente en un modo consistente (usando el apagado (solo NORMAL / INMEDIATO / TRANSACCIONAL). Esto asegurará que el encabezado de todos los archivos de la base de datos se actualice al mismo SCN
        • Copia de seguridad de todos los archivos de datos, archivos de control, archivos de parámetros mediante el comando de copia del sistema operativo
        • Iniciar la base de datos
        • Archive todos los registros de rehacer no archivados utilizando el siguiente comando y cópielos en la ubicación de la copia de seguridad.
        alter tablespace SIGE_TBS offline normal;

        Copia de seguridad de datos sin conexión (Offline)

        Suponga que desea realizar una copia de seguridad sin conexión de uno o más espacios de tabla, el método de copia de seguridad sin conexión le ayudará a lograr lo mismo, tenga en cuenta que el espacio de tabla SYSTEM y el espacio de tabla UNDO con deshacer activo no se pueden desconectar.
        suponga que el espacio de tabla es SIGE_TBS:

        • Identifique todos los archivos de datos asociados con el espacio de tabla mediante la vista dba_data_files

        select tablespace_name,file_name from dba-data_files from dba_data_files where tablespace_name='SIGE_TBS';

        • Ponga el espacio de tabla fuera de línea usando la prioridad normal (no use temporal e inmediato, requerirá recuperación en el momento de poner el espacio de tabla en línea)

        alter tablespace SIGE_TBS offline normal;

        • Haga una copia de seguridad de todos los archivos de datos relacionados con el espacio de tabla mediante el comando de copia del sistema operativo.
        • Ponga el tablespace en línea.

        alter tablespace SIGE_TBS online;

        Archive todos los registros de rehacer no archivados y copie el registro archivado en la ubicación de la copia de seguridad.

        alter system archive log current;

        Backups en caliente

        Esto se ha introducido en la versión 6 de Oracle, pero inicialmente estaba vinculado solo al espacio de tabla, a partir de la versión 10 también incluían toda la base de datos. Esto nos permite realizar copias de seguridad en caliente de la base de datos o el espacio de tabla sin necesidad de cerrar la base de datos.
        Al realizar una copia de seguridad en caliente, Oracle deja de registrar puntos de control en todos los archivos de datos asociados.
        A continuación se muestran dos cosas que suceden internamente mientras la base de datos se pone en modo BEGIN BACKUP:

        • Se establece una bandera de respaldo activo en el encabezado del archivo de datos
        • Se produce un punto de control, parpadeo de todos los bloques sucios de la memoria al disco, sincronizando todos los encabezados de los archivos de datos al mismo SCN y congelando los encabezados para lograr coherencia, protección y capacidad de recuperación.
        Se pueden realizar copias de seguridad en caliente en toda la base de datos, el espacio de tabla o incluso a nivel de contenedor, esto requiere un proceso de recuperación después de que se restaure la copia de seguridad, por lo que siempre realice una copia de seguridad de todos los archivos de registro archivados necesarios.

        Copia de seguridad en caliente de toda la base de datos
        Para realizar este tipo de copia de seguridad, debemos poner nuestra base de datos en modo de copia de seguridad usando 'alter database begin backup;'
        Este es el tipo más común de copia de seguridad administrada por el usuario que utiliza DBA en todo el mundo.
        A continuación se muestran los pasos:
        • Coloque la base de datos en modo de respaldo.
        alter database begin backup;
        • Haga una copia de seguridad de todos los archivos de datos y archivos de parámetros utilizando el comando de copia del sistema operativo-
        • Saque la base de datos del modo de respaldo.
        alter database end backup;
        • Archivar todos los registros no archivados y copiarlos como respaldo.
        • Crear copia del archivo de control como seguimiento.
        alter system archivelog current;
        • modifique el archivo de control de copia de seguridad de la base de datos a '/control_file.trc;
        alter system archive log current;


        Copia de seguridad en caliente de la base de datos de contenedores
        Como se introdujo en Oracle 12c, puede realizar una copia de seguridad administrada por el usuario de toda la base de datos del contenedor o del único PDB raíz o individual.

        Base de datos de contenedores completa:

        A continuación se muestran los pasos mencionados:
        • Inicie sesión en la base de datos utilizando un usuario que tenga privilegios de sysdba o sysbackup.
        sqlplus /nolog

        connect system@container1

        • Coloque su base de datos en modo de respaldo.ç
        alter database begin backup;
        • Modificar la base de datos comenzar la copia de seguridad;
        select file_name from dba_data_files;
        • Identifique todas las bases de datos relacionadas con la base de datos del contenedor usando el siguiente comando.
        select file_name from dba_data_files;
        • Copie toda la base de datos usando el comando de copia del sistema operativo.
        • Saque la base de datos del modo de respaldo.
        alter database end backup;
        • Archivar todos los registros no archivados y copiarlos como respaldo.
        alter system archivelog current;
        • Crear copia del archivo de control como seguimiento.
        alter database backup controlfile to '/control_file.trc;

        ROOT solo o PDB individual

        A continuación se muestran los sencillos pasos para completar la copia de seguridad en caliente de root contenedor o base de datos conectable individual.

        • Conectar a la raíz o base de datos conectable individuo con usuario tenga privilegios SYSDBA o sysbackup.
        sqlplus /nolog
        connect system

        alter session set container= tech_pdb;

        • Identifique todos los archivos de datos que forman parte de PDB usando la vista dba_data_files.

        select file_name from dba_data_files;
        • Coloque la base de datos conectable en modo de respaldo.
        alter pluggable database tech_pdb begin backup;
        • Copie todos los archivos de datos usando el comando de copia del SO.
        • Saque la PDB del modo de inicio de copia de seguridad.
        alter pluggable database tech_pbd end backup;
        • Archivar todos los registros no archivados y copiarlos como respaldo
        alter system archivelog current;
        • Crear una copia del archivo de control como seguimiento

        alter database backup controlfile to '/control_file.trc;

        Controlar la copia de seguridad de archivos
        Hay dos formas de recuperar el control
        • Copia de seguridad binaria
        • Copia de seguridad de archivos de texto
        Tener una copia de seguridad válida del archivo de control de una base de datos es crucial para la recuperación exitosa de la base de datos.

        Copia de seguridad binaria
        Se puede realizar una copia binaria del archivo de control mediante una declaración SQL. Esta copia contiene información adicional, como el historial de registro de rehacer archivado, rango fuera de línea para espacios de tabla de solo lectura y fuera de línea, entradas de archivos temporales y conjuntos de respaldo de RMAN y copias de datos.
        comando para tomar una copia de seguridad binaria.

        alter database backup controlfile to '';

        Copia de seguridad de archivos de texto
        Este tipo de copia de seguridad contiene una instrucción create controlfile basada en el archivo de control actual en uso. Este tipo de copia de seguridad se puede realizar mientras la base de datos está en modo de montaje o abierto. Esto se genera como archivo de seguimiento y se puede modificar fácilmente.
        A continuación se muestran algunas declaraciones utilizadas para crear una copia de seguridad basada en texto del archivo de control.

        1. alter database backup controlfile to trace;
        2. alter database backup controlfile to trace resetlogs;
        3. alter database backup controlfile to trace noresetlogs;
        4. alter database backup controlfile to trace as '';
        5. alter database backup controlfile to trace as '' reuse;
        6. alter database backup controlfile to trace as '' resetlogs;
        7. alter database backup controlfile to trace as '' noresetlogs;