Compartir a través de

  • Artículo

Planear la recuperación de un desastre

Al administrar una base de datos de SQL Server, es importante estar preparado para la recuperación de desastres potenciales. Es necesario un plan de copias de seguridad y restauración correctamente diseñado y probado para poder recuperar las copias de seguridad de SQL Server de las bases de datos después de un desastre. Para obtener más información, vea Introducción a estrategias de copias de seguridad y restauración en SQL Server. Además, para garantizar que todos los sistemas y datos puedan recuperar rápidamente su funcionamiento normal en caso de un desastre natural, es necesario crear un plan de recuperación de desastres. Durante la elaboración de este plan es preciso tener en cuenta los escenarios de distintos tipos de desastres que pueden afectar a su negocio, incluidos los desastres naturales, como un incendio, y los desastres técnicos, como los errores en dos discos de una matriz RAID-5. Cuando cree un plan de recuperación de desastres, identifique y prepare todos los pasos necesarios para hacer frente a cada tipo de desastre. Debe realizar la comprobación práctica de los pasos de recuperación de cada escenario. Se recomienda que compruebe el plan de recuperación de desastres mediante la simulación de un desastre natural.

Durante el diseño del plan de copias de seguridad y restauración, es necesario realizar el diseño del plan de recuperación de desastres según el entorno y las necesidades del negocio. Por ejemplo, supongamos que se produce un incendio y destruye el centro de datos disponibles 24 horas al día. ¿Está seguro de que es posible la recuperación? ¿Cuánto tiempo se puede tardar en llevar a cabo la recuperación y tener disponible el sistema? ¿Cuál es la cantidad de datos perdidos que pueden tolerar los usuarios?

Lo ideal es que el plan de recuperación de desastres indique el tiempo que durará la recuperación y el estado final de las bases de datos que los usuarios pueden esperar. Por ejemplo, puede determinar que, tras la adquisición del hardware especificado, la recuperación debe completarse en 48 horas y sólo se garantizarán los datos hasta finales de la semana previa al incidente.

Un plan de recuperación de desastres se puede estructurar de diferentes maneras y puede contener muchos tipos de información. Entre los tipos de planes de recuperación de desastres se incluyen los siguientes:

  • Un plan para adquirir el hardware.

  • Un plan de comunicación.

  • Una lista de las personas con las que ponerse en contacto si se produce un desastre.

  • Instrucciones para ponerse en contacto con las personas implicadas en la respuesta al desastre.

  • Información acerca del propietario de la administración del plan.

  • Una lista de comprobación de las tareas necesarias para cada escenario de recuperación. Para facilitar la revisión de la evolución de la recuperación de desastres, ponga a cada tarea una inicial a medida que se vayan completando y anote la hora de finalización en la lista de comprobación.

Modelos de recuperación de SQL Server

SQL Server proporciona tres modelos de recuperación alternativos: simple, completa y para cargas masivas de registros. Un modelo de recuperación es una propiedad de la base de datos que controla el comportamiento básico de las operaciones de copias de seguridad y restauración de una base de datos. La elección del modelo de recuperación óptimo para cada base de datos es esencial a la hora de planear la estrategia de copias de seguridad y restauración. El modelo de recuperación que elija para una base de datos depende hasta cierto punto de sus requisitos de disponibilidad y recuperación. A su vez, la elección del modelo de recuperación afecta a las posibilidades de recuperación de desastres de una base de datos.

Para ver información general acerca de los modelos de recuperación, vea Introducción al modelo de recuperación.

Administrar medios de copia de seguridad

Se recomienda que el plan de copias de seguridad estipule cómo se han de administrar los medios de copia de seguridad, por ejemplo:

  • Un plan de seguimiento y administración para almacenar y reciclar conjuntos de copias de seguridad.

  • Una programación para sobrescribir el medio de copia de seguridad.

  • En un entorno multiservidor, la decisión de utilizar copias de seguridad centralizadas o distribuidas.

  • Un modo de realizar un seguimiento de la vida útil del medio.

  • Un procedimiento para minimizar los efectos de la pérdida de un conjunto o medio de copia de seguridad, por ejemplo, la pérdida de una cinta.

  • La decisión de guardar los conjuntos de copia de seguridad dentro o fuera del sitio, y un análisis de cómo afectaría esta decisión al tiempo de recuperación.

Para obtener información acerca de cómo SQL Server utiliza los dispositivos y medios de copia de seguridad, vea Trabajar con medios de copia de seguridad en SQL Server.

Ejecutar un script con la funcionalidad básica

Normalmente, los scripts con la funcionalidad básica se incluyen en los planes de recuperación de desastres para confirmar que todo funciona como se espera. Un script con la funcionalidad básica proporciona una herramienta confiable para que los administradores de sistemas o de bases de datos puedan comprobar que se ha recuperado la base de datos con un estado viable, sin tener que depender de los usuarios finales para llevar a cabo la comprobación.

