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.
Respuestas:
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):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 sinCOPY_ONLY
romperá la cadena de registro. Como precaución, puede restringir a los usuarios para que usen soloCOPY_ONLY
copias de seguridad .Las transacciones marcadas funcionarán para su situación. Lo único que puede hacer copias de seguridad paralelas es a
STRIPE
ellos, pero luego terminas asegurándote de no perder tus franjas de copia de seguridad. Para que sean más rápidos, puedes jugar conBUFFERCOUNT
yMAXTRANSFERSIZE
.Debe usar la compresión de copia de seguridad y habilitar la inicialización instantánea de archivos .
Referirse a
fuente
not using
la compresión de respaldo podría acelerar los respaldos aún más ... si tiene el espacio de almacenamiento para ello.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
fuente
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.
fuente
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_ONLY
copias 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 mientrasCOPY_ONLY
se ejecutan mis copias de seguridad sin afectar su coherencia.fuente
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.
fuente