¿Cuál es la forma más efectiva de comprimir y almacenar una copia de seguridad de SQL Server? [cerrado]

He estado probando diferentes métodos para comprimir y almacenar copias de seguridad de SQL Server (usando SQL Server 2008 R2 Enterprise edition), y me pregunto cuál es el algoritmo de compresión más efectivo para el almacenamiento a largo plazo de esas copias de seguridad, fuera de SQL algoritmos de compresión interna.

No me preocupa el almacenamiento físico o las unidades de cinta ni nada, solo intento convertir nuestros 3 TB de datos y archivos de registro en el archivo más pequeño que pueda.

Entonces, por ejemplo, ¿sería un .zip o .7z? ¿O hay demasiadas variables dentro de mi base de datos para poder estimar con precisión cuál será la más efectiva y solo tendré que hacer algunas pruebas? ¿O es la compresión interna de SQL Server la mejor que obtendré?

He estado haciendo algunas pruebas de diferentes métodos para comprimir y almacenar copias de seguridad de MS SQL (usando la edición Enterprise de MS SQL 2008 R2), y me pregunto cuál es el algoritmo de compresión más efectivo para el almacenamiento a largo plazo de esas copias de seguridad, fuera de SQL algoritmos de compresión interna.

Como está utilizando SQL 2008 R2 Enterprise Edition, puede / debe aprovechar

• Compresión de datos: compresión de filas y páginas. a nivel de datos

• Compresión de respaldo al realizar el respaldo para minimizar la huella de disco de los respaldos.

  USE master;
  GO
  EXEC sp_configure 'backup compression default', '1';
  RECONFIGURE WITH OVERRIDE;

La compresión de respaldo utiliza ciclos de CPU para comprimir los datos antes de que salga del servidor, y es por eso que en la gran mayoría de los escenarios, los respaldos comprimidos son más rápidos que los sin comprimir.

Tenga en cuenta que cuando utiliza herramientas de código abierto, debe descomprimir el archivo de copia de seguridad de la base de datos antes de poder iniciar el proceso de restauración por sí mismo.

por ejemplo: cuando recibe una copia de seguridad de la base de datos SQL de 50 Gb que se comprime a 5 GB. Para restaurar esta base de datos, necesita mucho más espacio en disco:

• 5 Gb para el archivo zip
• 50 Gb para el archivo de respaldo
• 50 Gb para la base de datos restaurada. (suponga que no hay espacio vacío en la base de datos)

En total se necesitan 105 Gb de espacio en disco.

Todavía puede usar herramientas de compresión de código abierto como gzip , 7Zip , bzip2 o QuickLZ después de la compresión de respaldo para beneficiarse.

Además, eche un vistazo a MSSQL Compressed Backup en codeplex.

Buenas referencias para estadísticas de comparación

• Compresión de archivos en la era de múltiples núcleos .
• comparación de métodos de compresión para volcados de bases de datos

En términos de compresión de respaldo, hice (hace un par de años) una comparación de las opciones de compresión de respaldo proporcionadas por SQL Backup de Red Gate , LiteSpeed ​​de Quests para SQL Server y SQLSafe de Idera , comparando los tres productos. Las diferencias en una copia de seguridad típica en la compresión máxima fue aproximadamente un 5% de diferencia entre los tres por el tiempo necesario, y una extensión algo más amplia para el tamaño de la copia de seguridad, con Red Gate en primer lugar (90% de compresión frente a 80 y 85% para Idera y Búsqueda, en ese orden).