Cada día que pasa vemos como las bases de datos que manejamos crecen y crecen de tamaño. A medida que crecen nuestras necesidades de espacio para almacenar los ficheros de la base de datos, crecen en mayor medida nuestras necesidades de espacio para la realización de copias de seguridad. No debemos olvidar que una política de copias de seguridad es totalmente imprescindible pues una pérdida de datos puede traer serios problemas de continuidad en la actividad de una empresa.

Hasta la llegada de SQL Server 2008 el espacio ocupado por una copia de seguridad completa de nuestra base de datos ocupaba al menos lo mismo que el espacio ocupado por todos nuestros datos incluidos en los ficheros de nuestra base de datos. Debido a esta problemática han nacido múltiples soluciones propietarias que suplen esta carencia permitiendo crear copias de seguridad comprimidas. El uso de estas herramientas tienen varios inconvenientes. Por una parte que el formato utilizado suele ser propio del producto y no existe ninguna garantía de su continuidad para futuras versiones de SQL Server. Otra desventaja evidente es el pago de licencias adiciones aparte de las propias de SQL Server.

En este post vamos a comprobar la eficiencia de la nueva funcionalidad de copias de seguridad comprimidas que incluye SQL Server 2008. Compararemos el impacto en el rendimiento y las ventajas e inconvenientes respecto a otras soluciones sencillas (compresión nativa de NTFS, compresión ZIP y compresión RAR). Para nuestras pruebas vamos a utilizar una base de datos que contiene información de trazas a la cual se le presupone bastante compresibilidad (debido a su alto contenido en texto plano así como a la repetición de estructuras). Comenzaremos analizando el impacto de las opciones que tenemos disponibles durante la realización de la copia de seguridad, esto es, cuando lanzamos el comando en el servidor. Realizaremos una copia de seguridad estándar, una copia de seguridad sobre un volumen comprimido NTFS y una copia de seguridad con la nueva compresión de SQL Server 2008 y analizaremos los resultados.

Duración copia seguridad

Cuando el tiempo de realización de nuestra copia de seguridad sea crítico, dado un mismo sistema de ficheros, el beneficio de utilizar el nuevo algoritmo de compresión ha alcanzado el 64% lo cual es muy representativo, reduciéndose a menos de la mitad la duración del proceso. Esto puede ser crítico en sistemas con ventanas de mantenimiento muy reducidas o con bases de datos muy grandes.

Consumo de CPU

Los resultados obtenidos muestran que el consumo de CPU de SQL Server es prácticamente nulo durante la copia de seguridad estándar lo cual la hace recomendable para la realización de una copia de seguridad si la carga de CPU de nuestro servidor es muy elevada. Cuando la copia se realiza sobre un volumen comprimido NTFS vemos como el proceso de SQL Server asume el coste de dicha compresión alcanzando una media del 22% durante el proceso. Además, se produce una ralentización del proceso considerable con lo cual la penalización es mayor de lo esperado. Finalmente, vemos que el nuevo algoritmo de compresión de SQL Server 2008 es el más intensivo en CPU (45% de media) aunque a cambio reduce la duración del proceso a menos de la mitad de la copia estándar. Es por ello que la alternativa más apropiada dependerá de si nuestro sistema puede abordar este pico de CPU o no. Nuestra experiencia muestra que la mayoría de sistemas suelen tener su cuello de botella en la entrada y salida con lo cual la reducción de bytes a escribir gracias a la compresión de SQL Server 2008 es la mejor alternativa.

Escrituras/lecturas por segundo

