Descripción de las opciones de recuperación ante desastres para Microsoft SQL Server

Resumen

Este artículo describe varias soluciones para recuperar datos de una base de datos de Microsoft SQL Server, si se produce un desastre. En este artículo también se describe las ventajas y las desventajas de cada solución.

Recuperación ante desastres es un proceso que puede utilizar para recuperar datos y sistemas de información si se produce un desastre.

Algunos ejemplos de desastres incluyen un natural o un desastre provocados por el hombre, como un incendio o un desastre técnico como una falla en dos discos en una matriz redundante matriz de independiente discos (RAID) 5.

Planificación de recuperación ante desastres es el trabajo que se dedica a la preparación de todas las acciones que deben ocurrir en respuesta a un desastre. La planificación incluye la selección de una estrategia para ayudar a recuperar datos valiosos. La selección de la estrategia de recuperación ante desastres apropiada depende de los requerimientos del negocio.

Nota: Las soluciones que se describen en este artículo sólo proporcionan descripciones generales de las tecnologías que puede utilizar. Estas descripciones generales son para comparar los distintos métodos de recuperación de desastres y los planes de recuperación ante desastres. Antes de decidir en qué desastres solución de recuperación es mejor para usted, asegúrese de que mira cada una de las soluciones de recuperación ante desastres sugerido más detalladamente. Después de tratar cada solución de recuperación ante desastres, este artículo contiene vínculos donde puede encontrar información adicional acerca de esa solución.

Organización por clústeres de conmutación por error

Organización por clústeres de conmutación por error de Microsoft SQL Server 2000 está diseñado para conmutación por error automáticamente si se produce un error de hardware o software. Puede utilizar SQL Server 2000 conmutación por error para crear un clúster de conmutación por error para una sola instancia de SQL Server 2000 o para varias instancias de SQL Server 2000. Organización por clústeres de conmutación por error permite que un sistema de base de datos cambiar automáticamente el procesamiento de una instancia de SQL Server desde un servidor que ha fallado a un servidor de trabajo. Por lo tanto, la organización por clústeres de conmutación por error es útil si se produce un error de sistema operativo o si realiza una actualización planificada de los recursos del sistema de base de datos. Además, la organización por clústeres de conmutación por error aumenta la disponibilidad de servidor sin downtime.

Como organización por clústeres de conmutación por error está diseñado para una disponibilidad elevada en el servidor prácticamente sin downtime del servidor, los nodos del clúster deben ser geográficamente cerca uno del otro. Organización por clústeres de conmutación por error no puede ser útil si se produce un error de matriz de disco.

Nota: Para implementar clústeres de conmutación por error, debe instalar Microsoft SQL Server 2000 Enterprise Edition.

Los siguientes sistemas operativos admiten clústeres de conmutación por error:
  • Microsoft Windows NT 4.0, Enterprise Edition
  • Microsoft Windows 2000 Advanced Server
  • Microsoft Windows 2000 Datacenter Server
  • Microsoft Windows Server 2003, Enterprise Edition
  • Microsoft Windows Server 2003, Datacenter Edition
Estos sistemas operativos incluyen un componente instalable, Microsoft Cluster Service (MSCS). Para implementar la conmutación por error de SQL Server, debe instalar MSCS.

Para obtener más información acerca de MSCS y su instalación, haga clic en el número de artículo siguiente para verlo en Microsoft Knowledge Base:

Recursos de instalación de Microsoft Cluster Service 259267

Ventajas y desventajas del uso de clústeres de conmutación por error

Ventaja
Tener disponibilidad elevada en el servidor. Se produce conmutación por error automáticamente si se produce un error en el servidor principal.
Desventajas
  • Incurrir en un gasto mayor. El mantenimiento de dos servidores es dos veces el costo de mantener un único servidor. Porque tiene que mantener dos servidores al mismo tiempo, resulta más caro de instalar y mantener los nodos del clúster.
  • Servidores deben estar en la misma ubicación. Si las ramas de la organización en todo el mundo y los clústeres activo/activo deben implementarse en las ramas, las redes y la infraestructura de almacenamiento de información que tiene que utilizar es muy diferente de un clúster de servidores de dispositivo de quórum estándar. Por lo tanto, aunque es posible, es mejor no utilizar servidores geográficamente distantes.
  • No tiene protección contra un error de matriz de disco.
  • Organización por clústeres de conmutación por error no permiten crear clústeres de conmutación por error en el nivel de base de datos o en el nivel de objeto de base de datos, como el nivel de tabla.
