Cette note traite des outils de sauvegarde qui effectuent des sauvegardes en créant des archives sur un serveur de sauvegarde.
Parmi ceux qui répondent aux exigences figurent la duplicité (qui possède une belle interface sous forme de déjà dup) et la duplication.
Dar est un autre outil de sauvegarde très remarquable, mais comme il dispose d'une liste d'options très étendue - la méthodologie de test couvre à peine 10 % de ce dont il est capable - nous ne le testons pas dans le cadre du cycle actuel.
Résultats attendus
Étant donné que les deux candidats créent des archives d’une manière ou d’une autre, le tar ordinaire peut être utilisé comme guide.
De plus, nous évaluerons dans quelle mesure le stockage des données sur le serveur de stockage est optimisé en créant des copies de sauvegarde contenant uniquement la différence entre une copie complète et l'état actuel des fichiers, ou entre les archives précédentes et actuelles (incrémentielles, décrémentales, etc.). .
Comportement lors de la création de sauvegardes :
- Un nombre relativement faible de fichiers sur le serveur de stockage de sauvegarde (comparable au nombre de copies de sauvegarde ou à la taille des données en Go), mais leur taille est assez importante (des dizaines à des centaines de mégaoctets).
- La taille du référentiel n'inclura que les modifications - aucun doublon ne sera stocké, donc la taille du référentiel sera plus petite qu'avec un logiciel basé sur rsync.
- Attendez-vous à une charge CPU importante lors de l'utilisation de la compression et/ou du chiffrement, et probablement à une charge réseau et disque assez élevée si le processus d'archivage et/ou de chiffrement est exécuté sur un serveur de stockage de sauvegarde.
Exécutons la commande suivante comme valeur de référence :
cd /src/dir; tar -cf - * | ssh backup_server "cat > /backup/dir/archive.tar"Les résultats de l'exécution ont été les suivants :
Temps d'exécution 3m12s. On peut voir que la vitesse est limitée par le sous-système disque du serveur de stockage de sauvegarde, comme dans l'exemple avec . Seulement un peu plus vite, parce que... l'enregistrement va dans un seul fichier.
De plus, pour évaluer la compression, exécutons la même option, mais activons 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:
Temps d'exécution 10m11s. Le goulot d'étranglement est très probablement dû au compresseur à flux unique situé à la réception.
La même commande, mais avec compression transférée au serveur avec les données d'origine pour tester l'hypothèse selon laquelle le goulot d'étranglement est un compresseur monothread.
cd /src/dir; tar -czf - * | ssh backup_server "cat > /backup/dir/archive.tgz"Cela s'est passé comme ceci :
Le temps d'exécution était de 9m37s. La charge sur un noyau par le compresseur est clairement visible, car La vitesse de transfert réseau et la charge sur le sous-système du disque source sont similaires.
Pour évaluer le cryptage, vous pouvez utiliser openssl ou gpg en connectant une commande supplémentaire openssl ou gpg dans un tuyau. Pour référence, il y aura une commande comme celle-ci :
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 sont sortis comme ceci :
Le temps d'exécution s'est avéré être de 10 min 30 s, puisque 2 processus étaient en cours d'exécution du côté réception - le goulot d'étranglement est encore une fois un compresseur monothread, plus une petite surcharge de chiffrement.
UPD: A la demande de bliznezz j'ajoute des tests avec pigz. Si vous utilisez uniquement le compresseur, cela prendrait 6 minutes 30, si vous ajoutez également le cryptage, cela prendrait environ 7 minutes. Le creux dans le graphique du bas est un cache disque non vidé :
Tests en double
Duplicity est un logiciel python de sauvegarde en créant des archives cryptées au format tar.
Pour les archives incrémentielles, librsync est utilisé, vous pouvez donc vous attendre au comportement décrit dans .
Les sauvegardes peuvent être chiffrées et signées à l'aide de gnupg, ce qui est important lorsque vous utilisez différents fournisseurs pour stocker les sauvegardes (s3, backblaze, gdrive, etc.)
Voyons quels sont les résultats :
Voici les résultats que nous avons obtenus en exécutant sans cryptage
divulgacher
Durée d'exécution de chaque test :
Lancement 1
Lancement 2
Lancement 3
16m33s
17m20s
16m30s
8m29s
9m3s
8m45s
5m21s
6m04s
5m53s
Et voici les résultats lorsque le chiffrement gnupg est activé, avec une taille de clé de 2048 bits :
Temps de fonctionnement sur les mêmes données, avec cryptage :
Lancement 1
Lancement 2
Lancement 3
17m22s
17m32s
17m28s
8m52s
9m13s
9m3s
5m48s
5m40s
5m30s
La taille du bloc a été indiquée - 512 mégaoctets, ce qui est clairement visible sur les graphiques ; La charge du processeur est en fait restée à 50 %, ce qui signifie que le programme n'utilise pas plus d'un cœur de processeur.
Le principe de fonctionnement du programme est également assez clairement visible : ils ont pris une donnée, l'ont compressée et l'ont envoyée à un serveur de stockage de sauvegarde, ce qui peut être assez lent.
Une autre caractéristique est la durée d'exécution prévisible du programme, qui dépend uniquement de la taille des données modifiées.
L'activation du cryptage n'a pas augmenté de manière significative la durée d'exécution du programme, mais a augmenté la charge du processeur d'environ 10 %, ce qui peut être un bonus assez appréciable.
Malheureusement, ce programme n'a pas pu détecter correctement la situation avec le renommage du répertoire, et la taille du référentiel résultant s'est avérée égale à la taille des modifications (c'est-à-dire tous les 18 Go), mais la possibilité d'utiliser un serveur non fiable pour la sauvegarde est clairement couvre ce comportement.
Tests en double
Ce logiciel est écrit en C# et s'exécute à l'aide d'un ensemble de bibliothèques de Mono. Il existe une version GUI ainsi qu'une version CLI.
La liste approximative des principales fonctionnalités est similaire à celle de Duplicity, y compris divers fournisseurs de stockage de sauvegarde. Cependant, contrairement à Duplicity, la plupart des fonctionnalités sont disponibles sans outils tiers. Que ce soit un plus ou un moins dépend du cas spécifique, mais pour les débutants, il est probablement plus facile d'avoir une liste de toutes les fonctionnalités devant eux à la fois, plutôt que de devoir installer en plus des packages pour python, comme c'est le cas. le cas de la duplicité.
Autre petite nuance - le programme écrit activement une base de données SQLite locale au nom de l'utilisateur qui démarre la sauvegarde, vous devez donc également vous assurer que la base de données requise est correctement spécifiée à chaque fois que le processus est démarré à l'aide du cli. Lorsque vous travaillez via GUI ou WEBGUI, les détails seront cachés à l'utilisateur.
Voyons quels indicateurs cette solution peut produire :
Si vous désactivez le cryptage (et WEBGUI ne recommande pas de le faire), les résultats sont les suivants :
Heures d'ouverture:
Lancement 1
Lancement 2
Lancement 3
20m43s
20m13s
20m28s
5m21s
5m40s
5m35s
7m36s
7m54s
7m49s
Avec le cryptage activé, en utilisant aes, cela ressemble à ceci :
Heures d'ouverture:
Lancement 1
Lancement 2
Lancement 3
29m9s
30m1s
29m54s
5m29s
6m2s
5m54s
8m44s
9m12s
9m1s
Et si vous utilisez le programme externe gnupg, les résultats suivants apparaissent :
Lancement 1
Lancement 2
Lancement 3
26m6s
26m35s
26m17s
5m20s
5m48s
5m40s
8m12s
8m42s
8m15s
Comme vous pouvez le constater, le programme peut fonctionner sur plusieurs threads, mais cela n'en fait pas une solution plus productive, et si vous comparez le travail de cryptage, il lance un programme externe.
s'est avéré plus rapide que d'utiliser la bibliothèque de l'ensemble Mono. Cela peut être dû au fait que le programme externe est plus optimisé.
Une autre bonne chose était le fait que la taille du référentiel prend exactement autant que les données réellement modifiées, c'est-à-dire duplicati a détecté un changement de nom de répertoire et a géré cette situation correctement. Cela peut être vu lors de l’exécution du deuxième test.
Dans l’ensemble, impressions plutôt positives du programme, notamment le fait qu’il soit plutôt convivial avec les débutants.
résultats
Les deux candidats ont travaillé plutôt lentement, mais en général, par rapport au tar ordinaire, il y a des progrès, du moins avec les duplications. Le prix de ces progrès est également clair : un fardeau considérable
processeur. En général, il n'y a pas d'écarts particuliers dans la prévision des résultats.
résultats
Si vous n'avez pas besoin de vous précipiter n'importe où et que vous disposez également d'un processeur de rechange, n'importe laquelle des solutions envisagées fera l'affaire. Dans tous les cas, beaucoup de travail a été effectué qui ne devrait pas être répété en écrivant des scripts wrapper au-dessus de tar. . La présence d'un cryptage est une propriété très nécessaire si le serveur de stockage des copies de sauvegarde n'est pas entièrement fiable.
Par rapport aux solutions basées - les performances peuvent être plusieurs fois pires, malgré le fait que, sous sa forme pure, tar fonctionnait 20 à 30 % plus rapidement que rsync.
Il y a des économies sur la taille du référentiel, mais uniquement avec des duplications.
annonce
Sauvegarde Partie 3 : Examiner et tester la duplicité, duplicati, deja dup
Sauvegarde Partie 4 : Examen et test de zbackup, restic, borgbackup
Sauvegarde Partie 5 : Tester la sauvegarde bacula et veeam pour Linux
Sauvegarde Partie 6 : Comparaison des outils de sauvegarde
Sauvegarde Partie 7 : Conclusions
Posté par: Pavel Demkovitch
Source: habr.com