La copia de seguridad más pequeña posible ... con SQL Server

Diariamente enviamos nuestras copias de seguridad de SQL Server a través de la WAN. Necesitamos minimizar el tamaño de estas copias de seguridad para que no demore una eternidad.

No nos importa si nuestro proceso de copia de seguridad tarda un poco más; tal como están las cosas, necesitamos mover 30 gigas de copia de seguridad comprimida a través de la WAN que lleva más de 10 horas.

Hay 2 opciones que tenemos para obtener copias de seguridad diarias más pequeñas.

1. Envío de registros, lo que significaría que tendríamos que reestructurar el proceso de recuperación ante desastres.
2. Elimine la información de la base de datos y reconstruya en el otro lado (descarte los índices no agrupados, empaque los índices agrupados al 100% - reconstruya en el otro lado)

Ambos implicarían una buena cantidad de trabajo de nuestra parte. Estamos utilizando SQL Server 2008 pro, todas las copias de seguridad están comprimidas.

¿Hay algún producto comercial que pueda darnos un tamaño de copia de seguridad similar a la opción (2)?

¿Existe un script completo que nos permita lograr (2)? (manejo de vistas indexadas, índices filtrados, claves foráneas, etc.)

Primer pensamiento basado en comentarios ...

Use copias de seguridad diferenciales cada, por ejemplo, 6 horas, para reducir el tamaño / tiempo de la copia de seguridad + FTP. Luego, reduzca su copia de seguridad completa + FTP solo los fines de semana. Esto evita la complejidad del envío de registros, simple de hacer, y solo agrega una ligera complejidad a DR

Siento que las copias de seguridad diferenciales se pasan por alto ... He sugerido usarlas antes:

• Cómo hacer una copia de seguridad de una pequeña base de datos en SQL Server 2008 R2 Express Edition
  Usar copias de seguridad DIFF para resolver esto

  Me gustaría mantener todo lo más simple posible desde una perspectiva de recuperación mientras minimizo la cantidad de datos perdidos en caso de falla

• Pros y contras de las estrategias de copia de seguridad de SQL Server y sus escenarios de uso apropiados
• Migración de bases de datos grandes
  Uso de copias de seguridad DIFF para acelerar la migración del servidor de copia de seguridad / restauración

Editar: después del comentario de jcolebrand, intentaré explicar más

Una copia de seguridad diferencial solo toma páginas que han cambiado. Fuera de cualquier mantenimiento de índice (que puede afectar gran parte de la base de datos), solo un pequeño porcentaje de páginas cambiará durante un día. Por lo tanto, una copia de seguridad diferencial es mucho más pequeña que una copia de seguridad completa antes de cualquier compresión.

Si tiene una copia de seguridad completa, digamos semanalmente, puede hacer diferenciales diarios y enviarlos fuera del sitio. Una copia de seguridad completa diaria con diferenciales aún requerirá ambos archivos fuera del sitio.

Esto debería resolver el problema de obtener datos de A a B, C y D rápidamente.

Probablemente necesite restaurar tanto el diferencial completo como el último para obtener los datos más recientes, pero tal vez pueda solucionar esto con NORECOVERY y un archivo STANDBY (no lo he intentado con una restauración de diferencias durante años desde la última vez que estuve en un DBA puro trabajo).

Una ventaja adicional es que las copias de seguridad de diferencias no están relacionadas con las copias de seguridad de registros continuos, por lo que puede separar cualquier requisito de Alta disponibilidad / DR del requisito de "obtener datos para los monos de código".

Veo algunos problemas si tiene copias de seguridad completas diarias por política o auditoría, pero la restauración de diferencias se puede aplicar antes de cualquier restauración de registro para acortar el tiempo de recuperación. A diferencia de las copias de seguridad, las restauraciones de diferencias y registros interactúan.

Espero haber cubierto la mayoría de las bases ...

Existen productos comerciales que pueden ayudarlo a comprimir sus copias de seguridad mejor que la compresión nativa de 2008. Ejemplos son RedGate Backup , Hyperbac , Idera SQL Backup , Litespeed Backup .

Vienen con el costo adicional de CPU alta y tipos de archivos que deberán manejarse con herramientas externas a las enviadas por MS. Esto con la excepción de la compresión Hyperbac (ahora adquirida por Redgate), que maneja los archivos de forma transparente y permite crear archivos compatibles con zip (y tampoco necesita herramientas de terceros).

Pero no hay ninguna herramienta que le ofrezca un archivo del tamaño que obtendría al realizar la limpieza manual. Consulte el artículo de Brent Ozar: Cómo comprimir realmente sus copias de seguridad de SQL Server , él le aconsejará que siga los mismos pasos que tiene en el punto no. 2)

Pregunta 1: ¿Existe un producto de copia de seguridad comercial que otorgue un tamaño de copia de seguridad similar a la eliminación de datos no esenciales como los índices de la base de datos?

