Mostrando entradas con la etiqueta Recuperación. Mostrar todas las entradas
Mostrando entradas con la etiqueta Recuperación. Mostrar todas las entradas

23 febrero 2021

Conceptos básicos de Data Guard de Oracle 12c

 

Data Guard es la verdadera tecnología de protección contra desastres de Oracle 12c. En él, tiene un mínimo de dos bases de datos, principal y en espera. Data Guard tiene opciones para múltiples sitios en espera, así como una configuración activo-activo.

Por activo-activo, significa que ambos / todos los sitios están en funcionamiento, en funcionamiento y accesibles. Esto se opone a los sitios que tienen una ubicación activa y las otras deben iniciarse cuando se necesitan. Este es un ejemplo del diseño arquitectónico general.


Arquitectura de Data Guard y Oracle 12c

Comenzar una descripción con la base de datos primaria es fácil porque se diferencia muy poco de cualquier otra base de datos que pueda tener. La única diferencia es lo que hace con sus registros de rehacer archivados.

La base de datos principal escribe un conjunto de registros de rehacer archivos en un área de recuperación de Flash o en un disco local. Sin embargo, puede configurar uno o más destinos en un entorno de Data Guard.

El parámetro LOG_ARCHIVE_DEST_n puede tener este aspecto para la configuración anterior:

LOG_ARCHIVE_DEST_10 = 'UBICACIÓN = USE_DB_RECOVERY_FILE_DEST'

LOG_ARCHIVE_DEST_1 = 'SERVICIO = PHYSDBY1 ARCH'

LOG_ARCHIVE_DEST_2 = 'SERVICIO = LOGSDBY1 LGWR'

 

·         LOG_ARCHIVE_DEST_10 está configurado para enviar registros de rehacer archivos al Área de recuperación de Flash local. Se requiere un destino local para todas las bases de datos en modo de registro de archivo.

·         LOG_ARCHIVE_DEST_1 está configurado para enviar los registros de archivo a través del proceso de archivado a un sitio remoto PHYSDBY1. El nombre del servicio para este sitio remoto tiene una entrada en el archivo tnsnames.ora en el servidor primario.

·         LOG_ARCHIVE_DEST_2 está configurado para enviar los registros de archivo a través del proceso LGWR a un sitio remoto llamado LOGSDBY1. El nombre del servicio para este sitio remoto también tiene una entrada en el archivo tnsnames.ora en el servidor primario.

 

¿Por qué la diferencia entre los métodos de envío ARCn y LGWR? Eso tiene algo que ver con los modos de protección. Un entorno de Data Guard tiene tres modos de protección.

Disponibilidad máxima

El modo de protección de máxima disponibilidad se compromete entre el rendimiento y la disponibilidad de datos. Funciona mediante el uso de LGWR para escribir simultáneamente para rehacer registros en los sitios principal y en espera. La degradación del rendimiento viene en forma de procesos que tienen que esperar a que las entradas del registro de rehacer se escriban en varias ubicaciones.

Las sesiones que emiten confirmaciones deben esperar hasta que se haya registrado toda la información necesaria en al menos un registro de rehacer de la base de datos en espera. Si una sesión se bloquea debido a su incapacidad para escribir información de rehacer, el resto de la base de datos sigue avanzando.

Protección máxima

El modo de protección máxima es similar a la disponibilidad máxima, excepto que si una sesión no puede verificar que rehacer está escrito en el sitio remoto, la base de datos principal se apaga.

Consejo:  Configure al menos dos sitios en espera para el modo de máxima protección. De esa manera, un sitio en espera que deje de estar disponible no interrumpirá el servicio para toda la aplicación.

 

Este modo verifica que no se producirá ninguna pérdida de datos en caso de desastre a costa del rendimiento.

Rendimiento máximo

El modo de protección de máximo rendimiento separa el proceso de trasvase de registros de la base de datos principal pasándolo al proceso de registro de archivo (ARCn). Al hacer esto, todas las operaciones en el sitio principal pueden continuar sin esperar a que se escriban las entradas de rehacer para rehacer los registros o rehacer el envío.

 

