Cet article comparera les outils de sauvegarde, mais vous devez d'abord découvrir avec quelle rapidité et quelle efficacité ils gèrent la restauration des données à partir des sauvegardes.
Pour faciliter la comparaison, nous envisagerons une restauration à partir d'une sauvegarde complète, d'autant plus que tous les candidats supportent ce mode de fonctionnement. Pour plus de simplicité, les nombres sont déjà moyennés (la moyenne arithmétique de plusieurs exécutions). Les résultats seront résumés dans un tableau, qui contiendra également des informations sur les capacités : la présence d'une interface web, la facilité de configuration et d'utilisation, la possibilité d'automatisation, la présence de diverses fonctionnalités supplémentaires (par exemple, vérification de l'intégrité des données) , etc. Les graphiques montreront la charge sur le serveur sur lequel les données seront utilisées (et non sur le serveur de stockage des copies de sauvegarde).
Récupération de données
rsync et tar seront utilisés comme point de référence puisque des scripts simples pour faire des copies de sauvegarde.
Rsync a fait face aux données de test définies en 4 minutes et 28 secondes, montrant
une telle charge
Le processus de récupération a rencontré 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 noyau sans aucun problème (iowait et softirq faibles - aucun problème 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 régulièrement comme outil de récupération, ils auront à peu près le même profil de charge et le même temps de récupération de sauvegarde.
Goudron je l'ai fait un peu plus vite
2 minutes et 43 secondes :
La charge totale du système était plus élevée en moyenne de 20 % en raison de l'augmentation du softirq - les frais généraux lors de l'exploitation du sous-système réseau ont augmenté.
Si l'archive est davantage compressée, le temps de récupération passe à 3 minutes 19 secondes.
avec une telle charge sur le serveur principal (déballage du côté du serveur principal) :
Le processus de décompression occupe les deux cœurs du processeur car deux processus sont en cours d'exécution. En général, c'est 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 graphique précédent).
В rdiff-sauvegarde vous pouvez synchroniser la dernière sauvegarde que vous avez effectuée à l'aide de rsync standard (les résultats seront similaires), mais les sauvegardes plus anciennes doivent toujours être restaurées à l'aide du programme rdiff-backup, qui a terminé la restauration en 17 minutes et 17 secondes, affichant
cette charge :
Peut-être que cela avait pour but, au moins de limiter la rapidité des auteurs . Le processus de restauration d'une copie de sauvegarde lui-même 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 disque et réseau avec rsync.
Rinstantané Pour la récupération, il suggère d'utiliser rsync régulier, ses résultats seront donc similaires. En général, c'est ainsi que cela s'est passé.
Rot J'ai terminé la tâche de restauration d'une sauvegarde en 7 minutes et 2 secondes avec
avec cette charge :
Cela a fonctionné assez rapidement et est au moins beaucoup plus pratique que rsync pur : vous n'avez pas besoin de mémoriser d'indicateurs, une interface cli simple et intuitive, une prise en charge intégrée de plusieurs copies - bien que ce soit deux fois plus lent. Si vous devez restaurer les données de la dernière sauvegarde que vous avez effectuée, vous pouvez utiliser rsync, avec quelques mises en garde.
Le programme a montré à peu près la même vitesse et la même charge Sauvegarde PC lors de l'activation du mode de transfert rsync, le déploiement de la sauvegarde pour
7 minutes et 42 secondes :
Mais en mode transfert de données, BackupPC a géré tar plus lentement : en 12 minutes et 15 secondes, la charge du processeur était généralement inférieure
une fois et demie :
Duplicity sans cryptage a montré des résultats légèrement meilleurs, restaurant une sauvegarde en 10 minutes et 58 secondes. Si vous activez le cryptage à l'aide de gpg, le temps de récupération passe à 15 minutes et 3 secondes. De plus, lors de la création d'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 conventionnels, également en raison du mode de fonctionnement monothread, il n'y a pas beaucoup de différence. Il peut apparaître sous différentes tailles de bloc lorsque le stockage hybride est utilisé. La charge sur le serveur principal lors de la récupération était la suivante :
pas de cryptage
avec cryptage
Duplicati a montré un taux de récupération comparable, le complétant en 13 minutes et 45 secondes. Il a fallu environ 5 minutes supplémentaires pour vérifier l'exactitude des données récupérées (un total d'environ 19 minutes). La charge était
assez haut:
Lorsque le cryptage aes était activé en interne, le temps de récupération était de 21 minutes 40 secondes, avec une utilisation du processeur à son maximum (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).
Résultat
duplicati était un peu plus rapide avec la récupération lors de l'utilisation du programme gpg externe pour le cryptage, 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 une vérification des données en 6 minutes. La charge était
tel:
AMANDA, en utilisant du tar, l'a complété en 2 minutes 49 secondes, ce qui, en principe, est très proche du tar ordinaire. Charge sur le système en principe
le même:
Lors de la restauration d'une sauvegarde à l'aide zsauvegarde Les résultats suivants ont été obtenus:
cryptage, compression lzma
Durée 11 minutes et 8 secondes
Cryptage AES, compression Lzma
14 temps d'exécution minutes
Cryptage AES, compression lzo
Durée 6 minutes et 19 secondes
Dans l'ensemble, pas mal. Tout dépend de la vitesse du processeur sur le serveur de sauvegarde, ce qui ressort clairement du temps d'exécution du programme avec différents compresseurs. Côté serveur de sauvegarde, un tar standard a été lancé, donc si on le compare avec lui, la récupération est 3 fois plus lente. Il peut être intéressant de vérifier le fonctionnement en mode multithread, avec plus de deux threads.
BorgSauvegarde en mode non chiffré, c'était un peu plus lent que tar, en 2 minutes 45 secondes, cependant, contrairement à tar, il devenait possible de dédupliquer le référentiel. La charge s'est avérée être
suivant:
Si vous activez le chiffrement basé sur Blake, la vitesse de récupération des sauvegardes est légèrement plus lente. Le temps de récupération dans ce mode est de 3 minutes 19 secondes et la charge a disparu
comme ça:
Le cryptage AES est légèrement plus lent, le temps de récupération est de 3 minutes 23 secondes, la charge est particulièrement
n'a pas changé:
Étant donné que Borg peut fonctionner en mode multithread, la charge du processeur est maximale et lorsque des fonctions supplémentaires sont activées, la durée de fonctionnement augmente simplement. Apparemment, cela vaut la peine d'explorer le multithreading de la même manière que zbackup.
Restique a fait face à la récupération un peu plus lentement, la durée de fonctionnement était de 4 minutes 28 secondes. La charge ressemblait à
comme suit:
Apparemment, le processus de récupération fonctionne sur plusieurs threads, mais l'efficacité n'est pas aussi élevée que celle de BorgBackup, mais comparable dans le temps à celle d'un rsync classique.
Avec UrSauvegarde Il a été possible de restaurer les données en 8 minutes et 19 secondes, la charge était
tel:
La charge n’est toujours pas très élevée, voire inférieure à celle du goudron. Il y a des éclats à certains endroits, mais pas plus que la charge d'un noyau.
Sélection et justification des critères de comparaison
Comme indiqué dans l’un des articles précédents, le système de sauvegarde doit répondre aux critères suivants :
- Facilité d'utilisation
- Universalisme
- Stabilité
- Rapidité
Il convient d'examiner chaque point séparément plus en détail.
Facilité d'utilisation
Il est préférable qu'il y ait un seul bouton « Faites tout bien », mais si vous revenez à de vrais programmes, le plus pratique sera 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 ensemble de touches pour cli, de configurer un ensemble d'options différentes, souvent obscures, via le Web ou l'interface utilisateur, ou de configurer des notifications en cas d'échec d'une opération. 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. Il y a aussi la possibilité d'installation à l'aide d'un gestionnaire de paquets, ou en une ou deux commandes comme « télécharger et décompresser ». curl ссылка | sudo bash - une méthode complexe, puisqu'il faut vérifier ce qui arrive via le lien.
Par exemple, parmi les candidats considérés, une solution simple est burp, rdiff-backup et restic, qui disposent de clés mnémoniques pour différents modes de fonctionnement. Le borg et la duplicité sont légèrement plus complexes. Le plus difficile a été AMANDA. Les autres se situent quelque part au milieu en termes de facilité d’utilisation. Dans tous les cas, s'il vous faut plus de 30 secondes pour lire le manuel d'utilisation, ou si vous devez aller sur Google ou un autre moteur de recherche, et aussi faire défiler une longue feuille d'aide, la décision est difficile, d'une manière ou d'une autre.
Certains des candidats considérés sont capables d'envoyer automatiquement un message via e-mailjabber, tandis que d'autres s'appuient sur des alertes configurées dans le système. De plus, les solutions les plus souvent complexes n’ont pas de paramètres d’alerte tout à fait évidents. Dans tous les cas, si le programme de sauvegarde produit un code retour différent de zéro, qui sera correctement compris par le service système pour les tâches périodiques (un message sera envoyé à l'administrateur système ou directement au monitoring) - la situation est simple. Mais si le système de sauvegarde, qui ne fonctionne pas sur un serveur de sauvegarde, ne peut pas être configuré, la façon évidente de parler du problème est que la complexité est déjà excessive. Dans tous les cas, émettre des avertissements et autres messages uniquement sur l'interface Web ou sur le journal est une mauvaise pratique, car le plus souvent ils seront ignorés.
Quant à l'automatisation, un programme simple peut lire les variables d'environnement qui définissent son mode de fonctionnement, ou il dispose d'un cli développé qui peut dupliquer complètement le comportement lorsque l'on travaille via une interface Web, par exemple. Cela inclut également la possibilité d'un fonctionnement continu, la disponibilité d'opportunités d'expansion, etc.
Universalisme
Faisant partiellement écho à la sous-section précédente concernant l’automatisation, « intégrer » le processus de sauvegarde dans l’infrastructure existante ne devrait pas poser de problème particulier.
Il est à noter que l'utilisation de ports non standards (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 via un protocole non standard sont des signes d'une non-conformité. -solution universelle. Pour la plupart, tous les candidats les possèdent d’une manière ou d’une autre pour une raison évidente : simplicité et polyvalence ne font généralement pas bon ménage. A titre d'exception - le rot, il y en a d'autres.
En signe - la possibilité de travailler en utilisant ssh standard.
Vitesse de travail
Le point le plus controversé et controversé. D'une part, nous avons lancé le processus, il a fonctionné le plus rapidement possible et n'a pas interféré avec les tâches principales. En revanche, on constate une augmentation du trafic et de la charge du processeur pendant la période de sauvegarde. Il convient également de noter que les programmes de copie les plus rapides sont généralement les plus pauvres en termes de fonctions importantes pour les utilisateurs. Encore une fois : si pour obtenir un malheureux fichier texte de plusieurs dizaines d'octets avec un mot de passe, et à cause de cela, la totalité du service coûte (oui, oui, je comprends que le processus de sauvegarde n'est le plus souvent pas à blâmer ici), et vous devez relire séquentiellement tous les fichiers du référentiel ou développer l'intégralité de l'archive - le système de sauvegarde n'est jamais rapide. Un autre point qui devient souvent une pierre d'achoppement est la rapidité de déploiement d'une sauvegarde à partir d'une archive. Il y a ici un net avantage pour ceux qui peuvent simplement copier ou déplacer des fichiers vers l'emplacement souhaité sans trop de manipulations (rsync, par exemple), mais le plus souvent le problème doit être résolu de manière organisationnelle, empirique : en mesurant le temps de récupération des sauvegardes. et en informer ouvertement les utilisateurs.
Stabilité
Il faut le comprendre ainsi : d'une part, il doit être possible de redéployer la copie de sauvegarde de quelque manière que ce soit, d'autre part, elle doit être résistante à divers problèmes : interruption du réseau, panne de disque, suppression d'une partie du dépôt.
Comparaison des outils de sauvegarde
Heure de création de la copie
Temps de récupération de copie
Installation facile
Installation facile
Utilisation simple
Automatisation simple
Avez-vous besoin d'un serveur client ?
Vérification de l'intégrité du référentiel
Copies différentielles
Travailler via un tuyau
Universalisme
Autonomie
Transparence du référentiel
Шифрование
compression
Déduplication
interface Web
Remplissage vers le cloud
Prise en charge de Windows
marque
Rsync
4m15s
4m28s
oui
aucun
aucun
aucun
oui
aucun
aucun
oui
aucun
oui
oui
aucun
aucun
aucun
aucun
aucun
oui
6
Goudron
pur
3m12s
2m43s
oui
aucun
aucun
aucun
aucun
aucun
oui
oui
aucun
oui
aucun
aucun
aucun
aucun
aucun
aucun
oui
8,5
gzip
9m37s
3m19s
oui
Rdiff-sauvegarde
16m26s
17m17s
oui
oui
oui
oui
oui
aucun
oui
aucun
oui
aucun
oui
aucun
oui
oui
oui
aucun
oui
11
Rinstantané
4m19s
4m28s
oui
oui
oui
oui
aucun
aucun
oui
aucun
oui
aucun
oui
aucun
aucun
oui
oui
aucun
oui
12,5
Rot
11m9s
7m2s
oui
aucun
oui
oui
oui
oui
oui
aucun
oui
oui
aucun
aucun
oui
aucun
oui
aucun
oui
10,5
Duplicity
pas de cryptage
16m48s
10m58s
oui
oui
aucun
oui
aucun
oui
oui
aucun
aucun
oui
aucun
oui
oui
aucun
oui
aucun
oui
11
gpg
17m27s
15m3s
Duplicati
pas de cryptage
20m28s
13m45s
aucun
oui
aucun
aucun
aucun
oui
oui
aucun
aucun
oui
aucun
oui
oui
oui
oui
oui
oui
11
Aes
29m41s
21m40s
gpg
26m19s
16m30s
zbackup
pas de cryptage
40m3s
11m8s
oui
oui
aucun
aucun
aucun
oui
oui
oui
aucun
oui
aucun
oui
oui
oui
aucun
aucun
aucun
10
Aes
42m0s
14m1s
aes+lzo
18m9s
6m19s
BorgSauvegarde
pas de cryptage
4m7s
2m45s
oui
oui
oui
oui
oui
oui
oui
oui
oui
oui
aucun
oui
oui
oui
oui
aucun
oui
16
Aes
4m58s
3m23s
blake2
4m39s
3m19s
Restique
5m38s
4m28s
oui
oui
oui
oui
aucun
oui
oui
oui
oui
oui
aucun
oui
aucun
oui
aucun
oui
oui
15,5
UrSauvegarde
8m21s
8m19s
oui
oui
oui
aucun
oui
aucun
oui
aucun
oui
oui
aucun
oui
oui
oui
oui
aucun
oui
12
Amanda
9m3s
2m49s
oui
aucun
aucun
oui
oui
oui
oui
aucun
oui
oui
oui
oui
oui
aucun
oui
oui
oui
13
Sauvegarde PC
rsync
12m22s
7m42s
oui
aucun
oui
oui
oui
oui
oui
aucun
oui
aucun
aucun
oui
oui
aucun
oui
aucun
oui
10,5
goudron
12m34s
12m15s
Légende du tableau :
- Vert, durée de fonctionnement inférieure à cinq minutes, ou réponse « Oui » (sauf pour la colonne « Besoin d'un serveur client ? »), 1 point
- Jaune, durée de fonctionnement cinq à dix minutes, 0.5 point
- Rouge, le temps de travail est supérieur à dix minutes, ou la réponse est « Non » (sauf pour la colonne « Avez-vous besoin d'un serveur client ? »), 0 point
Selon le tableau ci-dessus, l'outil de sauvegarde le plus simple, le plus rapide et en même temps 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 à égalité avec un écart d'un ou deux points à la fin.
Je remercie tous ceux qui ont lu la série jusqu'au bout, je vous invite à discuter des options et à proposer les vôtres, le cas échéant. Au fur et à mesure que la discussion progresse, le tableau pourra être élargi.
Le résultat de la série sera l'article final, dans lequel on tentera de développer un outil de sauvegarde idéal, rapide et gérable qui vous permettra de déployer une copie dans les plus brefs délais et en même temps d'être pratique et facile. à configurer et à entretenir.
annonce
Sauvegarde Partie 6 : Comparaison des outils de sauvegarde
Sauvegarde Partie 7 : Conclusions
Source: habr.com