hashget est un déduplicateur gratuit basé sur l'opéra - un utilitaire de type archiveur qui peut réduire considérablement la taille des sauvegardes, ainsi qu'organiser des schémas de sauvegarde incrémentiels et différentiels et plus encore.
Il s'agit d'un article de revue pour décrire les fonctionnalités. L'utilisation de hashget lui-même (assez simple) est décrite dans le README et la documentation wiki du projet.
Comparaison
Selon la loi du genre, je vais commencer tout de suite par l'intrigue - comparer les résultats:
Contexte de ce que devrait être une sauvegarde idéale et efficace
Chaque fois que je faisais une sauvegarde d'une machine virtuelle fraîchement créée, j'étais hantée par le sentiment que je faisais quelque chose de mal. Pourquoi est-ce que j'obtiens une sauvegarde lourde d'un système où ma créativité inestimable inestimable est un index.html sur une seule ligne avec le texte "Hello world"?
Pourquoi y a-t-il 16 mégaoctets / usr / sbin / mysqld dans ma sauvegarde? Est-ce vraiment dans ce monde que j'ai l'honneur de stocker cet important fichier, et si je ne peux pas le faire, il sera perdu pour l'humanité? Probablement pas. Il est stocké sur des serveurs Debian très fiables (dont la fiabilité et la continuité ne peuvent être comparées à ce que je peux fournir), ainsi que dans des copies de sauvegarde (des millions d'entre eux) d'autres administrateurs. Avons-nous vraiment besoin de créer 10 000 000 + 1ère copie de ce fichier important pour augmenter la fiabilité?
En général, hashget résout ce problème. Lors de l'emballage - il crée une très petite sauvegarde. Lors du déballage - un système complètement déballé, similaire à celui qui serait avec tar -c
/ tar -x
. (En d'autres termes, il s'agit d'un emballage sans perte)
Comment fonctionne le hashget
Hashget a les concepts de Package et HashPackage, avec leur aide, il effectue la déduplication.
Paquet Un fichier (généralement une archive .deb ou .tar.gz) qui peut être téléchargé de manière fiable à partir du réseau et à partir duquel un ou plusieurs fichiers peuvent être obtenus.
HashPackage est un petit fichier JSON représentant le package, y compris l'URL du package et la somme de hachage (sha256) des fichiers qu'il contient. Par exemple, pour le paquet mariadb-server-core de 5 mégaoctets, la taille du hachage n'est que de 6 kilo-octets. Un millier de fois plus petit.
Déduplication - création d'une archive sans fichiers en double (si le dédoublonneur sait où le package d'origine peut être téléchargé, il réduit les doublons de l'archive).
Emballage
Lors de l'emballage, tous les fichiers du répertoire compressé sont affichés, leurs sommes de hachage sont prises en compte et si la somme est trouvée dans l'un des HashPackages connus, les métadonnées du fichier (nom, hachage, autorisations, etc.) sont enregistrées dans un fichier spécial .hashget-restore.json, qui sera également inclus dans l'archive.
L'emballage lui-même dans le cas le plus simple ne semble pas plus compliqué que le goudron:
hashget -zf /tmp/mybackup.tar.gz --pack /path/to/data
Déballage
Le déballage se fait en deux étapes. Tout d'abord, le déballage habituel du goudron:
tar -xf mybackup.tar.gz -C /path/to/data
puis restaurez à partir du réseau:
hashget -u /path/to/data
Lors de la récupération, hashget lit le fichier .hashget-restore.json, télécharge les packages nécessaires, les décompresse et extrait les fichiers nécessaires, en les définissant dans les bons chemins, avec le propriétaire / groupe / autorisations nécessaires.
Des choses plus compliquées
Ce qui est décrit ci-dessus est déjà suffisant pour ceux qui "veulent du tar, mais pour emballer ma Debian dans 4 mégaoctets". De plus, nous examinerons des choses plus difficiles.
Indexation
Si un hashget n'avait pas du tout de HashPackage, il ne pourrait tout simplement pas dédupliquer quoi que ce soit.
Vous pouvez également créer un HashPackage manuellement (simplement: hashget --submit https://wordpress.org/wordpress-5.1.1.zip -p my
), mais il existe un moyen plus pratique.
Afin d'obtenir le hashpackage dont vous avez besoin, il y a une étape d' indexation (elle est automatiquement effectuée lorsque la commande --pack
est --pack
) et une heuristique . Lors de l'indexation, le hachage "alimente" chaque fichier trouvé vers toutes les heuristiques existantes qui l'intéressent. L'heuristique peut ensuite indexer n'importe quel package pour créer un HashPackage.
Par exemple, une heuristique Debian aime le fichier / var / lib / dpkg / status et détecte les paquets Debian installés, et s'ils ne sont pas indexés (HashPackage n'a pas été créé pour eux), les télécharge et les indexe. Le résultat est un effet très agréable - hashget dédupliquera toujours efficacement les OS Debian, même s'ils ont les derniers paquets.
Fichiers d'indices
Si votre réseau utilise une sorte de package propriétaire ou un package public qui n'est pas inclus dans l'heuristique de hachage, vous pouvez lui ajouter un fichier de conseil simple hashget-hint.json comme suit:
{ "project": "wordpress.org", "url": "https://ru.wordpress.org/wordpress-5.1.1-ru_RU.zip" }
De plus, chaque fois que l'archive est créée, le package sera indexé (si ce n'est précédemment) et les fichiers du package seront dédupliqués à partir de l'archive. Aucune programmation n'est nécessaire, tout peut être fait à partir de vim et enregistré dans chaque sauvegarde. Notez que grâce à l'approche via des hachages, si certains fichiers du package sont modifiés localement (par exemple, le fichier de configuration est modifié), les fichiers modifiés seront enregistrés dans l'archive «tels quels» et ne seront pas réduits.
Si certains de vos propres packages sont mis à jour périodiquement, mais que les modifications ne sont pas très importantes, vous ne pouvez suggérer que des versions majeures. Par exemple, dans la version 1.0, ils ont fait un indice indiquant mypackage-1.0.tar.gz, et il sera complètement dédupliqué, puis ils ont publié la version 1.1, qui est légèrement différente, mais ils n'ont pas mis à jour l'indice. Rien à craindre. Seuls les fichiers qui correspondent (qui peuvent être restaurés) à la version 1.0 sont dédupliqués.
Une heuristique qui traite un fichier d'indices est un bon exemple pour comprendre le mécanisme interne de l'heuristique. Il ne traite que les fichiers hashget-hint.json (ou .hashget-hint.json avec un point) et ignore tout le monde. À l'aide de ce fichier, il détermine quelle URL de package doit être indexée et hashget l'indexe (si cela n'a pas été fait auparavant)
Hashver
Il serait assez long de réaliser une indexation complète lors de la création de sauvegardes. Pour ce faire, vous devez télécharger chaque package, décompresser, indexer. Par conséquent, hashget utilise un schéma avec un HashServer . Si un paquet Debian est installé, s'il ne se trouve pas dans le HashPackage local, une tentative est d'abord faite pour simplement télécharger le HashPackage depuis le serveur de hachage. Et seulement si cela ne fonctionne pas - hashget lui-même télécharge et hache le paquet (et le télécharge sur hashserver, afin que hashserver le fournisse plus tard).
HashServer - un élément facultatif du schéma, non critique, est utilisé exclusivement pour accélérer et réduire la charge sur les référentiels. Il est facilement déconnecté (avec l'option --hashserver
sans paramètres). De plus, vous pouvez facilement créer votre propre serveur de hachage .
Sauvegardes incrémentielles et différentielles, obsolescence planifiée
hashget rend très simple la réalisation de sauvegardes incrémentielles et différentielles . Pourquoi ne pas indexer notre sauvegarde elle-même (avec tous nos fichiers uniques)? Une équipe - --submit
et vous avez terminé! La prochaine sauvegarde créée par hashget n'inclura pas les fichiers de cette archive.
Mais ce n'est pas une très bonne approche, car il peut s'avérer que lors de la récupération, nous devrons récupérer toutes les sauvegardes de hachage pour tout l'historique (si chacun a au moins un fichier unique). Pour cela, il existe un mécanisme d' obsolescence de sauvegarde planifiée . Lors de l'indexation, vous pouvez spécifier la date d'expiration de HashPackage - --expires 2019-06-01
, et à cette date (à partir de 00:00), elle ne sera pas utilisée. L'archive elle-même ne peut pas être supprimée après cette date (bien que hashget puisse facilement afficher les URL de toutes les sauvegardes que nous avons pourries / pourries en ce moment ou à n'importe quelle date).
Par exemple, si vous effectuez une sauvegarde complète le 1er jour et l'indexez avec une durée de vie avant la fin du mois, nous obtiendrons un schéma de sauvegarde différentielle.
Si nous indexons également de nouvelles sauvegardes, il y aura un schéma de sauvegardes incrémentielles.
Contrairement aux schémas traditionnels, hashget vous permet d'utiliser plusieurs sources de base. La sauvegarde sera réduite en raison de la réduction des fichiers des sauvegardes précédentes (le cas échéant) et des fichiers publics (ce qui peut être téléchargé).
Si, pour une raison quelconque, nous ne faisons pas confiance à la fiabilité des ressources Debian ( https://snapshot.debian.org/ ) ou si nous utilisons une autre distribution, nous pouvons simplement effectuer une sauvegarde complète avec tous les paquets une fois, puis nous y fier déjà ( désactiver l'heuristique ) Maintenant, si tous les serveurs de nos distributions se révèlent inaccessibles pour nous (dans Internet souvenir ou pendant l'apocalypse zombie), mais nos sauvegardes sont en ordre - nous pouvons récupérer à partir de n'importe quelle sauvegarde de différence courte qui ne repose que sur nos sauvegardes précédentes.
Hashget ne dépend que de sources de récupération fiables à votre discrétion. Ce que vous considérez fiable - ceux-ci seront utilisés.
FilePool et Glacier
Le mécanisme FilePool vous permet de ne pas accéder constamment à des serveurs externes pour télécharger des packages, mais d'utiliser des packages à partir d'un répertoire local ou d'un serveur d'entreprise, par exemple:
$ hashget -u . --pool /tmp/pool
ou
$ hashget -u . --pool http://myhashdb.example.com/
Pour créer un pool dans un répertoire local - il suffit de créer un répertoire et d'y télécharger des fichiers, hashget lui-même trouvera ce dont il a besoin par hachage. Pour rendre le pool accessible via HTTP, vous devez créer des liens symboliques d'une manière spéciale, cela se fait avec une seule commande ( hashget-admin --build /var/www/html/hashdb/ --pool /tmp/pool
). HTTP FilePool lui-même est un fichier statique, donc tout serveur Web simple peut le servir, la charge sur le serveur est presque nulle.
Grâce à FilePool, non seulement les ressources http (s) peuvent être utilisées comme ressources de base, mais aussi, par exemple , Amazon Glacier.
Après le téléchargement de sauvegarde sur le glacier, nous obtenons son ID de téléchargement et nous l'utilisons comme URL. Par exemple:
hashget --submit Glacier_Upload_ID --file /tmp/my-glacier-backup.tar.gz --project glacier --hashserver --expires 2019-09-01
Désormais, les nouvelles sauvegardes (différentielles) s'appuieront sur cette sauvegarde et seront plus courtes. Après avoir déballé tar le diffback, nous pouvons voir sur quelles ressources il s'appuie:
hashget --info /tmp/unpacked/ list
et utilisez simplement le script shell pour télécharger tous ces fichiers du glacier dans le pool et exécutez la récupération habituelle: hashget -u / tmp / unpacked --pool / tmp / pool
Le jeu en vaut-il la chandelle
Dans le cas le plus simple, vous paierez simplement moins cher pour les sauvegardes (si vous les stockez quelque part dans le cloud pour de l'argent). Peut-être - beaucoup, beaucoup moins.
Mais ce n'est pas le seul. La quantité va dans la qualité. Vous pouvez l'utiliser pour obtenir une mise à niveau du schéma de sauvegarde de haute qualité. Par exemple, puisque nos sauvegardes sont maintenant plus courtes - vous ne pouvez pas faire une sauvegarde mensuelle, mais une sauvegarde quotidienne. Gardez-les non pas six mois, comme avant, mais 5 ans. Auparavant, ils étaient stockés dans un stockage "froid" lent mais bon marché (Glacier), vous pouvez désormais le stocker à chaud, d'où vous pouvez toujours télécharger rapidement une sauvegarde et récupérer en quelques minutes, pas en une journée.
Vous pouvez augmenter la fiabilité du stockage de sauvegarde. Si nous les stockons maintenant dans un magasin, alors en réduisant le volume des sauvegardes - nous pouvons stocker dans 2-3 magasins et survivre en toute sécurité si l'un d'eux est endommagé.
Comment essayer et commencer à utiliser?
Nous allons à la page gitlab https://gitlab.com/yaroslaff/hashget , l'installons avec une seule commande ( pip3 install hashget[plugins]
) et lisons et pip3 install hashget[plugins]
simplement le démarrage rapide. Je pense que toutes les choses simples à faire - cela prendra 10-15 minutes. Ensuite, vous pouvez essayer de secouer vos machines virtuelles, créer des fichiers de conseil si nécessaire, pour presser plus fort, jouer avec des pools, une base de données de hachage locale et un serveur de hachage, si cela est intéressant, et voir le lendemain quelle sera la taille de la sauvegarde incrémentielle par rapport à hier.
Restic + HashGet
(Ce chapitre a été ajouté plus tard. Merci aux commentateurs pour leurs critiques et leur motivation.)
Il existe un bon outil pratique pour les sauvegardes - restic . Il peut également effectuer la déduplication, mais uniquement au sein du référentiel, ne peut pas la déduplication externe, ce que hashget fait facilement . Mais en combinaison de restic + hashget , nous parvenons à utiliser les avantages des deux approches!
Préparation (déballer wordpress et indexer):
# wget -q https://wordpress.org/wordpress-5.2.2.tar.gz # hashget --submit https://wordpress.org/wordpress-5.2.2.tar.gz -p my --file wordpress-5.2.2.tar.gz --hashserver # tar -xf wordpress-5.2.2.tar.gz # du -sh wordpress 46M wordpress
Ajout d'un instantané à restic via
# hashget -X exclude-list --prepack wordpress --hashserver Saved: 1468 files, 1 pkgs, size: 40.5M. Download: 10.7M # restic --exclude-file exclude-list backup wordpress password is correct scan [/tmp/wp/wordpress] scanned 193 directories, 367 files in 0:02 [0:04] 100.00% 700.829 KiB / 700.829 KiB 560 / 560 items 0 errors ETA 0:00 duration: 0:04 snapshot 76b54230 saved # du -sh /tmp/restic-repo/ 2,1M /tmp/restic-repo/
À ce stade, nous avons ajouté un instantané de catalogue (40+ Mo) et la taille du référentiel n'a augmenté que de 1 Mo.
La récupération se fait par deux commandes:
# restic restore 76b54230 -t unpacked password is correct restoring <Snapshot 76b54230 of [/tmp/wp/wordpress] at 2019-06-19 04:30:55.760618336 +0700 +07 by root@braconnier> to unpacked # hashget -u unpacked/wordpress/ --hashserver Recovered 1468/1468 files 40.5M bytes (0 downloaded, 0 from pool, 10.7M cached) in 1.56s