Réduisez les sauvegardes de 99.5 % avec hashget

hashget - c'est gratuit, open source déduplicateur est un utilitaire similaire à un archiveur qui vous permet de réduire considérablement la taille des sauvegardes, ainsi que d'organiser des schémas de sauvegarde incrémentielles et différentielles et bien plus encore.

Il s'agit d'un article de présentation pour décrire les fonctionnalités. L'utilisation réelle de hashget (assez simple) est décrite dans README projet et documentation wiki.

Comparaison

Selon la loi du genre, je commencerai tout de suite par l'intrigue - en comparant les résultats :

Échantillon de données
taille déballée
.tar.gz
hashget.tar.gz

WordPress-5.1.1
43 Mb
11 Mo (26%)
155 Ko ( 0.3% )

Noyau Linux 5.0.4
934 Mb
161 Mo (20%)
4.7 Mo ( 0.5% )

Machine virtuelle Debian 9 (LAMP) LXC
724 Mb
165 Mo (23%)
4.1 Mo ( 0.5% )

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é par le sentiment que je faisais quelque chose de mal. Pourquoi est-ce que je reçois une sauvegarde volumineuse du système, où ma créativité inestimable et impérissable est un index.html d'une seule ligne avec le texte « Bonjour tout le monde » ?

Pourquoi y a-t-il un fichier /usr/sbin/mysqld de 16 Mo dans ma sauvegarde ? Est-il vraiment possible que dans ce monde j'aie l'honneur de conserver ce dossier important, et si j'échoue, il sera perdu pour l'humanité ? Très probablement non. Il est stocké sur des serveurs Debian hautement fiables (dont la fiabilité et la disponibilité ne peuvent être comparées à ce que je peux fournir), ainsi que dans des sauvegardes (des millions d'entre eux) d'autres administrateurs. Avons-nous vraiment besoin de créer plus de 10 000 000 1ères copies de ce fichier important pour améliorer la fiabilité ?

Généralement hashget et résout ce problème. Une fois emballé, il crée une très petite sauvegarde. Au déballage - un système complètement déballé, semblable à ce qu'il serait si tar -c / tar -x. (En d’autres termes, il s’agit d’un emballage sans perte)

Comment fonctionne hashget

hashget a les concepts de Package et HashPackage, avec leur aide, il effectue la déduplication.

Emballage Papier (sac plastique). Fichier (généralement une archive .deb ou .tar.gz) qui peut être téléchargé en toute sécurité depuis Internet et à partir duquel un ou plusieurs fichiers peuvent être obtenus.

Paquet de hachage — un petit fichier JSON représentant un package, comprenant l'URL du package et les sommes de hachage (sha256) des fichiers qu'il contient. Par exemple, pour un package mariadb-server-core de 5 Mo, la taille du paquet de hachage n'est que de 6 kilo-octets. Environ mille fois moins.

Déduplication — créer une archive sans fichiers en double (si le déduplicateur sait où le package d'origine peut être téléchargé, il réduit les doublons de l'archive).

Emballage

Lors du compactage, tous les fichiers du répertoire en cours de compactage sont analysés, leurs sommes de hachage sont calculées et si la somme est trouvée dans l'un des HashPackages connus, les métadonnées sur le fichier (nom, hachage, droits d'accès, etc.) sont enregistrées. dans un fichier spécial .hashget-restore.json, qui sera également inclus dans l'archive.

Dans le cas le plus simple, l'emballage lui-même n'a pas l'air 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 tar :

tar -xf mybackup.tar.gz -C /path/to/data

puis restaurez depuis le réseau :

hashget -u /path/to/data

Lors de la restauration, 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 installant dans les chemins requis, avec le propriétaire/groupe/autorisations requis.

Des choses plus difficiles

Ce qui est décrit ci-dessus est déjà suffisant pour ceux qui « veulent que ce soit comme tar, mais pour emballer ma Debian dans 4 mégaoctets ». Regardons des choses plus complexes plus tard.

Indexation

