Restic: Données provenant d'un instantané incomplet.

Ah, hm. Avez-vous besoin d'un fichier spécifique ou simplement de «toutes les données qui existent»? Les données sont là, et restic a tous les moyens de les extraire, mais cela signifierait soit un script autour de restic (qui sera très lent), soit l'ajout de code personnalisé pour restic.

Question honnête: quelle est l'importance des données pour vous? Je pourrais passer un peu de temps aujourd'hui à pirater quelque chose ensemble pour vous, ce qui devrait vous donner accès à presque toutes les données qui ont été téléchargées dans le dépôt, mais ce n'est probablement pas aussi "prêt pour la production" que la plupart du code. :)

Les données sont très importantes pour moi et malheureusement il n'y a pas d'autre copie. Je sais que ce n'est pas idéal, mais c'était un problème que j'essayais de résoudre. Je cherche un correctif matériel pour essayer de remettre le volume en ligne, mais cela ne semble pas trop optimiste pour le moment. S'il y avait un moyen pour moi de spécifier un répertoire et d'être en mesure d'accéder et de télécharger tout ce qui se trouve à l'intérieur de ce répertoire, cela me sauverait sérieusement la vie. C'est beaucoup de données (une grande partie est des projets vidéo), donc l'option la plus rapide serait préférable. Cela étant dit, je ne sais pas vraiment combien de travail cela prendrait et j'apprécie que ce soit du logiciel libre, mais je serais extrêmement reconnaissant si cela pouvait être rendu possible.

ok, je vais voir ce que je peux faire.

Merci beaucoup.

Vous pouvez commencer par exécuter restic rebuild-index , nous avons donc un nouvel index couvrant tous les packs du dépôt.

Commencer maintenant.

Wow, c'est super généreux de ta part @ fd0.

Si je peux vous aider à tester quoi que ce soit à ce sujet, faites-le moi savoir.

Est-ce que restic rebuild-index devrait me demander le mot de passe du repo? Ce n'est pas encore le cas. Je soupçonne que cela peut prendre un certain temps en raison de la quantité de données dans le repo. Je suis parfaitement content de le laisser fonctionner tout le week-end, ou la semaine prochaine si nécessaire. Je veux juste m'assurer qu'il n'a pas besoin d'un mot de passe de ma part avant de le laisser sans surveillance pendant une longue période.

Hm, il devrait demander un mot de passe dès le début. Il doit décrypter tous les en-têtes de tous les fichiers du dépôt. Avez-vous peut-être exporté la variable d'environnement RESTIC_PASSWORD , elle n'a donc pas besoin d'un mot de passe de votre part?

Il devrait imprimer quelque chose comme ça dès le début:

repository ed6136ad opened successfully, password is correct

Au moins lorsqu'il est exécuté de manière interactive (pas de redirection de stdout vers un fichier journal).

Vous pouvez également sauter le rebuild-index si les 15 dernières minutes des données téléchargées ne sont pas si importantes, nous pouvons toujours le faire plus tard.

Je n'ai pas que la variable d'environnement RESTIC_PASSWORD définie, mais je vais la définir et laisser la commande s'exécuter. Il n'a rien retourné pendant environ 10 minutes, alors je lui ai donné un ctrl-c et j'ai réessayé. Ma syntaxe est correcte, non? restic -r b2:MY_BUCKET_NAME:/ rebuild-index Dans tous les cas, les 15 dernières minutes de données devraient être très petites par rapport au total des données téléchargées, donc je serais parfaitement heureux d'y revenir plus tard.

ok, alors ne lancez pas encore rebuild-index , nous pouvons donc essayer le code de récupération :)

J'ai poussé un commit dans la branche recover-data , construisez juste restic ( go run build.go ) et appelez-le comme ceci:

$ restic -r b2:MY_BUCKET_NAME:/ recover

Il doit ensuite lister toutes les arborescences du référentiel, trouver les arborescences racine et créer un nouvel instantané faisant référence à toutes les arborescences racine:

repository abe002d6 opened successfully, password is correct
load index files
load 543 trees
tree (543/543)
done
found 2 roots
save tree with 2 nodes
saved new snapshot 26f25bf1

Ensuite, vous avez un instantané ( 26f25bf1 dans ce cas) que vous pouvez restaurer, ou utilisez simplement restic mount pour le parcourir. Vous pouvez également simplement le lister:

