Informe de investigación de Snapshot-manager

Glosario

  • backup: copia de seguridad de un archivo o directorio, bien sea en forma de copia o en forma de incremental.
  • sistema de copias de seguridad: un sistema de copias de seguridad permite restaurar parte de un sistema de archivos a un estado anterior denominado snapshot.
  • snapshot: unidad mínima del sistema de copias de seguridad. Formado por los ficheros necesarios para la recuperación de archivos y directorios en el instante de la creación del mismo además de otros ficheros de mantenimiento.
    • snapshot-incremental: snapshot en el que los backup necesarios para la recuperación de archivos son diferenciales sobre el original, optimizando así el uso del espacio.
    • snapshot-íntegro: snapshot en el que los backup necesarios para la recuperación de archivos son versiones íntegras de esos archivos en ese instante.
  • snapshot-core: módulo encargado de la creación y mantenimeinto de los snapshot de HD-Lorean.
  • timestamp: o sello de tiempo es una cadena de caracteres que representa el instante actual. Se utiliza como una marca única para identificar un instante de tiempo dado y puede actuar a varias resoluciones. La resolución puede ser anual si sólo se determina el año; mensual, si se determina además el mes; diaria, si añadimos el dia o incluso mayor si contabilizamos horas, minutos y segundos.

Descripción del módulo snapshot-core

El módulo snapshot-core se encarga de la gestión del sistema de snapshots de HD-Lorean.

Las funcionalidades más representativas de snapshot-core son:

  • Realizar una copia de seguridad de un archivo o directorio.
  • Restaurar una copia de seguridad previa.
  • Gestionar el espacio en disco eliminando ciertos intervalos de snapshots.

Abstracción al problema

El objetivo de snapshot-core es definir una estructura para copias de seguridad. Esta estructura debe incluir la localización dónde se almacenarán las copias de seguridad,el formato de los archivos e informes, sumarios y archivos de configuración necesarios.

Abstracción a la solución

Una primera aproximación a la solución del problema consiste en identificar el proceso de copia de seguridad e intentar resolver las partes no triviales del mismo. Se describe su algoritmia en las siguientes líneas:

  1. A la entrada llega una lista de los ficheros (o directorios) de los que se desea realizar la snapshot.
  2. Crear un directorio para el snapshot
  3. Leer fichero de la lista de rutas de ficheros
  4. Identificar si existe un snapshot anterior
  5. Si existe:
    1. Almacenar tan sólo una diferencia con alguna versión anterior
  6. Si no existe:
    1. Copiar el archivo tal como está.
    2. Marcar dicho directorio como origen para el fichero.
  7. Volver a 3 hasta agotar la lista
  8. Fin del snapshot

Los puntos marcados en negrita requieren especial atención puesto que plantean nuevas dudas a cerca del sistema que se intenta definir:

El punto 3 lleva a la cuestión sobre qué formato tiene la lista que alimenta al método de creación de snapshots.

El punto 5.1 induce a plantearnos la manera de establecer los incrementales

Diferencias entre tipos de ficheros

La lista de rutas de ficheros contiene, además de las rutas a cada fichero (directorio) del que queramos un nuevo snapshot, alguna información extra que permite optimizar el tratamiento del archivo o directorio.

Al menos, provee un indicador del tipo de archivo al que se refiere la ruta pues a primera vista, existe una diferenciación entre ficheros y directorios. Mientras que en los primeros se realizan diferencias a nivel de byte, en los directorios los cambios se realizan a nivel de entrada de directorio. Es decir, en un archivo de texto pueden cambiar una palabra, en un archivo binario pueden cambiar algunos bytes, pero en un directorio lo que cambia es el conjunto de archivos y otros directorios en su interior.

En relación a puntos posteriores, utilizaremos dos tecnologías de copia incremental, una para archivos y otra para directorios. Luego concluimos que debemos hacer una primera diferenciación entre archivos y directorios.

Cómo se almacenan los ficheros incrementales

Para gestionar eficientemente el espacio de la unidad donde se encuentran almacenados los snapshot es necesario almacenar tan sólo las modificaciones ocurridas a un fichero en lugar del fichero completo. La duda existe a la hora de si definir estas diferencias respecto del archivo original o respecto del último conjunto de diferencias.

Como una de las características de HD-Lorean permite al usuario la eliminación de snapshots intermedios sin riesgo de perder la información, es conveniente optar por la primera opción, donde los conjuntos de diferencias se establecen en relación al primer archivo.

Conclusiones

El hecho de haber dividido el problema en pequeños subproblemas nos lleva a la necesidad de investigar nuevas tecnologías que permitan resolver eficientemente cada una de las tareas implicadas en el algoritmo.

