Copias de seguridad en KMKey

Mantener copias de seguridad es algo importante no sólo en entornos profesionales como servidores en los que esté instalado KMKey sino también una práctica muy prudente a título doméstico, pero a la que habitualmente damos poca prioridad, puesto que mientras no son necesarias resultan una carga algo molesta... pero si un día resultan necesarias y no disponemos de ellas, lamentaremos no haberlas realizado.

Antes de hablar de cómo realizarlas, es preciso indicar qué debe ser resguardado. En KMKey hay dos ubicaciones en las que se almacenan los datos de usuario: por un lado está la base de datos Postgres, en la que hay todos los patrones, expedientes, píldoras y demás, mientras que los documentos se almacenan en un diretorio física, por defecto bajo /var/zope/storages pero podría variar según la instalación.

En la instalación por defecto de KMKey hay un simple script auxiliar (KMKeyCore/utils/rsbackup.sh) que realiza una copia completa en cada ejecución de ambas ubicaciones, realizando un bolcado completo de la base de datos y un archivo contenedor de todos los documentos. Se recomienda encarecidamente su uso.

Sin embargo, con la popularización del KMKey Quality hemos detectado en algunas de las instalaciones que gestionamos un aumento muy significativo del volumen de documentos, debido a la propia vida de los ciclos documentales, lo que a su vez ha repercutido en un crecimiento muy significativo del volumen de las copias de seguridad. Si mantenemos varias copias de seguridad simultáneamente, algo por su parte recomendable, las necesidades de espacio aumentan exponencialmente, lo cual puede resultar inconveniente tanto por el coste de almacenamiento como el de transmisión externa. Además nos hemos percatado que en la mayoría de los casos la proporción de documentos modificados en relación al total de los existentes es reducida, siendo la operación más habitual la de inclusión de nuevo material.

Es por ello que para estos casos sugerimos una aproximación distinta a la estrategia de copias completas cada vez, usando para ello copias incrementales: en ellas realizamos una primera copia completa y seguidamente sólo registramos las diferencias. De este modo nos evitamos almacenar múltiples copias de documentos completamente idénticos.

Para ello usaremos una característica del comando `tar': --listed-incremental. Con ella crearemos dos ficheros: el almacén de documentación similar al habitual más un fichero índice que registra el estado de los ficheros archivados. Mientras usemos este fichero índice especial, las posteriores copias de seguridad incluirán únicamente las diferencias respecto la anterior. La contrapartida importante a tener en cuenta es que para restaurar una copia hasta el estado de una fecha en particular, serán necesarias todos los archivos desde la primera completa hasta la última parcial, incluyendo todas las intermedias.

Pongamos ejemplos: un proceso de copia de seguridad habitual consiste en:

$ tar --create --gzip --file /mnt/backup/kmkey_files.tar.gz /var/zope/storages/kmkey/files
$ tar -czf /mnt/backup/kmkey_files.tar.gz /var/zope/storages/kmkey/files

(los dos comandos son idénticos)

Para convertirlo a un proceso incremental, basta con añadir la opción --listed-incremental (o su versión abreviada, -g) y la ruta al fichero de índice:

$ tar --create --gzip --file /mnt/backup/kmkey_files.tar.gz --listed-incremental /mnt/backup/kmkey_files.tar.incr /var/zope/storages/kmkey/files
$ tar -czf /mnt/backup/kmkey_files.tar.gz -g /mnt/backup/kmkey_files.tar.incr /var/zope/storages/kmkey/files


Si el fichero /mnt/backup/kmkey_files.tar.incr no existe, se creará mientras se realiza una copia completa, mientras que si existe de una ejecución anterior, lo actualizará y el tar que creará contendrá únicamente las diferencias desde la última ejecución. Debemos también tener la precaución de dar un nombre adecuado a cada fichero tar y sobretodo que sean distintos para evitar sobreescribir una copia anterior.


Para la restauración, simplemente sustituiremos --create por --extract (o -c por -x en su forma abreviada), ejecutándolo sobre cada fichero .tar por orden, empezando por la copia completa. Esto además nos permite ir avanzando copia por copia en caso que deseemos restaurar en un punto intermedio: mientras respetemos el orden, podemos detenernos en cualquier momento que la copia será fiel al instante en que se creó la última incremental que hayamos extraído.


Es recomendable generar de vez en cuando una copia completa para reducir el número de incrementales que hay que mantener controlados. Una posibilidad puede ser generar una completa durante el fin de semana, asumiendo una menor carga del servidor ese día, y diarias incrementales. Bastará con eliminar o renombrar el fichero de índice, al que le hemos puesto la extensión .incr, justo antes de lanzar el proceso que deba realizar la copia para que la realize completa en lugar de incremental.

Por lo que se refiere a la base de datos, realizar una copia incremental es algo más complejo si hay que analizar las diferencias entre volcados. Es por ello que, en caso de considerarse necesarias, remitimos al lector a la documentación oficial de Postgres.

En una próxima versión de KMKey modificaremos el script para que sea compatible con el método incremental de copia de seguridad de documentos.

Etiquetas: