Sauvegarde, partie 3 : Aperçu et test de duplicity, duplicati

Cet article examine les outils de sauvegarde qui effectuent des sauvegardes en créant des archives sur un serveur de sauvegarde.

Parmi ceux qui répondent aux exigences se trouvent duplicity (pour lequel il existe une interface agréable sous la forme de deja dup) et duplicati.

Un autre outil de sauvegarde très notable est dar, mais comme il dispose d'une liste d'options très vaste – la méthode de test ne couvre à peine 10 % de ses capacités – nous ne le testerons pas dans le cadre de ce cycle.

Résultats attendus

Étant donné que les deux candidats créent des archives d'une manière ou d'une autre, on peut utiliser un tar ordinaire comme référence.

Nous évaluerons également dans quelle mesure le stockage des données sur le serveur de stockage est optimisé en créant des sauvegardes qui contiennent uniquement les différences entre une copie complète et l'état actuel des fichiers, ou entre les archives passées et actuelles (incrémentales, décimales, etc.).

Comportement lors de la création de sauvegardes :

1. Un nombre relativement faible de fichiers sur le serveur de sauvegarde (comparable au nombre de sauvegardes ou à la taille des données en Go), mais leur taille est suffisamment grande (dizaines à centaines de mégaoctets).
2. La taille du référentiel inclura uniquement les modifications – les doublons ne seront pas conservés, ainsi la taille du référentiel sera inférieure à celle d'un logiciel basé sur rsync.
3. Une charge de travail importante sur le processeur est attendue lors de l'utilisation de la compression et/ou du chiffrement, ainsi qu'une charge réseau et de disque probablement assez élevée si le processus d'archivage et/ou de chiffrement s'exécute sur le serveur de sauvegarde.

En tant que valeur de référence, nous lancerons la commande suivante :

cd /src/dir; tar -cf - * | ssh backup_server "cat > /backup/dir/archive.tar"

Les résultats de l'exécution sont les suivants :

Le temps d'exécution est de 3m12s. On constate que la vitesse est limitée par le système de disque du serveur de sauvegarde, comme dans l'exemple avec rsync. Juste un peu plus rapide, car l'écriture se fait dans un seul fichier.

Pour évaluer également la compression, nous lancerons la même option, mais nous activerons la compression côté serveur de sauvegarde :

cd /src/dir; tar -cf - * | ssh backup_server "gzip > /backup/dir/archive.tgz"

Les résultats sont les suivants :

Le temps d'exécution est de 10m11s. Il est probable que le goulet d'étranglement soit le compresseur mono-thread côté réception.

La même commande, mais avec le transfert de la compression vers le serveur contenant les données sources pour vérifier l'hypothèse selon laquelle le goulot d'étranglement est le compresseur mono-thread.

cd /src/dir; tar -czf - * | ssh backup_server "cat > /backup/dir/archive.tgz"

Voici ce que ça donne :

Le temps d'exécution était de 9m37s. On peut clairement voir la charge d'un cœur par le compresseur, car la vitesse de transmission sur le réseau et la charge sur le sous-système de disque source sont similaires.

Pour évaluer le chiffrement, vous pouvez utiliser openssl ou gpg, en ajoutant une commande supplémentaire openssl ou gpg dans le pipe. Pour référence, voici une commande :

cd /src/dir; tar -cf - * | ssh backup_server "gzip | openssl enc -e -aes256 -pass pass:somepassword -out /backup/dir/archive.tgz.enc"

Les résultats étaient les suivants :

Le temps d'exécution était de 10m30s, car 2 processus étaient lancés sur le côté récepteur — le goulot d'étranglement était encore le compresseur mono-thread, plus quelques frais généraux sur le chiffrement.

Mise à jour : À la demande de bliznezz, j'ajoute des tests avec pigz. Si l'on utilise seulement le compresseur, cela a pris 6m30s, et si on ajoute le chiffrement — environ 7m. L'échec sur le graphique inférieur — cache disque non vidé :

Test de duplicity

Duplicity est un logiciel en python pour la sauvegarde en créant des archives chiffrées au format tar.

Pour les archives incrémentielles, librsync est utilisé, donc un comportement similaire à celui décrit dans la note précédente du cycle.

Les sauvegardes peuvent être chiffrées et signées à l'aide de gnupg, ce qui est important lors de l'utilisation de différents fournisseurs pour le stockage des sauvegardes (s3, backblaze, gdrive, etc.)

Voyons quels seront les résultats :

Voici les résultats obtenus lors de l'exécution sans chiffrement

spoiler

Temps d'exécution de chaque lancement de test :

Lancement 1
Lancement 2
Lancement 3

16m33s
17m20s
16m30s

8m29s
9m3s
8m45s

5m21s
6m04s
5m53s

Voici les résultats lorsque le chiffrement gnupg est activé, avec une taille de clé de 2048 bits :

Temps d'exécution sur les mêmes données, avec chiffrement :

Lancement 1
Lancement 2
Lancement 3

17m22s
17m32s
17m28s

8m52s
9m13s
9m3s