$ restic ls -l 26f25bf1 /
repository abe002d6 opened successfully, password is correct
snapshot aac6d0ed of [/recover] filtered by [/] at 2018-08-23 22:23:56.903268714 +0200 CEST):
drwxr-xr-x     0     0      0 2018-08-23 22:23:56 /0b9e25fb
drwxr-xr-x     0     0      0 2018-08-23 22:23:56 /d0d9386a

Les répertoires de niveau supérieur sont nommés d'après les ID d'arborescence, ils sont donc un peu cryptiques, mais le niveau suivant a des noms normaux.

Faites-moi savoir si cela vous aide!

Donc, pour ajouter un peu d'histoire: j'ai lu le numéro de github, puis je suis allé prendre une douche et je me suis dit: "hm, ce n'est pas si difficile à faire". Il s'avère que j'avais raison, et ce n'était pas le cas. Si cette fonctionnalité est utile pour d'autres, nous pouvons la transformer en une commande appropriée plus tard, mais pour le moment, j'espère que cela fonctionne pour vous et que vous pourrez accéder aux données déjà téléchargées sur B2.

De combien de données s'agissait-il? Combien avez-vous récupéré?

Bonne chance!

Hou la la! C'était rapide! Merci beaucoup! Je viens de cloner le repo et je vais essayer de le construire maintenant. J'ai également compris pourquoi rebuild-index ne fonctionnait pas. C'était un problème DNS sur le réseau sur lequel se trouve notre serveur. J'ai corrigé cela et j'ai obtenu Fatal: unable to create lock in backend: repository is already locked by PID 41208 donc apparemment mon téléchargement ne s'est pas arrêté après tout. La commande unlock semble avoir effacé le problème et rebuild-index est en cours d'exécution.

Je vais en faire autant que je peux aujourd'hui, mais je pars pour le nord du Michigan pour le week-end dans environ 15 minutes et je ne pense pas que mon accès Internet sera très bon là-bas. Cela attirera toute mon attention lundi à mon retour et je vous donnerai plus de détails :-)

Merci beaucoup pour cela! Désolé de vous laisser en suspens, mais je vous contacterai lundi.

Si cette fonctionnalité est utile pour d'autres, nous pouvons la transformer en une commande appropriée plus tard

J'aimerais aider de toutes les manières possibles. Ma vitesse de téléchargement ici est de 1 Mbps et mes sauvegardes initiales peuvent donc prendre jusqu'à 3-6 mois. Avoir un moyen de restaurer avant la fin serait une excellente fonctionnalité, surtout si ce n'est pas trop difficile, comme vous le dites. Faites-moi savoir comment je peux être utile! Merci beaucoup pour votre travail! :RÉ

De plus, votre solution est assez brillante, je pense. Élégant et assez simple.

Désolé de vous laisser en suspens, mais je vous contacterai lundi.

Ne vous inquiétez pas, je suis juste curieux de savoir si cela fonctionne: lunettes de soleil:

Les données sont en sécurité chez B2 et ne disparaîtront pas. Même la commande recover ne changera aucune donnée, elle la lira simplement, ajoutera un autre fichier et un instantané, et c'est tout.

Donc, pour vous donner un peu de contexte (peut-être que je développerai cela dans un article de blog plus tard): Sous le capot, un référentiel restic contient différents types de fichiers, par exemple snapshot et data fichiers:

• data fichiers tree ou data courts, avec un en-tête à la fin décrivant ce qu'il y a dans le fichier et où exactement
• snapshot fichiers tree

Lorsqu'un fichier est enregistré avec restic, il est coupé en blobs data , qui sont collectés et enregistrés ensemble dans un ou plusieurs fichiers du référentiel. Le nom du fichier ainsi que la liste des références (ID) aux blobs data sont ensuite enregistrés dans une arborescence. Lorsque restic a terminé l'archivage du répertoire, la liste des fichiers (noms et références pour data blobs) est enregistrée en tant que tree blob dans un autre fichier data .

Pour les sous-répertoires, restic stocke le nom du sous-répertoire avec la référence du blob tree décrivant le contenu dans un autre tree .

À la fin de l'exécution de restic backup , nous avons une racine tree qui n'est référencée par aucun autre arbre, mais contient toutes les références à tous les arbres de niveau supérieur et donc (indirectement) à tous les fichiers et sous-répertoires dans la sauvegarde. Comme dernière étape, restic crée un nouveau fichier snapshot qui fait référence à la racine tree .