Para obtener más información acerca de los clústeres de conmutación por error, visite el siguiente sitio Web de Microsoft:Para obtener más información acerca de los clústeres de conmutación por error, haga clic en los números de artículo siguientes para verlos en Microsoft Knowledge Base:

243218 orden de instalación de SQL Server 2000 Enterprise Edition en Microsoft Cluster Server

822250 support WebCast: procedimientos de recuperación ante desastres de clústeres de conmutación por error de Microsoft SQL Server 2000

Para obtener más información acerca de la directiva de soporte técnico de Microsoft para un clúster de conmutación por error de SQL Server, haga clic en el número de artículo siguiente para verlo en Microsoft Knowledge Base:

327518 directiva de soporte técnico de Microsoft para un clúster de conmutación por error de SQL Server

La creación de reflejo de base de datos

El reflejo de base de datos es una solución de software principalmente para incrementar la disponibilidad de la base de datos. Sólo puede implementar la creación de reflejos de bases de datos. Reflejo sólo funciona con bases de datos que utilizan el modelo de recuperación completa. Los modelos de recuperación simple o de registro masivo no admiten la creación de reflejo de base de datos. Por lo tanto, todas las operaciones masivas se registran siempre completamente. La creación de reflejo de base de datos funciona con cualquier nivel de compatibilidad de base de datos compatible.

Ventajas y desventajas del uso de la creación de reflejo de base de datos

Ventajas
  • La creación de reflejo de base de datos aumenta la protección de datos.
  • La creación de reflejo de base de datos aumenta la disponibilidad de una base de datos.
  • La creación de reflejo de base de datos mejora la disponibilidad de la base de datos de producción durante las actualizaciones.
Desventajas
  • La base de datos reflejada debe ser idéntica a la base de datos principal. Por ejemplo, todos los objetos, inicios de sesión y permisos deben ser idénticos.
  • La creación de reflejo de base de datos implica a la transferencia de información de un equipo a otro equipo a través de una red. Por lo tanto, la seguridad de la información que se transfiere de SQL Server es muy importante.

Replicación transaccional punto a punto

Replicación transaccional punto a punto está diseñada para aplicaciones que pueden leer o pueden modificar los datos de cualquier base de datos que participa en la replicación. Además, si todos los servidores que alojan las bases de datos están disponibles, puede modificar la aplicación para enrutar el tráfico a los servidores restantes. Los servidores restantes contienen copias idénticas de los datos.

Ventajas y desventajas del uso de la replicación transaccional punto a punto

Ventajas
  • Se ha mejorado el rendimiento de lectura porque se puede propagar la actividad en todos los nodos.
  • Agregar el rendimiento de la actualización, inserte el rendimiento y eliminar rendimiento para la topología similar el rendimiento de un solo nodo porque todos los cambios se propagan a todos los nodos.
Desventajas
  • Replicación punto a punto sólo está disponible en SQL Server 2005 Enterprise Edition.
  • Todos los participantes bases de datos deben contener datos y esquemas idénticos.
  • Recomendamos que cada nodo utilice su propia base de datos de distribución. Esta configuración elimina la posibilidad de SQL Server 2005 para tener un punto único de falla.
  • No puede incluir tablas y otros objetos en varias publicaciones peer-to-peer dentro de la base de datos de una sola publicación.
  • Debe tener una publicación habilitada para replicación peer-to-peer antes de crear las suscripciones.
  • Debe inicializar las suscripciones mediante una copia de seguridad o por el valor del tipo de sincronización de suscripción para replicación sólo son compatibles con.
  • Replicación transaccional punto a punto no proporciona detección de conflictos o resolución de conflictos.
  • Se recomienda que no utilice columnas de identidad.

Mantenimiento de un servidor de reserva activo

Puede crear y mantener un servidor de reserva activo utilizando cualquiera de los métodos siguientes:
  • Trasvase de registros
  • Duplicación transaccional
Para obtener más información acerca de cada uno de estos dos métodos sigue.

Trasvase de registros

El trasvase de registros se incluye en el kit de recursos de Microsoft SQL Server 7.0, y está totalmente incorporada en Microsoft SQL Server 2000 Enterprise Edition y en Microsoft SQL Server 2000 Developer Edition. El trasvase de registros utiliza un servidor de reserva que no se utiliza durante las operaciones normales. Un servidor de reserva es útil para recuperar datos si se produce un desastre. Sólo puede utilizar el trasvase de registros en el nivel de base de datos. No puede utilizarlo en el nivel de instancia.