No. Hay muchos productos de compresión de respaldo (Quest LiteSpeed, Red Gate SQL Backup, Idera SQLSafe, Hyperbac, etc.) pero todos funcionan simplemente comprimiendo la salida del proceso de respaldo regular de SQL Server. Algunos de ellos lo hacen de formas complicadas: HyperBac y la opción Engine de LiteSpeed ​​son controladores de filtro del sistema de archivos, lo que significa que están interceptando la salida en su camino al disco, pero el resultado final de todos estos productos es solo una salida de respaldo comprimida.

Pregunta 2. ¿Existe un script completo para volcar todos estos datos adicionales?

Con el tiempo, a medida que mantenga más historial en la base de datos (4, 5, 8, 10 años), no querrá extraer todos los datos del índice y reconstruirlos en el otro lado de la WAN. En cambio, solo desea transferir los datos modificados, y ahí es donde entra el envío de registros.

No deberías hacer esto.

Pero si realmente quieres hacer esto (y no, no te ayudaré), puedes hacerlo con copias de seguridad de grupos de archivos. Configure los grupos de archivos de su base de datos de esta manera:

• Grupo de archivos primario (requerido, pero déjelo vacío)
• Grupo de archivos ClusteredIndex (ponga aquí sus índices agrupados)
• ExtraneousCrap Filegroup (ponga todo lo demás aquí)

Comience a hacer copias de seguridad de grupos de archivos comprimidos de los dos primeros y copie los más pequeños en su servidor DR. Puede usar la capacidad de copia de seguridad y restauración de grupos de archivos de SQL Server 2008 solo para restaurar los grupos de archivos de índice principal y ClusteredIndex, y luego estarán inmediatamente disponibles para realizar consultas. Realmente no serán viables hasta que obtenga ese grupo de archivos ExtraneousCrap en línea, pero también hay un truco desagradable para eso: en el libro MVP Deep Dives , hay un capítulo sobre la edición de las tablas del sistema para hacer el grupo de archivos ExtraneousCrap y todo de los índices asociados desaparecen. Este truco es peligroso, totalmente incompatible y una mala idea, pero bueno, lo pediste.

Recomiendo cambiar a algo como el envío de registros. Esencialmente, si tiene la opción de enviar 30 Gigs durante 24 horas en lugar de enviar al final del día dentro de un período de tiempo más corto, la velocidad de la red será un problema menor para usted.

Sus desarrolladores en la red lenta también podrán descargar archivos de tamaño más conveniente, a través de FTP o cualquier proceso que tenga instalado. También podrían configurar trabajos que se descargan durante el día.

Además de la compresión del servidor sql, puede implementar una herramienta de terceros que tenga una compresión más alta como litespeed o redgate sqlbackup.

Además, en el lado de la red, puede instalar dispositivos de red que pueden optimizar su rendimiento en el sitio de recuperación ante desastres. En el pasado, utilicé con éxito el dispositivo Riverbed para obtener 90 GB de copia de seguridad de FL a VA en menos de 3 horas.

Otra opción sería hacer una copia de seguridad de grupos de archivos específicos, excluyendo los índices, etc., pero todavía está atascado con índices agrupados y, dependiendo de su estructura de base de datos, puede obtener más costos / molestias que beneficios de ese enfoque.

Gracias

Si tiene el dinero y su arquitectura lo permite, consulte algo como las tecnologías Riverbed (http://www.riverbed.com/us/). Un dispositivo como este junto con un escenario de replicación o envío de registros podría ser su mejor opción.

Si no, entonces algunas preguntas. Si solo tiene que actualizar cada pocos meses, ¿por qué preocuparse por el ancho de banda? El único momento en el que tendría que preocuparse por la transferencia es una vez, obtener la copia de seguridad completa allí para hacer una restauración local, ¿o me equivoco en esa configuración?

Otra posibilidad es, en lugar de preocuparse por obtener todos esos datos, configurar un entorno Citrix y tenerlos a distancia. Con Citrix, tiene requisitos mínimos de ancho de banda entre cliente / host y tiene la capacidad de hacer lo que necesita localmente y no preocuparse por tener que replicar esos cambios en otro lugar. Solo mis $ 0.02

Usaría la replicación transaccional de SQL. Su carga inicial llevaría algún tiempo, pero una vez que se puso en funcionamiento, solo pudo enviar la información que desea. Por ejemplo, si solo tiene 3 o 4 tablas que se actualizan, solo puede enviar esas 3 o 4 tablas.

También puede elegir lo que desea enviar. FK's, índices agrupados / no agrupados, esquemas de partición de tablas, procesos almacenados y TONELADAS más.

http://www.sql-server-performance.com/2010/transactional-replication-2008-r2/

Si esto no es una opción, puede usar REDGATE SQL BACKUP - http://www.red-gate.com/products/dba/sql-backup/ . Utilicé esto antes y obtuve niveles de compresión de hasta el 90%. Mucho más pequeño que el de SQL.