¿Copia de seguridad y restauración de 10-20 bases de datos de SQL Server a un estado ~ síncrono?


15

Necesito hacer una copia de seguridad de 10-20 bases de datos SQL Server 2008 R2 con tamaños entre 10-50 GB, mientras están en línea y se usan simultáneamente por una sola aplicación empresarial. También necesito restaurarlos a un estado que esté sincronizado en gran medida en todas las bases de datos (puedo permitirme unos segundos de desincronización entre bases de datos). El propósito es capturar datos de producción para entornos QA / DEV.

Me gustaría no exigir que las bases de datos se ejecuten en recuperación total y proponer un método de respaldo que esté dedicado a capturar datos para entornos de control de calidad y que sea independiente de un proceso de respaldo principal que no esté bajo mi control.

Para mis clientes, tomará 1-2 horas capturar 20 copias de seguridad completas a ~ 30 GB cada una. Esto hace que la realización de copias de seguridad completas sea secuencialmente inaceptable, ya que las bases de datos estarían demasiado desincronizadas cuando se ejecuten en una recuperación simple.

Estoy buscando una idea mejor que estas:

IDEA 1: instantánea de nivel de SAN de discos VM. xcopy MDF / LDF de la instantánea.

Una vez que los archivos copiados se adjuntan a una instancia de servidor diferente, su proceso de recuperación debería producir bases de datos consistentes que son instantáneas casi simultáneamente.
Buscar en Google me convenció de que esta es una mala idea, al menos porque puedo obtener desincronización vs. master / msdb / etc.

IDEA 2: orquesta una copia de seguridad compleja y restauración de sincronización en todas las bases de datos

Esto requiere que las bases de datos exigentes se ejecuten en recuperación completa, lo que no quiero. Inicie copias de seguridad paralelas para todas las bases de datos mucho antes de la fecha límite (T0). Una vez que se alcanza T0, haga una copia de seguridad de todos los registros (debería tomar como máximo unos minutos). Tome la miríada de copias de seguridad resultantes e intente restaurarlas y avance los registros hacia adelante / atrás para obtener un estado algo consistente en las bases de datos, en relación con T0.
Esto requiere mucha planificación y secuencias de comandos para que se use de manera confiable, por lo que haría todo lo posible para evitarlo.

¿Me estoy perdiendo alguna otra solución?

PS1: Me hubiera encantado poder usar instantáneas db . La idea era iniciar una instantánea en cada base de datos (que debería terminar en segundos), luego hacer una copia de seguridad completa de cada secuencia secuencialmente durante los siguientes minutos / horas. Luego restaure todos en un servidor diferente y revierta cada uno a la instantánea. AFAIK este escenario no es posible porque no se pueden hacer copias de seguridad de las instantáneas junto con la base de datos. Solo se pueden revertir en su lugar, en el servidor donde se crearon. Además, requieren Enterprise Edition, que no tengo para todos los clientes.

PS2: si conoce una solución de terceros capaz de producir copias de seguridad sincronizadas cross-db, por favor menciónela.


¿Cuál es la versión del servidor SQL para este escenario con su edición? y aproximadamente ¿de qué tamaño son las bases de datos de las que estamos hablando aquí?
KASQLDBA

Respuestas:


12

Necesito hacer una copia de seguridad de 10-20 dbs de SQL Server utilizados simultáneamente por una sola aplicación empresarial, mientras están en línea, de tal manera que los restaure a un estado que esté sincronizado en gran medida en todos los dbs

Lo que está buscando es una copia de seguridad consistente en todas las bases de datos de sus clientes, debe usar copias de seguridad COMPLETAS junto con Marked Transactions(énfasis en negrita agregado):

Cuando realiza actualizaciones relacionadas a dos o más bases de datos, bases de datos relacionadas , puede usar marcas de transacción para recuperarlas a un punto lógicamente coherente . Sin embargo, esta recuperación pierde cualquier transacción que se confirme después de la marca que se utilizó como punto de recuperación. Marcar transacciones es adecuado solo cuando está probando bases de datos relacionadas o cuando está dispuesto a perder transacciones recientemente confirmadas.

ingrese la descripción de la imagen aquí

Asegúrese de llevar una copia de seguridad de registro de transacciones adhoc COPY_ONLY, de lo contrario su recuperación será un problema, ya que cualquier copia de seguridad de registro de transacciones adhoc sin COPY_ONLYromperá la cadena de registro. Como precaución, puede restringir a los usuarios para que usen solo COPY_ONLY copias de seguridad .

Necesito una solución para SQL Server versiones 2008 R2 y posteriores. El tamaño de la base de datos es de hasta 50 GB por base de datos y es probable que el tiempo para hacer una copia de seguridad de todos ellos sea de 1 a 2 horas.

Las transacciones marcadas funcionarán para su situación. Lo único que puede hacer copias de seguridad paralelas es a STRIPEellos, pero luego terminas asegurándote de no perder tus franjas de copia de seguridad. Para que sean más rápidos, puedes jugar con BUFFERCOUNTyMAXTRANSFERSIZE .

Debe usar la compresión de copia de seguridad y habilitar la inicialización instantánea de archivos .

Referirse a


1
Solo una pequeña nota, not usingla compresión de respaldo podría acelerar los respaldos aún más ... si tiene el espacio de almacenamiento para ello.

44
En un almacenamiento más lento, sospecho que la sobrecarga de compresión estará más que justificada, ya que el tiempo ahorrado en E / S superará el tiempo adicional que se dedica a la CPU. En un almacenamiento más rápido, los beneficios de la compresión son mucho más importantes para el espacio de almacenamiento.
Aaron Bertrand

