VENTAS: 1-800-867-1389

Consideraciones sobre alta disponibilidad y recuperación ante desastres con Base de datos SQL de Azure

Actualizado: abril de 2014

Si va a migrar una base de datos local de SQL Server a Base de datos SQL de Azure (Base de datos SQL), una pregunta frecuente es cómo implementar una estrategia de copias de seguridad y restauración para proteger los datos frente a errores de los usuarios, errores de las aplicaciones, errores de hardware, cierre del centro de datos por desastres naturales y otros desastres naturales. A diferencia de las implementaciones locales, Base de datos SQL está diseñado para enmascarar las operaciones físicas de administración de bases de datos y de archivos de base de datos. Tenga en cuenta que un servidor de Base de datos SQL es un servidor lógico que define un grupo de bases de datos. Las bases de datos asociadas a su servidor de Base de datos SQL pueden residir en equipos físicos diferentes en el centro de datos de Microsoft. Una base de datos lógica individual puede compartir el espacio de una sola base de datos física con otra base de datos lógica. En un entorno Azure multiempresa, las herramientas tradicionales de copia de seguridad y restauración de SQL Server no funcionan.

Autores: Kun Cheng, Selcin Turkarslan
Revisores: Steve Howard, Adrian Bethune

Cada instancia de Base de datos SQL tiene tres réplicas que residen en tres equipos físicos diferentes de un centro de datos: una réplica principal y dos secundarias. Todas las lecturas y escrituras pasan a través de la réplica principal y los cambios se replican en las réplicas secundarias de forma asincrónica.

Base de datos SQL emplea un esquema de confirmación basado en quórum donde la escritura se debe completar en la réplica principal y en una réplica secundaria para que la transacción se considere confirmada. Si se produce un error de hardware en la réplica principal, el tejido de Base de datos SQL lo detecta y conmuta por error a una de las réplicas secundarias. Por tanto, hay al menos dos copias físicas coherentes transaccionalmente de los datos en un centro de datos. Las tres réplicas para cada instancia de Base de datos SQL de Microsoft Azure protegen los datos frente a errores de servidores individuales, dispositivos o conectividad de red. Además de las réplicas redundantes, el tejido de Base de datos SQL de Microsoft Azure mantiene un determinado número de copias de seguridad tomadas en incrementos de cinco minutos para todas las bases de datos del centro de datos. Estas copias de seguridad se almacenan en el centro de datos como medida preventiva frente a errores de hardware y del sistema simultáneos o catastróficos.

El entorno de Base de datos SQL está diseñado para mantener el servidor disponible, así como la integridad de los datos en caso de que se produzcan errores de hardware. Durante un evento de conmutación por error, una instancia de Base de datos SQL puede no estar accesible durante un período breve de tiempo. La aplicación necesita tener lógica de reintento para administrar estos eventos de conmutación por error. Pero puede usar la misma cadena de conexión para volver a establecer la conexión después de la conmutación por error a la réplica secundaria. Para obtener más información sobre cómo administrar los errores de pérdida de conexión, vea el artículo sobre la administración de recursos de Base de datos SQL de Azure en el sitio wiki de TechNet.

Un error del usuario o de una aplicación es uno de los escenarios más frecuentes de pérdida de datos o de daños en muchas aplicaciones de software. Un usuario puede quitar una tabla o una aplicación por error o enviar una transacción dos veces. Es difícil controlar y recuperarse de estos tipos de errores. Puede emplear las herramientas y los servicios siguientes para abordar estos problemas:

  • Autoservicio de restauración (para SKU Premium/Standard/Basic)

  • Copia de una base de datos

  • Servicio de importación y exportación de Base de datos SQL

  • Bcp y SQL Server Integration Services

Autoservicio de restauración. Con la vista previa actual de Base de datos SQL, puede restaurar su base de datos individual a un punto dentro de determinadas ventanas de tiempo. Las ventanas de tiempo son diarias y hasta 35 días. Para obtener más información, lea "Copia de seguridad y restauración de Base de datos SQL de Azure".

Copiar base de datos permite crear una copia de la base de datos en el mismo servidor o en otro servidor diferente del mismo centro de datos. Se trata de una operación en línea, asincrónica y coherente transaccionalmente. Puesto que es una operación asincrónica, puede emitir el comando de copia y después supervisar el progreso consultando la vista del sistema sys.dm_database_copies (Base de datos SQL).

Para copiar una instancia de Base de datos SQL, el inicio de sesión debe ser miembro del rol dbmanager de nivel de servidor en el servidor de destino y ser un DBO de la base de datos de origen en el servidor de origen. El inicio de sesión debe tener el mismo nombre de inicio de sesión y la misma contraseña en ambos servidores de Base de datos SQL: el de origen y el de destino. La frecuencia a la que elija copiar la base de datos puede variar y depende de las necesidades empresariales. Para recuperarse de los errores de las aplicaciones o los usuarios, es aconsejable crear una copia diariamente y mantener dos o tres copias vigentes de forma rotatoria quitando la copia más antigua cada día una vez que se complete una copia reciente.

