Cet article comparera les outils de sauvegarde, mais il est d'abord essentiel de découvrir comment ils gèrent rapidement et efficacement la récupération des données à partir des sauvegardes.
Pour simplifier la comparaison, la récupération à partir d'une sauvegarde complète sera examinée, d'autant plus que ce mode de fonctionnement est pris en charge par tous les candidats. Pour simplifier, les chiffres sont déjà moyennés (moyenne arithmétique de plusieurs lancements). Les résultats seront présentés dans un tableau, qui contiendra également des informations sur les fonctionnalités : présence d'une interface web, simplicité de configuration et d'utilisation, capacité d'automatisation, disponibilité de diverses fonctionnalités supplémentaires (par exemple, vérification de l'intégrité des données), etc. Les graphiques montreront la charge du serveur sur lequel les données seront appliquées (et non sur le serveur de stockage des sauvegardes).
Récupération des données
Comme point de référence, rsync et tar seront utilisés, car les scripts les plus simples pour effectuer des sauvegardes.
Rsync a complété l'ensemble de données de test en 4 minutes et 28 secondes, montrant
une telle charge
Le processus de récupération était limité par la sous-système de stockage du serveur de sauvegarde (graphique en dents de scie). Il est également évident que l'un des cœurs était très sollicité sans aucun problème particulier (faible iowait et softirq — aucun problème avec le disque et le réseau, respectivement). Comme les deux autres programmes, à savoir rdiff-backup et rsnapshot, sont basés sur rsync et proposent également rsync comme outil de récupération, ils auront un profil de charge et un temps de récupération de sauvegarde similaires.
Tar a été légèrement plus rapide, en
2 minutes et 43 secondes :
La charge complète du système était en moyenne 20% plus élevée en raison de l'augmentation des softirq — les frais généraux de la sous-système réseau ont augmenté.
Si l'archive est compressée en plus, le temps de récupération passe à 3 minutes et 19 secondes avec
une telle charge sur le serveur principal (décompression du côté du serveur principal) :
Le processus de décompression utilise les deux cœurs du processeur, car deux processus sont en cours. Dans l'ensemble, c'est un résultat attendu. Un résultat comparable (3 minutes et 20 secondes) a également été obtenu lors de l'exécution de gzip côté serveur avec des sauvegardes, le profil de charge sur le serveur principal étant très similaire à celui de l'exécution de tar sans le compresseur gzip (voir le graphique précédent).
Dans rdiff-backup la dernière sauvegarde effectuée peut être synchronisée à l'aide du traditionnel rsync (les résultats seront similaires), mais les sauvegardes plus anciennes doivent tout de même être restaurées avec le programme rdiff-backup, qui a réussi à effectuer la restauration en 17 minutes et 17 secondes, montrant
une telle charge :
C'était peut-être prévu, en tout cas pour limiter la vitesse, les auteurs . Le processus de restauration de la sauvegarde prend un peu moins de la moitié d'un cœur, avec une performance proportionnellement comparable (c'est-à-dire 2 à 5 fois plus lent) en termes de disque et de réseau avec rsync.
Rsnapshot suggère d'utiliser le traditionnel rsync pour la restauration, donc ses résultats seront similaires. Dans l'ensemble, c'est ce qui s'est passé.
Burp a réussi à restaurer la sauvegarde en 7 minutes et 2 secondes avec
une telle charge :
Cela a fonctionné assez rapidement et, au moins, c'est beaucoup plus pratique que rsync pur : il n'est pas nécessaire de se souvenir de divers drapeaux, interface cli simple et intuitive, support intégré pour plusieurs sauvegardes, bien qu'il soit environ deux fois plus lent. Si les données doivent être restaurées à partir de la dernière sauvegarde effectuée, vous pouvez utiliser rsync, avec quelques réserves.
Un résultat de vitesse et de charge similaire a montré le programme BackupPC lors de l'activation du mode de transfert rsync, ayant restauré la sauvegarde en
7 minutes et 42 secondes :
En revanche, en mode de transfert de données avec tar, BackupPC a été moins performant : en 12 minutes et 15 secondes, la charge processeur était globalement plus faible
d'environ une fois et demie :
Duplicity sans chiffrement a montré de légèrement meilleurs résultats, réussissant à restaurer une sauvegarde en 10 minutes et 58 secondes. Si le chiffrement avec gpg est activé, le temps de restauration augmente à 15 minutes et 3 secondes. De plus, lors de la création d'un dépôt pour stocker les copies, il est possible de spécifier la taille de l'archive qui sera utilisée pour segmenter le flux de données entrantes. En général, sur des disques durs classiques, en raison du fonctionnement à un seul fil, il n'y a pas de différence significative. Cela pourrait apparaître avec différentes tailles de blocs lors de l'utilisation de stockages hybrides. La charge sur le serveur principal lors de la restauration était la suivante :
sans chiffrement
avec chiffrement
Duplicati a montré une vitesse de restauration comparable, réussissant en 13 minutes et 45 secondes. Environ 5 minutes supplémentaires ont été consacrées à la vérification de l'intégrité des données restaurées (pour un total d'environ 19 minutes). La charge était alors
assez élevée :
Lorsque le chiffrement aes a été activé par des moyens internes, le temps de restauration a été de 21 minutes et 40 secondes, et la charge processeur était maximale (les deux cœurs !) pendant la restauration ; lors de la vérification des données, seul un fil était actif, occupant un cœur de processeur. La vérification des données après restauration a duré les mêmes 5 minutes (soit un total de près de 27 minutes).
Résultat
Duplicati a été légèrement plus rapide pour la restauration en utilisant le programme externe gpg pour le chiffrement, mais en général, les différences par rapport au mode précédent sont minimales. Le temps de fonctionnement a été de 16 minutes et 30 secondes, avec une vérification des données de 6 minutes. La charge était
la suivante :
AMANDA, utilisant tar, a réussi en 2 minutes et 49 secondes, ce qui, en principe, est très proche de tar ordinaire. La charge sur le système est essentiellement
la même :
Lors de la restauration de la sauvegarde à l'aide de zbackup les résultats suivants ont été obtenus :
chiffrement, compression lzma
Temps de fonctionnement 11 minutes et 8 secondes
chiffrement aes, compression lzma
Temps de fonctionnement 14 minutes
chiffrement aes, compression lzo
Temps de fonctionnement 6 minutes, 19 secondes
Dans l'ensemble, ça ne va pas trop mal. Tout dépend de la vitesse du processeur sur le serveur de sauvegarde, ce qui se voit assez clairement par le temps de fonctionnement du programme avec différents compresseurs. Du côté du serveur de sauvegarde, on a utilisé le tar classique, donc si on compare, la restauration s'effectue trois fois plus lentement. Il serait peut-être utile de vérifier le fonctionnement en mode multithread, avec un nombre de threads supérieur à deux.
BorgBackup en mode sans chiffrement, a été légèrement plus lent que tar, prenant 2 minutes 45 secondes, cependant, contrairement à tar, la possibilité de dédupliquer le référentiel est apparue. La charge résultante était
la suivante :
Si l'on active le chiffrement basé sur blake, la vitesse de restauration de la sauvegarde ralentit un peu. Le temps de restauration dans ce mode est de 3 minutes 19 secondes, et la charge est devenue
la suivante :
Le chiffrement aes fonctionne un peu plus lentement, le temps de restauration est de 3 minutes 23 secondes, la charge ne
a pas particulièrement changé :
Comme Borg peut fonctionner en mode multithread, la charge du processeur est maximum, et en activant des fonctions supplémentaires, le temps de traitement augmente simplement. Il semble qu'il faudrait explorer le multithreading de manière similaire à zbackup.
Restic a réussi à restaurer légèrement plus lentement, le temps de travail a été de 4 minutes 28 secondes. La charge à ce moment-là était
donc :
Il semblerait que le processus de restauration fonctionne sur plusieurs fils, mais l'efficacité n'est pas aussi élevée que celle de BorgBackup, bien que comparable en temps avec le rsync classique.
Avec UrBackup a réussi à restaurer les données en 8 minutes 19 secondes, la charge à ce moment-là était
la suivante :
On voit toujours une charge pas très élevée, même inférieure à celle de tar. Quelques pics occasionnels, mais pas plus de charge qu'un seul cœur.
Choix et justification des critères de comparaison
Comme mentionné dans l'un des articles précédents, le système de sauvegarde doit répondre aux critères suivants :
- Simplicité d'utilisation
- Polyvalence
- Stabilité
- Rapidité
Il vaut la peine d'examiner chaque point séparément de manière plus détaillée.
Simplicité d'utilisation
Le mieux, c'est d'avoir un seul bouton « Tout faire correctement », mais si l'on revient aux programmes réels, le principe de fonctionnement le plus pratique est celui qui est habituel et standard.
La plupart des utilisateurs préféreront probablement ne pas avoir à mémoriser une multitude de clés pour le CLI, à configurer de nombreuses options souvent peu compréhensibles via le web ou l'interface TUI, ou à établir des alertes en cas d'échec. Cela inclut également la possibilité d'intégrer facilement une solution de sauvegarde dans l'infrastructure existante, ainsi que l'automatisation du processus de sauvegarde. On peut également mentionner l'installation via un gestionnaire de paquets, ou en une ou deux commandes telles que "télécharger et décompresser". curl lien | sudo bash — méthode complexe, car il faut vérifier ce qui arrive par le lien.
Par exemple, parmi les candidats examinés, les solutions simples incluent burp, rdiff-backup et restic, qui disposent de clés mnémotechniques pour différents modes de fonctionnement. Des solutions un peu plus complexes incluent borg et duplicity. La plus complexe était AMANDA. Les autres se situent quelque part au milieu en termes de facilité d'utilisation. Dans tous les cas, si cela prend plus de 30 secondes pour lire le manuel de l'utilisateur, ou si l'on doit aller sur Google ou un autre moteur de recherche, ou encore parcourir une longue page d'aide — la solution est complexe, quelle qu'elle soit.
Certaines des solutions examinées peuvent automatiquement envoyer un message par e-mail ou Jabber, tandis que d'autres s'appuient sur des alertes configurées dans le système. Dans la plupart des cas, les solutions complexes ont des paramètres d'alerte peu évidents. En tout cas, si le programme de sauvegarde renvoie un code de retour non nul, qui sera correctement compris par le service système des tâches périodiques (un message sera envoyé à l'administrateur système ou directement au système de surveillance) — la situation est simple. En revanche, si le système de sauvegarde, qui ne fonctionne pas sur le serveur de sauvegarde, ne peut pas indiquer un problème de manière évidente sans configuration — la complexité est déjà excessive. Dans tous les cas, la transmission d'avertissements et d'autres messages uniquement via l'interface web ou dans le journal est une mauvaise pratique, car ils seront souvent ignorés.
En ce qui concerne l'automatisation — un programme simple sait lire les variables d'environnement qui définissent son mode de fonctionnement, ou possède une interface CLI développée capable de répliquer entièrement le comportement de l'interface web, par exemple. Cela inclut également la capacité de travailler en continu, ainsi que des possibilités d'extension, etc.
Polyvalence
Cela se recoupe partiellement avec le sous-chapitre précédent sur l'automatisation. Il ne devrait pas être particulièrement problématique d'intégrer le processus de sauvegarde dans l'infrastructure existante.
Il convient de noter que l'utilisation de ports non standards (en dehors de l'interface web) pour le fonctionnement, la mise en œuvre du chiffrement de manière non standard, et l'échange de données via un protocole non standard sont des signes d'une solution non universelle. La plupart des candidats en ont, pour des raisons évidentes : simplicité et universalité ne sont généralement pas compatibles. En revanche, burp en est une exception, il en existe d'autres.
Un signe révélateur est la possibilité de fonctionner en utilisant un ssh classique.
Vitesse de chargement
C'est le point le plus controversé et discuté. D'une part, le processus a été lancé, il s'est déroulé aussi rapidement que possible et ne gêne pas les tâches principales. D'autre part, un pic de trafic et une charge sur le processeur au moment de la sauvegarde. Il est également important de noter que les programmes les plus rapides pour effectuer des sauvegardes sont généralement les plus pauvres en fonctionnalités importantes pour les utilisateurs. Encore une fois : si pour accéder à un simple fichier texte de quelques dizaines d'octets avec un mot de passe, le service entier est mis à mal (oui, je comprends que le processus de sauvegarde n'en est souvent pas responsable), et que l'on doit relire tous les fichiers de manière séquentielle dans le dépôt ou déployer un archive complète - le système de sauvegarde n'est définitivement pas rapide. Un autre point qui devient souvent un obstacle - la vitesse de déploiement d'une sauvegarde depuis une archive. Ici, ceux qui peuvent simplement copier ou déplacer des fichiers à l'endroit souhaité sans manipulation particulière (comme rsync par exemple) ont un avantage clair, mais le problème doit souvent être résolu de manière organisationnelle, de manière empirique : mesurer le temps de restauration de la sauvegarde et en informer ouvertement les utilisateurs.
Stabilité
Il faut donc comprendre : d'un côté, il doit y avoir une possibilité de restaurer une sauvegarde, peu importe les circonstances ; de l'autre, il doit y avoir une résistance à divers problèmes : coupure de réseau, défaillance du disque, suppression d'une partie du dépôt.
Comparaison des outils de sauvegarde
Temps de création de la copie
Temps de restauration de la copie
Installation simple
Configuration simple
Utilisation simple
Automatisation simple
Le client-serveur est-il nécessaire ?
Vérification de l'intégrité du référentiel
Copies différentielles
Travail via pipe
Polyvalence
Autonomie
Transparence du référentiel
Chiffrement
Compression
— consiste à créer une archive sans fichiers dupliqués (si le dédupliqueur sait où le paquet d'origine peut être téléchargé, il réduit les duplicatas de l'archive).
Interface web
Téléversement vers le cloud
Support Windows
Point
Rsync
4m15s
4m28s
oui
non
non
non
oui
non
non
oui
non
oui
oui
non
non
non
non
non
oui
6
Tar
pure
3m12s
2m43s
oui
non
non
non
non
non
oui
oui
non
oui
non
non
non
non
non
non
oui
8,5
gzip
9m37s
3m19s
oui
Rdiff-backup
16m26s
17m17s
oui
oui
oui
oui
oui
non
oui
non
oui
non
oui
non
oui
oui
oui
non
oui
11
Rsnapshot
4m19s
4m28s
oui
oui
oui
oui
non
non
oui
non
oui
non
oui
non
non
oui
oui
non
oui
12,5
Burp
11m9s
7m2s
oui
non
oui
oui
oui
oui
oui
non
oui
oui
non
non
oui
non
oui
non
oui
10,5
Duplicity
pas de cryptage
16m48s
10m58s
oui
oui
non
oui
non
oui
oui
non
non
oui
non
oui
oui
non
oui
non
oui
11
gpg
17m27s
15m3s
Duplicati
pas de cryptage
20m28s
13m45s
non
oui
non
non
non
oui
oui
non
non
oui
non
oui
oui
oui
oui
oui
oui
11
aes
29m41s
21m40s
gpg
26m19s
16m30s
Zbackup
pas de cryptage
40m3s
11m8s
oui
oui
non
non
non
oui
oui
oui
non
oui
non
oui
oui
oui
non
non
non
10
aes
42m0s
14m1s
aes+lzo
18m9s
6m19s
BorgBackup
pas de cryptage
4m7s
2m45s
oui
oui
oui
oui
oui
oui
oui
oui
oui
oui
non
oui
oui
oui
oui
non
oui
16
aes
4m58s
3m23s
blake2
4m39s
3m19s
Restic
5m38s
4m28s
oui
oui
oui
oui
non
oui
oui
oui
oui
oui
non
oui
non
oui
non
oui
oui
15,5
UrBackup
8m21s
8m19s
oui
oui
oui
non
oui
non
oui
non
oui
oui
non
oui
oui
oui
oui
non
oui
12
Amanda
9m3s
2m49s
oui
non
non
oui
oui
oui
oui
non
oui
oui
oui
oui
oui
non
oui
oui
oui
13
BackupPC
rsync
12m22s
7m42s
oui
non
oui
oui
oui
oui
oui
non
oui
non
non
oui
oui
non
oui
non
oui
10,5
tar
12m34s
12m15s
Légende du tableau :
- Vert, temps de fonctionnement inférieur à cinq minutes, ou réponse « Oui » (sauf dans la colonne « Besoin d'un client-serveur ? »), 1 point
- Jaune, temps de fonctionnement entre cinq et dix minutes, 0,5 point
- Rouge, temps de fonctionnement supérieur à dix minutes, ou réponse « Non » (sauf dans la colonne « Besoin d'un client-serveur ? »), 0 point
Selon le tableau ci-dessus, l'outil le plus simple, rapide, tout en étant pratique et puissant pour les sauvegardes est BorgBackup. En seconde position se trouve Restic, les autres candidats examinés se sont positionnés de manière à peu près égale avec un écart d'un à deux points à la fin.
Je remercie tous ceux qui ont lu le cycle jusqu'au bout, je propose de discuter des options, et d'en suggérer d'autres, si vous en avez. Au fur et à mesure des discussions, le tableau pourra être complété.
Le résultat du cycle sera un article de conclusion, dans lequel nous tenterons de déterminer le moyen idéal, rapide et gérable pour la sauvegarde, permettant de restaurer une copie en un minimum de temps tout en ayant la commodité et la simplicité de configuration et de maintenance.
Annonce
Sauvegarde, partie 6 : Comparaison des outils de sauvegarde
Sauvegarde, partie 7 : Conclusions
Source : habr.com