Si vous dites à restic d'oublier un instantané particulier, l'arborescence racine n'est plus référencée. restic prune détecte cela et supprime l'arbre et tous les autres blobs tree et data inutiles.

En général, un tree n'est enregistré dans le référentiel que lorsque tous les fichiers et sous-répertoires qu'il contient ont été enregistrés avec succès. Ainsi, dès qu'un blob tree est là, nous pouvons supposer que les données auxquelles il fait référence (y compris les sous-répertoires) sont également là.

Lorsque la restauration est abandonnée pendant la sauvegarde, il y aura un tas de blobs tree dans le dépôt, ainsi que les données dans les fichiers auxquels ils font référence. Donc, pour récupérer les données, restic n'a besoin que de faire ce qui suit:

• faire une liste de tous les identifiants d'arbres, noter quels arbres ont été référencés (initialement: aucun)
• pour chaque arbre:
  
  
  
  • charger l'arbre
  
  
  • pour chaque entrée de l'arborescence:
    
    
    
    
    
    • si est un répertoire, il fait référence à un autre arbre, marquez cet arbre comme référencé dans la liste
    
    
    
  
  

Ensuite, parcourez à nouveau la liste des arbres, jetez tous ceux pour lesquels nous avons vu des références. Les arbres restants sont les arbres racines, ce qui signifie soit les arbres qui sont (ou ont été) directement référencés par un instantané, soit qui sont «pendantes» suite à une exécution avortée de restic backup .

Comme dernière étape, créez une nouvelle arborescence qui répertorie toutes les arborescences racine, enregistrez-la dans le référentiel, puis créez un nouvel instantané qui fait référence à cette nouvelle arborescence.

Vous pouvez alors simplement utiliser ce nouvel instantané normalement, sauf pour les noms cryptiques des répertoires (qui ne sont que les identifiants courts des arbres racines que nous avons trouvés).

Avant de fusionner cela avec master, je pense que nous devrions faire ce qui suit:

• Ajoutez une option à recover qui exclut les arbres racines référencés par les instantanés existants, donc nous n'obtenons que des arbres racines vraiment suspendus. Peut-être que ce comportement devrait même être celui par défaut, la plupart des utilisateurs ne sont probablement pas intéressés par les données auxquelles ils peuvent accéder via des instantanés existants ...
• Rendez également les objets blob data non référencés disponibles dans le nouvel instantané, afin que les utilisateurs puissent rassembler des parties de fichiers qui n'étaient pas encore incluses dans un objet tree .
• Définissez des métadonnées sensibles pour la nouvelle arborescence et le nouvel instantané. Pour le moment, c'est très moche (juste assez pour que ça marche).
• Un meilleur rapport de progression, c'est très piraté en ce moment

Petite mise à jour à ce sujet: j'ai commencé un rebuild-index avant de partir jeudi dernier. Qui est mort avant mon retour avec un read: connection reset by peer . Je l'ai redémarré hier avec un nombre plus élevé de connexions parallèles à b2 et il semble bien fonctionner. C'est seulement à 5% maintenant, mais je m'attends à ce que cela prenne un certain temps. Le seau b2 contient environ 90 To et les répertoires que je sauvegardais contenaient probablement environ 110 à 120 To.

Je suis honnêtement très impressionné par le fait que restic soit resté si stable pendant le téléchargement. J'ai essayé cloudberry pour Mac avant d'essayer restic et je n'ai pas pu le faire fonctionner avec autant de données. J'utilise restic pour sauvegarder mon ordinateur portable à la maison et je l'adore, alors j'ai pensé que je tenterais de le faire. Comme je n'ai même pas terminé mon téléchargement initial, je n'ai aucune idée de la façon dont quelque chose comme un prune ira, mais je serai heureux de vous tenir au courant si vous avez besoin de données sur le comportement de Restic avec de gros volumes de données . Si je peux l'obtenir pour terminer toutes les opérations nécessaires pour maintenir une sauvegarde hebdomadaire en moins d'une semaine, je pense que ce sera un excellent candidat pour gérer ces sauvegardes.

Pour le moment, j'ai quelques questions: Dois-je laisser ce rebuild-index se terminer avant d'essayer un recover ? Vais-je perdre quelque chose si je ne le fais pas? J'y ai réfléchi et je pense que j'aimerais récupérer autant que possible du premier coup si possible car les choses prennent un certain temps à fonctionner sur autant de données, mais s'il vaut mieux tuer cela, exécutez recover abord et rebuild-index plus tard, je peux le faire. Est-ce que l'exécution de rebuild-index ou recover avec un indicateur --quiet accélérera les choses comme elle le fait avec la commande backup ?