Observe que, aunque recomendamos que las copias sean diarias, puede copiar la base de datos con más frecuencia. No se recomienda realizar la operación de copia de la base de datos con más frecuencia que cada hora. Cada proceso de copia de la base de datos, aunque se ejecuta independientemente del resto de los procesos de copia de la base de datos, producirá una copia de la base de datos que es coherente transaccionalmente al final del proceso de copia. Cada copia cuenta hasta llegar al límite de 150 bases de datos para cada servidor de Base de datos SQL y se le cobrará como una base de datos independiente. Por tanto, el hecho de copiar con demasiada frecuencia conduce a una situación en la que se puede quedar sin bases de datos disponibles en la cuenta y tiene que pagar innecesariamente copias de la base de datos que son casi idénticas. Para obtener más información, vea el tema "Copias bases de datos" en MSDN Library de Base de datos SQL.

Además de la copia de la base de datos, puede usar el SQL Database Import/Export Service. Este servicio permite importar o exportar tanto los datos como el esquema en un paquete con la extensión .bacpac. El paquete tiene un formato comprimido que incluye todos los objetos compatibles con Base de datos SQL como tablas, vistas, índices, restricciones, desencadenadores, procedimientos almacenados, inicios de sesión, usuarios, etc. El servicio puede importar o exportar directamente archivos BACPAC entre una instancia de Base de datos SQL y un almacenamiento de Blob de Azure. Puede tener acceso al Servicio de importación y exportación desde el Portal de administración de Azure. Si desea importar o exportar directamente entre SQL Server local y Base de datos SQL sin usar el almacenamiento de Blob de Azure, use las clases proporcionadas en el Espacio de nombres Microsoft.SqlServer.Dac.

A diferencia de la copia de la base de datos, el Servicio de importación y exportación no produce una copia de seguridad coherente transaccionalmente. Para hacer una copia de seguridad, se recomienda que bloquee la base de datos y detenga las transacciones antes de exportar los datos y el esquema, o bien, que use Copiar base de datos para crear primero una copia coherente transaccionalmente y exportar desde la copia. Para obtener más información, vea Importar y exportar una base de datos

Bulk copy utility (BCP.exe), SQL Server Integration Services (SSIS) y System.Data.SqlClient.SqlBulkCopy son similares también al Import/Export Service. Actualmente, Base de datos SQL admite BCP, la API de copia masiva y SSIS para mover datos. Necesita crear objetos de esquema de Base de datos SQL antes de cargar los datos. El uso de BCP o SSIS como mecanismo de copia masiva permite controlar qué objetos se mueven desde una base de datos y qué datos se mueven desde esos objetos. También puede especificar diferentes parámetros como el tamaño de lote, el tamaño de paquete y el número de flujos para obtener el mejor rendimiento en función del ancho de banda y la latencia de red.

Como ayuda para protegerse frente a la pérdida del centro de datos en el caso de que ocurra un desastre, tiene que crear un almacenamiento fuera de las instalaciones de las copias de seguridad de las bases de datos fuera del centro de datos, en la que la aplicación de base de datos esté implementada. Para lograrlo, se recomienda que use:

  • Replicación geográfica para SKU de la edición Premium y Standard.

  • Restaure a una región de Azure alternativa para SKU de la edición Basic.

  • Servicio de copia de base de datos y de importación y exportación de Base de datos SQL (descrito en la sección anterior) para SKU de la edición Web o Business.

Para obtener más información sobre la replicación geográfica, lea “Replicación geográfica activa para Base de datos SQL de Azure”. Para las ediciones Web y Business de bases de datos de Azure, se recomienda emplear las siguientes herramientas sugeridas para administrar toda la estrategia de copia de seguridad y restauración:

  • Implemente una estrategia de copia de seguridad y restauración para controlar los errores de usuario y de aplicación mediante:

    • Copia de una base de datos

    • Servicio de importación y exportación de Base de datos SQL

    • Bcp o SQL Server Integration Services

  • Implemente una estrategia avanzada de copia de seguridad y restauración para controlar la pérdida generalizada del centro de datos mediante:

    • Servicio de importación y exportación para migrar una copia de la base de datos a uno o más centros de datos secundarios y, opcionalmente, dentro de su propio SQL Server local.

Para obtener más información acerca de las opciones de copia de seguridad, restauración y recuperación ante desastres de Microsoft Azure, lea los artículos “Continuidad del negocio de Base de datos SQL de Azure” y “Orientación técnica de la continuidad del negocio de Microsoft Azure” en MSDN Library.

¿Te ha resultado útil?
(Caracteres restantes: 1500)
Gracias por sus comentarios
Mostrar:
© 2014 Microsoft