Cet article examinera les outils logiciels de sauvegarde qui, en fragmentant le flux de données en composants distincts (chunks), forment un référentiel.
Les composants du référentiel peuvent également être compressés et chiffrés, et surtout, lors des processus de sauvegarde répétés, être réutilisés.
Une sauvegarde dans un tel référentiel est une chaîne nommée de composants liés entre eux, par exemple, sur la base de différentes fonctions de hachage.
Il existe plusieurs solutions similaires, je vais m'arrêter sur 3 : zbackup, borgbackup et restic.
Résultats attendus
Étant donné que tous les candidats nécessitent d'une manière ou d'une autre la création d'un référentiel, l'un des facteurs les plus importants sera l'évaluation de la taille du référentiel. Dans l'idéal, sa taille ne devrait pas dépasser 13 Go selon la méthode adoptée, voire moins, à condition d'une bonne optimisation.
Il est également fortement souhaitable de pouvoir créer des sauvegardes 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 à la taille des modifications, ou inférieure.
- On s'attend à une grande charge sur le processeur lors de l'utilisation de la compression et/ou du chiffrement, ainsi qu'à une charge assez importante sur le réseau et le sous-système de stockage, si le processus d'archivage et/ou de chiffrement fonctionne sur le serveur de stockage des sauvegardes.
- Si le référentiel est endommagé, il peut y avoir une erreur différée tant lors de la création de nouvelles sauvegardes que lors de la tentative de restauration. Il est nécessaire de planifier 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é.
La référence est le travail avec tar, comme cela a été montré dans l'un des précédents articles.
Test du zbackup
Le mécanisme général de fonctionnement de zbackup est que le programme trouve dans le flux de données fourni en entrée des zones contenant des données identiques, puis les compresse, les chiffre éventuellement, en conservant chaque zone uniquement une fois.
Pour la déduplication, une fonction de hachage circulaire 64 bits avec une fenêtre glissante est utilisée pour la vérification byte à byte en correspondance avec des blocs de données déjà existants (similaire à ce qui est réalisé dans rsync).
Pour la compression, llzma et lzo sont utilisés en mode multithread, et pour le chiffrement, l'aes. Dans les dernières versions, il est possible de supprimer à l'avenir les anciennes données du dépôt.
Le programme est écrit en C++ avec des dépendances minimales. L'auteur semble s'être inspiré de l'unix-way, car le programme prend des données depuis stdin lors de la création de sauvegardes et fournit un flux de données similaire dans stdout lors de la restauration. Ainsi, zbackup peut être utilisé comme un excellent « bloc » pour écrire ses propres solutions de sauvegarde. Par exemple, pour l'auteur de cet article, ce programme est le principal outil de sauvegarde pour les machines domestiques depuis environ 2014.
Un tar standard sera utilisé comme flux de données, sauf indication contraire.
Voyons quels seront les résultats :
Le test a été effectué dans 2 variantes :
- un dépôt est créé et zbackup est lancé sur le serveur avec les données d'origine, puis le contenu du dépôt est transféré sur le serveur de stockage des sauvegardes.
- un dépôt est créé sur le serveur de stockage des sauvegardes, zbackup est lancé via ssh sur le serveur de stockage des sauvegardes, et les données lui sont transmises via un pipe.
Les résultats de la première variante étaient les suivants : 43m11s — avec un dépôt non chiffré et le compresseur lzma, 19m13s — en remplaçant le compresseur par lzo.
La charge sur le serveur avec les données d'origine était la suivante (exemple avec lzma, avec lzo c'était à peu près la même image, mais la part de rsync était d'environ le quart du temps) :
Il est clair qu'un tel processus de sauvegarde n'est approprié que pour des changements relativement rares et petits. Il est également fortement recommandé de limiter le travail de zbackup à 1 thread, sinon la charge processeur sera très élevée, car le programme peut efficacement fonctionner en plusieurs threads. La charge sur le disque était faible, ce qui, dans l'ensemble, sera imperceptible avec un système de disque moderne basé sur ssd. Il est également clair que le processus de synchronisation des données du dépôt sur un serveur distant est comparable en vitesse à un rsync normal et est limité par les performances du système de disque du serveur de stockage des sauvegardes. Un inconvénient de cette approche est le stockage d'un dépôt local et, par conséquent, la duplication des données.
Le deuxième scénario, qui consiste à lancer zbackup directement sur le serveur de stockage des sauvegardes, est plus intéressant et applicable en pratique.
Pour commencer, nous allons tester le fonctionnement sans utiliser le chiffrement avec le compresseur lzma :
Temps d'exécution de chaque lancement de test :
Lancement 1
Lancement 2
Lancement 3
39m45s
40m20s
40m3s
7m36s
8m3s
7m48s
15m35s
15m48s
15m38s
Lorsque l'on active le chiffrement avec aes, les résultats sont assez similaires :
Temps d'exécution sur les mêmes données, avec chiffrement :
Lancement 1
Lancement 2
Lancement 3
43m40s
44m12s
44m3s
8m3s
8m15s
8m12s
15m0s
15m40s
15m25s
Si le chiffrement est combiné avec la compression lzo, les résultats sont les suivants :
Temps d'exécution :
Lancement 1
Lancement 2
Lancement 3
18m2s
18m15s
18m12s
5m13s
5m24s
5m20s
8m48s
9m3s
8m51s
La taille du dépôt résultant était relativement constante et s'élevait à 13 Go. Cela signifie que la déduplication fonctionne correctement. De plus, l'application de lzma sur des données déjà compressées a un effet significatif, et le temps de traitement total de zbackup se rapproche fortement de duplicity/duplicati, bien qu'il soit encore à la traîne par rapport à ceux basés sur librsync de 2 à 5 fois.
Les avantages sont évidents — économies d'espace disque sur le serveur de stockage des sauvegardes. En ce qui concerne les outils de vérification du dépôt, ils ne sont pas prévus par l'auteur de zbackup, il est recommandé d'utiliser un ensemble de disques tolérant aux pannes ou un fournisseur de services cloud.
Dans l'ensemble, une impression plutôt bonne, malgré le fait que le projet est stagnant depuis environ 3 ans (la dernière demande de fonctionnalité date d'une année, mais sans réponse).
Test de borgbackup
Borgbackup est un fork de attic, un autre système similaire à zbackup. Écrit en python, il a une liste de fonctionnalités similaire à zbackup, mais est capable de :
- Monter des sauvegardes via fuse
- Vérifier le contenu du dépôt
- Fonctionner en mode client-serveur
- Utiliser différents compresseurs pour les données, ainsi qu'une détection heuristique du type de fichier lors de sa compression.
- 2 options de chiffrement : aes et blake
- Outil intégré pour
tester la performance
borgbackup benchmark crud ssh://backup_server/repo/path local_dir
Les résultats sont les suivants :
C-Z-BIG 96.51 MB/s (10 100.00 MB fichiers tous nuls : 10.36s)
R-Z-BIG 57.22 MB/s (10 100.00 MB fichiers tous nuls : 17.48s)
U-Z-BIG 253.63 MB/s (10 100.00 MB fichiers tous nuls : 3.94s)
D-Z-BIG 351.06 MB/s (10 100.00 MB fichiers tous nuls : 2.85s)
C-R-BIG 34.30 MB/s (10 100.00 MB fichiers aléatoires : 29.15s)
R-R-BIG 60.69 MB/s (10 100.00 MB fichiers aléatoires : 16.48s)
U-R-BIG 311.06 MB/s (10 100.00 MB fichiers aléatoires : 3.21s)
D-R-BIG 72.63 MB/s (10 100.00 MB fichiers aléatoires : 13.77s)
C-Z-MEDIUM 108.59 MB/s (1000 1.00 MB fichiers tous nuls : 9.21s)
R-Z-MEDIUM 76.16 MB/s (1000 1.00 MB fichiers tous nuls : 13.13s)
U-Z-MEDIUM 331.27 MB/s (1000 1.00 MB fichiers tous nuls : 3.02s)
D-Z-MEDIUM 387.36 MB/s (1000 1.00 MB fichiers tous nuls : 2.58s)
C-R-MEDIUM 37.80 MB/s (1000 1.00 MB fichiers aléatoires : 26.45s)
R-R-MEDIUM 68.90 MB/s (1000 1.00 MB fichiers aléatoires : 14.51s)
U-R-MEDIUM 347.24 MB/s (1000 1.00 MB fichiers aléatoires : 2.88s)
D-R-MEDIUM 48.80 MB/s (1000 1,00 Mo fichiers aléatoires : 20,49 s)
C-Z-PETIT 11,72 Mo/s (10000 10,00 Ko fichiers tous-zéros : 8,53 s)
R-Z-PETIT 32,57 Mo/s (10000 10,00 Ko fichiers tous-zéros : 3,07 s)
U-Z-PETIT 19,37 Mo/s (10000 10,00 Ko fichiers tous-zéros : 5,16 s)
D-Z-PETIT 33,71 Mo/s (10000 10,00 Ko fichiers tous-zéros : 2,97 s)
C-R-PETIT 6,85 Mo/s (10000 10,00 Ko fichiers aléatoires : 14,60 s)
R-R-PETIT 31,27 Mo/s (10000 10,00 Ko fichiers aléatoires : 3,20 s)
U-R-PETIT 12,28 Mo/s (10000 10,00 Ko fichiers aléatoires : 8,14 s)
D-R-PETIT 18,78 Mo/s (10000 10,00 Ko fichiers aléatoires : 5,32 s)
L'heuristique sera utilisée pour la compression en fonction du type de fichier (compression auto), et les résultats seront les suivants :
Commençons par vérifier le fonctionnement sans chiffrement :
Temps d'exécution :
Lancement 1
Lancement 2
Lancement 3
4m6s
4m10s
4m5s
56s
58s
54s
1m26s
1m34s
1m30s
Si l'authentification du dépôt est activée (mode authentifié), les résultats seront similaires :
Temps d'exécution :
Lancement 1
Lancement 2
Lancement 3
4m11s
4m20s
4m12s
1m0s
1m3s
1m2s
1m30s
1m34s
1m31s
Avec l'activation du chiffrement aes, 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 l'on remplace aes par blake, la situation s'améliore :
Temps d'exécution :
Lancement 1
Lancement 2
Lancement 3
4m33s
4m43s
4m40s
59s
1m0s
1m0s
1m38s
1m43s
1m40s
Comme dans le cas de zbackup, la taille du dépôt était de 13 Go, voire un peu moins, ce qui est globalement attendu. J'ai été particulièrement satisfait du temps de fonctionnement, qui est comparable à des solutions basées sur librsync, offrant beaucoup plus de possibilités. J'ai également été satisfait de la possibilité de définir divers paramètres via des variables d'environnement, ce qui constitue un avantage considérable lors de l'utilisation de borgbackup en mode automatique. De plus, la charge lors de la sauvegarde était raisonnable : étant donné la charge du processeur, borgbackup fonctionne en 1 fil.
Aucun inconvénient majeur n'a été constaté lors de l'utilisation.
Test de restic
Bien que restic soit une solution relativement nouvelle (les deux premières candidates étaient connues depuis 2013 ou plus), elle dispose de caractéristiques assez intéressantes. Écrite en Go.
Comparé à zbackup, elle offre en plus :
- Une vérification de l'intégrité du dépôt (y compris la vérification par parties).
- Une énorme liste de protocoles et de fournisseurs pris en charge pour le stockage des sauvegardes, ainsi que le support de rclone — rsync pour des solutions « cloud ».
- Comparaison de 2 sauvegardes entre elles.
- Montage du dépôt via fuse.
Dans l'ensemble, la liste des fonctionnalités est assez proche de celle de borgbackup, parfois plus étendue, parfois moins. En termes de spécificités, l'absence de possibilité de désactiver le chiffrement signifie que les sauvegardes seront toujours chiffrées. Voyons pratiquement ce que nous pouvons tirer de ce logiciel :
Les résultats étaient les suivants :
Temps d'exécution :
Lancement 1
Lancement 2
Lancement 3
5m25s
5m50s
5m38s
35s
38s
36s
1m54s
2m2s
1m58s
Les résultats sont également comparables à ceux des solutions basées sur rsync et, dans l'ensemble, assez proches de borgbackup, mais la charge CPU est plus élevée (utilisation de plusieurs threads) et irrégulière.
Il est probable que le programme soit limité par les performances du système de stockage sur le serveur, comme cela a été le cas avec rsync. La taille du dépôt était de 13 Go, tout comme pour zbackup ou borgbackup, et aucun inconvénient majeur n'a été constaté avec cette solution.
Résultats
En fait, tous les candidats ont obtenu des performances proches, mais à des prix différents. Borgbackup s'est le mieux comporté, suivi par restic, et il est probablement préférable de ne pas commencer à utiliser zbackup.
Si zbackup est déjà utilisé, il serait judicieux de passer à borgbackup ou restic.
Conclusions
Restic semble être la solution la plus prometteuse, car elle offre le meilleur rapport entre fonctionnalités et rapidité, mais il est encore trop tôt pour tirer des conclusions définitives.
Borgbackup n'est fondamentalement pas inférieur, mais zbackup devrait probablement être remplacé. Cependant, pour respecter la règle 3-2-1, zbackup peut toujours être utilisé, par exemple, en complément des outils de sauvegarde basés sur (lib)rsync.
Annonce
Sauvegarde, partie 5 : Test de bacula et veeam backup for linux
Sauvegarde, partie 6 : Comparaison des outils de sauvegarde
Sauvegarde, partie 7 : Conclusions
Auteur de la publication : Pavel Demkovich
Source : habr.com