Si hashget n’avait pas un seul HashPackage, il ne pourrait tout simplement pas 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 paquet de hachage nécessaire, il y a une étape indexage (il s'exécute automatiquement avec la commande --pack) Et heuristique. Lors de l'indexation, hashget « alimente » chaque fichier trouvé vers toutes les heuristiques disponibles qui s'y intéressent. L'heuristique peut ensuite indexer n'importe quel package pour créer un HashPackage.

Par exemple, l'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 (aucun HashPackage n'a été créé pour eux), les télécharge et les indexe. Le résultat est un très bel effet : hashget dédupliquera toujours efficacement les systèmes d'exploitation Debian, même s'ils disposent des derniers paquets.

Fichiers d'indices

Si votre réseau utilise certains de vos packages propriétaires ou un package public qui n'est pas inclus dans l'heuristique hashget, vous pouvez y ajouter un simple fichier d'indication hashget-hint.json comme ceci :

{
    "project": "wordpress.org",
    "url": "https://ru.wordpress.org/wordpress-5.1.1-ru_RU.zip"
}

Ensuite, chaque fois qu'une archive est créée, le package sera indexé (si cela ne l'a pas déjà été) et les fichiers du package seront dédupliqués de l'archive. Aucune programmation n'est nécessaire, tout peut être fait depuis vim et sauvegardé dans chaque sauvegarde. Veuillez noter que grâce à l'approche de somme de hachage, si certains fichiers du package sont modifiés localement (par exemple, un fichier de configuration est modifié), alors les fichiers modifiés seront enregistrés dans l'archive « tels quels » et ne seront pas tronqués.

Si certains de vos propres packages sont mis à jour périodiquement, mais que les modifications ne sont pas très importantes, vous ne pouvez faire allusion qu'aux versions majeures. Par exemple, dans la version 1.0, ils ont fait un indice pointant vers 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 l'indice n'a pas été mis à jour. C'est bon. Seuls les fichiers correspondant à la version 1.0 (pouvant être restaurés vers) sont dédupliqués.

L'heuristique qui traite le fichier d'indices est un bon exemple pour comprendre le mécanisme interne du fonctionnement de l'heuristique. Il traite uniquement les fichiers hashget-hint.json (ou .hashget-hint.json avec un point) et ignore tous les autres. À partir de ce fichier, il détermine quelle URL du package doit être indexée et hashget l'indexe (si ce n'est pas déjà fait)

Serveur de hachage

Il serait assez fastidieux d'effectuer une indexation complète lors de la création de sauvegardes. Pour ce faire, vous devez télécharger chaque package, le décompresser et l'indexer. Par conséquent, hashget utilise un schéma avec Serveur de hachage. Lorsqu'un paquet Debian installé est détecté, s'il n'est pas trouvé 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 package (et le télécharge sur hashserver, afin que hashserver le fournisse à l'avenir).

HashServer est un élément facultatif du schéma, non critique, il sert uniquement à accélérer et à réduire la charge sur les référentiels. Facilement désactivé (en option --hashserver sans paramètres). De plus, vous pouvez facilement créez votre propre serveur de hachage.

Sauvegardes incrémentielles et différentielles, obsolescence programmée

hashget il est très facile de faire un diagramme sauvegardes incrémentielles et différentielles. Pourquoi n'indexons-nous pas notre sauvegarde elle-même (avec tous nos fichiers uniques) ? Une équipe --submit et tu as fini! 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 se peut que lors de la restauration, nous devions extraire toutes les sauvegardes hashget de tout l'historique (si chacune contient au moins un fichier unique). Il existe un mécanisme pour cela obsolescence programmée des sauvegardes. Lors de l'indexation, vous pouvez spécifier la date d'expiration de HashPackage --expires 2019-06-01, et après cette date (à partir de 00h00), il ne sera plus utilisé. 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 qui sont/seront pourries à ce moment-là ou à n'importe quelle date).

