Restic: manche gros pruneau beaucoup plus efficace

Avec les performances des restaurations pour les dépôts/dépôts volumineux avec des fichiers volumineux désormais résolus par la branche hors service de @ifedorenko , il semble que ce soit le prochain rocher pour l'utilisation de restic dans des environnements de plusieurs téraoctets où le dépôt n'est pas sur local disque et n'est pas accessible via le serveur REST sur une interface de bouclage.

Actuellement, un élagage vide (élagage d'un instantané identique à 100 % à un instantané précédent) par rapport à un référentiel dans un compartiment S3 local AZ sur des instances AWS haut de gamme avec une bande passante théorique de 10 gbit/s s'exécute à :

1) création d'un nouvel index -- ~160 packs/seconde
2) trouver des données encore utilisées -- 56 secondes au total
3) packs de réécriture -- ~3 packs/seconde

160 packs/seconde est lent, mais toujours tolérable (durée d'exécution d'environ 80 minutes contre un repo de 3 To).

Mais la réécriture @ 3 packs/seconde durera près de 10 heures, même pour mon pruneau noop (supprimera 0 packs et réécrira 111098 packs, cela libère 180,699 GiB). Pour un élagage significatif sur un dépôt volumineux, vous gèlez les nouvelles sauvegardes pendant plus de 24 heures.

Il semble que les réécritures de packs se produisent actuellement dans un seul thread, donc permettre que cela s'exécute sur plusieurs travailleurs pourrait aider un peu, même si l'approche actuelle de copie puis de purge est maintenue.

Personnellement, je ne passerais pas de temps à optimiser la mise en œuvre actuelle du pruneau bloquant, je pense que le pruneau non bloquant est une meilleure solution à long terme.

J'ai travaillé dessus récemment. Voici ce que j'ai fait :

• Chargez l'index existant au lieu d'analyser tous les packs (puis analysez tous les packs qui ne figuraient pas dans l'index)
• Balayage parallèle des instantanés pour les blobs utilisés
• Réécriture parallélisée de packs partiellement utilisés
• Ecrire le nouvel index en utilisant les informations d'index déjà en mémoire

Je travaille actuellement pour déterminer le niveau de parallélisme à utiliser pour réécrire les packs partiellement utilisés (je prévois de baser cela sur le nombre configuré de connexions pour le backend). Je dois également faire beaucoup plus de tests dans divers scénarios d'erreur.

Voici quelques chiffres de performances (en utilisant un référentiel avec 875 Gio de données, environ 180 000 packs et 36 instantanés, en utilisant un serveur de repos en boucle comme backend) :

• Code actuel :
  
  
  
  • 35-40 minutes (chacun) pour construire l'index au début et à la fin de la prune (70-80 minutes au total)
  
  
  • 4-5 minutes pour trouver des blobs usagés
  
  
  • Quelques secondes pour réécrire les packs partiellement utilisés
  
  
• Mes modifications pour l'instant :
  
  
  
  • Quelques secondes pour charger l'index existant (un peu plus longtemps s'il faut scanner des packs non indexés)
  
  
  • Moins de 2 minutes pour trouver des blobs usagés
  
  
  • Quelques secondes pour écrire le nouvel index
  
  

Je prévois également de mettre en place un cas de test généré qui impliquera beaucoup plus de réécriture de pack.

Courtney :

Cela semble super prometteur ! Vous vouliez confirmer qu'il s'agit bien de la succursale dans laquelle vous travaillez ? Je suis content de tester.

https://github.com/cbane/restic/tree/prune-aggressive

Non, cette branche fait partie du fork du référentiel principal. Je n'ai pas encore poussé mes modifications à un endroit public. Je devrais être en mesure de pousser ma version de travail en cours sur GitHub dans quelques jours afin que vous puissiez l'essayer.

OK, j'ai une version qui devrait être prête à être essayée par d'autres personnes. C'est sur cette branche : https://github.com/cbane/restic/tree/prune-speedup

Limites actuelles :

• Je n'ai implémenté aucun réglage automatique du nombre de travailleurs de reconditionnement. Pour l'instant, définissez la variable d'environnement RESTIC_REPACK_WORKERS sur le nombre de travailleurs que vous souhaitez utiliser. Il sera par défaut à 4 s'il n'est pas défini.
• Je dois travailler sur la gestion des erreurs lors du remballage. Je n'ai apporté aucune modification réelle par rapport au remballage à un seul thread existant ; Je dois examiner les différents cas d'erreur et m'assurer que le reconditionnement en parallèle ne pose aucun problème.

Ça a l'air incroyable. Merci pour votre travail!

J'ai un peu testé cela avec une copie de 3 To + repo dans Amazon S3 et jusqu'à présent, cela semble incroyable. Un pruneau de remballage qui aurait pris des semaines se termine maintenant en moins d'une heure, et cela utilise un EBS relativement lent comme espace tmp.

Un vrai changeur de jeu ici! Excellent travail, @cbane !

Eek, j'ai réalisé que j'avais mal chronométré la course.

Un domaine qui est encore à thread unique et qui semble pouvoir bénéficier de la parallélisation est l'étape de "vérification des packs non indexés" - qui peut encore prendre 3 à 4 heures dans les dépôts de plusieurs téraoctets - mais c'est toujours un énorme, énorme amélioration, merci!

@cbane Je n'ai pas pu ouvrir de problème contre votre fork, alors faites-moi savoir s'il y a un meilleur endroit pour ceux-ci.

Lors d'un autre test, le repack a échoué à la toute fin (réécriture du dernier pack), exécuté avec 32 workers :