Cuando un servidor de reserva es restaurar registros de transacciones, la base de datos está en modo exclusivo y es inutilizable. Sin embargo, puede ejecutar informes de trabajos entre restauraciones de registro de transacciones del lote o los comandos de consola de base de datos (DBCC) comprueba continuamente la integridad del servidor de reserva. Para aplicaciones como servidores de apoyo de decisión que requieren procesamiento continuo en un servidor de base de datos, trasvase de registros no es una opción adecuada.

La latencia del servidor de reserva se basa en la frecuencia se toman las copias de seguridad del registro de transacciones en el servidor principal y, a continuación, se aplica en el servidor de reserva. Si el servidor principal falla, puede perder los cambios realizados por las transacciones que se produjeron después de su registro de transacciones más reciente copia de seguridad.

Por ejemplo, si las copias de seguridad del registro de transacciones se realizan cada 10 minutos, las transacciones durante la más reciente 10 minutos se pueden perder. Esto no significa necesariamente que se perderán las actualizaciones de datos que se realizan en el servidor principal durante el período de latencia. Normalmente, las nuevas actualizaciones en el registro de transacciones principal pueden recuperarse y aplicadas en el servidor de reserva activo con sólo un pequeño retraso en la conmutación del servidor principal al servidor de reserva. El propósito principal de trasvase de registros es mantener un servidor de reserva activo. Si mantiene que un servidor de reserva activo es su principal objetivo, el trasvase de registros es probable que sea más apropiado que las otras soluciones que se describe en este artículo.

Ventajas y desventajas de utilizar el trasvase de registros

Ventajas
  • Puede recuperar todas las actividades de la base de datos. La recuperación incluye los objetos que se crearon como tablas y vistas. También incluye cambios de seguridad como los usuarios nuevos que se crearon y los cambios de permiso.
  • Puede restaurar la base de datos con mayor rapidez. La restauración de la base de datos y el registro de transacciones se basa en formatos de página de bajo nivel. Por lo tanto, el trasvase de registros se acelera el proceso de restauración y da como resultado la recuperación rápida de datos.
Desventajas
  • La base de datos está inutilizable durante el proceso de restauración porque la base de datos está en modo exclusivo en el servidor de reserva.
  • Hay una falta de granularidad. Durante el proceso de restauración, se aplican todos los cambios en el servidor principal en el servidor de reserva. No puede utilizar el trasvase de registros para aplicar cambios a unas cuantas tablas y para rechazar los cambios restantes.
  • No hay ningún failover automático de las aplicaciones. Cuando el servidor principal falla debido a una catástrofe, el servidor de reserva no lo hará automáticamente. Por lo tanto, debe redirigir explícitamente las aplicaciones que se conectan al servidor principal al servidor en espera (failover).
Nota: Si su objetivo principal es mantener un servidor de reserva activa, Microsoft recomienda que utilice el trasvase de registros. El servidor de reserva activo refleja todas las transacciones que se producen en el servidor principal. Sin embargo, no puede utilizar el servidor de reserva cuando el servidor principal no está disponible.


Para obtener más información acerca de cómo configurar un servidor de reserva activo mediante el trasvase de registros, haga clic en los números de artículo siguientes para verlos en Microsoft Knowledge Base:

323135 Microsoft SQL Server 2000 - cómo configurar el trasvase de registros (notas del producto)

325220 support WebCast: Microsoft SQL Server 2000 trasvase de registros

Para obtener más información acerca de trasvase de registros, visite los siguientes sitios Web de Microsoft:

Duplicación transaccional

También puede utilizar la duplicación transaccional para mantener un servidor de reserva activo. Duplicación transaccional replica los datos en un servidor (el publicador) a otro servidor (el suscriptor) con la menor latencia de trasvase de registros. Puede implementar la duplicación transaccional en el nivel de objeto de base de datos como el nivel de tabla. Por lo tanto, Microsoft recomienda usar la replicación transaccional al tener menos datos a proteger y debe tener un plan de recuperación rápida.

Puede utilizar una suscripción de inserción para exigir la replicación transaccional entre dos servidores con el servidor principal como el Editor y el servidor de reserva como el suscriptor. Duplicación transaccional garantiza la replicación de datos. Cuando se produce un error en el publicador, el suscriptor puede utilizarse.

Esta solución es vulnerable al error en el publicador y el suscriptor al mismo tiempo. En este caso, no puede proteger los datos. En todos los otros escenarios como la falla de un distribuidor o un suscriptor, es mejor volver a sincronizar los datos en el suscriptor con los datos en el publicador.

Debe utilizar la duplicación transaccional para mantener un servidor de reserva activo sólo cuando no se implementan cambios en el esquema o no implementar otros cambios en la base de datos como cambios de seguridad que la replicación no se admite.