Par exemple, si nous effectuons une sauvegarde complète le 1er et que nous l'indexons avec une durée de vie jusqu'à la fin du mois, nous obtiendrons un schéma de sauvegarde différentielle.

Si nous indexons les nouvelles sauvegardes de la même manière, nous obtiendrons un schéma de sauvegardes incrémentielles.

Contrairement aux schémas traditionnels, hashget vous permet d'utiliser plusieurs sources sous-jacentes. La sauvegarde sera réduite à la fois en réduisant les fichiers des sauvegardes précédentes (le cas échéant) et par les 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 utilise une autre distribution, on peut simplement faire une fois une sauvegarde complète avec tous les paquets, puis s'appuyer dessus (en désactivant l'heuristique). Désormais, si tous les serveurs de nos distributions s'avèrent indisponibles (sur l'Internet souvenir ou lors d'une apocalypse zombie), mais que nos sauvegardes sont en ordre, nous pouvons récupérer à partir de n'importe quelle sauvegarde courte diff qui repose uniquement sur nos sauvegardes antérieures. .

Hashget s'appuie uniquement sur des sources de récupération fiables, à VOTRE discrétion. Ceux que vous considérez comme fiables seront utilisés.

FilePool et Glacier

Mécanisme Pool de fichiers vous permet de ne pas contacter constamment des serveurs externes pour télécharger des packages, mais d'utiliser des packages à partir d'un annuaire 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 vous suffit de créer un répertoire et d'y placer des fichiers, hashget trouvera lui-même ce dont il a besoin en utilisant les hachages. 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 constitué de fichiers statiques, donc n'importe quel simple serveur Web peut le servir, la charge sur le serveur est presque nulle.

Grâce à FilePool, vous pouvez utiliser non seulement les ressources http(s) comme ressources de base, mais aussi par exemple,, Glacier Amazonien.

Après avoir téléchargé la sauvegarde sur le glacier, nous obtenons son ID de téléchargement et 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) seront basées sur cette sauvegarde et seront plus courtes. Après avoir décompressé le diffbackup par tar, nous pouvons voir sur quelles ressources il repose :

hashget --info /tmp/unpacked/ list

et utilisez simplement un script shell pour télécharger tous ces fichiers de Glacier vers 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 pour les sauvegardes (si vous les stockez quelque part dans le cloud contre de l'argent). Peut-être beaucoup, beaucoup moins.

Mais ce n'est pas la seule chose. La quantité se transforme en qualité. Vous pouvez l'utiliser pour obtenir une mise à niveau de haute qualité de votre système de sauvegarde. Par exemple, comme nos sauvegardes sont désormais plus courtes, nous pouvons effectuer non plus des sauvegardes mensuelles, mais quotidiennes. Conservez-les non pas six mois, comme avant, mais 5 ans. Auparavant, vous le stockiez dans un stockage « froid » lent mais bon marché (Glacier), vous pouvez désormais le stocker dans un stockage chaud, d'où vous pouvez toujours télécharger rapidement une sauvegarde et la restaurer en quelques minutes, et non en une journée.

Vous pouvez augmenter la fiabilité du stockage de sauvegarde. Si nous les stockons actuellement dans une seule installation de stockage, alors en réduisant le volume des sauvegardes, nous pourrons les stocker dans 2-3 installations de stockage et survivre sans douleur si l'une d'entre elles est endommagée.

Comment essayer et commencer à utiliser ?

Aller sur la page gitlab https://gitlab.com/yaroslaff/hashget, installez avec une seule commande (pip3 install hashget[plugins]) et lisez et exécutez simplement le démarrage rapide. Je pense que cela prendra 10 à 15 minutes pour faire toutes les choses simples. Ensuite, vous pouvez essayer de compresser vos machines virtuelles, créer des fichiers d'indices si nécessaire pour renforcer la compression, jouer avec des pools, une base de données de hachage locale et un serveur de hachage si vous êtes intéressé, et voir le lendemain quelle est la taille de la sauvegarde incrémentielle. sera au-dessus de celui d'hier.

Source: habr.com

Ajouter un commentaire