Sauvegarde, partie 6: comparaison des outils de sauvegarde

Cet article compare les outils de sauvegarde, mais vous devez d'abord savoir comment ils traitent rapidement et correctement la récupération des données à partir des sauvegardes.
Pour faciliter la comparaison, la récupération à partir d'une sauvegarde complète sera envisagée, d'autant plus que tous les candidats prennent en charge ce mode de fonctionnement. Par souci de simplicité, les nombres sont déjà moyennés (moyenne arithmétique de plusieurs démarrages). Les résultats seront résumés dans un tableau, qui contiendra également des informations sur les fonctionnalités: la présence d'une interface Web, la facilité de configuration et de fonctionnement, la capacité d'automatisation, la présence de diverses fonctionnalités supplémentaires (par exemple, la vérification de l'intégrité des données), etc. Les graphiques montreront la charge du serveur, où les données seront utilisées (pas le serveur pour stocker les sauvegardes).

Récupération de données

Rsync et tar seront utilisés comme point de référence, car c'est sur ceux-ci que les scripts de sauvegarde les plus simples sont généralement basés .

Rsync a terminé l' ensemble de données de test en 4 minutes et 28 secondes en montrant


Le processus de récupération s'est heurté à une limitation du sous-système de disque du serveur de stockage de sauvegarde (graphiques en dents de scie). Vous pouvez également voir clairement le chargement d'un cœur sans aucun problème (faible iowait et softirq - il n'y a pas de problèmes avec le disque et le réseau, respectivement). Étant donné que 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 approximativement le même profil de charge et le même temps de récupération de sauvegarde.

Le goudron a été un peu plus rapide


La charge totale du système était plus élevée de 20% en moyenne en raison de l'augmentation de softirq - augmentation des frais généraux pendant le fonctionnement du sous-système réseau.

Si l'archive est en outre compressée, le temps de récupération augmente à 3 minutes 19 secondes avec

Le processus de déballage occupe les deux cœurs de processeur, car deux processus fonctionnent. En général, le résultat attendu. De plus, un résultat comparable (3 minutes et 20 secondes) a été obtenu lors de l'exécution de gzip côté serveur avec des sauvegardes, le profil de charge sur le serveur principal était très similaire à l'exécution de tar sans le compresseur gzip (voir le graphique précédent).

Dans rdiff-backup, vous pouvez synchroniser la dernière sauvegarde effectuée à l'aide de rsync ordinaire (les résultats seront similaires), mais les anciennes sauvegardes doivent toujours être restaurées à l'aide du programme rdiff-backup, qui a réussi à restaurer en 17 minutes et 17 secondes, montrant


Peut-être que cela a été conçu, en tout cas, les auteurs proposent une telle solution pour limiter la vitesse. Le processus de restauration d'une sauvegarde prend un peu moins de la moitié d'un cœur, avec des performances proportionnellement comparables (c'est-à-dire 2 à 5 fois plus lentes) sur un disque et un réseau avec rsync.

Rsnapshot pour la récupération suggère d'utiliser rsync normal, donc ses résultats seront similaires. En général, c'est comme ça que ça s'est passé.

Burp a fait face à la tâche de restaurer une sauvegarde en 7 minutes et 2 secondes avec

Cela a fonctionné assez rapidement et au moins beaucoup plus commodément que la pure rsync: vous n'avez pas besoin de vous souvenir de drapeaux, d'une interface cli simple et intuitive, d'un support intégré pour plusieurs copies - c'est vrai deux fois plus lent. Si vous devez restaurer les données de la dernière sauvegarde effectuée, vous pouvez utiliser rsync, avec quelques mises en garde.

BackupPC a montré à peu près la même vitesse et la même charge lors de l'activation du mode de transfert rsync en déployant une sauvegarde pour


Mais en mode de transfert de données avec tar BackupPC copié plus lentement: en 12 minutes et 15 secondes, la charge du processeur était généralement plus faible


La duplicité sans cryptage a montré des résultats légèrement meilleurs, ayant réussi à restaurer une sauvegarde en 10 minutes et 58 secondes. Si vous activez le chiffrement à l'aide de gpg - le temps de récupération passe à 15 minutes et 3 secondes. De plus, lorsque vous créez un référentiel pour stocker des copies, vous pouvez spécifier la taille de l'archive, qui sera utilisée lors de la division du flux de données entrant. En général, sur les disques durs ordinaires, également en raison du mode de fonctionnement monothread, il n'y a pas beaucoup de différence. Il peut apparaître avec différentes tailles de bloc lors de l'utilisation du stockage hybride. La charge sur le serveur principal pendant la récupération était la suivante:



Duplicati a montré une vitesse de récupération comparable, faisant face en 13 minutes et 45 secondes. Cinq autres minutes ont été nécessaires pour vérifier l'exactitude des données récupérées (un total d'environ 19 minutes). La charge était


Lorsque le chiffrement aes était activé en interne, le temps de récupération était de 21 minutes et 40 secondes et la charge du processeur était maximale (les deux cœurs!) Pendant la récupération; lors de la vérification des données, un seul thread était actif, occupant un cœur de processeur. La vérification des données après la récupération a pris les mêmes 5 minutes (près de 27 minutes au total).


Duplicati a géré la récupération un peu plus rapidement lors de l'utilisation d'un programme gpg externe pour le chiffrement, mais en général, les différences par rapport au mode précédent sont minimes. La durée de fonctionnement était de 16 minutes 30 secondes, avec vérification des données en 6 minutes. La charge était


AMANDA , utilisant du goudron, a réussi en 2 minutes 49 secondes, ce qui, en principe, est très proche du goudron ordinaire. Charge du système en principe


Lors de la restauration d'une sauvegarde à l'aide de zbackup , les résultats suivants ont été obtenus:




Dans l'ensemble, pas mal. Tout dépend de la vitesse du processeur sur le serveur de sauvegarde, qui est assez clairement visible au moment où le programme s'exécute avec différents compresseurs. Du côté du serveur de sauvegarde, un tar régulier a été lancé, donc si vous le comparez, la récupération fonctionne 3 fois plus lentement. Il peut être utile de vérifier le travail en mode multi-thread, avec plus de deux threads.

BorgBackup en mode non crypté a réussi un peu plus lentement que tar, en 2 minutes 45 secondes, cependant, contrairement au même tar, il est devenu possible de dédupliquer le référentiel. La charge s'est avérée en même temps


Si vous activez le chiffrement basé sur Blake, la vitesse de restauration d'une sauvegarde ralentit un peu. Le temps de récupération dans ce mode est de 3 minutes 19 secondes et la charge est libérée


Le cryptage AES fonctionne un peu plus lentement, le temps de récupération 3 minutes 23 secondes, en particulier la charge


Étant donné que Borg peut fonctionner en mode multi-thread - la charge du processeur est maximale, tandis que lorsque vous activez des fonctions supplémentaires, le temps de fonctionnement augmente simplement. Apparemment, il vaut la peine d'explorer le travail de multithreading de la même manière que zbackup.

Restic a fait face à la récupération un peu plus lentement, le temps de fonctionnement était de 4 minutes 28 secondes. La charge avait l'air


Apparemment, le processus de récupération fonctionne dans plusieurs threads, mais l'efficacité n'est pas aussi élevée que celle de BorgBackup, mais elle est comparable dans le temps à la rsync habituelle.

En utilisant UrBackup, j'ai pu récupérer des données en 8 minutes et 19 secondes, alors que la charge était


On ne voit toujours pas de charge très élevée, même inférieure à celle du goudron. Par endroits, éclate, mais pas plus que le chargement d'un seul noyau.

Sélection et justification des critères de comparaison

Comme mentionné dans un article précédent, le système de sauvegarde doit répondre aux critères suivants:

• Simplicité au travail
• Polyvalence
• La stabilité
• La vitesse

Il vaut la peine d'examiner chaque élément séparément plus en détail.

Simplicité de travail

C’est mieux quand il n’y a qu’un bouton «Rendre tout bon», mais si vous revenez à de vrais programmes, il sera plus pratique d’avoir un principe de fonctionnement familier et standard.
La plupart des utilisateurs seront probablement mieux lotis s'ils n'ont pas besoin de mémoriser un trousseau de clés pour cli, de configurer un ensemble d'options différentes, souvent obscures via le Web ou l'interface utilisateur, et de configurer des alertes en cas d'échec de l'opération. Cela inclut également la possibilité d '«adapter» facilement une solution de sauvegarde à une infrastructure existante, ainsi que d'automatiser le processus de sauvegarde. Immédiatement la possibilité d'installer un gestionnaire de paquets, ou dans une ou deux commandes du type "télécharger et décompresser". curl | sudo bash curl | sudo bash est une méthode compliquée car vous devez vérifier qu'elle arrive par référence.

Par exemple, parmi les candidats considérés, une solution simple est burp, rdiff-backup et restic, qui ont mémorisé des clés pour différents modes de fonctionnement. Un peu plus compliqués sont le borg et la duplicité. Le plus difficile a été AMANDA. Le reste de la facilité d'utilisation se situe quelque part entre les deux. Dans tous les cas, si vous avez besoin de plus de 30 secondes pour lire le manuel d'utilisation, ou si vous devez aller sur Google ou un autre moteur de recherche, et faire défiler la longue feuille d'aide, la solution est compliquée, d'une manière ou d'une autre.

Certains des candidats considérés peuvent envoyer automatiquement un message par e-mail \ jabber, tandis que d'autres s'appuient sur des alertes configurées dans le système. De plus, le plus souvent, les décisions complexes n'ont pas de paramètres de notification assez évidents. Dans tous les cas, si le programme de sauvegarde donne un code retour différent de zéro, qui sera correctement compris par le service système des tâches périodiques (le message s'envolera vers l'administrateur système ou immédiatement vers la surveillance) - la situation est simple. Mais si le système de sauvegarde, qui ne fonctionne pas sur le serveur de sauvegarde, ne peut pas être configuré de manière évidente, la complexité est déjà excessive. Dans tous les cas, l'envoi d'avertissements et d'autres messages uniquement à l'interface Web et / ou au journal est une mauvaise pratique, car ils seront le plus souvent ignorés.

En ce qui concerne l'automatisation, un programme simple peut lire des variables d'environnement qui spécifient son mode de fonctionnement, ou il a une interface utilisateur développée qui peut reproduire complètement le comportement lors du travail via une interface Web, par exemple. Cela comprend également la possibilité d'un travail continu, la disponibilité de possibilités d'expansion, etc.

Polyvalence

Fait écho en partie à la sous-section précédente en termes d'automatisation, il ne devrait pas être un problème spécial pour «adapter» le processus de sauvegarde dans l'infrastructure existante.
Il convient de noter que l'utilisation de ports non standard (enfin, à l'exception de l'interface Web) pour le travail, la mise en œuvre du cryptage de manière non standard, l'échange de données avec un protocole non standard sont les signes d'une solution non universelle. Pour la plupart, tous les candidats ont une façon ou une autre pour la raison évidente: la simplicité et la polyvalence ne sont généralement pas compatibles. Burp est une exception, il y en a d'autres.

Comme signe - la capacité de travailler en utilisant ssh ordinaire.

Vitesse de travail

Le point le plus controversé et le plus controversé. D'une part, ils ont entamé le processus, cela a fonctionné le plus rapidement possible et n'interfère pas avec les tâches principales. En revanche, il y a une augmentation du trafic et de la charge CPU pendant la sauvegarde. Il convient également de noter que les programmes de copie les plus rapides sont généralement les plus pauvres en fonctionnalités importantes pour les utilisateurs. Encore une fois: si pour obtenir un fichier texte malheureux de la taille de plusieurs dizaines d'octets avec un mot de passe, et à cause de cela, le coût total du service (oui, je comprends qu'ici le processus de sauvegarde n'est le plus souvent pas coupable), et vous devez relire séquentiellement tous les fichiers du référentiel ou déployer l'archive entière - le système de sauvegarde n'est jamais rapide. Un autre point qui devient souvent une pierre d'achoppement est la vitesse de déploiement d'une sauvegarde à partir de l'archive. Il y a un avantage évident pour ceux qui peuvent simplement copier ou déplacer des fichiers au bon endroit sans manipulations spéciales (rsync par exemple), mais le plus souvent, le problème doit être résolu de manière organisationnelle, empiriquement: mesurer le temps de récupération de la sauvegarde et informer ouvertement les utilisateurs à ce sujet.

La stabilité

Il doit être compris comme suit: d'une part, il devrait être possible de redéployer la sauvegarde de toute façon, d'autre part, résistance à divers problèmes: panne de réseau, panne de disque, suppression d'une partie du référentiel.

Comparaison des outils de sauvegarde

Légende du tableau:

• Vert, la durée de fonctionnement est inférieure à cinq minutes, ou la réponse est «Oui» (sauf pour la colonne «Besoin d'un client \ serveur?»), 1 point
• Jaune, durée de fonctionnement de cinq à dix minutes, 0,5 point
• Rouge, la durée de fonctionnement est supérieure à dix minutes, ou la réponse est «Non» (sauf pour la colonne «Besoin d'un client \ serveur?»), 0 point

Selon le tableau ci-dessus, l'outil de sauvegarde le plus simple, rapide et à la fois pratique et puissant est BorgBackup. Restic a pris la deuxième place, les autres candidats considérés ont été placés à peu près de la même façon avec un ou deux points à la fin.

Je remercie tous ceux qui ont lu le cycle jusqu'à la fin, je suggère de discuter des options, en suggérant les vôtres, le cas échéant. À mesure que la discussion progresse, le tableau peut être complété.

Le résultat du cycle sera l'article final, dans lequel il y aura une tentative de sortir un outil de sauvegarde idéal, rapide et gérable, qui vous permet de déployer rapidement une copie en arrière et en même temps avoir la commodité et la simplicité de la configuration et de la maintenance.

Annonce

Sauvegarde, partie 1: Pourquoi avez-vous besoin d'une sauvegarde, un aperçu des méthodes, des technologies
Sauvegarde, Partie 2: Présentation et test des outils de sauvegarde basés sur rsync
Sauvegarde, Partie 3: Présentation et test de la duplicité, duplicati
Sauvegarde, Partie 4: Présentation et test de zbackup, restic, borgbackup
Sauvegarde, partie 5: Test de la sauvegarde de bacula et veeam pour linux
Sauvegarde: pièce demandée par les lecteurs: revue AMANDA, UrBackup, BackupPC
Sauvegarde, partie 6: comparaison des outils de sauvegarde
Sauvegarde, partie 7: Conclusions