Este documento versa sobre las tecnologías de compresión delta, indispensables para la creación de archivos diferenciales y su posterior reconstrucción.

Tecnologías empleadas

A continuación se establecen las bases teóricas para comprender la terminología utilizada a lo largo del documento. Luego se describe brevemente cada tecnología, se otorga un ejemplo de uso y se destacan sus aspectos positivos y negativos.

Codificación delta

También conocida como compresión delta, la codificación delta es un modo de almacenar un archivo en forma de variaciones secuenciales sobre una versión anterior del mismo. Estas diferencias son almacenadas de manera independiente en ficheros llamados deltas o diffs.

En general, las diferencias entre versiones son pequeñas por lo que el conjunto de deltas suele ocupar menos que el archivo equivalente no codificado.

Desde otro punto de vista, mucho más interesante para nuestra aplicación, un delta entre dos archivos A y B es la información que debe ser aplicada a A para lograr B.

Existen codificaciones direccionales o bidireccionales dependiendo de si se pretende transformar exclusivamente de A a B o de B a A; o si por el contrario se necesita poder transformar indistintamente A en B y B en A.

Normalmente la codificación delta proporcionada por alguna aplicación incluye también un protocolo para la sincronización de archivos en distintos puntos de una red a través de la transmisión de los deltas únicamente.

Este tipo de codificaciones fue concebido para archivos que presenten cierta regularidad en su formato, donde un cambio no alteré más que una región pequeña del total. Si se usa para codificar otro tipo de archivos en los que un cambio puede afectar a la estructura completa del archivo, su rendimiento se degrada considerablemente.

Estándar VCDIFF1

VCDIFF es un estándar de codificación de archivos delta. Es necesario atender a que VCDIFF no atiende a cómo se deben obtener las diferencias entre dos archivos sino a cómo han de escribirse estas diferencias en el archivo de diferencias. Esto es, el formato VCDIFF es independiente del algoritmo de extracción de datos y por tanto, un decodificador compatible con VCDIFF podrá actuar sobre cualquier archivo de diferencias en ese formato, sin conocer los detalles del algoritmo de codificación.


Aplicaciones de codificación delta

diff

No es estrictamente un programa de compresión delta pues opera únicamente sobre ficheros de texto. Sin embargo permite comparar dos directorios rápidamente. Si bien no distingue entre los archivos modificados, si es capaz de determinar qué archivos han sido añadidos y cuales eliminados.

Ejemplo de uso:

Contenido de prueba.txt

int main(int argc, char** argv){
    int i = 5;
    return i;
}

Contenido de prueba2.txt

void main(int argc, char** argv){ 
    int i = 5; 
    i++; 
    return; 
}

Salida producida por diff prueba.txt prueba2.txt