Esto se opone a los modos de trasvase de registros que utilizan el escritor de registros para transferir transacciones. El uso del escritor de registros puede ralentizar el procesamiento de la transacción porque puede verse afectado por la disponibilidad o el rendimiento de la red.

El rendimiento máximo proporciona el nivel más alto de rendimiento en el sitio principal a expensas de la divergencia de datos. La divergencia de datos se produce cuando los datos de los dos sitios comienzan a de sincronizarse. Los datos de rehacer del archivo no se envían hasta que se llena todo el registro de rehacer del archivo. En el peor de los casos, la pérdida de un sitio completo podría resultar en la pérdida de todos los datos de un registro de rehacer de archivo (archive redo log).

 

Realización de operaciones de conmutación y conmutación por error

Puede cambiar el procesamiento a su sitio en espera de dos maneras:

·         La conmutación (switchover) es un cambio planificado que puede ocurrir si desea realizar mantenimiento en el sitio principal que requiere que no esté disponible. Esta operación puede requerir unos minutos de inactividad en la aplicación, pero si tiene que realizar un mantenimiento que dure una hora o más, el tiempo de inactividad podría valer la pena. Esta operación se denomina cambio elegante porque convierte el sitio principal en su sitio en espera y su sitio en espera en el principal. Además, puede volver fácilmente al sitio principal original sin tener que volver a crearlo desde cero.

·         La conmutación por error (failover) ocurre cuando el sitio principal se ha visto comprometido de alguna manera. Quizás fue una pérdida total del sitio, o quizás descubrió daños físicos en un archivo de datos. No siempre, pero por lo general después de una conmutación por error, debe volver a crear completamente el sitio principal o recuperarlo de una copia de seguridad y reinstalarlo. Por lo general, realiza una conmutación por error solo cuando ha determinado que reparar el sitio principal llevará el tiempo suficiente para que prefiera no tener una interrupción de la aplicación durante todo el tiempo.

Para realizar un cambio, siga estos pasos:

1.        En el primario actual, inicie sesión en SQL * Plus y escriba lo siguiente:

<alter database commit to switchover to physical standby;>

 Deberías ver esto:

< Base de datos alterada >

.

2.       Apague la base de datos primaria:

 <shutdown immediate>

Deberías ver esto::

Database closed.
Database dismounted.
ORACLE instance shut down.

3.       Inicie la base de datos primaria en modo nomount:

  <startup nomount>

Debería ver algo como esto:

ORACLE instance started.

Total System Global Area 789172224 bytes

Fixed Size         2148552 bytes

Variable Size       578815800 bytes

Database Buffers     201326592 bytes

Redo Buffers        6881280 bytes

4.       Monte la base de datos en espera:

<alter database mount standby database;>

Deberías ver esto:

Database altered.

5.       Iniciar la recuperación:

<recover managed standby database disconnect;>

Ves esto:

Media recovery complete.

6.       Inicie sesión en SQL * Plus en el modo de espera actual y escriba lo siguiente:

<alter database commit to switchover to physical primary;>

Deberías ver esto:

Database altered.

7.       Apague la base de datos en espera:

 <shutdown immediate>

Deberías ver esto:

Database closed.

Database dismounted.

ORACLE instance shut down.

8. Asegúrese de que todos los parámetros de inicialización apropiados estén configurados para que esta base de datos se comporte correctamente como primaria.

9.       Empiece normalmente:

<startup>

Debería ver algo como esto:

ORACLE instance started.

Total System Global Area 789172224 bytes

Fixed Size         2148552 bytes

Variable Size       578815800 bytes

Database Buffers     201326592 bytes

Redo Buffers        6881280 bytes

Database mounted.

Database opened.


Asegúrese de que los usuarios y las aplicaciones puedan conectarse y utilizar la nueva instancia principal.



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.