found 1396709 of 2257203 data blobs still in use, removing 860494 blobs
will remove 0 invalid files
will delete 119301 packs and rewrite 88485 packs, this frees 896.269 GiB
using 32 repack workers
Save(<data/c136027b25>) returned error, retrying after 723.31998ms: client.PutObject: Put https://ak-logical-db-backup.s3.dualstack.us-west-1.amazonaws.com/xxxxx: Connection closed by foreign host https://ak-logical-db-backup.s3.dualstack.us-west-1.amazonaws.com/xxxx. Retry again.
Save(<data/09d4692900>) returned error, retrying after 538.771816ms: client.PutObject: Put https://ak-logical-db-backup.s3.dualstack.us-west-1.amazonaws.com/xxxxx: Connection closed by foreign host https://ak-logical-db-backup.s3.dualstack.us-west-1.amazonaws.com/xxxxx. Retry again.
Save(<data/23d0d4f842>) returned error, retrying after 617.601934ms: client.PutObject: Put https://ak-logical-db-backup.s3.dualstack.us-west-1.amazonaws.com/xxxx: Connection closed by foreign host https://ak-logical-db-backup.s3.dualstack.us-west-1.amazonaws.com/xxxx. Retry again.
[10:02] 100.00%  88484 / 88485 packs rewritten
panic: reporting in a non-running Progress

goroutine 386596 [running]:
github.com/restic/restic/internal/restic.(*Progress).Report(0xc42011c2c0, 0x0, 0x0, 0x0, 0x0, 0x1, 0x0)
        internal/restic/progress.go:122 +0x242
github.com/restic/restic/internal/repository.Repack.func2(0x8, 0xe17f58)
        internal/repository/repack.go:66 +0x136
github.com/restic/restic/vendor/golang.org/x/sync/errgroup.(*Group).Go.func1(0xc4389246c0, 0xc56f509160)
        vendor/golang.org/x/sync/errgroup/errgroup.go:57 +0x57
created by github.com/restic/restic/vendor/golang.org/x/sync/errgroup.(*Group).Go
        vendor/golang.org/x/sync/errgroup/errgroup.go:54 +0x66

J'ai une nouvelle version disponible, dans la même succursale qu'avant. J'ai également rebasé contre master .

Voici les principaux changements par rapport à la version précédente :

• Conversion du remballage de chaque travailleur effectuant toutes les étapes du remballage d'un seul paquet en un pipeline.
• Correction du crash signalé à la fin du remballage.
• Le reconditionnement ajuste désormais automatiquement le nombre de nœuds de calcul pour les étapes du pipeline en fonction du nombre de processeurs et de la limite de connexion configurée pour le backend. (La variable d'environnement RESTIC_REPACK_WORKERS n'est plus utilisée.)
• Modifications mineures pour trouver des blobs utilisés.
• Parallélisation de l'analyse des packs inconnus.

Je veux encore faire un peu plus de travail sur la recherche de blobs utilisés. Actuellement, chaque instantané est traité par un seul agent. Cela peut laisser des ressources CPU inutilisées s'il y a moins d'instantanés que de CPU, ou s'il existe des différences de taille importantes entre les instantanés. J'aimerais qu'il répartisse le traitement des sous-arbres sur différents travailleurs; Je pense que je sais comment faire cela, j'ai juste besoin de le mettre en œuvre.