Nota: La replicación no está diseñada para el mantenimiento de servidores de reserva activos. Con la replicación, puede utilizar los datos replicados en el suscriptor para generar informes. También puede utilizar la replicación para otros usos generales sin tener que realizar el procesamiento en el publicador relativamente ocupado.

Ventajas y desventajas del uso de la duplicación transaccional

Ventajas
  • Puede leer datos en un suscriptor al aplicar cambios.
  • Cambios se aplican con menor latencia.

    Nota: Esta ventaja puede no ser aplicable si se cumple alguna de las siguientes acciones:
    • Agentes de duplicación no se establecen en continuo.
    • Agentes de duplicación se detienen debido a errores que pueden producirse durante la replicación.
La duplicación transaccional puede tardar más tiempo para aplicar cambios, pues es necesario realizar actualizaciones por lotes grandes durante la replicación.
Desventajas
  • Cambios de esquema o cambios de seguridad que se realizan en el publicador después de establecer la replicación no estarán disponibles en el suscriptor.
  • El distribuidor en la duplicación transaccional utiliza una conexión de conectividad abierta de base de datos (ODBC) o una conexión de base de datos OLE (OLEDB) para distribuir los datos. Sin embargo, el trasvase de registros utiliza la instrucción de Transact-SQL de bajo nivel de transacción restaurar para distribuir los registros de transacciones. Una instrucción RESTORE TRANSACTION es mucho más rápida que una conexión ODBC o una conexión OLEDB.
  • Normalmente, el cambio de servidores borra configuraciones de replicación. Por lo tanto, tiene que configurar la replicación de dos veces:
    Al cambiar al suscriptor.
    Al cambiar al publicador.
  • Si se produce un desastre, debe cambiar manualmente servidores redirigiendo todas las aplicaciones al suscriptor.
Para obtener más información acerca de la replicación, haga clic en el número de artículo siguiente para verlo en Microsoft Knowledge Base:

195757 preguntas más frecuentes - SQL Server 7.0 - replicación

Característica de copia de seguridad y restauración

La característica copia de seguridad y restauración de SQL Server proporciona una importante protección para ayudar a proteger los datos críticos almacenados en las bases de datos de SQL Server. Puede crear una copia de una base de datos (una copia de seguridad) mediante la característica de copia de seguridad y restauración y, a continuación, almacenar la copia de la base de datos en una ubicación que está protegida frente a los posibles errores del servidor que ejecuta la instancia de SQL Server. Si experimenta un error de sistema de base de datos o daños en la base de datos, a continuación, puede utilizar la copia de seguridad para volver a crear la base de datos o restaurar la base de datos.

Al planear la recuperación ante desastres mediante la característica de copia de seguridad y restauración, determinar también están la importancia de los datos en la base de datos. Además, determinar los requisitos de la restauración de la base de datos. Por ejemplo, determinar los requisitos de la restauración siguiente:
  • El punto de restaurar la base de datos. Tiene que decidir cuál de los dos siguientes desea realizar:
    Restaurar la base de datos a la condición de la noche anterior al fallo.
    Restaurar la base de datos a la condición de un punto de tiempo tan cerca como sea posible en el momento del error.
  • ¿Cuánto tiempo puede no estar disponible la base de datos. Si debe restaurar la base de datos inmediatamente.
Después de determinar los requisitos de la restauración, puede planear un proceso de copia de seguridad que mantiene un conjunto de copias de seguridad para satisfacer los requisitos

Sólo puede restaurar una base de datos a la condición del punto de tiempo en el que realizó la copia de seguridad más reciente. Transacciones que se produjo después de esa copia de seguridad puede perderse. Por lo tanto, Microsoft recomienda que utilice la característica copia de seguridad y restauración sólo para aplicaciones de misión crítica de la base de datos.

Ventajas y desventajas de utilizar la característica copia de seguridad y restauración

Ventajas
  • Puede realizar la copia de la base de datos de medios extraíbles para ayudar a proteger contra errores de disco.
  • No tiene que depender de la red como cuando el uso de clústeres de conmutación por error o el trasvase de registros.
Desventajas
  • Realizar una copia de la base de datos, se pueden realizar operaciones como la creación de tablas, creación de índices, reducción de la base de datos u operaciones no registradas.
  • Si se produce un error, puede perder los datos más recientes.
  • Si se produce un desastre, debe restaurar manualmente la base de datos.
Nota: Antes de utilizar el procedimiento de copia de seguridad y restauración en un entorno de producción, es aconsejable probar exhaustivamente este procedimiento en un entorno de prueba.

