diff. roulants pour le stockage de fichiers très similaires?

Au travail, nous faisons un vidage nocturne de nos bases de données mysql. De jour en jour, je pense que près de 90 à 95% des données sont en double, augmentant avec le temps. (Heck à ce stade, certains sont probablement à 99%)

Ces vidages sont là où une ligne est une seule instruction mysql INSERT, donc les seules différences sont les lignes entières et l'ordre dans lequel elles se trouvent dans le fichier. Si je les triais, la différence réelle d'un fichier à l'autre serait très faible.

J'ai cherché et je n'ai trouvé aucun moyen de trier la sortie sur le vidage. Je pourrais le diriger via la sortcommande, cependant. Il y aurait alors de longs, longs blocs de lignes identiques.

J'essaie donc de trouver un moyen de stocker uniquement les différences. Je pourrais commencer avec un vidage principal, et faire la différence contre cela chaque nuit. Mais les différences seraient plus importantes chaque nuit. Ou, je pourrais faire des différences de roulement, qui individuellement seraient très petites, mais il semble que cela prendrait de plus en plus de temps à calculer, si je dois assembler un diff principal de chaque série chaque nuit.

Est-ce faisable? Avec quels outils?

Edit Je ne demande pas comment faire des sauvegardes mysql. Oubliez mysql pour le moment. C'est un hareng rouge. Ce que je veux savoir, c'est comment créer une série de différences de roulement à partir d'une série de fichiers. Chaque nuit, nous obtenons un fichier (qui se trouve être un fichier mysqldump ) qui est similaire à 99% à celui qui le précède. Oui, nous les gzipons tous. Mais c'est redondant d'avoir toute cette redondance en premier lieu. Tout ce dont j'ai vraiment besoin, c'est des différences par rapport à la veille ... ce qui n'est différent que de 1% de la veille ... et ainsi de suite. Donc, ce que je veux, c'est comment faire une série de différences, donc je n'ai besoin que de stocker ce 1% chaque nuit.

Deux outils de sauvegarde qui peuvent stocker des différences binaires sont rdiff-backup et duplicity . Les deux sont basés sur librsync, mais au-dessus de cela, ils se comportent très différemment. Rdiff-backup stocke les dernières différences de copie et de reverse, tandis que la duplicité stocke les différences incrémentielles traditionnelles. Les deux outils offrent également un ensemble différent de fonctionnalités périphériques.

Dernièrement, j'ai essayé de stocker des vidages de base de données dans git. Cela peut devenir impossible si vos vidages de base de données sont vraiment volumineux, mais cela a fonctionné pour moi pour les petites bases de données (sites Wordpress et autres).

Mon script de sauvegarde est à peu près:

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

Vous pouvez faire quelque chose comme ça (avec a.sqlcomme sauvegarde hebdomadaire).

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

Vos fichiers diff deviendront plus volumineux d'ici la fin de la semaine.

Ma suggestion est juste de le gzip (à utiliser gzip -9pour une compression maximale). Nous le faisons pour le moment et cela donne un fichier gz de 59 Mo alors que l'original est de 639 Mo.

Il existe plusieurs approches possibles, selon la taille et la similitude textuelle réelle des vidages de base de données:

1. appliquer un programme de sauvegarde à déduplication qui utilise une somme de contrôle mobile comme demandes OP, par exemple restic ( https://restic.net/ ) ou borgbackup ( https://borgbackup.readthedocs.io/ ) sur les vidages non modifiés. Les deux systèmes permettent même de monter une certaine version de sauvegarde via FUSE et fonctionnent de manière soi-disant toujours incrémentielle.
2. Découplez la structure de la base de données du contenu, de la même manière que les gars du NCBI le font pour leurs bases de données génétiques assez volumineuses. C'est-à-dire: vous créeriez des scripts SQL pour créer le schéma de base de données (par exemple, comme ftp://ftp.ncbi.nlm.nih.gov/snp/organisms/human_9606_b151_GRCh38p7/database/organism_schema/ ) et stockeriez séparément le contenu des tables dans l'un ou l'autre texte clair ou format binaire compressé sans les instructions d'insertion (comme dans ftp://ftp.ncbi.nlm.nih.gov/snp/organisms/human_9606_b151_GRCh38p7/database/organism_data/), par exemple en tant que valeurs séparées par des tabulations ou des virgules. Bien sûr, cela nécessite une routine d'importation distincte qui créerait les instructions d'insertion juste à temps pour réimporter les données dans la base de données, c'est-à-dire restaurer à partir de la sauvegarde. Si votre SGBD propose un importateur de fichiers csv, l'exigence du script supplémentaire ci-dessus peut être omise. Les fichiers texte ainsi réduits pourraient ensuite à nouveau être introduits dans les programmes de sauvegarde réguliers susmentionnés ou dans d'autres, comme rdiff-backup.
3. Choisissez une solution où la structure et le contenu sont faiblement couplés en utilisant un format comme les fichiers arff comme le WEKA utilise ( https://www.cs.waikato.ac.nz/ml/weka/arff.html ): la structure et les types de données de les colonnes seraient déclarées dans l'en-tête du fichier, et le contenu réel suivrait ensuite séparé par une instruction @DATA une fois de plus sous forme de csv. De nombreux outils ETL offrent aujourd'hui un lecteur arff en plus d'un connecteur de base de données. Les fichiers eux-mêmes pourraient à nouveau être introduits dans des programmes de sauvegarde réguliers

(Je ne l'ai pas fait en production.)

Effectuez une sauvegarde complète une fois par jour ou par semaine. Le relais de sauvegarde se connecte une fois par heure ou par jour.