1c1 
< int main(int argc, char** argv){ 
--- 
> void main(int argc, char** argv){ 
3c3,4 
<     return i; 
--- 
>       i++; 
>     return;

Ejemplo de uso con directorios:
Contenido en el directorio ~/carpeta1

  • A
  • B
  • C

Contenido en el directorio ~/carpeta2

  • B
  • C
  • D
  • E

Salida producida por diff diff carpeta1 carpeta2

Sólo en carpeta1: A 
Sólo en carpeta2: D 
Sólo en carpeta2: E

Conclusiones:
La consecuencia de estas pruebas descartan a diff como una aplicación para la creación de deltas binarios aunque puede resultar una buena opción de cara a la simple comparación de ficheros o a la comparación de directorios.

Además, la mayoría de aplicaciones usa su algoritmo de comparación (descrito en E.Meyers2) o una optimización sobre del mismo y para casos especiales en archivos de texto cuenta con herramientas muy interesantes para la manipulación de deltas.


xdelta (v2.x)

Esta aplicación permite la creación de deltas para archivos binarios. Si no hay coincidencias entre la versiones entonces el parche se prepara para poder aplicarse sin necesidad del original.

dibujo1.bmp (368KiB)
dibujo.png

dibujo2.bmp (368KiB)
dibujo2.png

Salida para xdelta delta dibujo.bmp dibujo2.bmp to-dibujo2.patch

NADA

Salida para xdelta patch to-dibujo2.patch dibujo.bmp dibujo2-2.bmp
NADA

Salida para diff dibujo2.bmp dibujo2-2.bmp
NADA

La salida nula del último comando indica que ambos ficheros son iguales, de no ser así, el comando diff emitiría un mensaje indicando lo contrario como puede comprobarse ejecutando:

Salida para diff dibujo.bmp dibujo2.bmp

Los ficheros binarios dibujo.bmp y dibujo2.bmp son distintos

El tamaño del parche en la ocasión anterior es de 192,6KiB, el parche ocupa un poco más del 50% del tamaño original de la imagen. Si bien, este resultado es fruto de la codificación de imágenes BMP y no resulta tan eficiente utilizamos formatos ya comprimidos.

dibujo1.png (161,3KiB)
dibujo.png

dibujo2.png (205,4KiB)
dibujo2.png

Salida para xdelta delta dibujo.png dibujo2.png to-dibujo2.patch

NADA

Salida para xdelta patch to-dibujo2.patch dibujo.png dibujo2-2.png
NADA

Salida para diff dibujo2.png dibujo2-2.png
NADA

El resultado es un archivo parche de 205,6Kib, incluso mayor que el del original debido a algunos campos extra que el propio xdelta añade al crear el archivo de diferencias.

Conclusiones:
Pese a todo, HD-Lorean está enfocado al usuario doméstico que mantiene una colección de fotografías normalmente inalterable o modificada muy de vez en cuando. El módulo snapshot-core podría detectar esta situación y no crear un archivo de diferencias sino copiar directamente el nuevo archivo.


xdelta (v3.x)

Se trata de la siguiente versión de xdelta. Posee una interfaz drásticamente distinta y produce un delta codificado en el estándar VCDIFF.

El mismo ejemplo que en su versión anterior produce un peor archivo en el primer caso y un resultado ajustado en el segundo, siendo el parche del mismo tamaño que el archivo original.

A continuación se ilustra tan sólo su uso:

xdelta3 encode -s fromFile toFile patchFile
xdelta3 decode -s fromFila patchFile toFile

La primera sentencia codifica, mientras que la segunda decodifica.

Conclusiones:
Las conclusiones son prácticamente las mismas que en el caso anterior aunque el hecho de que se utilice VCDIFF a la hora de crear los archivos de diferencia permite en un futuro portar a otros sistemas potencialmente mejores sin perder la compatibilidad.

bsdiff / bspatch
Su autor afirma que consigue una compresión un 50% - 80% mejor que xdelta. A costa de un mayor tiempo de procesamiento, usa muy poca memoria y ofrece una interfaz extremadamente sencilla.

Ejemplo de uso:
dibujo1.png (368KiB)
dibujo.png

dibujo2.png (368KiB)
dibujo2.png

Salida para bsdiff dibujo.bmp dibujo2.bmp to-dibujo2.patch

NADA

Salida para bspatch dibujo.bmp to-dibujo2.patch dibujo2-2.bmp
NADA

Salida para diff dibujo2.bmp dibujo2-2.bmp
NADA

En este caso el parche ha resultado en 180,1KiB, algo menos que el parche de xdelta pero la ejecución ha tardado unas 10 veces más.

El segundo resultado, sobre archivos PNG, produce resultados peores que xdelta en mayor tiempo.

Conclusiones:
En conclusión, bsdiff ofrece un mejor rendimiento a costa de un gran coste en tiempo lo que puede ir en detrimento de la funcionalidad de HD-Lorean pero es una opción a tener en cuenta en situaciones dónde el tiempo no sea crítico y sí la optimización des espacio en disco. Sin embargo, mezclar alternativas que no siguen ningún estándar podría ser incompatible.


KDiff33

Se trata de una herramienta de comparación de archivos y carpetas con una agradable interfaz gráfica. También permite mezclar ficheros y editar los resultados y la posibilidad de hacer estas operaciones con 2 ó 3 entradas.

Ejemplo de ejecución de la herramienta:

kdiff-interfaz.png

Comparamos los directorios Temp1 y Temp2 y obtenemos como resultado:

kdiff-resultados.png

Como resultado obtenemos que el archivo “file1.txt” (notar los dos cuadrados verdes) se encuentra en los dos directorios y son idénticos, mientras que el archivo “file2.txt” es diferente (notar el cuadrado rojo), y por último el archivo “file3.txt” se encuentra en el directorio A pero no en el directorio B (el cuadrado es gris en la segunda columna).

La herramienta también aporta información adicional sobre los archivos que podría ser de gran ayuda a la hora de relacionar los snapshot de los directorios con los snapshots de los archivos.

Conclusiones:
Como veremos a continuación, KDiff3 pertenece a un nuevo grupo de tecnologías caracterizadas por ser aplicación, más que herramienta. Estudiar herramientas con interfaces gráficas implementadas sirve para conocer formas de representar resultados de manera óptima al usuario, acogiendo las ideas interesantes y desechando las menos relevantes, aunque esta tarea no sea el objetivo de este módulo.


xxdiff4

En este caso encontramos al igual que la herramienta anterior, una aplicación que nos permite comparar dos o tres archivos y dos directorios. La característica interesante de esta aplicación es que permite comparar dos directorios de forma recursiva, es decir, si en algún momento existiese un directorio interno a los directorios a comparar, éste también sería incluido en la comparación.
Esta funcionalidad sería interesante en nuestro programa ya que será muy común que algún usuario use la aplicación sobre múltiples directorios.

Ejemplo de comparación de directorios:

xxdiff-resultados.png

Conclusiones:
La funcionalidad de la aplicación es básicamente idéntica y no hay nada que remarcar de su investigación. Tan sólo se considera otra alternativa y será necesario un estudio de grano fino para poder elegir entre alguna de las dos.


rdiff-backup5

Se trata de un completísimo script escrito en python con licencia GPL que permite realizar una copia de seguridad de un directorio en otro. El directorio que contiene la copia de seguridad contiene también un conjunto de archivos diferenciales que permite la recuperación de cualquier estado intermedio.

Su interfaz es sencilla pero versátil y resulta la mejor opción de todas las puesto que podría cubrir todos los casos de uso de snapshot-core de manera automática.

Ejemplo de backup de la carpeta /home/salvador de 15,4MiB.

La primera operación crea el snapshot del directorio /home/salvador en /home/salva-back haciendo de este un clon del primero.

Salida para time rdiff-backup /home/salvador /home/salva-back

6.26user 2.77system 0:43.50elapsed 20%CPU

Después de algunas modificaciones (borrado, adición y edición de algunos archivos), el segundo comando, aunque en apariencia idéntico, tan sólo guarda las modificaciones acaecidas al directorio original. El incremento del tiempo se debe al hecho de que es necesario revisar cada archivo en busca de cambios aunque se intuye que para snapshots de directorios más grandes, las operaciones de comparación requerirían menos tiempo que las de creación de la estructura.

Salida para time rdiff-backup /home/salvador /home/salva-back

19.07user 0.35system 0:21.06elapsed 94%CPU

El tercer comando lista los incrementales ocurridos desde la primera copia.

Salida para rdiff-backup -l /home/salva-back/

Found 1 increments: 
    increments.2007-11-15T22:46:47+01:00.dir   Thu Nov 15 22:46:47 2007 
Current mirror: Thu Nov 15 22:52:39 2007

Por último, tras nuevos cambios (borrado de casi toda la estructura), el cuarto comando restaura el directorio tal y como estaba en el momento del primer incremental.

Salida para time rdiff-backup -r 2007-11-15T22:46:47+01:00 /home/salva-back/ /home/salva-restored/

5.49user 2.56system 0:17.03elapsed 47%CPU

En el ejemplo se ha incluido la salida del comando time que devuelve los tiempos de usuario y sistema para un proceso argumento.

Puede encontrarse la documentación de rdiff-backup en esta dirección:
//www.nongnu.org/rdiff-backup/docs.html

La documentación incluye ejemplos de uso y las páginas del manual.

Conclusiones:
Como conclusión, usando esta aplicación snapshot-core actuaría a modo de envoltorio para las funciones propias de rdiff-backup y proporcionaría una interfaz focalizada y sencilla. Además podría atender múltiples peticiones mediante el uso de threads.

Se trata de la forma más rápida de implementar snapshot-core pero presenta un inconveniente: HD-Lorean desconocería los detalles de implementación del sistema de snapshots.

La solución existente es investigar el código fuente de la aplicación.

Comparación

Se han estudiado dos grupos diferentes de tecnologías. El primero, formado por diff, xdelta (v2), xdelta (v3) y bsdiff pretenden ser una base para el desarrollo del gestor de snapshots de HD-Lorean. El segundo grupo formado por KDiff3, xxdiff y rdiff-backup pretende que HD-Lorean delegue la responsabilidad de mantener las snapshots haciendo uso de tal software. Como pequeño inciso decir que KDiff y xxdiff se encuentran muy limitados en comparación con rdiff-backup e incluso podrían resultar más útiles incluyéndolos en el primer grupo, por lo que, de considerar el segundo grupo de aplicaciones, la mejor opción con diferencia es rdiff-backup.

Conclusión

La implementación más rápida proviene del uso de rdiff-backup, sin embargo, desde el punto de la investigación y desarrollo, la opción más interesante es la gestión propia apoyada en el uso de herramientas menores como xdelta o diff. Si bien se puede lograr un compromiso estudiando rdiff-backup al tiempo que se desarrolla y compara con un administrador propio.

El estado del proyecto y el tiempo límite de entrega deberían influir en la toma de una decisión.

Opinión personal

Como responsable del módulo snapshot-core considero más interesante el desarrollo propio del sistema de snapshots pero atendiendo a las condiciones del proyecto recomiendo el uso de rdiff-backup teniendo en cuenta los nuevos riesgos que esto supone.


Nuevos desarrollos

Gracias a la investigación llevada a cabo se pudo desarrollar un módulo de pruebas que simulaba un sistema de archivos primitivo pero funcional. A continuación se detalla su funcionamiento exponiéndolo a una situación real.

Configuración

La aplicación de prueba toma una entrada como una lista de rutas caracterizadas por ser archivo o directorio que debe comprobar. En este momento, el procesamiento de carpetas no se lleva a cabo pero sí el de archivos. El de directorios, sin embargo, sólo es simulado.

Contenido del archivo de configuración

d#/home/salvador/pruebas-hd/+inotify
d#/home/salvador/pruebas-hd/+inotify
f#/home/salvador/pruebas-hd/+inotify/inotify-test.py
f#/home/salvador/pruebas-hd/+inotify/inotify threaded test.py

Como puede observarse claramente, cada ruta es de la forma

<tipo de ruta>#<ruta>

El tipo de ruta puede ser 'd', 'D', 'f' o 'F' refiriéndose los dos primeros a directorios y los últimos a ficheros. Es importante advertir que snapshot-core no realiza copias de seguridad recursivas y por tanto, el archivo de configuración debe incluuir toda la estructura del directorio si así lo disponemos.

De cara a la integración en HD Lorean este archivo será reemplazado por una lista de rutas acompañadas de información útil sobre las mismas y el proceso de recursión sobre directorios será llevado a cabo por otro módulo, específicamente por watcher.

Forma de uso

Es necesario indicar el archivo de configuración como primer argumento. De esta manera:

salvador@lodr:~$ ./hdl-snapshot-core ~/hdlorean-config

Estructura del directorio de copias de seguridad.

El resultado para una ejecución inicial como la anterior es:

snapshot-core started:
Monitorized files file (/home/salvador/.hdlorean/monitorized-files) is ready. That's good!
/home/salvador/pruebas-hd/+inotify=process performed for /home/salvador/pruebas-hd/+inotify
/home/salvador/pruebas-hd/+inotify=process performed for /home/salvador/pruebas-hd/+inotify
Executing: mkdir -p "/home/salvador/.hdlorean/backups/20071128-142422/home/salvador/pruebas-hd/+inotify/"
Executing: cp -a "/home/salvador/pruebas-hd/+inotify/inotify-test.py" "/home/salvador/.hdlorean/backups/20071128-142422/home/salvador/pruebas-hd/+inotify/"
/home/salvador/pruebas-hd/+inotify/inotify-test.py=backup in [/home/salvador/.hdlorean/backups/20071128-142422/home/salvador/pruebas-hd/+inotify/]
Executing: mkdir -p "/home/salvador/.hdlorean/backups/20071128-142422/home/salvador/pruebas-hd/+inotify/"
Executing: cp -a "/home/salvador/pruebas-hd/+inotify/inotify threaded test.py" "/home/salvador/.hdlorean/backups/20071128-142422/home/salvador/pruebas-hd/+inotify/"
/home/salvador/pruebas-hd/+inotify/inotify threaded test.py=backup in [/home/salvador/.hdlorean/backups/20071128-142422/home/salvador/pruebas-hd/+inotify/]
Nothing more!
Monitorized files file (/home/salvador/.hdlorean/monitorized-files) is ready for writing. That's good!
snapshot-core finished ok. See you!

Tras ella, en la carpeta personal de la sesión existirá un nuevo directorio llamado '.hd-lorean' cuyo contenido es:

salvador@lodr:~$ cd .hdlorean/
salvador@lodr:~/.hdlorean$ ls -a
.  ..  backups  monitorized-files

El contenido del archivo 'monitorized-files' es un listado de parejas de la forma

<ruta del archivo monitorizado>
<ruta de la copia de seguridad del archivo monitorizado
...

En especial, el contenido de este será:

/home/salvador/pruebas-hd/+inotify/inotify threaded test.py
/home/salvador/.hdlorean/backups/20071128-142422/home/salvador/pruebas-hd/+inotify/inotify threaded test.py
/home/salvador/pruebas-hd/+inotify/inotify-test.py
/home/salvador/.hdlorean/backups/20071128-142422/home/salvador/pruebas-hd/+inotify/inotify-test.py

Es importante notar que la copia de seguridad original del archivo preserva la ruta original del mismo pero dentro del directorio de copias de seguridad.

Si exploramos el contenido del directorio 'backups' encontramos:

salvador@lodr:~/.hdlorean$ cd backups/
salvador@lodr:~/.hdlorean/backups$ ls -a
.  ..  20071128-142422
salvador@lodr:~/.hdlorean/backups$

Esos números son un timestamp generado en el instante en el que da comienzo la copia de seguridad. También son el nombre de la carpeta de backup para ese instante. En su interior encontraremos los archivos (originales en este caso) salvados y un archivo llamado 'briefing' con los resultados de la copia de seguridad.

salvador@lodr:~/.hdlorean/backups$ cd 20071128-142422/
salvador@lodr:~/.hdlorean/backups/20071128-142422$ ls -a
.  ..  briefing  home

Queda patente que la copia de seguridad preserva la ruta original. Si, desde aquí, exploramos la ruta del directorio 'home' encontraremos copias idénticas de los archivos originales.

salvador@lodr:~/.hdlorean/backups/20071128-142422$ cd ./home/salvador/pruebas-hd/+inotify/
salvador@lodr:~/.hdlorean/backups/20071128-142422/home/salvador/pruebas-hd/+inotify$ ls
inotify-test.py  inotify threaded test.py
salvador@lodr:~/.hdlorean/backups/20071128-142422/home/salvador/pruebas-hd/+inotify$

Resultados de la copia de seguridad

Los resultados de la copia de seguridad se encuentran en el archivo 'briefing'

Contenido del archivo briefing

/home/salvador/pruebas-hd/+inotify=process performed for /home/salvador/pruebas-hd/+inotify
/home/salvador/pruebas-hd/+inotify=process performed for /home/salvador/pruebas-hd/+inotify
/home/salvador/pruebas-hd/+inotify/inotify-test.py=backup in [/home/salvador/.hdlorean/backups/20071128-142422/home/salvador/pruebas-hd/+inotify/]
/home/salvador/pruebas-hd/+inotify/inotify threaded test.py=backup in [/home/salvador/.hdlorean/backups/20071128-142422/home/salvador/pruebas-hd/+inotify/]

En él se aprecian las operaciones realizadas para cada archivo. En el caso de las carpetas sólo se simulo su procesamiento pero en el caso de los archivos, tal y como se indica, estos fueron copiados a las rutas indicadas. Tal y como vimos anteriormente.

Una segunda ejecución.

Si modificamos los archivos originales, y realizamos una segunda ejecución obtendremos para el mismo comando, la siguiente salida.

salvador@lodr:~$ ./hdl-snapshot-core ~/hdlorean-config
snapshot-core started:
HD-Lorean directory (/home/salvador/.hdlorean) already exists. That's good!
Backup directory (/home/salvador/.hdlorean/backups) already exists. That's good!
Monitorized files file (/home/salvador/.hdlorean/monitorized-files) is ready. That's good!
/home/salvador/pruebas-hd/+inotify=process performed for /home/salvador/pruebas-hd/+inotify
/home/salvador/pruebas-hd/+inotify=process performed for /home/salvador/pruebas-hd/+inotify
Executing: mkdir -p "/home/salvador/.hdlorean/backups/20071128-145209/home/salvador/pruebas-hd/+inotify/"
Executing: xdelta delta "/home/salvador/.hdlorean/backups/20071128-142422/home/salvador/pruebas-hd/+inotify/inotify-test.py" "/home/salvador/pruebas-hd/+inotify/inotify-test.py" "/home/salvador/.hdlorean/backups/20071128-145209/home/salvador/pruebas-hd/+inotify/inotify-test.py.diff"
/home/salvador/pruebas-hd/+inotify/inotify-test.py=incremental diff in  [/home/salvador/.hdlorean/backups/20071128-145209/home/salvador/pruebas-hd/+inotify/]
Executing: mkdir -p "/home/salvador/.hdlorean/backups/20071128-145209/home/salvador/pruebas-hd/+inotify/"
Executing: xdelta delta "/home/salvador/.hdlorean/backups/20071128-142422/home/salvador/pruebas-hd/+inotify/inotify threaded test.py" "/home/salvador/pruebas-hd/+inotify/inotify threaded test.py" "/home/salvador/.hdlorean/backups/20071128-145209/home/salvador/pruebas-hd/+inotify/inotify threaded test.py.diff"
/home/salvador/pruebas-hd/+inotify/inotify threaded test.py=incremental diff in  [/home/salvador/.hdlorean/backups/20071128-145209/home/salvador/pruebas-hd/+inotify/]
Nothing more!
Monitorized files file (/home/salvador/.hdlorean/monitorized-files) is ready for writing. That's good!
snapshot-core finished ok. See you!

Si ahora accedemos al directorio de copias de seguridad encontraremo una carpeta más con el timestamp actual.

salvador@lodr:~$ cd .hdlorean/backups/
salvador@lodr:~/.hdlorean/backups$ ls -a
.  ..  20071128-142422  20071128-145209
salvador@lodr:~/.hdlorean/backups$

El directorio 20071128-145209 es nuevo.

Veamos qué contiene su archivo de briefing:

/home/salvador/pruebas-hd/+inotify=process performed for /home/salvador/pruebas-hd/+inotify
/home/salvador/pruebas-hd/+inotify=process performed for /home/salvador/pruebas-hd/+inotify
/home/salvador/pruebas-hd/+inotify/inotify-test.py=incremental diff in  [/home/salvador/.hdlorean/backups/20071128-145209/home/salvador/pruebas-hd/+inotify/]
/home/salvador/pruebas-hd/+inotify/inotify threaded test.py=incremental diff in  [/home/salvador/.hdlorean/backups/20071128-145209/home/salvador/pruebas-hd/+inotify/]

El resultado es muy similar puesto que se han tratado los mismos archivos pero esta vez nótese que el resultado del procesamiento de archivos no es backup sino diff.

Podemos explorar el directorio de la copia de seguridad en busca de estos archivos y tener de esta manera:

salvador@lodr:~/.hdlorean/backups/20071128-145209/home/salvador/pruebas-hd/+inotify$ ls
inotify-test.py.diff  inotify threaded test.py.diff
salvador@lodr:~/.hdlorean/backups/20071128-145209/home/salvador/pruebas-hd/+inotify$

Esta vez, los archivos son parches generados con la aplicación xdelta de la que hablamos previamente.

Conclusiones finales

Aunque precario, este módulo es fácilmente ampliable a cualquiera de los casos de uso contemplados para HD Lorean y permite el control total de los contenidos y estructura del snapshot. Sin embargo, debido a su estado de desarrollo no se asegura que esta sea la solución más eficiente aunque haga uso de algoritmos realmente fiables.

El manual con la estructura de snapshot de rdiff-backup indica serias semejanzas entre esta organización y la presentada por rdiff-backup lo que supone una migración relativamente rápida de una a otra. De todas formas el objetivo de esta aplicación siempre fue familiarizar al grupo de desarrollo con el tipo de aplicación que iban a desarrollar. Además ha servido para identificar nuevos riesgos descritos detalladamente en el informe de final de iteración.

Apéndice A (Dic-07)

Sobre rdiff-backup

El término de las investigaciones sobre la utilidad rdiff-backup ha llevado a la valoración en profundidad de sus características de cara al desarrollo de HD Lorean.

Para empezar, rdiff-backup es una aplicación de backups6 preparada para resoluciones de tiempo grandes, como las copias cada x minutos, cada hora, día, semana… De hecho, su resolución mínima es el segundo lo que imposibilita el hecho de que notificadores en tiempo real como inotify o cron ordenen más de un backup en el mismo segundo. Por otra parte, rdiff utiliza un sistema de diferencias reversas independientes lo que implica que siempre se almacene el último estado de los ficheros salvados y una serie de archivos parche para la recuperación independiente de versiones anterirores.

Independiente quiere decir que, en caso de que algunos de los archivos de diferencias se pierdan, siempre será posible hacer uso del resto para recuperar otras versiones ya sean posteriores o anteriores al eliminado.

Problemas encontrados y soluciones propuestas

Rendimiento de rdiff-backup

Al ordenar un backup en un instante dado, rdiff comprueba las fechas de modificación de todos los archivos a la hora de generar los parches de diferencia por lo que, en principio, no realiza más trabajo del que es necesario. Sin embargo, el hecho de tener que acceder a todos los i-nodos de los archivos en busca de una posible modificación degrada el rendimiento de la aplicación en directorios con gran cantidad de archivos de pequeño tamaño. Esto, sumado al hecho de que rdiff-backup carece totalmente de una opción añadir al backup que permita únicamente agregar un archivo al backup existente sin tener que para ello acceder al resto de los ficheros del directorio produce una limitación de rendimiento importante y a tener en cuenta.

No existe solución inmediata puesto que rdiff-actua de esta manera y sería necesario modificar el código fuente para incluir esta optimización. La solución breve para simular el comportamiento deseado es hacer uso de las opciones —include y —exclude de rdiff-backup para seleccionar sólo aquellos ficheros deseados en cada instante y excluir todo lo demás. Si se desea añadir un fichero B a un directorio anteriormente salvado que tuviera ya los archivos A y C, se debería construir una lista A,B,C a rdiff-backup. Sin embargo si los archivos A y C hubieran sido modificados desde la última vez, no estaríamos añadiendo un nuevo archivo sino realizando un backup de nuevo. De todas formas, la adopción de esta solución puede llevarnos a violar el diagrama de colaboraciones entre clases diseñado para HD Lorean.

Otra solución es investigar otras aplicaciones de backup como rsnapshot o bien desarrollar nuestro propio gestor como encaminaba el módulo discontinuado llamado snapshot-core.

Eliminación de backups

rdiff-backup limita su gestión de espacio a poder eliminar del backup los ficheros con más de X tiempo sin haber sido modificados. HD Lorean no establece una gestión ni siquiera similar.
HD Lorean debe eliminar backups completos al término de cada hora, día, semana o mes y a voluntad del usuario de manera que ese instante de tiempo se habrá perdido para siempre.

La única manera de solucionar este problema es manipular los archivos de backup convenientemente, de manera que conserven la compatibilidad con rdiff-backup. Los riesgos de esta solución incluyen el hecho de que la manipulación externa a rdiff corrompa los archivos de backup inutilizando la copia de seguridad.

Dudas sobre rdiff-backup

He aquí la correspondencia mantenida por algunos desarrolladores de HD Lorean y los desarrolladores de snapshot-manager a cerca del comportamiento comentado sobre estas líneas.

De Salvador de la Puente a Ben Escoto, creador del documento titulado rdiff-backup file formar

Hi Ben!

I started to use rdiff-backup some days ago for an universitary project. I have a question about remove backups.

In man, you explain that remove-older-than deletes backups older than given time. That's ok, but… if I want to delete just one backup, not those older than time, only that that matches with time? How can i do it?

Thanks for all

PD: Excuse my english please. XD

Respuesta

Hi, I don't really work on rdiff-backup anymore, so you may have more
luck posting to the mailing list.

But I don't think there is a great answer to your question. If you
know that you have 12 backups, I think it may work to say
"—remove-older-than 11B", and if you know the last increment was a
bit more than 2 weeks old, maybe you could say "2W".

But in general I don't think there is a solution. If you wanted to
create one I think I would list the increments, find the time of the
second oldest, and delete older than that.


De Salvador de la Puente a la lista de correos de rdiff-backup

Hi everybody.

I'm developing a backup application that wraps rdiff-backup and it's triggered by inotify.

Supose I have following folder:

myFolder:

FileA.txt
FileB.txt
FileC..txt

If I execute rdiff-backup —exclude ~myFolder/FileB myFolder backup then I have a backup at time T.

Then, I execute rdiff-backup —include ~myFolder/FileB —exclude-regexp '.' myFolder backup to "add" B to the backup and I have a new backup at time T' containing only FileB.

The, If I list backup content at time T', then It's shown:

myFolder:

FileB

My question is, is possible to add FileB to the last backup?

I mean, is possible some like rdiff-backup —update —include ~myFolder/FileB —exclude-regexp '.' myFolder backup

Then, If i list buckup content at last backup time, It should show:

myFolder

FilaA
FileB (added)
FileC

Now another question.

Anybody can explain me how rdiff-backup make its reverse diff files and what is the structure and mean of each file inside rdiff backup folder?

That's all.

Thanks a lot.

P:D: Excuse my English, please and thx again. x)

Respuesta

Hi Salvador,

My question is, is possible to add FileB to the last backup?
I mean, is possible some like rdiff-backup —update —include
~myFolder/FileB —exclude-regexp '.' myFolder backup
Then, If i list buckup content at last backup time, It should show:
myFolder
FilaA
FileB (added)
FileC

Well, one thing to remember is that if you do several backups of the
same directory to the same rdiff-backup repository, then the backup
repository always shows the state of the source directory at the time
of the most recent backup. So in your example, all you would need to
do to add in FileB is not to exclude it, i.e. to run rdiff-backup
with no —exclude options at all. Then FileA and FileC would stay
there (since they are still in the source directory), and FileB would
be added (since this time you haven't told rdiff-backup to exclude
it). So all you would need to do is

rdiff-backup myFolder backup

No explicit includes or excludes are needed, if all you want is for
the backup repository to exactly mirror the source filesystem. This
doesn't cause rdiff-backup to do any extra work to keep FileA or
FileC, since they were already there. (It will check their
modification times to make sure they haven't changed, but if they are
the same, it won't re-copy those files.)

Hope this helps,

Eric


Conclusiones

Jamás recomendaría modificar los fuentes de rdiff.backup debido a que perderíamos la independencia respecto de la aplicación estando obligados a modificar cada release para adecuarla al comportamiento que necesitamos. Por tanto, adoptaría cualquiera de las otras soluciones para las cuales es necesario realizar una reunión con el fin de permitir o no la expresión de nuevas colaboraciones entre clases que puedan modificar la estandarización de la ruta de colaboración.

Debido a las particularidades de nuestro sistema de snapshots, recomiendo encarecidamente la investigación de un formato propio aunque esto retrasase algunas de las funcionalidades críticas en pos de un mejor control sobre nuestra aplicación.

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License