5m48s
5m40s
5m30s

La taille de bloc spécifiée était de 512 mégaoctets, ce qui est clairement visible sur les graphiques ; la charge processeur était en fait maintenue à environ 50 %, donc le programme n'utilise pas plus d'un cœur processeur.

Le principe de fonctionnement du programme est également assez clair : on prend un morceau de données, on le compresse, on l'envoie au serveur de stockage des sauvegardes, qui peut être plutôt lent.
Une autre caractéristique est le temps d'exécution prévisible du programme, qui dépend uniquement de la taille des données modifiées.

L'activation du chiffrement n'a pas particulièrement augmenté le temps d'exécution du programme, mais a augmenté la charge processeur d'environ 10 %, ce qui peut être un bon bonus.

Malheureusement, ce programme n'a pas pu détecter correctement la situation liée au renommage du répertoire, et la taille résultante du dépôt était égale à la taille des modifications (c'est-à-dire 18 Go), mais la possibilité d'utiliser un serveur non fiable pour les sauvegardes compense clairement ce comportement.

Test de duplicati

Ce logiciel est écrit en C#, et il s'exécute en utilisant un ensemble de bibliothèques de Mono. Il dispose d'une interface graphique, ainsi que d'une version CLI.

La liste approximative des principales fonctionnalités est proche de celle de duplicity, incluant divers fournisseurs de stockage pour les sauvegardes, cependant, contrairement à duplicity, la plupart des fonctionnalités sont disponibles sans outils tiers. Que cela soit un avantage ou un inconvénient dépend du contexte spécifique, mais pour les débutants, il est probablement plus simple d'avoir sous les yeux une liste de toutes les fonctionnalités plutôt que d'installer des paquets pour Python, comme dans le cas de duplicity.

Un petit détail supplémentaire : le programme écrit activement une base de données locale SQLite au nom de l'utilisateur qui lance la sauvegarde, il est donc nécessaire de faire attention à indiquer correctement la base appropriée à chaque lancement du processus en utilisant la CLI. Lors de l'utilisation via GUI ou WEBGUI, les détails seront cachés à l'utilisateur.

Examinons les indicateurs que cette solution peut fournir :

Si l'on désactive le chiffrement (ce que le WEBGUI ne recommande pas), les résultats sont les suivants :

Temps d'exécution :

Lancement 1
Lancement 2
Lancement 3

20m43s
20m13s
20m28s

5m21s
5m40s
5m35s

7m36s
7m54s
7m49s

Avec le chiffrement activé, utilisant aes, cela donne :

Temps d'exécution :

Lancement 1
Lancement 2
Lancement 3

29m9s
30m1s
29m54s

5m29s
6m2s
5m54s

8m44s
9m12s
9m1s

Et si l'on utilise le programme externe gnupg, les résultats sont les suivants :

Lancement 1
Lancement 2
Lancement 3

26m6s
26m35s
26m17s

5m20s
5m48s
5m40s

8m12s
8m42s
8m15s

Comme on peut le voir, le programme peut fonctionner en plusieurs fils d'exécution, mais cela ne le rend pas plus performant, et si l'on compare le travail de chiffrement, le lancement du programme externe
s'est avéré plus rapide que l'utilisation de la bibliothèque du package Mono. Cela peut être dû au fait que le programme externe est mieux optimisé.

Un aspect positif est également le fait que la taille du référentiel correspond exactement à la quantité réelle de données modifiées, c'est-à-dire que duplicati a détecté le renommage du répertoire et a correctement traité cette situation. Cela peut être constaté lors de l'exécution du second test.

Dans l'ensemble, des impressions globalement positives sur le programme, y compris une bonne convivialité pour les débutants.

Résultats

Les deux candidats ont travaillé assez lentement, mais en comparaison avec le tar classique, il y a un progrès, au moins pour duplicati. Le prix de ce progrès est également clair : une charge notable.
du processeur. Dans l'ensemble, il n'y a pas de déviations particulières dans la prévision des résultats.

Conclusions

Si l'on n'est pas pressé et qu'il y a une marge de processeur, n'importe quelle solution examinée conviendra, en tout cas un travail considérable a été réalisé, qu'il ne vaut pas la peine de répéter en écrivant des scripts d'enveloppement au-dessus de tar. La présence de chiffrement est une caractéristique très nécessaire si le serveur de stockage des sauvegardes ne peut pas être entièrement fiable.

Si l'on compare avec des solutions basées sur rsync — les performances peuvent être inférieures de plusieurs fois, même si, en version pure, tar a fonctionné plus rapidement que rsync de 20 à 30%.
Il y a des économies sur la taille du référentiel, mais seulement avec duplicati.

Annonce

Sauvegarde, partie 1 : Pourquoi faire des sauvegardes, aperçu des méthodes et technologies
Sauvegarde, partie 2 : Revue et test des outils de sauvegarde basés sur rsync
Sauvegarde, partie 3 : Aperçu et test de duplicity, duplicati, deja dup
Sauvegarde, partie 4 : Aperçu et test de zbackup, restic, borgbackup
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