Un script con la funcionalidad básica es específica de la aplicación y puede adoptar muchas formas diferentes. Por ejemplo, en un sistema de informes o ayuda a la toma de decisiones, el script puede ser simplemente una copia de varias de las consultas para informes más importantes. Para una aplicación de procesamiento de transacciones en línea (OLTP), el script puede ejecutar un lote de procedimientos almacenados que contengan instrucciones INSERT, UPDATE y DELETE. Por ejemplo, un script con la funcionalidad básica puede ser tan simple como un archivo .sql que envía instrucciones SQL por lotes al servidor desde la utilidad sqlcmd. Otro ejemplo es usar un archivo .bat que contenga los comandos bcp y sqlcmd.

Garantizar la disposición para afrontar desastres

Para asegurarse de que está preparado para hacer frente a desastres, se recomienda que realice las siguientes tareas de forma periódica:

  • Compruebe los procedimientos de copia de seguridad y recuperación antes de que se produzca un error real. Las comprobaciones le ayudan a asegurarse de que cuenta con las copias de seguridad necesarias para recuperarse de diversos errores, que sus procedimientos están perfectamente definidos y documentados y que cualquier operario cualificado puede ejecutarlos rápidamente y sin problemas.

  • Para que la cantidad de datos perdidos sea mínima, realice periódicamente copias de seguridad de las bases de datos y los registros de transacciones. Se recomienda realizar copias de seguridad del sistema y de las bases de datos de los usuarios.

  • Mantenga los registros del sistema de manera segura. Conserve registros de todos los Service Pack instalados en Microsoft Windows y SQL Server. Conserve registros de las bibliotecas de red usadas y del modo de seguridad. Asimismo, si SQL Server se ejecuta en autenticación de modo mixto (modo de autenticación de SQL Server y de Windows), guarde la contraseña de sa en un lugar seguro. Para obtener más información, consulte Seguridad y protección (motor de base de datos).

    Nota importanteImportante

    La autenticación de Windows es mucho más segura que la de SQL Server. Siempre que sea posible, utilice la autenticación de Windows.

  • En otro servidor, evalúe por anticipado los pasos que debe seguir para la recuperación de un desastre, modifíquelos según sea necesario para ajustarlos a su entorno de servidor local y compruebe los pasos modificados.

  • Conserve un script con la funcionalidad básica a fin de evaluar rápidamente la capacidad mínima.

Revisar y reducir los posibles errores desastrosos del usuario

Uno de los escenarios de recuperación más difíciles es recuperarse de un error de usuario importante, como quitar objetos de la base de datos de forma accidental. En esta sección se enumeran herramientas que le pueden ayudar a revisar y en algunos casos a regular los cambios efectuados a las bases de datos.

  • Desencadenadores del lenguaje de definición de datos (DDL)

    Estos desencadenadores se pueden crear para revisar y regular algunos cambios del esquema de base de datos. Los desencadenadores DDL activan procedimientos almacenados en respuesta a una variedad de instrucciones DDL. Estas instrucciones son básicamente las que empiezan por CREATE, ALTER y DROP. El ámbito de un desencadenador DDL puede ser una base de datos determinada o una instancia de servidor completa. Para obtener más información, vea Descripción de los desencadenadores DDL.

  • Notificaciones de eventos

    Las notificaciones de eventos se ejecutan en respuesta a una variedad de instrucciones DDL de Transact-SQL y eventos de la traza de SQL, y envían información acerca de esos eventos a un servicio de Service Broker.

    Se pueden programar notificaciones de eventos para muchos de los eventos capturados por Traza de SQL, Pero, en lugar de usarlas para crear trazas, puede usar dichas notificaciones para realizar una acción en una instancia de SQL Server como respuesta a eventos. Dado que las notificaciones de eventos se ejecutan de forma asincrónica, estas acciones no consumen recursos definidos por la transacción inmediata. Para obtener más información, vea Notificaciones de eventos (motor de base de datos).

    [!NOTA]

    No todos los eventos DDL se pueden utilizar en desencadenadores DDL. Algunos eventos están diseñados únicamente para instrucciones asincrónicas, no transaccionales. Por ejemplo, en un desencadenador DDL no se puede utilizar un evento CREATE DATABASE. Para estos eventos debe utilizar notificaciones de eventos.

  • Agente SQL Server

    Se trata de un servicio de Windows que ejecuta tareas administrativas programadas, denominadas trabajos. El Agente SQL Server utiliza SQL Server para almacenar información de los trabajos. Entre otras cosas, el Agente SQL Server puede ejecutar un trabajo en respuesta a un evento concreto; por ejemplo, errores que tienen un nivel de gravedad o un número de mensaje específicos.

    Para obtener una introducción al Agente SQL Server, vea Automatizar las tareas administrativas (Agente SQL Server). Para obtener información acerca cómo usar el Agente SQL Server para eventos, vea Supervisar y responder a eventos.

  • Traza de SQL

    La traza de SQL proporciona procedimientos almacenados del sistema Transact-SQL para crear trazas sobre clases de eventos seleccionadas por el usuario en una instancia de SQL Server Database Engine (Motor de base de datos de SQL Server). Puede utilizar estos procedimientos almacenados del sistema desde sus propias aplicaciones para crear trazas manualmente. Para obtener más información, vea Introducción a Traza de SQL.

    [!NOTA]

    El Analizador de SQL Server es una interfaz gráfica de usuario de la traza de SQL que se usa para supervisar una instancia de Database Engine (Motor de base de datos) o Analysis Services. Para obtener más información, vea Usar el Analizador de SQL Server.