@ShawnMelton Estaría de acuerdo con usted, pero al transferir copias de seguridad, las copias de seguridad comprimidas serían mucho más rápidas de transferir. Las copias de seguridad serían rápidas sin compresión (dependiendo del subsistema de almacenamiento), pero pensando en las ganancias de la compresión, tiendo a activarla en mi entorno.
Kin Shah

@Kin, no creo que las transacciones m sean una solución aquí porque: A) No parecen diseñadas para funcionar en un servidor diferente al que se tomaron las copias de seguridad. Algunos lo resolvieron restaurando filas en logmarkhistory pero no puedo usar el comportamiento indocumentado. B) No puedo cambiar el código de mi aplicación para agregar soporte para transacciones m. Necesitaría iniciar transacciones m especiales desde mis scripts de respaldo y, si lo entendí correctamente , detendrán todas las transacciones más nuevas hasta que se confirmen las más antiguas. Esto afecta la disponibilidad de la aplicación, que es un gran obstáculo.
bogdan

3
Se está volviendo un poco claro lo que realmente está preguntando aquí. Primero tiene un entorno en plena recuperación, luego tiene varios clientes, cada uno con su propia estrategia de respaldo. No desea cambiar la capa de aplicación, no desea realizar ninguna copia de seguridad de SQL y no desea ninguna replicación a nivel de bloque, pero espera una solución. Los requisitos siguen cambiando y todo lo que implica "trabajo" real es denegado. Lamentablemente no tenemos un sitio web magic.stackexchange.com.
Tom V - prueba topanswers.xyz

7

Si está ejecutando copias de seguridad completas, así como copias de seguridad del registro de transacciones (y debería hacerlo si considera que estos datos son importantes), simplemente podría copiar las copias de seguridad y las copias de seguridad del registro de transacciones al sistema de prueba y realizar una restauración en un punto en el tiempo para restaurar las bases de datos a + - al mismo tiempo.

Dependiendo de si todas las bases de datos residen en la misma máquina de SQL Server o qué tan bien están sincronizados los relojes de los servidores, debería poder coincidir con el objetivo de 'desincronización de un par de segundos'.

Puede ser una solución un poco curita, pero cumpliría con los requisitos y sería bastante simple y económico.

Si no tiene copias de seguridad completas y copias de seguridad del registro de transacciones de sus bases de datos importantes (que están en plena recuperación), realmente necesita revisar su estrategia de copia de seguridad. Las instantáneas de nivel SAN realmente discuten el punto de tener una base de datos en modo de recuperación completa, ya que de todos modos no podrá hacer una restauración en un punto en el tiempo.

Por favor, lea lo que MrDenny tiene que decir al respecto



1

En las circunstancias que ha indicado, ¿ha examinado las copias de seguridad de VSS a través de un proveedor de VSS que está basado en un tercero o en Microsoft? Puede realizar una copia de seguridad COPY_ONLY que no romperá su cadena de recuperación de producción y debe terminar con una copia de seguridad de todas las bases de datos que luego puede recuperar en otro lugar dentro de sus márgenes razonables. Tenga en cuenta que una copia de seguridad VSS tiene algunos de los mismos mecanismos y caídas que las instantáneas de la base de datos, ya que una base de datos muy activa podría causar un problema de espacio en disco debido a la escasez de archivos utilizados. Eche un vistazo a los recursos de TechNet en el servicio SQL Writer aquí y las copias de seguridad VSS de SQL Server aquí .

Para hacer esto a través de Windows Server Backup, deberá seguir los pasos del asistente para una copia de seguridad manual, asegurándose de seleccionar la copia de seguridad de copia VSS en la configuración personalizada en Configuración VSS. Esto permitirá que su copia de seguridad de Windows Server no interfiera con ninguna otra copia de seguridad realizada en el servidor. Consulte la referencia de Copia de seguridad de Windows Server para más detalles.


Consideré VSS como una alternativa a tomar instantáneas de disco en el nivel de hipervisor / SAN. Incluí estos casos en mi solución (publicada ahora como una respuesta adicional) para clientes que usan recuperación simple.
bogdan

1

Votaré a @ Kin como respuesta porque fue la primera que coincidió con la pregunta. Terminé encontrando una respuesta adicional y la describiré a continuación.

Para los clientes que usan un modelo de recuperación simple, requeriré una copia de MDF y LDF extraídos de una instantánea de disco temporal tomada en T0 en el nivel de hipervisor o SAN. Puedo usar estos para recuperar los dbs en el estado de T0.

Para los clientes que usan el modelo de recuperación completa, requeriré:

  • Copias de su proceso de copia de seguridad PRINCIPAL de la última copia de seguridad completa completada antes de T0 + cadena mínima de copias de seguridad posteriores del registro de transacciones que cubren T0. Entonces puedo realizar un punto en el tiempo de recuperación a T0.

  • Acceso para realizar mis propias COPY_ONLYcopias de seguridad auxiliares . Los comenzaré todos en paralelo en T0, lo que no debería tomar más de unos segundos y fue mi principal preocupación. Luego, en la restauración, realizaré una recuperación en el momento en FirstLSN de cada copia de seguridad. La belleza de esto es que no requiere que interactúe en absoluto con el proceso de copia de seguridad PRINCIPAL, que era mi otra preocupación, incluso pueden truncar los registros mientras COPY_ONLYse ejecutan mis copias de seguridad sin afectar su coherencia.


0

Hago esto varias veces al año para el control de calidad y otros entornos que son copias de producción. Para las restauraciones, el modo de recuperación completa es realmente necesario y la restauración a un punto en el tiempo funciona bien. También hay mucha replicación y es raro que tengamos errores de "fila no encontrada" después de restaurar en un punto en el tiempo. También utilizamos el método SAN de clonación / instantánea para una copia de producción geográficamente distante y que también funciona bien para sincronizar las bases de datos.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.