Para obtener más información acerca de la característica de copia de seguridad y restauración, haga clic en los números de artículo siguientes para verlos en Microsoft Knowledge Base:

WebCast de soporte técnico 325257 : recuperación de base de datos de SQL Server 2000: Backup y Restore

281122 descripción de restaurar archivos y copias de seguridad en SQL Server

Para obtener más información acerca de la característica de copia de seguridad y restauración, visite los siguientes sitios Web de Microsoft:

Redundancia de disco de datos utilizando una matriz redundante de discos independientes (RAID)

Una RAID almacena datos redundantes en varios discos para ofrecer mayor confiabilidad y menor tiempo de inactividad de los servidores. Niveles RAID 0, 1 y 5 se utilizan generalmente como opciones de recuperación de SQL Server. Las tecnologías RAID que se mencionan permiten el error y la consiguiente sustitución de un único disco sin el servidor fuera de conexión. Si se producen varios errores de disco, los datos pueden no ser recuperables. Por lo tanto, Microsoft recomienda que combina la administración de datos redundantes con un procedimiento de Backup y Restore para ayudar a asegurarse de que no se pierden datos si un error de hardware o se produce otro desastre.

RAID 0 utiliza tecnología de creación de bandas para un acceso más rápido, mientras que RAID 1 utiliza la tecnología de espejado para la confiabilidad de los datos. Una técnica común utilizada en la administración de bases de datos relacionales implica el uso conjunto de RAID 0 y RAID 1. En esta técnica, dos matrices distribuidas idénticas de unidades se actualizan constantemente para que la información que se almacena en los arreglos de discos es la misma. Si se produce un error en una matriz, la matriz de otra automáticamente asume el control hasta que la matriz original vuelva a estar online.

RAID 5 (también conocido como bandas con paridad) utiliza una matriz de disco seccionado solo con los bits de paridad escritos junto con los datos. Cuando cualquier un disco falla, los bits de paridad puede utilizarse para calcular los datos que faltan hasta que se reemplace el disco. Al reemplazar el disco, puede utilizar la información de paridad y los datos restantes para volver a crear los datos desde el disco con errores y copiar los datos vuelve a crear en el nuevo disco. Todas estas operaciones se producen sin downtime del sistema de base de datos. RAID ofrece muchas otras opciones y características para ayudarle a asegurarse de que los sistemas de base de datos de experiencia como menor downtime posible.

Ventajas y desventajas de utilizar RAID

Ventaja
No se pierden datos si falla cualquier uno disco.
Desventajas
  • Puede tardar mucho tiempo en recuperar los datos.
  • Si se produce un error en varios discos, no podrá recuperar datos valiosos.
Para obtener más información acerca de RAID, haga clic en el número de artículo siguiente para verlo en Microsoft Knowledge Base:

100110 resumen de matrices redundantes de discos económicos (RAID)

Referencias

Para descargar una versión actualizada de los libros en pantalla de SQL Server 2000, visite el siguiente sitio Web de Microsoft:Para obtener más información acerca de otras opciones de recuperación ante desastres, haga clic en el número de artículo siguiente para verlo en Microsoft Knowledge Base:

307775 artículos de recuperación ante desastres para Microsoft SQL Server

Para obtener más información acerca de los clústeres de conmutación por error, haga clic en los números de artículo siguientes para verlos en Microsoft Knowledge Base:

195761 preguntas más frecuentes - SQL Server 7.0 - conmutación por error

260758 frecuentes preguntas - SQL Server 2000 - Failover clustering

Actualización de 274446 a la solución de conmutación por error de SQL Server 2000 recomendada para todos los servidores virtuales no son de SQL Server 2000

280743 Windows clústeres y sitios dispersos geográficamente

Para obtener más información acerca de la característica de copia de seguridad y restauración, visite el siguiente sitio Web de Microsoft:Para obtener más información acerca de la característica de copia de seguridad y restauración, haga clic en los números de artículo siguientes para verlos en Microsoft Knowledge Base:

253817 cómo hacer copia de seguridad del último registro de transacciones cuando están dañados los archivos maestro y la base de datos de SQL Server

314546 cómo mover bases de datos entre equipos que ejecutan SQL Server

Para obtener más información acerca de los archivos y carpetas del catálogo de texto, haga clic en el número de artículo siguiente para verlo en Microsoft Knowledge Base:

240867 cómo mover, copiar y hacer copia de seguridad de archivos y carpetas de catálogos de texto completo

Propiedades

Id. de artículo: 822400 - Última revisión: 17 ene. 2017 - Revisión: 1

Comentarios