Je pencherais pour continuer à discuter de ce problème (ou de la future demande d'extraction pour cela), afin que tout reste ici dans le référentiel principal au lieu d'être étalé.

Juste testé. Il résout le crash à la fin du remballage et fonctionne vraiment, vraiment bien.

Le seul endroit supplémentaire qui pourrait bénéficier d'un parallélisme accru est la suppression des packs, qui est actuellement monothread.

Cela mord particulièrement fort lors du premier élagage d'un dépôt qui n'était pas élagable auparavant, car il y a _beaucoup_ de packs qui doivent être supprimés.

Même avec une suppression à un seul thread, cependant, un oubli/élagage quotidien contre un référentiel de packs de 1,7 To et 356 000 qui réécrit les packs de 14,7 000 et supprime les packs de 33 000 prend maintenant un peu moins de 20 minutes.
Auparavant, il était impossible de tailler du tout.

Excellent travail, merci !

OK, j'ai une autre version disponible. Le seul véritable changement cette fois est qu'il supprime désormais les packs inutilisés en parallèle (plus quelques modifications mineures à certaines modifications précédentes). J'ai implémenté l'analyse d'instantané modifiée, mais cela n'a pas donné une accélération suffisante et il n'y avait pas de bon moyen de signaler la progression à l'utilisateur, alors je l'ai supprimée à nouveau.

Je prévois d'ouvrir une pull request pour cela bientôt, en supposant que rien ne s'est cassé. (Je vais d'abord nettoyer l'historique.) @fd0 , voulez-vous d'abord y jeter un œil ?

A très bien fonctionné lors de notre test. Réécriture de packs de 30 000 en 225 secondes, suppression de packs de 73 000 en 50 secondes.

Le temps d'exécution total par rapport à un référentiel de 1,74 Tio dans S3 avec 32 instantanés survivants était d'un peu plus de 6 minutes.

Travail brillant.

@cbane j'ai essayé votre branche https://github.com/cbane/restic/tree/prune-speedup

mais c'est l'erreur que je reçois :(

root<strong i="9">@srv</strong> ~/restic-backups # restic --no-cache prune
repository 49b87c6a opened successfully, password is correct
listing files in repo
loading index for repo
[0:28] 1.01%  30 / 2982 index files
pack cbbebd8d already present in the index
github.com/restic/restic/internal/index.(*Index).AddPack
    internal/index/index.go:266
github.com/restic/restic/internal/index.Load.func1
    internal/index/index.go:230
github.com/restic/restic/internal/repository.(*Repository).List.func1
    internal/repository/repository.go:640
github.com/restic/restic/internal/backend.(*RetryBackend).List.func1.1
    internal/backend/backend_retry.go:133
github.com/restic/restic/internal/backend/rest.(*Backend).listv2
    internal/backend/rest/rest.go:423
github.com/restic/restic/internal/backend/rest.(*Backend).List
    internal/backend/rest/rest.go:358
github.com/restic/restic/internal/backend.(*RetryBackend).List.func1
    internal/backend/backend_retry.go:127
github.com/cenkalti/backoff.RetryNotify
    vendor/github.com/cenkalti/backoff/retry.go:37
github.com/restic/restic/internal/backend.(*RetryBackend).retry
    internal/backend/backend_retry.go:36
github.com/restic/restic/internal/backend.(*RetryBackend).List
    internal/backend/backend_retry.go:126
github.com/restic/restic/internal/repository.(*Repository).List
    internal/repository/repository.go:634
github.com/restic/restic/internal/index.Load
    internal/index/index.go:202
main.pruneRepository
    cmd/restic/cmd_prune.go:202
main.runPrune
    cmd/restic/cmd_prune.go:128
main.glob..func18
    cmd/restic/cmd_prune.go:28
github.com/spf13/cobra.(*Command).execute
    vendor/github.com/spf13/cobra/command.go:762
github.com/spf13/cobra.(*Command).ExecuteC
    vendor/github.com/spf13/cobra/command.go:852
github.com/spf13/cobra.(*Command).Execute
    vendor/github.com/spf13/cobra/command.go:800
main.main
    cmd/restic/main.go:86
runtime.main
    /snap/go/3947/src/runtime/proc.go:200
runtime.goexit
    /snap/go/3947/src/runtime/asm_amd64.s:1337

@antetna Il semble que votre référentiel comporte plusieurs fichiers d'index couvrant les mêmes packs. Je ne sais pas comment cela peut arriver, mais j'ai ajouté un cas de test à la suite de tests et je peux reproduire votre erreur. Je vais travailler à le réparer.

@antetna OK, je viens de pousser une nouvelle version dans la même branche (pas d'avance rapide) qui fonctionne avec mon cas de test d'index en double. Pourriez-vous essayer?

Je prévois d'ouvrir bientôt une pull request avec la version actuelle de cette branche, à moins que quelqu'un d'autre ne remarque des problèmes.

Merci beaucoup @cbane ! L'élagage standard a pris environ 55 heures pour élaguer mon référentiel d'instantanés d'environ 860 Go 12000+. Avec votre approche parallèle plus agressive, il est tombé à un peu plus de 3 heures.

Salut @cbane , travail incroyable !

Exécuter ce PR ici sur Debian 9 amd64, compilé avec Go 1.12.1, obtenant l'erreur suivante après 220 minutes d'exécution sur mon référentiel de 30 To :

checking for packs not in index
[0:52] 16.45%  178 / 1082 packs
[5:23] 100.00%  1082 / 1082 packs
repository contains 3213929 packs (259446787 blobs) with 15.025 TiB
processed 259446787 blobs: 30090 duplicate blobs, 4.906 GiB duplicate
load all snapshots
find data that is still in use for 3 snapshots
[0:04] 0.00%  0 / 3 snapshots
tree 6f144a19eaae0e81518b396bfdfc9dd5c6c035bdba28c6a90d6f70e692aa1c55 not found in repository
github.com/restic/restic/internal/repository.(*Repository).LoadTree
        internal/repository/repository.go:707
github.com/restic/restic/internal/restic.FindUsedBlobs.func3
        internal/restic/find.go:52
github.com/restic/restic/internal/restic.FindUsedBlobs.func3
        internal/restic/find.go:74
github.com/restic/restic/internal/restic.FindUsedBlobs.func3
        internal/restic/find.go:74
github.com/restic/restic/internal/restic.FindUsedBlobs.func3
        internal/restic/find.go:74
github.com/restic/restic/internal/restic.FindUsedBlobs.func4
        internal/restic/find.go:89
gopkg.in/tomb%2ev2.(*Tomb).run
        vendor/gopkg.in/tomb.v2/tomb.go:163
runtime.goexit
        /usr/local/go/src/runtime/asm_amd64.s:1337

Comment dois-je m'en remettre ?

Merci,
--Durval.

@DurvalMenezes Il semble que votre référentiel manque de certains fichiers de pack. L'avez-vous déjà taillé ? Est-ce que restic check réussit ? Si ce n'est pas le cas, cela devrait vous donner une idée plus détaillée de ce qui ne va pas.

Vous pourrez peut-être récupérer quelque peu en exécutant restic rebuild-index , puis en exécutant une nouvelle sauvegarde. Si un élément des packs manquants est toujours disponible à l'emplacement en cours de sauvegarde, une nouvelle sauvegarde l'ajoutera à nouveau au référentiel. Cela pourrait permettre à vos sauvegardes existantes de fonctionner à nouveau. Si cela ne résout pas le problème, je pense que vous devrez oublier les instantanés concernés avant de pouvoir faire un élagage.

Merci pour la réponse, @cbane. Plus, ci-dessous:

L'avez-vous déjà taillé ?

Non, c'est mon premier pruneau. Pour faire court : mon référentiel contient environ 95 instantanés de 3 arbres de terre locaux sur mon NAS ; ces 3 saletés totalisent ~30 To et ~60 millions de fichiers/sous-répertoires, et prennent de plus en plus de temps à sauvegarder, au point que la sauvegarde de seulement 24 heures de nouvelles données (moins de 10 Go) prenait plus de 24 heures à s'exécuter. Le conseil sur le forum était d'exécuter restic forget (ce que j'ai fait, ne laissant que les 3 derniers instantanés) puis restic prune , ce que j'ai d'abord fait en utilisant restic 0.9.5 (mais il a abandonné après ~ 24 heures en raison de OOM). J'ai ensuite mis à niveau la machine (une machine virtuelle sur Google Compute Cloud) à deux fois la RAM, puis j'ai utilisé votre PR, ce qui a donné l'erreur ci-dessus.

Est-ce que la vérification restic réussit ? Si ce n'est pas le cas, cela devrait vous donner une idée plus détaillée de ce qui ne va pas.

J'exécute restic check depuis 90 heures (également en utilisant votre PR), et jusqu'à présent, il m'a donné cette sortie : restic-check-PARTIAL_output.txt

Comme indiqué à la fin du fichier ci-dessus, restic check a affiché son dernier message ("vérifier les instantanés, les arbres et les blobs") il y a plus de 3 jours... Je commence à me demander si c'est bloqué et ne finira jamais :-/ En fait, un "strace" sur le processus montre qu'il ouvre le même fichier de cache local encore et encore :

```date ; strace -t -f -p 2608 -e openat 2>&1 | grep openat | egrep -v inachevé\|repris | diriger
mar 23 juillet 2019 00:41:59 UTC
[Pid 26508] 00:41:59 openat (AT_FDCWD, "/ tmp / restic-check-cache-370688148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / data / 53 / 53d242f8d6444bc2bd49e6689b4c7688fec8996c5e86863bf146a9eb28f54b5d", O_RDONLY | O_CLOEXEC) = 5
[Pid 2608] 00:41:59 openat (AT_FDCWD, "/ tmp / restic-check-cache-370688148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / data / 53 / 53d242f8d6444bc2bd49e6689b4c7688fec8996c5e86863bf146a9eb28f54b5d", O_RDONLY | O_CLOEXEC) = 10
[Pid 2615] 00:41:59 openat (AT_FDCWD, "/ tmp / restic-check-cache-370688148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / data / 53 / 53d242f8d6444bc2bd49e6689b4c7688fec8996c5e86863bf146a9eb28f54b5d", O_RDONLY | O_CLOEXEC) = 5
[Pid 5482] 00:41:59 openat (AT_FDCWD, "/ tmp / restic-check-cache-370688148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / data / 53 / 53d242f8d6444bc2bd49e6689b4c7688fec8996c5e86863bf146a9eb28f54b5d", O_RDONLY | O_CLOEXEC) = 5
[Pid 2615] 00:41:59 openat (AT_FDCWD, "/ tmp / restic-check-cache-370688148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / data / 53 / 53d242f8d6444bc2bd49e6689b4c7688fec8996c5e86863bf146a9eb28f54b5d", O_RDONLY | O_CLOEXEC) = 5
[Pid 3688] 00:41:59 openat (AT_FDCWD, "/ tmp / restic-check-cache-370688148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / data / 53 / 53d242f8d6444bc2bd49e6689b4c7688fec8996c5e86863bf146a9eb28f54b5d", O_RDONLY | O_CLOEXEC) = 5
[Pid 5482] 00:41:59 openat (AT_FDCWD, "/ tmp / restic-check-cache-370688148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / data / 53 / 53d242f8d6444bc2bd49e6689b4c7688fec8996c5e86863bf146a9eb28f54b5d", O_RDONLY | O_CLOEXEC) = 10
[Pid 2608] 00:41:59 openat (AT_FDCWD, "/ tmp / restic-check-cache-370688148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / data / 53 / 53d242f8d6444bc2bd49e6689b4c7688fec8996c5e86863bf146a9eb28f54b5d", O_RDONLY | O_CLOEXEC) = 11
[Pid 2638] 00:41:59 openat (AT_FDCWD, "/ tmp / restic-check-cache-370688148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / data / 53 / 53d242f8d6444bc2bd49e6689b4c7688fec8996c5e86863bf146a9eb28f54b5d", O_RDONLY | O_CLOEXEC) = 5
[Pid 2638] 00:41:59 openat (AT_FDCWD, "/ tmp / restic-check-cache-370688148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / data / 53 / 53d242f8d6444bc2bd49e6689b4c7688fec8996c5e86863bf146a9eb28f54b5d", O_RDONLY | O_CLOEXEC) = 5

And then, almost 10 hours later: 

mar 23 juillet 2019 10:14:27 UTC
[Pid 2632] 10:14:27 openat (AT_FDCWD, "/ tmp / restic-check-cache-370688148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / data / 53 / 53d242f8d6444bc2bd49e6689b4c7688fec8996c5e86863bf146a9eb28f54b5d", O_RDONLY | O_CLOEXEC) = 5
[Pid 2639] 10:14:28 openat (AT_FDCWD, "/ tmp / restic-check-cache-370688148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / data / 53 / 53d242f8d6444bc2bd49e6689b4c7688fec8996c5e86863bf146a9eb28f54b5d", O_RDONLY | O_CLOEXEC) = 5
[Pid 2634] 10:14:28 openat (AT_FDCWD, "/ tmp / restic-check-cache-370688148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / data / 53 / 53d242f8d6444bc2bd49e6689b4c7688fec8996c5e86863bf146a9eb28f54b5d", O_RDONLY | O_CLOEXEC) = 5
[Pid 2613] 10:14:28 openat (AT_FDCWD, "/ tmp / restic-check-cache-370688148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / data / 53 / 53d242f8d6444bc2bd49e6689b4c7688fec8996c5e86863bf146a9eb28f54b5d", O_RDONLY | O_CLOEXEC) = 5
[Pid 2634] 10:14:28 openat (AT_FDCWD, "/ tmp / restic-check-cache-370688148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / data / 53 / 53d242f8d6444bc2bd49e6689b4c7688fec8996c5e86863bf146a9eb28f54b5d", O_RDONLY | O_CLOEXEC) = 5
[Pid 3688] 10:14:28 openat (AT_FDCWD, "/ tmp / restic-check-cache-370688148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / data / 53 / 53d242f8d6444bc2bd49e6689b4c7688fec8996c5e86863bf146a9eb28f54b5d", O_RDONLY | O_CLOEXEC) = 5
[Pid 2617] 10:14:28 openat (AT_FDCWD, "/ tmp / restic-check-cache-370688148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / data / 53 / 53d242f8d6444bc2bd49e6689b4c7688fec8996c5e86863bf146a9eb28f54b5d", O_RDONLY | O_CLOEXEC) = 5
[Pid 3688] 10:14:28 openat (AT_FDCWD, "/ tmp / restic-check-cache-370688148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / data / 53 / 53d242f8d6444bc2bd49e6689b4c7688fec8996c5e86863bf146a9eb28f54b5d", O_RDONLY | O_CLOEXEC) = 5
[Pid 2634] 10:14:28 openat (AT_FDCWD, "/ tmp / restic-check-cache-370688148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / data / 53 / 53d242f8d6444bc2bd49e6689b4c7688fec8996c5e86863bf146a9eb28f54b5d", O_RDONLY | O_CLOEXEC) = 5
[Pid 2611] 10:14:28 openat (AT_FDCWD, "/ tmp / restic-check-cache-370688148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / data / 53 / 53d242f8d6444bc2bd49e6689b4c7688fec8996c5e86863bf146a9eb28f54b5d", O_RDONLY | O_CLOEXEC) = 5
```

Vous pourrez peut-être récupérer quelque peu en exécutant restic refresh-index, puis en exécutant une nouvelle sauvegarde. Si un élément des packs manquants est toujours disponible à l'emplacement en cours de sauvegarde, une nouvelle sauvegarde l'ajoutera à nouveau au référentiel. Cela pourrait faire fonctionner à nouveau vos sauvegardes existantes

Je pense que je vais essayer ceci ensuite; si ce restic check ne se termine pas dans les prochaines 24 heures, je le SIGINT puis exécuterai un restic rebuild-index . Pour l'indice de reconstruction, dois-je utiliser ce PR ? Le chef restic-maître ? Ou autre chose?

Merci encore,
--Durval.

Ouais, ça n'a pas l'air prometteur. La meilleure chose à faire est probablement de faire un restic rebuild-index , puis d'exécuter de nouvelles sauvegardes de vos trois répertoires, puis d'oublier tous les autres instantanés. Après cela, vous devriez être capable de réussir un restic prune .

Je n'ai pas touché au code rebuild-index , vous pouvez donc le faire avec la version de votre choix.

@cbane , juste pour vous tenir au courant : j'ai lancé un restic rebuild-index en utilisant votre PR il y a 5 jours (je comprends que n'importe quelle version ferait l'affaire, mais en utilisant la vôtre, cela simplifie les choses) et il fonctionne depuis. Après les premiers jours désespérés (lorsque l'extrapolation à partir des pourcentages semblait indiquer qu'il fonctionnerait pendant plus de 30 jours), il semble avoir pris de la vitesse et devrait fonctionner pendant "seulement" 10 jours de plus environ (du moins dans sa version actuelle phase de 'comptage des fichiers en dépôt').

En supposant que ce rebuild-index se termine correctement, le plan est alors d'exécuter un restic prune avec votre PR. Vous fera savoir comment ça se passe.

Tenir tout le monde au courant : mon crédit GCloud gratuit de 300 $ a pris fin, totalement dévoré par la machine virtuelle de 104 Go que j'ai dû créer pour exécuter le prune (et, je suppose, aussi le rebuild-index ). Je suis à court d'options :-/ Je mettrai à jour quand/si je trouve un moyen de sortir de ce pétrin.

J'ai essayé la branche "prune-speedup" et les résultats sont très prometteurs !

Back-end : S3

# bin/restic version
restic 0.9.5 compiled with go1.12.4 on linux/amd64
# bin/restic prune
repository 6240cd5d opened successfully, password is correct
counting files in repo
building new index for repo
[1:30:34] 100.00%  319784 / 319784 packs
repository contains 319784 packs (5554019 blobs) with 1.445 TiB
processed 5554019 blobs: 0 duplicate blobs, 0 B duplicate
load all snapshots
find data that is still in use for 30 snapshots
[3:38:52] 100.00%  30 / 30 snapshots
found 5376708 of 5554019 data blobs still in use, removing 177311 blobs
will remove 0 invalid files
will delete 3526 packs and rewrite 4850 packs, this frees 26.925 GiB
[1:28:21] 100.00%  4850 / 4850 packs rewritten
counting files in repo
[1:20:27] 100.00%  314240 / 314240 packs
finding old index files
saved new indexes as [b7029105 797145b1 0ed8981e 7f19c455 dff4d9be a52d8e7a 0cf9f266 ab32a9e4 f34331b3 84c84cbb 563896c9 9902e35d 817ef96c 6b4dcfef 32d3e18c 1d782d96 b12554dd d4b69bcf 8ec94a43 66cbd035 8e9cb96d d74b5246 ca7d7ca3 1f209708 9fe26189 28414ee2 88ff07fb 24280466 8757a1f9 8706ff35 5fab942b 549409c3 f781a762 9417afec 4b2361aa 6b43f992 8da8dfe7 54ec498e 5be6fb8a 17411b83 270f3ce3 ba520d35 95913ad0 f8f15108 cbc67971 a419ff7c 875cfcc7 13f55ece bd488aa4 7f5b588a cddd40b4 7a79d1ce bd7e3d0f 2cdcd635 ee6e28c3 98146287 50867bde 41a056ae 836ce971 e9451c8b 0f9cc7e6 52dedc04 c4e8e7f6 2e4966f0 ba4fa5b3 ddc9a766 b995fd36 fd6b3ac8 1c12bcc3 4c98c3c9 39ac7cd5 42ebf4c1 1a48465e b5245192 73a73c5e daa6ee8d d26ce697 9f84d9b3 bc371def b141466a 6906b3c1 282ce115 d8024363 10f0b924 ad4fad64 9450aada 31378365 65d785b3 98b085d0 768f420c f22512b3 be3223ba 031d5488 f2b7fcf6 87177471 fd269664 b239b89e 6bf972ea 0d6f8f36 87362542 fff9c2cd 5c85ac76 f91daae1 dc594a83 220bdc83]
remove 1459 old index files
[2:33] 100.00%  8376 / 8376 packs deleted
done
# 

Maintenant avec la version de développement :

# bin/restic_linux_amd64 version
restic 0.9.5-dev (compiled manually) compiled with go1.12.4 on linux/amd64
# bin/restic_linux_amd64 prune
repository 6240cd5d opened successfully, password is correct
counting files in repo
building new index for repo
[57:21] 100.00%  314240 / 314240 packs
repository contains 314240 packs (5376708 blobs) with 1.419 TiB
processed 5376708 blobs: 0 duplicate blobs, 0 B duplicate
load all snapshots
find data that is still in use for 29 snapshots
[1:48:18] 100.00%  29 / 29 snapshots
found 5356653 of 5376708 data blobs still in use, removing 20055 blobs
will remove 0 invalid files
will delete 212 packs and rewrite 1427 packs, this frees 3.114 GiB
[14:16] 100.00%  1427 / 1427 packs rewritten
counting files in repo
[57:47] 100.00%  313618 / 313618 packs
finding old index files
saved new indexes as [004d6eb2 630de131 1b85faed 0fb7a978 bc500e05 34f7d187 447c3b59 ada047d2 5430430e 768f606e a5c341ea a75059c5 71d0fbec c63f5c56 ba43e69d f47699f5 d7cd2587 5826bcae 6250ec67 6af77aa4 cbf8c1f9 a7809b5f c3242748 8bb7d037 8ca69481 5a8877c3 fb30ea48 4bdb6269 eeeba466 7cdc444a bc15ddd5 c5544612 b8a5004c 2879403a c33778b7 e692013a 41ce8a1d 55b4be0a 5714b820 1adca569 b06ccd6b 16467da7 79ed066a 64c7e397 43217ede af7350a4 73c65a0f 35260990 a232ea42 c843bfa5 332aded7 0e294517 26984755 3c36a14b 68b2024e 267bf0b2 a41c4f64 aa46affb c7a6e2ac 0d34c60f 766d21f0 0d7b8b41 4fea4363 a1a3c5cd 73809a0e 56a67410 25314d47 a32ded24 68feae36 78ef5cbb b051a740 6a51f900 d2ee860f 1ad44787 c6c4358d 89de2f69 a157bd2b 77995b94 3bc58934 b905be42 0a1df2e7 ba67a98c 263b5266 7a809abc 34ff6f07 d96adc12 8f69fc74 ebb053eb 8fb68f6a 11224e7d 990f61f8 764941fc ed95513b 1c17c8aa 3226a7cb 76988c78 e4d8f156 b4d4c952 8c379d51 e968f3c9 f9cfff55 464cf3e1 f9d23c32 136957e3 02e397b1]
remove 105 old index files
[0:32] 100.00%  1639 / 1639 packs deleted
done
#

Cela ressemble à une grande amélioration! félicitations!
Je publierai plus de résultats si j'essaie plus de machines dans les semaines à venir.

@fbarbeira D'après la sortie que vous avez publiée, il semble que vous n'utilisiez pas réellement ma version améliorée. Voici la sortie que j'obtiens lorsque je taille mon gros référentiel sur Backblaze B2 :

repository 399dfab1 opened successfully, password is correct
listing files in repo
loading index for repo
[0:02] 100.00%  71 / 71 index files
checking for packs not in index
repository contains 208840 packs (1675252 blobs) with 1006.203 GiB
processed 1675252 blobs: 0 duplicate blobs, 0 B duplicate
load all snapshots
find data that is still in use for 32 snapshots
[0:16] 100.00%  32 / 32 snapshots
found 1675113 of 1675252 data blobs still in use, removing 139 blobs
will remove 0 invalid files
will delete 4 packs and rewrite 24 packs, this frees 26.404 MiB
[3:31] 100.00%  24 / 24 packs rewritten
saving new index
[10:31] 70 index files
remove 71 old index files
[0:04] 100.00%  28 / 28 packs deleted
done

La principale source de lenteur est la vitesse de téléchargement limitée sur mon modem câble.

La sortie de restic version devrait également ressembler à ceci :

restic 0.9.5 (v0.9.5-31-g09b92d6d) compiled with go1.11.6 on linux/amd64

Avez-vous l'intention de fusionner cette mise à jour @fd0 ?

J'apprécierais beaucoup cette amélioration pour en faire une version officielle également. La rotation des sauvegardes est devenue si lente que le restic commence à ne plus vraiment être une option, malheureusement.

@cbane , un élément qui n'est certainement pas un bloqueur, mais je pense que je signalerais: les réécritures du pack prune deviennent plus lentes à mesure que les repos augmentent.

Par exemple, l'étape de réécriture de pack pour un dépôt de pack de 3 984 097 réécrit les packs à 110 packs/seconde sur un i3.8xlarge communiquant avec un compartiment S3 dans la même AZ.

Le même combo instance + backing store avec un dépôt plus petit (450 473) réécrit à 200 packs/seconde.

@pmkane , est-ce que cette disparité de vitesse existe même s'ils réécrivent le même nombre de packs ? Ou est-il toujours là, peu importe le nombre de packs réécrits ? De plus, est-ce juste la réécriture du pack, ou est-ce que d'autres étapes ralentissent également ?

Il n'y a rien d'évident dans le code qui le ralentirait à mesure que le référentiel grossit. J'ai ajouté la prise en charge du profilage à l'étape de réécriture du pack dans ma version locale pour aider à retrouver la source de la lenteur. Cependant, mon plus grand référentiel ne contient qu'environ 200 000 packs, ce qui ne me donne pas une bonne comparaison avec ce que vous voyez. Seriez-vous prêt à l'exécuter avec le profilage activé et à rendre les fichiers de sortie disponibles ?

@cbane , je ne sais pas si c'est une fonction du nombre de packs ou de la taille du dépôt. Je peux exécuter des tests sur un duplicata de notre dépôt plus petit et voir. Heureux d'exécuter une version avec profilage et de partager les résultats.

Voici quelques exemples de minutages pour le dépôt du pack 460k - minutages de 3,7 mm :

chargement de l'index pour le dépôt
[0:01] 100,00 % 154 / 154 fichiers d'index

trouver les données qui sont encore utilisées pour 36 instantanés
[0:34] 100,00 % 36 / 36 instantanés
[0:26] 100,00 % 4555 / 4555 packs réécrits (175 packs/seconde)
[0:21] 151 fichiers d'index
[0:01] 100.00% 11401 / 11401 packs supprimés

Repo de 3 752 505 packs. Il convient également de noter que l'utilisation de la mémoire passe de ~ 1 Go de RSS à 8 Go de RSS à l'étape "Rechercher les données encore utilisées pour 14 instantanés". Restic se retrouve finalement à ~ 16 Go RSS. Peut-être inévitable, étant donné la grande taille du dépôt :

chargement de l'index pour le dépôt
[0:33] 100,00 % 1188 / 1188 fichiers d'index

trouver les données qui sont encore utilisées pour 14 instantanés
[2:12] 100,00 % 14 / 14 instantanés
[49:07] 100,00 % 339187 / 339187 packs réécrits (115 packs/seconde)
enregistrement d'un nouvel index
[10:59] 1176 fichiers d'index
supprimer 1188 anciens fichiers d'index
[4:51] 100,00 % 409728 / 409728 packs supprimés

@cbane , je m'excuse. Hareng rouge sur les vitesses de pruneau - lorsque je faisais un profilage indépendant, j'ai remarqué que les deux repos étaient dans des AZ différentes, donc la différence était entièrement due à une latence différente par rapport à l'AZ la plus éloignée.

Dans notre dépôt volumineux (20,791 Tio, 40 522 693 blobs), nous obtenons l'erreur suivante lors de l'élagage à l'étape « Rechercher les données encore utilisées » :

arbre 5e40b6de93549df6443f55f0f68f24bf36671e28590579c78bc62f7557490c56 introuvable dans le référentiel
github.com/restic/restic/internal/repository.(Repository).LoadTreeinterne/dépôt/dépôt.go:711github.com/restic/restic/internal/restic.FindUsedBlobs.func3interne/restic/find.go:52github.com/restic/restic/internal/restic.FindUsedBlobs.func3interne/restic/find.go:74github.com/restic/restic/internal/restic.FindUsedBlobs.func4interne/restic/find.go:89gopkg.in/tomb%2ev2.( Tomb).run
vendeur/gopkg.in/tomb.v2/tomb.go:163
runtime.goexit
/usr/lib/golang/src/runtime/asm_amd64.s:1337

toutes les sauvegardes se sont terminées avec succès et une vérification restic ne renvoie aucune erreur.

Des recherches supplémentaires valent la peine d'être faites ici, @cbane ?

Un index de reconstruction a permis au pruneau de réussir. Je ne sais pas s'il existe un bon moyen de rendre l'élagage plus résistant, afin qu'il puisse résoudre le problème de manière native.

Hmm, j'ai encore eu la même erreur aujourd'hui. Résolu avec un index de reconstruction, mais je commence à me demander si le pruneau lui-même pourrait être à l'origine du problème. Un contrôle restic revient propre à chaque fois.

arbre 7dc9112b587a2b67a2459e6badf7c14f986408e05dbe8a68e7458a30740ea951 introuvable dans le référentiel
github.com/restic/restic/internal/repository.(Repository).LoadTreeinterne/dépôt/dépôt.go:711github.com/restic/restic/internal/restic.FindUsedBlobs.func3interne/restic/find.go:52github.com/restic/restic/internal/restic.FindUsedBlobs.func3interne/restic/find.go:74github.com/restic/restic/internal/restic.FindUsedBlobs.func4interne/restic/find.go:89gopkg.in/tomb%2ev2.( Tomb).run
vendeur/gopkg.in/tomb.v2/tomb.go:163
runtime.goexit
/usr/lib/golang/src/runtime/asm_amd64.s:1337

Nous effectuons des restaurations complètes une fois par semaine pour vérifier l'intégrité de la sauvegarde, en complément des restaurations ponctuelles quotidiennes de fichiers.

Alors que la vérification restic n'a montré aucun problème avec la sauvegarde, les restaurations complètes échouent en raison d'un blob manquant. Il semble donc que quelque chose ait pu être élagué en cours de route, ce qui n'aurait pas dû l'être.

Il n'est pas clair s'il s'agit d'un bogue dans la branche d'accélération, quelque chose dans le code d'élagage de base ou quelque chose d'autre entièrement. Malheureusement, je n'ai pas de grand cas de test reproductible, mais c'est la deuxième fois que nous voyons ce type de corruption de dépôt avec notre plus grand dépôt. Nos dépôts plus petits n'ont montré aucun problème.

Malheureusement, les tests avec stock prune sont impossibles, en raison de la taille des repos.

Nous allons revenir à l'instantané EBS, pour l'instant, mais nous continuerons à surveiller ce problème et d'autres et nous sommes heureux de tester là où cela a du sens !

J'ai ajouté un petit PR #2507 qui devrait améliorer la situation. J'apprécierais que certains d'entre vous puissent faire des tests à ce sujet...
Merci!

Lecture du code prune - le reconditionnement lit les blobs puis enregistre les nouveaux packs en série. Si vous remballez sur le réseau, ce sera le goulot d'étranglement.

@DurvalMenezes est votre NAS sur le réseau local ou sur internet ? Si sur le réseau local vous vous y connectez via wifi ou ethernet ?

Il semble qu'une victoire facile serait de paralléliser la lecture des blobs / la sauvegarde des packs sur le réseau.

Séparément, je me demande si une meilleure stratégie serait d'essayer de rendre l'élagage incrémentiel à la place. Quelque chose comme la collection de fossiles en deux étapes de duplicacy : https://github.com/gilbertchen/duplicacy/wiki/Lock-Free-Deduplication#two -step-fossil-collection

Séparément, je me demande si une meilleure stratégie serait d'essayer de rendre l'élagage incrémentiel à la place. Quelque chose comme la collection de fossiles en deux étapes de duplicacy : https://github.com/gilbertchen/duplicacy/wiki/Lock-Free-Deduplication#two -step-fossil-collection

Veuillez consulter #1141 pour une discussion sur ce sujet.

Les deux nouvelles commandes 'cleanup-index' et 'cleanup-packs' du PR #2513 devraient aussi beaucoup améliorer la situation. Avec ces commandes, vous pouvez faire un élagage sans remballer si votre dépôt est sain d'esprit.

J'ai donc accidentellement fait deux choses, j'ai exécuté une sauvegarde horaire 11 fois par heure au lieu de 1, et je n'ai pas exécuté mon travail d'oubli pendant les 384 derniers jours environ. J'ai 101417 instantanés. J'ai pensé qu'il serait trop lent d'oublier/d'élaguer cela, je pense que je vais juste le supprimer.

Vous pouvez essayer #2718 - cependant, il n'y a pas d'amélioration pour "oublier" les instantanés.
Si l'étape d'oubli est votre problème, je vous conseillerais de :

• déterminez les instantanés que vous souhaitez conserver, par exemple en consultant vos derniers journaux de sauvegarde ou effectuez simplement une autre sauvegarde.
• supprimez tous les fichiers sauf ces fichiers manuellement du répertoire /snapshots de votre référentiel
• après cela, exécutez prune (si vous voulez avec #2718)

Je voulais seulement les conserver quelques jours, donc je vais simplement supprimer tout le répertoire sur S3 et recommencer. J'ai commencé le processus d'oubli et cela prenait beaucoup de temps, je pensais que soit la nouvelle branche aiderait (elle n'en a pas l'air), soit à tout le moins quelqu'un pourrait trouver cela amusant.

Je veux vraiment essayer cette branche (ou vraiment, j'aimerais qu'elle soit intégrée à master). J'ai essayé de tester et d'obtenir

Fatal : impossible d'ouvrir le fichier de configuration : Stat : l'ID de clé d'accès AWS que vous avez fourni n'existe pas dans nos enregistrements.

Fonctionne sans problème en utilisant la version principale. J'ai également pu utiliser la branche sur https://github.com/restic/restic/pull/2340 sans problème.

Je peux utiliser cette branche sur un référentiel monté NFS, seul le référentiel stocké AWS n'est pas fonctionnel. Je ne sais pas comment résoudre le problème...

merci pour tout le bon travail malgré tout

@vtwaldo21 Quelle branche avez-vous essayée ? Était-ce le #2718 ?
Votre message d'erreur indique que vous rencontrez des problèmes avec vos informations d'identification AWS. Cela peut également expliquer pourquoi NFS a fonctionné sans problème.

Les autres commandes restic fonctionnent-elles avec votre référentiel AWS ?

@aawsome , je suis un idiot et j'ai transposé les numéros de branche/problème et des choses vraiment confuses. Pardon.

La branche 2718 a très bien fonctionné (sur les référentiels AWS et NFS). Je ne peux pas dire avec certitude que c'était plus rapide ou pas car il fonctionne toujours
La branche 2340 était celle qui avait le problème et pourquoi j'étais dans ce fil de discussion.

La branche 2340 est basée sur la version 0.9.5, donc un peu plus ancienne mais pas trop mal. Je faisais des tests simples comme celui-ci:

binaire restic est le chemin est juste installé via RPM (0.9.6)

instantanés restic
[travaux]
restic.2718/restic instantanés
[travaux]
instantanés restic.2340/restic
Fatal : impossible d'ouvrir le fichier de configuration : Stat : l'ID de clé d'accès AWS que vous avez fourni n'existe pas dans nos enregistrements.

Ainsi, bien que l'erreur implique quelque chose avec les informations d'identification AWS, j'exécute littéralement les commandes dos à dos sans changement de variable. Il semble qu'il y ait autre chose qui ne va pas avec cette branche.

Mes pruneaux prennent des jours pour un dépôt d'environ 2 To, donc très intéressé par la fusion de 2718 et 2340 dans le maître

@cbane merci beaucoup pour tout votre travail ! Nous venons de fusionner #2718, qui retravaille le code prune, et je pense que cela résout ce problème ainsi que #2340.

Je suis vraiment désolé de la façon dont nous avons traité votre contribution, j'espère que vous accepterez mes excuses. :désappointé:

J'ai parlé avec @MichaelEischer , il a mentionné que le PR #2340 inclut plus d'idées qui n'ont pas encore été mises en œuvre, donc je rouvre ce problème.

@cbane êtes-vous intéressé à travailler avec nous pour intégrer ces idées dans le code actuel ? Je peux tout à fait comprendre si ce n'est pas le cas, alors nous passerons par votre PR et les extrairons nous-mêmes :)

Nous avons également eu une courte discussion hier et avons essayé d'identifier ce qui n'allait pas, afin que nous puissions faire mieux la prochaine fois. Certains points que nous avons identifiés étaient :

• Le PR a modifié une zone très sensible du code (prune, qui supprime finalement les données), il nécessite donc un examen plus approfondi
• @MichaelEischer ainsi que @aawsome ont essayé de revoir le PR et ont dit qu'il était trop volumineux
• Le PR n'était que deux commits, l'un d'eux a remplacé tout le code par un autre code complètement différent, c'est très difficile à revoir
• Le PR comprenait au moins 4 à 5 idées et améliorations différentes, ce qui rend encore plus difficile l'examen

D'autres choses que j'ai ratées ?

Les modifications apportées à cmd_prune.go à partir de # 2340 sont, pour autant que je sache, complètement remplacées par # 2718 et # 2842 par @aawsome . #3006 remplace également les modifications index/index.go.

J'ai extrait l'implémentation de marche arborescente hautement parallélisée de checker.go (voir https://github.com/MichaelEischer/restic/tree/streamtrees), qui permet d'implémenter un parallèle FindUsedBlobs avec quelques lignes de code supplémentaires. Il est également réutilisable pour la commande de copie. Ma branche mentionnée unifie également le code utilisé pour paralléliser le chargement de l'index et de l'instantané. Je vais diviser la branche en PR plus petits.

Cela semble laisser l'utilisation du nombre de connexions backend et de GOMAXPROCS pour s'adapter automatiquement au parallélisme IO/CPU dans le cadre de #2340.

J'ai remarqué que ni # 2340 ni l'autre Prune PR ne parallélisent actuellement le téléchargement de l'index réécrit.