¿Diferencias continuas para el almacenamiento de archivos muy similares?

En el trabajo hacemos un volcado nocturno de nuestras bases de datos mysql. De día en día, quisiera estimar que cerca del 90-95% de los datos están duplicados, aumentando a medida que pasa el tiempo. (Diablos, en este punto, algunos son probablemente del 99%)

Estos volcados son donde una línea es una sola instrucción INSERT de mysql, por lo que las únicas diferencias son las líneas enteras y el orden en que están en el archivo. Si los ordenara, la diferencia real de un archivo a otro sería muy pequeña.

He estado buscando y no he encontrado ninguna forma de ordenar la salida en el volcado. Sin embargo, podría canalizarlo a través del sortcomando. Entonces habría largos, largos bloques de líneas idénticas.

Así que estoy tratando de encontrar una manera de almacenar solo las diferencias. Podría comenzar con un volcado maestro, y diferir en contra de eso cada noche. Pero las diferencias serían mayores cada noche. O bien, podría hacer diffs continuos, que individualmente serían muy pequeños, pero parece que tomaría más y más tiempo calcularlos, si tengo que armar un diff maestro de toda la serie cada noche.

¿Es esto factible? ¿Con que herramientas?

Editar No estoy preguntando cómo hacer copias de seguridad mysql. Olvídate de mysql por el momento. Es un arenque rojo. Lo que quiero saber es cómo hacer una serie de diferencias continuas de una serie de archivos. Cada noche tenemos un archivo (que resulta ser un archivo mysqldump ) que es 99% similar al anterior. Sí, los comprimimos a todos. Pero es redundante tener toda esa redundancia en primer lugar. Todo lo que realmente necesito son las diferencias de la noche anterior ... que es solo un 1% diferente de la noche anterior ... y así sucesivamente. Entonces, lo que busco es cómo hacer una serie de diferencias, así que solo necesito almacenar ese 1% cada noche.

Dos herramientas de respaldo que pueden almacenar diferencias binarias son rdiff-backup y duplicidad . Ambos se basan en librsync, pero por encima de eso se comportan de manera bastante diferente. Rdiff-backup almacena las últimas diferencias de copia e inversión, mientras que la duplicidad almacena diferencias incrementales tradicionales. Las dos herramientas también ofrecen un conjunto diferente de características periféricas.

Últimamente he estado intentando almacenar volcados de bases de datos en git. Esto puede ser poco práctico si los volcados de su base de datos son realmente grandes, pero me ha funcionado para bases de datos más pequeñas (sitios de Wordpress y similares).

Mi script de respaldo es aproximadamente:

cd /where/I/keep/backups && \
mysqldump > backup.sql && \
git commit -q -m "db dump `date '+%F-%T'`" backup.sql

Podrías hacer algo como esto (con a.sqltu respaldo semanal).

mysqldump > b.sql
diff a.sql b.sql > a1.diff
scp a1.diff backupserver:~/backup/

Sus archivos diff se agrandarán al final de la semana.

Sin embargo, mi sugerencia es simplemente gzip (usar gzip -9para máxima compresión). Hacemos esto en este momento y eso da uso a un archivo gz de 59 MB mientras que el original es de 639 MB.

Hay varios enfoques posibles que uno podría seguir, dependiendo del tamaño y la similitud textual real de los volcados de la base de datos:

1. aplique un programa de copia de seguridad de deduplicación que use una suma de comprobación continua según lo solicite el OP, por ejemplo, restic ( https://restic.net/ ) o borgbackup ( https://borgbackup.readthedocs.io/ ) en los volcados no modificados. Ambos sistemas permiten incluso montar una cierta versión de copia de seguridad a través de FUSE y funcionan de una manera llamada incremental para siempre.
2. Desacoplar la estructura de la base de datos del contenido, de forma similar a como lo hacen los chicos de NCBI por sus bases de datos genéticas bastante grandes. Es decir: crearía scripts SQL para crear el esquema de la base de datos (p. Ej., Como ftp://ftp.ncbi.nlm.nih.gov/snp/organisms/human_9606_b151_GRCh38p7/database/organism_schema/ ) y almacenará por separado el contenido de las tablas en texto claro o formato binario comprimido sin las instrucciones de inserción (como se hace en ftp://ftp.ncbi.nlm.nih.gov/snp/organisms/human_9606_b151_GRCh38p7/database/organism_data/) por ejemplo, como tabulación o valores separados por comas Por supuesto, eso requiere una rutina de importación separada que cree las instrucciones de inserción justo a tiempo para importar los datos nuevamente a la base de datos, es decir, restaurar desde la copia de seguridad. En caso de que su DBMS ofrezca un importador de archivos csv, se puede omitir el requisito del script adicional anterior. Los archivos de texto tan reducidos podrían volver a introducirse en los programas de copia de seguridad mencionados anteriormente u otros, como rdiff-backup.
3. Elija una solución en la que la estructura y el contenido se acoplen libremente utilizando un formato como los archivos arff que usa WEKA ( https://www.cs.waikato.ac.nz/ml/weka/arff.html ): la estructura y los tipos de datos de las columnas se declararían en el encabezado del archivo, y el contenido real seguiría separado por una declaración @DATA una vez más en forma de csv. Muchas herramientas ETL hoy en día ofrecen un lector arff además de un conector de base de datos. Los archivos en sí mismos podrían volver a ingresar a los programas de respaldo habituales.

(No he hecho esto en producción).

Haga una copia de seguridad completa una vez por día o semana. Los registros de retransmisión de respaldo una vez por hora o día