OK cool! Je recommanderais de faire ce qui suit:

• Annuler le rebuild-index
• Exécutez restic recover
• Jetez un œil aux données contenues dans l'instantané nouvellement créé

Si vous souhaitez essayer, vous pouvez exécuter à nouveau rebuild-index et récupérer les mégaoctets de données restants du dépôt. Ce sera probablement moins de quelques centaines de mégaoctets, et il est probable que cela ne révélera aucune nouvelle donnée non encore contenue dans l'instantané. Mais vous pouvez l'essayer :)

Pendant que rebuild-index est en cours d'exécution, vous ne pouvez pas accéder au référentiel.

L'exécution de rebuild-index ou de restauration avec un indicateur --quiet accélérera-t-elle les choses comme elle le fait avec la commande backup?

Nan.

J'ai laissé les choses fonctionner du jour au lendemain et il semble avoir rempli le disque dur et a échoué:

found 755 roots Fatal: unable to save new tree to the repo: fs.TempFile: open /var/folders/tq/67qp8py137n_5nzf563qlylr0000gn/T/restic-temp-pack-913168611: no space left on device

Existe-t-il un moyen simple de savoir combien de données cette opération devra télécharger ou un moyen de réduire la quantité de données téléchargées?

De plus, si je veux libérer cet espace disque, est-ce que restic cache --cleanup le moyen de le faire?

Non, cela ne supprime que les répertoires de cache qui n'ont pas été utilisés depuis 30 jours. Supprimez simplement le répertoire de cache, qui devrait être quelque part dans votre répertoire personnel.

Quelle commande avez-vous exécutée exactement? rebuild-index et recover ne devraient pas enregistrer beaucoup de données sur le disque dur, à l'exception du cache de métadonnées ...

Pas à mon bureau pour le moment. mais c'était quelque chose comme: ./restic -o b2.connections=x -r b2:mybucket:/ recover Je pense que x avait réglé quelque chose d'énorme. Cela peut avoir fait partie du problème. Je peux le redémarrer sans le bit -o b2.connections=x . J'ai trouvé le répertoire de cache et je l'ai supprimé.

Tout d'abord, un outil génial.
J'ai également besoin de sauvegarder des téraoctets de données sur une connexion lente et j'ai une chance que la sauvegarde échoue alors qu'elle n'est toujours pas terminée. Existe-t-il un moyen recommandé de ne sauvegarder que quelques fichiers à la fois?

Existe-t-il un moyen recommandé de ne sauvegarder que quelques fichiers à la fois?

Ce qui fonctionne généralement (j'ai entendu dire) est de sauvegarder des parties individuelles des données source (par exemple des répertoires uniques) et, lorsque cela est terminé, de sauvegarder tous les répertoires ensemble. Lorsque les données source n'ont pas changé, restic ne devrait télécharger presque rien en raison de la déduplication intégrée.

Un meilleur endroit pour de telles questions serait le forum à https://forum.restic.net , la question (et les réponses!) Y sont beaucoup plus découvrables.

@pauletg alors, comment ça s'est passé?

J'ai proposé la nouvelle commande recover dans # 2056.

Je n'ai pas beaucoup progressé sur la récupération du restic depuis mon dernier message. La bonne nouvelle est que nous avons réussi à relancer le serveur et que les données n'ont pas été endommagées par le crash, donc j'ai mes données. La commande de récupération semble remplir le HD de ma machine, avant qu'elle ne puisse se terminer. Cela aurait pu être causé par plusieurs facteurs: Ma sauvegarde était énorme et j'utilisais un grand nombre de connexions à b2 pour le téléchargement et le HD sur la machine que j'utilisais pour la restauration était relativement petit. Je suis sûr que cela fonctionnerait probablement très bien si ma sauvegarde était d'une taille plus raisonnable. Faites-moi savoir si d'autres informations vous seraient utiles. J'apprécie vraiment que vous travailliez là-dessus et avoir cette fonctionnalité disponible pour mes sauvegardes d'ordinateur portable est vraiment agréable.

Merci pour les commentaires! Si vous aimez (et avez beaucoup de temps), vous pouvez réessayer avec --no-cache , mais cela prendra encore plus de temps. Je fermerai ce problème lorsque # 2056 sera fusionné.

S'il vous plaît laissez-nous savoir si vous avez des commentaires supplémentaires! :)