{"id":38746,"date":"2019-10-31T22:25:40","date_gmt":"2019-10-31T19:25:40","guid":{"rendered":"https:\/\/prohoster.info\/blog\/rezervnoe-kopirovanie-chast-6-sravnenie-sredstv-rezervnogo-kopirovaniya\/"},"modified":"2019-10-31T22:25:40","modified_gmt":"2019-10-31T19:25:40","slug":"rezervnoe-kopirovanie-chast-6-sravnenie-sredstv-rezervnogo-kopirovaniya","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/rezervnoe-kopirovanie-chast-6-sravnenie-sredstv-rezervnogo-kopirovaniya","title":{"rendered":"Sauvegarde, partie 6 : Comparaison des outils de sauvegarde","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Sauvegarde,
\nCet article comparera les outils de sauvegarde, mais il est d'abord essentiel de d\u00e9couvrir comment ils g\u00e8rent rapidement et efficacement la r\u00e9cup\u00e9ration des donn\u00e9es \u00e0 partir des sauvegardes.
\nPour simplifier la comparaison, la r\u00e9cup\u00e9ration \u00e0 partir d'une sauvegarde compl\u00e8te sera examin\u00e9e, d'autant plus que ce mode de fonctionnement est pris en charge par tous les candidats. Pour simplifier, les chiffres sont d\u00e9j\u00e0 moyenn\u00e9s (moyenne arithm\u00e9tique de plusieurs lancements). Les r\u00e9sultats seront pr\u00e9sent\u00e9s dans un tableau, qui contiendra \u00e9galement des informations sur les fonctionnalit\u00e9s : pr\u00e9sence d'une interface web, simplicit\u00e9 de configuration et d'utilisation, capacit\u00e9 d'automatisation, disponibilit\u00e9 de diverses fonctionnalit\u00e9s suppl\u00e9mentaires (par exemple, v\u00e9rification de l'int\u00e9grit\u00e9 des donn\u00e9es), etc. Les graphiques montreront la charge du serveur sur lequel les donn\u00e9es seront appliqu\u00e9es (et non sur le serveur de stockage des sauvegardes).
\n<\/a><\/noindex><\/p>\n

R\u00e9cup\u00e9ration des donn\u00e9es<\/h2>\n

\nComme point de r\u00e9f\u00e9rence, rsync et tar seront utilis\u00e9s, car c'est g\u00e9n\u00e9ralement sur eux que sont bas\u00e9s<\/a><\/noindex> les scripts les plus simples pour effectuer des sauvegardes.<\/p>\n

Rsync<\/i> a compl\u00e9t\u00e9 l'ensemble de donn\u00e9es de test en 4 minutes et 28 secondes, montrant <\/p>\n

une telle charge<\/b>\"Sauvegarde,
\n
\nLe processus de r\u00e9cup\u00e9ration \u00e9tait limit\u00e9 par la sous-syst\u00e8me de stockage du serveur de sauvegarde (graphique en dents de scie). Il est \u00e9galement \u00e9vident que l'un des c\u0153urs \u00e9tait tr\u00e8s sollicit\u00e9 sans aucun probl\u00e8me particulier (faible iowait et softirq \u2014 aucun probl\u00e8me avec le disque et le r\u00e9seau, respectivement). Comme les deux autres programmes, \u00e0 savoir rdiff-backup et rsnapshot, sont bas\u00e9s sur rsync et proposent \u00e9galement rsync comme outil de r\u00e9cup\u00e9ration, ils auront un profil de charge et un temps de r\u00e9cup\u00e9ration de sauvegarde similaires.<\/p>\n

Tar<\/i> a \u00e9t\u00e9 l\u00e9g\u00e8rement plus rapide, en <\/p>\n

2 minutes et 43 secondes :<\/b>\"Sauvegarde,
\n
\nLa charge compl\u00e8te du syst\u00e8me \u00e9tait en moyenne 20% plus \u00e9lev\u00e9e en raison de l'augmentation des softirq \u2014 les frais g\u00e9n\u00e9raux de la sous-syst\u00e8me r\u00e9seau ont augment\u00e9.<\/p>\n

Si l'archive est compress\u00e9e en plus, le temps de r\u00e9cup\u00e9ration passe \u00e0 3 minutes et 19 secondes avec
\nune telle charge sur le serveur principal (d\u00e9compression du c\u00f4t\u00e9 du serveur principal) :<\/b>\"Sauvegarde,
\n
\nLe processus de d\u00e9compression utilise les deux c\u0153urs du processeur, car deux processus sont en cours. Dans l'ensemble, c'est un r\u00e9sultat attendu. Un r\u00e9sultat comparable (3 minutes et 20 secondes) a \u00e9galement \u00e9t\u00e9 obtenu lors de l'ex\u00e9cution de gzip c\u00f4t\u00e9 serveur avec des sauvegardes, le profil de charge sur le serveur principal \u00e9tant tr\u00e8s similaire \u00e0 celui de l'ex\u00e9cution de tar sans le compresseur gzip (voir le graphique pr\u00e9c\u00e9dent).<\/p>\n

Dans rdiff-backup<\/i> la derni\u00e8re sauvegarde effectu\u00e9e peut \u00eatre synchronis\u00e9e \u00e0 l'aide du traditionnel rsync (les r\u00e9sultats seront similaires), mais les sauvegardes plus anciennes doivent tout de m\u00eame \u00eatre restaur\u00e9es avec le programme rdiff-backup, qui a r\u00e9ussi \u00e0 effectuer la restauration en 17 minutes et 17 secondes, montrant <\/p>\n

une telle charge :<\/b>\"Sauvegarde,
\n
\nC'\u00e9tait peut-\u00eatre pr\u00e9vu, en tout cas pour limiter la vitesse, les auteurs proposent cette solution<\/a><\/noindex>. Le processus de restauration de la sauvegarde prend un peu moins de la moiti\u00e9 d'un c\u0153ur, avec une performance proportionnellement comparable (c'est-\u00e0-dire 2 \u00e0 5 fois plus lent) en termes de disque et de r\u00e9seau avec rsync.<\/p>\n

Rsnapshot<\/i> sugg\u00e8re d'utiliser le traditionnel rsync pour la restauration, donc ses r\u00e9sultats seront similaires. Dans l'ensemble, c'est ce qui s'est pass\u00e9.<\/p>\n

Burp<\/i> a r\u00e9ussi \u00e0 restaurer la sauvegarde en 7 minutes et 2 secondes avec
\nune telle charge :<\/b>\"Sauvegarde,
\n
\nCela a fonctionn\u00e9 assez rapidement et, au moins, c'est beaucoup plus pratique que rsync pur : il n'est pas n\u00e9cessaire de se souvenir de divers drapeaux, interface cli simple et intuitive, support int\u00e9gr\u00e9 pour plusieurs sauvegardes, bien qu'il soit environ deux fois plus lent. Si les donn\u00e9es doivent \u00eatre restaur\u00e9es \u00e0 partir de la derni\u00e8re sauvegarde effectu\u00e9e, vous pouvez utiliser rsync, avec quelques r\u00e9serves.<\/p>\n

Un r\u00e9sultat de vitesse et de charge similaire a montr\u00e9 le programme BackupPC<\/i> lors de l'activation du mode de transfert rsync, ayant restaur\u00e9 la sauvegarde en <\/p>\n

7 minutes et 42 secondes :<\/b>\"Sauvegarde,
\n
\nEn revanche, en mode de transfert de donn\u00e9es avec tar, BackupPC a \u00e9t\u00e9 moins performant : en 12 minutes et 15 secondes, la charge processeur \u00e9tait globalement plus faible <\/p>\n

d'environ une fois et demie :<\/b>\"Sauvegarde,
\n
\nDuplicity<\/i> sans chiffrement a montr\u00e9 de l\u00e9g\u00e8rement meilleurs r\u00e9sultats, r\u00e9ussissant \u00e0 restaurer une sauvegarde en 10 minutes et 58 secondes. Si le chiffrement avec gpg est activ\u00e9, le temps de restauration augmente \u00e0 15 minutes et 3 secondes. De plus, lors de la cr\u00e9ation d'un d\u00e9p\u00f4t pour stocker les copies, il est possible de sp\u00e9cifier la taille de l'archive qui sera utilis\u00e9e pour segmenter le flux de donn\u00e9es entrantes. En g\u00e9n\u00e9ral, sur des disques durs classiques, en raison du fonctionnement \u00e0 un seul fil, il n'y a pas de diff\u00e9rence significative. Cela pourrait appara\u00eetre avec diff\u00e9rentes tailles de blocs lors de l'utilisation de stockages hybrides. La charge sur le serveur principal lors de la restauration \u00e9tait la suivante :<\/p>\n

sans chiffrement<\/b>\"Sauvegarde,
\n
\navec chiffrement<\/b>\"Sauvegarde,
\n
\nDuplicati<\/i> a montr\u00e9 une vitesse de restauration comparable, r\u00e9ussissant en 13 minutes et 45 secondes. Environ 5 minutes suppl\u00e9mentaires ont \u00e9t\u00e9 consacr\u00e9es \u00e0 la v\u00e9rification de l'int\u00e9grit\u00e9 des donn\u00e9es restaur\u00e9es (pour un total d'environ 19 minutes). La charge \u00e9tait alors <\/p>\n

assez \u00e9lev\u00e9e :<\/b>\"Sauvegarde,
\n
\nLorsque le chiffrement aes a \u00e9t\u00e9 activ\u00e9 par des moyens internes, le temps de restauration a \u00e9t\u00e9 de 21 minutes et 40 secondes, et la charge processeur \u00e9tait maximale (les deux c\u0153urs !) pendant la restauration ; lors de la v\u00e9rification des donn\u00e9es, seul un fil \u00e9tait actif, occupant un c\u0153ur de processeur. La v\u00e9rification des donn\u00e9es apr\u00e8s restauration a dur\u00e9 les m\u00eames 5 minutes (soit un total de pr\u00e8s de 27 minutes).<\/p>\n

R\u00e9sultat<\/b>\"Sauvegarde,
\n
\nDuplicati a \u00e9t\u00e9 l\u00e9g\u00e8rement plus rapide pour la restauration en utilisant le programme externe gpg pour le chiffrement, mais en g\u00e9n\u00e9ral, les diff\u00e9rences par rapport au mode pr\u00e9c\u00e9dent sont minimales. Le temps de fonctionnement a \u00e9t\u00e9 de 16 minutes et 30 secondes, avec une v\u00e9rification des donn\u00e9es de 6 minutes. La charge \u00e9tait <\/p>\n

la suivante :<\/b>\"Sauvegarde,
\n
\nAMANDA<\/i>, utilisant tar, a r\u00e9ussi en 2 minutes et 49 secondes, ce qui, en principe, est tr\u00e8s proche de tar ordinaire. La charge sur le syst\u00e8me est essentiellement <\/p>\n

la m\u00eame :<\/b>\"Sauvegarde,
\n
\nLors de la restauration de la sauvegarde \u00e0 l'aide de zbackup<\/i> les r\u00e9sultats suivants ont \u00e9t\u00e9 obtenus :<\/p>\n

chiffrement, compression lzma<\/b>\"Sauvegarde,
\n
\nTemps de fonctionnement 11 minutes et 8 secondes<\/p>\n

chiffrement aes, compression lzma<\/b>\"Sauvegarde,
\n
\nTemps de fonctionnement 14 minutes<\/p>\n

chiffrement aes, compression lzo<\/b>\"Sauvegarde,
\n
\nTemps de fonctionnement 6 minutes, 19 secondes<\/p>\n

Dans l'ensemble, \u00e7a ne va pas trop mal. Tout d\u00e9pend 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\u00e9rents compresseurs. Du c\u00f4t\u00e9 du serveur de sauvegarde, on a utilis\u00e9 le tar classique, donc si on compare, la restauration s'effectue trois fois plus lentement. Il serait peut-\u00eatre utile de v\u00e9rifier le fonctionnement en mode multithread, avec un nombre de threads sup\u00e9rieur \u00e0 deux.<\/p>\n

BorgBackup<\/i> en mode sans chiffrement, a \u00e9t\u00e9 l\u00e9g\u00e8rement plus lent que tar, prenant 2 minutes 45 secondes, cependant, contrairement \u00e0 tar, la possibilit\u00e9 de d\u00e9dupliquer le r\u00e9f\u00e9rentiel est apparue. La charge r\u00e9sultante \u00e9tait <\/p>\n

la suivante :<\/b>\"Sauvegarde,
\n
\nSi l'on active le chiffrement bas\u00e9 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 <\/p>\n

la suivante :<\/b>\"Sauvegarde,
\n
\nLe chiffrement aes fonctionne un peu plus lentement, le temps de restauration est de 3 minutes 23 secondes, la charge ne <\/p>\n

a pas particuli\u00e8rement chang\u00e9 :<\/b>\"Sauvegarde,
\n
\nComme Borg peut fonctionner en mode multithread, la charge du processeur est maximum, et en activant des fonctions suppl\u00e9mentaires, le temps de traitement augmente simplement. Il semble qu'il faudrait explorer le multithreading de mani\u00e8re similaire \u00e0 zbackup.<\/p>\n

Restic<\/i> a r\u00e9ussi \u00e0 restaurer l\u00e9g\u00e8rement plus lentement, le temps de travail a \u00e9t\u00e9 de 4 minutes 28 secondes. La charge \u00e0 ce moment-l\u00e0 \u00e9tait <\/p>\n

donc :<\/b>\"Sauvegarde,
\n
\nIl semblerait que le processus de restauration fonctionne sur plusieurs fils, mais l'efficacit\u00e9 n'est pas aussi \u00e9lev\u00e9e que celle de BorgBackup, bien que comparable en temps avec le rsync classique.<\/p>\n

Avec UrBackup<\/i> a r\u00e9ussi \u00e0 restaurer les donn\u00e9es en 8 minutes 19 secondes, la charge \u00e0 ce moment-l\u00e0 \u00e9tait <\/p>\n

la suivante :<\/b>\"Sauvegarde,
\n
\nOn voit toujours une charge pas tr\u00e8s \u00e9lev\u00e9e, m\u00eame inf\u00e9rieure \u00e0 celle de tar. Quelques pics occasionnels, mais pas plus de charge qu'un seul c\u0153ur.<\/p>\n

Choix et justification des crit\u00e8res de comparaison<\/h2>\n

\nComme mentionn\u00e9 dans l'un des articles pr\u00e9c\u00e9dents, le syst\u00e8me de sauvegarde doit r\u00e9pondre aux crit\u00e8res suivants :<\/p>\n