Restic: Lent, bien qu'il vérifie simplement les horodatages

Créé le 17 févr. 2016  ·  5Commentaires  ·  Source: restic/restic

J'ai 164809 fichiers à sauvegarder régulièrement (environ 60 Go)... Chaque fois que j'exécute une "sauvegarde restic", le rapport ne dépasse pas 33 Mo/s et vérifie avec strace qu'il ne fait que des appels lstat().

Cela représente environ 20 minutes par sauvegarde. Je me demande ce que fait restic, car étant presque tous les fichiers non modifiés, il affiche les 33 Mo/s stables et je comprends qu'il suffit de les lstat(), ce qui est exactement ce que restic fait déjà à la première étape de la sauvegarde juste pour montrer la taille totale, en 6 ou 7 secondes.

Est-ce juste le temps CPU passé à vérifier le contenu de ce même fichier/horodatage déjà présent dans un instantané précédent ?

feature enhancement

Commentaire le plus utile

Oui, ce sera probablement la raison. Pour ce cas d'utilisation particulier, il existe une solution de contournement : utilisez l'option -f ( --force ) pour la commande backup , qui lira à nouveau tous les fichiers localement et ne chargera pas les métadonnées du dépôt . Cela devrait être rapide.

Tous les 5 commentaires

Pour le moment, les métadonnées des fichiers et des répertoires ne sont pas mises en cache, mais chargées (et déchiffrées) à partir du référentiel. Ceci est fait une fois par répertoire. Je prévois de mettre en cache les métadonnées localement, ce qui n'est pas encore implémenté mais devrait accélérer considérablement les sauvegardes "incrémentales".

salut

Cela pourrait-il également entraîner de mauvaises performances pour les sauvegardes incrémentielles sur une connexion WAN lente ?

Je viens de sauvegarder un dossier contenant plus de 9 000 fichiers et 250 Mo sur un serveur s3 distant. Les deux ordinateurs sont connectés avec une connexion Internet asymétrique de 50/5 mbit/s vers le bas et vers le haut.

La sauvegarde initiale a pris environ 5 minutes et semblait assez raisonnable. Mais une deuxième sauvegarde peu de temps après a pris presque deux fois plus de temps ! Un dossier avec moins de fichiers semble être beaucoup plus rapide.

Oui, ce sera probablement la raison. Pour ce cas d'utilisation particulier, il existe une solution de contournement : utilisez l'option -f ( --force ) pour la commande backup , qui lira à nouveau tous les fichiers localement et ne chargera pas les métadonnées du dépôt . Cela devrait être rapide.

Merci beaucoup! Fonctionne comme un charme!

Nous avons ajouté un cache local de métadonnées (voir #1040) dans la branche master, je pense que ce problème est résolu et donc je le ferme. Merci!

Cette page vous a été utile?
0 / 5 - 0 notes