A blog about data, information and Tech by Mario Alberich

        

mysqldump, backup comprimido con gzip

En algunas ocasiones el espacio disponible para almacenar copias de seguridad de la base de datos es escaso, por lo que quizá no disponemos del espacio para realizar un volcado completo de la base de datos, y en segunda fase comprimir ese resultado. También puede ser que queramos acortar el proceso evitando la escritura en disco (que puede ser lento), y al disponer de un cierto margen de CPU, podemos comprimir al vuelo.

Pipes


Suponiendo que el comando básico de mysqldump sea como sigue:

mysqldump --opt -u [usuario] -p[clave] [base_de_datos] > [copiaseguridad.sql]

Sabemos que mysqldump devuelve por stdout todo el texto de las sentencias SQL que conforman la base de datos. Eso se guarda en el archivo copiaseguridad.sql.  Lo que se puede hacer es añadir un pipe hacia gzip, y que éste programa sea el que realmente genera el archivo de backup:

mysqldump -u [usuario] -p[clave] [base_de_datos] | gzip > [copiaseguridad.sql.gz]

En este caso, gzip capturará todo el contenido que antes enviábamos a copiaseguridad.sql y lo comprimirá. Una vez hecho esto, ahora sí, lo guardamos en un archivo. Por convención se le añade el sufijo ".sql.gz", ya que de este modo queda claro que está comprimido y del contenido.  Además, al descomprimir desaparece el ".gz", por lo que nos queda la extensión ".sql".

Importar el archivo comprimido


Llega el fatídico día que requiere recuperar la base de datos.  ¿Cómo procedemos? Vamos a incorporar a gunzip, la utilidad de descompresión.  Como en el caso anterior, podríamos ejecutar gunzip y luego mysql. Pero la idea es economizar la escritura en disco, así que seguiremos usando pipes:

gunzip < [copiaseguridad.sql.gz] | mysql -u [usuario] -p[clave] [base_de_datos]

Simplemente:

  • Enviamos a gunzip el contenido del archivo gz.
  • gunzip envía el resultado por stdout.
  • Este resultado es recogido por la pipe de mysql, que lo importa a base_de_datos.

Ratios de compresión


Los archivos SQL son ni más ni menos que archivos de texto. En estos casos los ratios de compresión (tamaño del archivo comprimido en comparación al archivo normal) son bastante notables, y pueden variar según el nivel de compresión. La contrapartida es que a mayor nivel de compresión, más uso de CPU (y más lento).

Sin embargo, si lo tuyo es una necesidad apremiante de espacio en disco, puedes añadir el nivel de compresión (entre 1 y 9, siendo 6 el valor por defecto) al ejecutar gzip:

mysqldump -u [usuario] -p[clave] [base_de_datos] | gzip -9 > [copiaseguridad.sql.gz]

Puedes hacer pruebas para revisar los ratios de compresión. La decisión final depende de todos los factores (CPU disponible, espacio/velocidad de disco, etc.).

En último término, también puedes usar bzip2, aunque la relación entre velocidad y compresión respecto a gzip puede desmotivarte.

© 2007 and beyond Mario Alberich, licensed under CC-BY-SA unless stated otherwise.