Si nos centramos en la actividad en disco, vemos como la copia de seguridad estándar realiza aproximadamente el mismo número de lecturas que escrituras a lo largo del tiempo, manteniéndose constante. El comportamiento de la compresión NTFS implica un número de escrituras que triplica el de lecturas. La media de lecturas se sitúa en casi 50 por segundo y el número de escrituras en 150 (fuera de gráfico). El motivo parece ser que el volumen comprimido comprime cada vez gran parte de los datos ya almacenados, necesitando releer y descomprimir datos anteriormente ya comprimidos. El motivo puede estar provocado por una compresión orientada a conjunto de bloques y no a flujo como sería más apropiado para una copia de seguridad de SQL Server. El beneficio lo obtendríamos si luego tuviéramos que hacer accesos aleatorios a dicho fichero, cosa que no tiene sentido en nuestro caso. Finalmente la compresión de SQL Server 2008 disminuye el número de escrituras por segundo (gracias a la compresión en origen de los datos) y nos aumenta, de forma proporcional a la disminución de la duración, el número de lecturas. De nuevo se nos presenta como caballo ganador entre las 3 alternativas.

Tamaños de ficheros

Lo primero que podemos apreciar al observar los tamaños de los ficheros es que hasta la peor de las alternativas, reduce el tamaño de los ficheros en un 62%. Si nuestros problemas de espacio son remarcables cuando hacemos las copias de seguridad, la compresión debe estar en nuestro punto de mira. Hemos agrupado los resultados por colores para poder comentar los resultados relacionados. En amarillo tenemos la compresión NTFS la cual resulta ser en el análisis la más lenta, la que mayor estrés provoca a nuestro sistema de disco y la que obtiene el peor resultado. Resulta difícil recomendar el uso de esta alternativa con lo que quedaría restringida a aquellos casos en que los volúmenes donde podemos hacer las copias son forzosamente volúmenes comprimidos con NTFS por política de empresa o similar.

El grupo de resultados en azul muestra el resultado de aplicar la nueva compresión de SQL Server 2008 de forma independiente o conjunta con una compresión posterior por métodos tradicionales. Vemos que el resultado alcanzado, teniendo en cuenta la rapidez del proceso, es muy bueno. La compresión reduce en más de un 81% el tamaño del fichero resultando un fichero que no permite una compresión adicional significativa por métodos tradicionales (ZIP o RAR). El escenario de uso de esta alternativa es claro: siempre que necesitemos una compresión muy rápida y con una tasa de compresión aceptable.

Finalmente los grupos verde y rosa muestran el resultado de aplicar compresores convencionales al fichero de copia de seguridad sin comprimir. En este caso los resultados son mejores que cualquier otra alternativa hasta ahora aunque no podemos dejar de lado que el proceso es muy costoso en tiempo. Además, el proceso debe realizarse en dos fases y consume gran cantidad de recursos en el servidor (CPU + MEMORIA) por lo que posiblemente se requiera de utilizar servidores específicos para esta labor si las bases de datos son grandes. Es sorprendente ver como el fichero original es reducido hasta un 92% en su tamaño en el mejor de los casos lo cual nos da una idea del potencial de beneficio que podemos llegar a obtener.

El tamaño del fichero de copia de seguridad es importante pero también importan los efectos que la compresión implica. Por una parte tenemos el coste del proceso que ya ha quedado analizado en párrafos anteriores. Por otra tenemos la vulnerabilidad del fichero ante un problema en el medio físico que lo almacena. En este aspecto, cuanto mayor sea la compresión, mayor será la alteración que sufra el fichero si forzamos su descompresión con errores. En casos extremos, puede ser imposible de descomprimir el fichero perdiendo toda la información. Es por ello que si conseguimos tasas tan altas de compresión, deberíamos aprovechar para duplicar al menos estas copias en diferentes medios físicos de forma que podamos salvarnos ante un desastre de este tipo. Aún teniendo esta duplicidad, el ahorro de espacio sigue siendo considerable (una media del 66%) aunque con mayor variabilidad entre las alternativas.

En conclusión, la nueva compresión nativa en SQL Server 2008 nos aporta importantes mejoras en la velocidad de realización de las copias junto a un grado de compresión aceptable. Si el factor decisivo en nuestro caso es el ratio final de compresión alcanzado, nos decantaríamos por la compresión tradicional de las copias de seguridad originales sin comprimir.