Cet article portera sur un logiciel de sauvegarde qui, en divisant le flux de données en composants distincts (morceaux), forme un référentiel.
Les composants du référentiel peuvent être davantage compressés et chiffrés et, plus important encore, lors de processus de sauvegarde répétés, réutilisés.
Une copie de sauvegarde dans un tel référentiel est une chaîne nommée de composants connectés les uns aux autres, par exemple sur la base de diverses fonctions de hachage.
Il existe plusieurs solutions similaires, je me concentrerai sur 3 : zbackup, borgbackup et restic.
Résultats attendus
Puisque tous les candidats exigent la création d’un dépôt d’une manière ou d’une autre, l’un des facteurs les plus importants sera d’estimer la taille du dépôt. Idéalement, sa taille ne devrait pas dépasser 13 Go selon la méthodologie acceptée, voire moins - sous réserve d'une bonne optimisation.
Il est également hautement souhaitable de pouvoir créer des copies de sauvegarde de fichiers directement, sans utiliser d'archiveurs comme tar, ainsi que de travailler avec ssh/sftp sans outils supplémentaires comme rsync et sshfs.
Comportement lors de la création de sauvegardes :
- La taille du référentiel sera égale ou inférieure à la taille des modifications.
- Une charge CPU importante est attendue lors de l'utilisation de la compression et/ou du chiffrement, et une charge réseau et disque assez élevée est probable si le processus d'archivage et/ou de chiffrement est exécuté sur un serveur de stockage de sauvegarde.
- Si le référentiel est endommagé, une erreur retardée est probable à la fois lors de la création de nouvelles sauvegardes et lors de la tentative de restauration. Il est nécessaire de prévoir des mesures supplémentaires pour garantir l'intégrité du référentiel ou d'utiliser des outils intégrés pour vérifier son intégrité.
Travailler avec tar est pris comme valeur de référence, comme cela a été montré dans l'un des articles précédents.
Test de zbackup
Le mécanisme général de zbackup est que le programme trouve dans le flux de données d'entrée des zones contenant les mêmes données, puis les compresse et les crypte éventuellement, en enregistrant chaque zone une seule fois.
La déduplication utilise une fonction de hachage en anneau de 64 bits avec une fenêtre glissante pour vérifier les correspondances octet par octet par rapport aux blocs de données existants (de la même manière que rsync l'implémente).
Lzma et lzo multithread sont utilisés pour la compression et aes pour le cryptage. Les dernières versions ont la possibilité de supprimer ultérieurement les anciennes données du référentiel.
Le programme est écrit en C++ avec des dépendances minimales. L'auteur s'est apparemment inspiré de la méthode Unix, de sorte que le programme accepte les données sur stdin lors de la création de sauvegardes, produisant un flux de données similaire sur stdout lors de la restauration. Ainsi, zbackup peut être utilisé comme un très bon « élément de base » lors de l’écriture de vos propres solutions de sauvegarde. Par exemple, l'auteur de l'article utilise ce programme comme principal outil de sauvegarde pour les machines domestiques depuis environ 2014.
Le flux de données sera un tar normal, sauf indication contraire.
Voyons quels sont les résultats :
Le travail a été vérifié selon 2 options :
- un référentiel est créé et zbackup est lancé sur le serveur avec les données sources, puis le contenu du référentiel est transféré vers le serveur de stockage de sauvegarde.
- un référentiel est créé sur le serveur de stockage de sauvegarde, zbackup est lancé via ssh sur le serveur de stockage de sauvegarde et les données lui sont envoyées via un tube.
Les résultats de la première option étaient les suivants : 43 m11s - lors de l'utilisation d'un référentiel non chiffré et du compresseur lzma, 19 m13s - lors du remplacement du compresseur par lzo.
La charge sur le serveur avec les données d'origine était la suivante (un exemple avec lzma est montré ; avec lzo, il y avait à peu près la même image, mais la part de rsync était d'environ un quart du temps) :
Il est clair qu’un tel processus de sauvegarde ne convient que pour des modifications relativement rares et mineures. Il est également fortement conseillé de limiter zbackup à 1 thread, sinon la charge CPU sera très élevée, car Le programme fonctionne très bien dans plusieurs threads. La charge sur le disque était faible, ce qui, en général, ne serait pas perceptible avec un sous-système de disque moderne basé sur SSD. Vous pouvez également voir clairement le début du processus de synchronisation des données du référentiel sur un serveur distant ; la vitesse de fonctionnement est comparable à celle d'un rsync classique et dépend des performances du sous-système de disque du serveur de stockage de sauvegarde. L'inconvénient de cette approche est le stockage d'un référentiel local et, par conséquent, la duplication des données.
Plus intéressante et applicable en pratique est la deuxième option, qui consiste à exécuter zbackup directement sur le serveur de stockage de sauvegarde.
Dans un premier temps, nous allons tester le fonctionnement sans utiliser de chiffrement avec le compresseur lzma :
Durée d'exécution de chaque test :
Lancement 1
Lancement 2
Lancement 3
39m45s
40m20s
40m3s
7m36s
8m3s
7m48s
15m35s
15m48s
15m38s
Si vous activez le chiffrement via aes, les résultats sont assez proches :
Temps de fonctionnement sur les mêmes données, avec cryptage :
Lancement 1
Lancement 2
Lancement 3
43m40s
44m12s
44m3s
8m3s
8m15s
8m12s
15m0s
15m40s
15m25s
Si le chiffrement est combiné avec la compression utilisant lzo, cela ressemble à ceci :
Heures d'ouverture:
Lancement 1
Lancement 2
Lancement 3
18m2s
18m15s
18m12s
5m13s
5m24s
5m20s
8m48s
9m3s
8m51s
La taille du référentiel résultant était relativement la même, soit 13 Go. Cela signifie que la déduplication fonctionne correctement. De plus, sur des données déjà compressées, l'utilisation de lzo donne un effet notable : en termes de temps de fonctionnement total, zbackup se rapproche de la duplicité/duplication, mais est en retard de 2 à 5 fois par rapport à ceux basés sur librsync.
Les avantages sont évidents : économiser de l'espace disque sur le serveur de stockage de sauvegarde. Quant aux outils de vérification du référentiel, l'auteur de zbackup ne les fournit pas, il est recommandé d'utiliser une baie de disques ou un fournisseur cloud tolérant aux pannes.
Dans l'ensemble, une très bonne impression, malgré le fait que le projet est au point mort depuis environ 3 ans (la dernière demande de fonctionnalité remonte à environ un an, mais sans réponse).
Tester Borgbackup
Borgbackup est un fork of attic, un autre système similaire à zbackup. Écrit en python, il possède une liste de fonctionnalités similaires à zbackup, mais peut en outre :
- Monter les sauvegardes via un fusible
- Vérifier le contenu du référentiel
- Travailler en mode client-serveur
- Utilisez divers compresseurs pour les données, ainsi que la détermination heuristique du type de fichier lors de sa compression.
- 2 options de cryptage, aes et blake
- Outil intégré pour
contrôles de performances
borgbackup benchmark crud ssh://backup_server/repo/path local_dir
Les résultats étaient les suivants :
CZ-BIG 96.51 Mo/s (10 100.00 Mo de fichiers tout à zéro : 10.36 s)
RZ-BIG 57.22 Mo/s (10 100.00 Mo de fichiers tout à zéro : 17.48 s)
UZ-BIG 253.63 Mo/s (10 100.00 Mo de fichiers tout à zéro : 3.94 s)
DZ-BIG 351.06 Mo/s (10 100.00 Mo de fichiers tout à zéro : 2.85 s)
CR-BIG 34.30 Mo/s (10 100.00 Mo de fichiers aléatoires : 29.15 s)
RR-BIG 60.69 Mo/s (10 100.00 Mo de fichiers aléatoires : 16.48 s)
UR-BIG 311.06 Mo/s (10 100.00 Mo de fichiers aléatoires : 3.21 s)
DR-BIG 72.63 Mo/s (10 100.00 Mo de fichiers aléatoires : 13.77 s)
CZ-MOYEN 108.59 Mo/s (1000 XNUMX 1.00 Mo de fichiers tout à zéro : 9.21 s)
RZ-MOYEN 76.16 Mo/s (1000 XNUMX 1.00 Mo de fichiers tout à zéro : 13.13 s)
UZ-MEDIUM 331.27 Mo/s (1000 XNUMX 1.00 Mo de fichiers tout à zéro : 3.02 s)
DZ-MOYEN 387.36 Mo/s (1000 XNUMX 1.00 Mo de fichiers tout à zéro : 2.58 s)
CR-MOYEN 37.80 Mo/s (1000 XNUMX 1.00 Mo de fichiers aléatoires : 26.45 s)
RR-MOYEN 68.90 Mo/s (1000 XNUMX 1.00 Mo de fichiers aléatoires : 14.51 s)
UR-MOYEN 347.24 Mo/s (1000 XNUMX 1.00 Mo de fichiers aléatoires : 2.88 s)
DR-MEDIUM 48.80 Mo/s (1000 XNUMX 1.00 Mo de fichiers aléatoires : 20.49 s)
CZ-PETIT 11.72 Mo/s (10000 XNUMX Fichiers tout à zéro de 10.00 Ko : 8.53 s)
RZ-PETIT 32.57 Mo/s (10000 XNUMX Fichiers tout à zéro de 10.00 Ko : 3.07 s)
UZ-PETIT 19.37 Mo/s (10000 XNUMX Fichiers tout à zéro de 10.00 Ko : 5.16 s)
DZ-PETIT 33.71 Mo/s (10000 XNUMX Fichiers tout à zéro de 10.00 Ko : 2.97 s)
CR-SMALL 6.85 Mo/s (10000 XNUMX Fichiers aléatoires de 10.00 Ko : 14.60 s)
RR-PETIT 31.27 Mo/s (10000 XNUMX Fichiers aléatoires de 10.00 Ko : 3.20 s)
UR-SMALL 12.28 Mo/s (10000 XNUMX Fichiers aléatoires de 10.00 Ko : 8.14 s)
DR-SMALL 18.78 Mo/s (10000 XNUMX Fichiers aléatoires de 10.00 Ko : 5.32 s)
Lors des tests, des heuristiques de compression seront utilisées pour déterminer le type de fichier (compression automatique), et les résultats seront les suivants :
Tout d'abord, vérifions comment cela fonctionne sans cryptage :
Heures d'ouverture:
Lancement 1
Lancement 2
Lancement 3
4m6s
4m10s
4m5s
56s
58s
54s
1m26s
1m34s
1m30s
Si vous activez l'autorisation du référentiel (mode authentifié), les résultats seront proches :
Heures d'ouverture:
Lancement 1
Lancement 2
Lancement 3
4m11s
4m20s
4m12s
1m0s
1m3s
1m2s
1m30s
1m34s
1m31s
Lorsque le cryptage aes a été activé, les résultats ne se sont pas beaucoup détériorés :
Lancement 1
Lancement 2
Lancement 3
4m55s
5m2s
4m58s
1m0s
1m2s
1m0s
1m49s
1m50s
1m50s
Et si vous changez aes en Blake, la situation s'améliorera complètement :
Heures d'ouverture:
Lancement 1
Lancement 2
Lancement 3
4m33s
4m43s
4m40s
59s
1m0s
1m0s
1m38s
1m43s
1m40s
Comme dans le cas de zbackup, la taille du référentiel était de 13 Go et même un peu moins, ce qui est généralement attendu. J'ai été très satisfait du temps d'exécution, il est comparable aux solutions basées sur librsync, offrant des capacités beaucoup plus larges. J'ai également été satisfait de la possibilité de définir divers paramètres via des variables d'environnement, ce qui donne un très sérieux avantage lors de l'utilisation de borgbackup en mode automatique. J'ai également été satisfait de la charge lors de la sauvegarde : à en juger par la charge du processeur, borgbackup fonctionne dans 1 thread.
Il n'y avait pas d'inconvénients particuliers lors de son utilisation.
test restique
Malgré le fait que Restic soit une solution relativement nouvelle (les 2 premiers candidats étaient connus en 2013 et avant), elle présente d'assez bonnes caractéristiques. Écrit en Go.
Par rapport à zbackup, il donne en plus :
- Vérification de l'intégrité du référentiel (y compris la vérification de certaines parties).
- Une énorme liste de protocoles et de fournisseurs pris en charge pour le stockage des sauvegardes, ainsi que la prise en charge de rclone - rsync pour les solutions cloud.
- Comparaison de 2 sauvegardes entre elles.
- Montage du référentiel via fusible.
En général, la liste des fonctionnalités est assez proche de celle de borgbackup, à certains endroits plus, à d'autres moins. L'une des fonctionnalités est qu'il n'existe aucun moyen de désactiver le cryptage et que les copies de sauvegarde seront donc toujours cryptées. Voyons en pratique ce qui peut être extrait de ce logiciel :
Les résultats étaient les suivants :
Heures d'ouverture:
Lancement 1
Lancement 2
Lancement 3
5m25s
5m50s
5m38s
35s
38s
36s
1m54s
2m2s
1m58s
Les résultats de performances sont également comparables aux solutions basées sur rsync et, en général, très proches de borgbackup, mais la charge CPU est plus élevée (plusieurs threads en cours d'exécution) et en dents de scie.
Très probablement, le programme est limité par les performances du sous-système de disque sur le serveur de stockage de données, comme c'était déjà le cas avec rsync. La taille du référentiel était de 13 Go, tout comme zbackup ou borgbackup, il n'y avait aucun inconvénient évident lors de l'utilisation de cette solution.
résultats
En fait, tous les candidats ont obtenu des résultats similaires, mais à des prix différents. Borgbackup a le mieux fonctionné, restic était un peu plus lent, zbackup ne vaut probablement pas la peine de commencer à l'utiliser,
et s'il est déjà utilisé, essayez de le changer en borgbackup ou restic.
résultats
La solution la plus prometteuse semble être restic, car... c'est lui qui a le meilleur rapport capacités/vitesse de fonctionnement, mais ne nous précipitons pas vers des conclusions générales pour l'instant.
Borgbackup n'est fondamentalement pas pire, mais zbackup est probablement mieux remplacé. Certes, zbackup peut toujours être utilisé pour garantir le fonctionnement de la règle 3-2-1. Par exemple, en plus des fonctionnalités de sauvegarde basées sur (lib)rsync.
annonce
Sauvegarde Partie 5 : Tester la sauvegarde bacula et veeam pour Linux
Sauvegarde Partie 6 : Comparaison des outils de sauvegarde
Sauvegarde Partie 7 : Conclusions
Posté par: Pavel Demkovitch
Source: habr.com