Restic: Ajouter une commande pour copier toutes les données dans un autre référentiel

Est-ce destiné à gérer une copie unique d'un référentiel (A) vers un nouveau (B) ? Ou est-ce censé être plus général en effectuant une « synchronisation » ou une mise à jour du contenu modifié entre (A) et (B) depuis la dernière synchronisation ?

Pour le moment, cela est destiné à gérer une copie unique, afin que les utilisateurs puissent migrer vers un référentiel différent dans un emplacement différent, ou avec une nouvelle clé principale.

Compte tenu d'une connexion Internet lente, j'aimerais avoir la possibilité de sauvegarder sur s3 et un autre emplacement aussi efficacement que possible.

@witeshadow Je ne sais pas comment cela peut être fait efficacement, car les données sont cryptées dans le référentiel A avec le maître A' et doivent être effectuées dans le référentiel B avec une clé principale différente B`. Nous devons lire toutes les données, déchiffrer avec A`, chiffrer avec B` et écrire. Il n'y a aucun moyen d'optimiser cela pour une bande passante lente. Ça va faire mal...

la seule optimisation que je puisse penser est d'avoir un critère de sélection sur le référentiel source A, en utilisant les filtres host, path et tags afin que vous n'ayez pas à tout copier. Cependant, cela dépend de votre cas d'utilisation.

@fd0 Je voulais juste ajouter mon vote pour cette demande de fonctionnalité. Que puis-je faire pour que cela se produise ?

Vous pouvez l'implémenter... La fonctionnalité elle-même n'est pas difficile à faire, configurer les deux backends est la chose la plus difficile. Nous ne prenons pas en charge l'accès à plus d'un backend (par exemple, il n'y a qu'un seul $B2_ACCOUNT_ID )... donc je pense que cette fonctionnalité dépend d'un fichier de configuration approprié (voir #16).

Disons que nous avons deux dépôts, A et B, et que vous souhaitez synchroniser A->B de sorte qu'une fois le processus terminé, l'ensemble de blobs (et d'instantanés) dans B soit un sur-ensemble de l'ensemble de blobs dans A .

Ainsi, vous ouvrez les deux dépôts et chargez les fichiers d'index pour chacun. Ensuite, vous parcourez l'indice de A, pour chaque blob en vérifiant si le blob est également contenu dans B. Si cela est vrai, passez au suivant. S'il est faux, téléchargez-le, déchiffrez-le, chiffrez-le et téléchargez-le sur B.

Le dernier consiste à copier les fichiers d'instantanés. Pour chaque fichier d'instantané dans A, décryptez le fichier, cryptez-le à nouveau pour B, stockez-le là et c'est fait.

Comme je l'ai dit, la mise en œuvre technique est plutôt facile :)

Super! Merci pour les conseils. J'ai cette démangeaison, donc je vais voir si je peux prendre le temps de la gratter - mais à court terme, je devrai me passer de cette fonctionnalité restic merge . Si quelqu'un y parvient avant moi, ce n'est pas un problème - ou je reviendrai à cela un jour !

Je pense que j'ai déjà implémenté le... /me se gratte la tête et le cherche...
... https://github.com/middelink/restic/tree/fix-323
Je dois vérifier si elle compile toujours, cette branche est derrière 228 commits ...

Il peut être utile d'autoriser non seulement une copie complète, mais également un sous-ensemble d'instantanés. Cela prendrait en charge un cas d'utilisation suggéré par # 1910 (sauvegarde souvent sur un référentiel principal, et à partir de là, sauvegarde moins souvent vers un stockage hors site/plus lent/plus cher) et, je pense, ne serait pas beaucoup plus difficile à mettre en œuvre qu'une copie complète. Peut-être un futur ajout, cependant :-)

Euh… Des nouvelles pour les simples utilisateurs sans compétences en développement pour compiler et essayer la suggestion de @middelink ?

C'est principalement un commentaire "moi aussi", mais j'aimerais avoir la possibilité de copier uniquement des instantanés spécifiques d'un référentiel à un autre, plutôt qu'une sémantique "copier tout" ou "synchroniser" ; par exemple, effectuez des sauvegardes quotidiennes sur le stockage local, puis une fois par semaine, copiez uniquement la plus récente quotidiennement dans un compartiment s3, etc.

Eh bien, alors vous avez de la chance, ma copie cmd prend un ou plusieurs identifiants d'instantané. En fait, copier tout n'est pas quelque chose qu'il fait. Vous devrez d'abord répertorier vos identifiants d'instantané, puis les concaténer sur la ligne de commande "restic copy". Comme je vois cela comme un cas d'utilisation dégénéré, je suis d'accord avec ça.

Sans approfondir cela, peut-être que quelques discussions avec ncw/rclone pourraient être utiles...

Je suis également intéressé par la fonctionnalité de fusion/copie, j'ai un référentiel sur une clé USB que je souhaite fusionner/copier dans mon référentiel central (mêmes mots de passe).
des nouvelles à ce sujet?

On dirait que la branche fork a été mise à jour vers master , mais il n'y a pas encore de PR pour cela.

@middelink Votre code est-il terminé / fusionnable ? Si non, que reste-t-il à faire ? C'est une fonctionnalité que je veux vraiment :)

@theoretical2019 Le code lui-même est terminé, mais chaque fois que je m'assois pour créer un PR officiel, je continue à trouver des choses que je dois faire avant qu'il ne soit prêt. Comme la documentation, comme un unreleased/changelog...
Ah et des tests ! Ai-je mentionné les tests? Il faut des tests :P

@middelink Pour info , j'ai testé votre branche en rebasant sur le maître en amont et cela fonctionne plutôt bien. Il a créé un nouvel instantané avec le même hôte, les mêmes balises et la même date :+1 :
En attente de PR :tada:

Maintenant, avec une telle fonctionnalité, je peux créer un référentiel secondaire, qui est utilisé par les clients uniquement lorsque le premier référentiel est verrouillé pour la maintenance (par exemple, élaguer). Et la tâche d'élagage peut déclencher une copie du secondaire une fois celle-ci terminée, donc pas de sauvegardes manquantes, donc aucun temps d'arrêt sur le service de sauvegarde.

@middelink Auriez -vous la gentillesse de créer un PR de votre code ? Ce faisant, veuillez également autoriser les modifications des responsables - de cette façon, nous pouvons vous aider avec le journal des modifications, la documentation, etc.

L'important est que nous ayons une base de relations publiques sur laquelle travailler. J'adorerais faire avancer votre excellent travail, et d'autres aussi, je pense :) Faites-moi savoir si vous avez besoin d'aide pour créer le PR !

@rawtaz Bien sûr. Laisse-moi synchroniser et tout ça. Pour une raison quelconque, je n'ai pas trouvé le temps de le faire plus tôt, mais il semble que j'ai un peu de temps maintenant.

Merci à tous pour votre travail là-dessus !

Il me reste une question à laquelle les docs ne répondent pas (du moins pour moi) : dois-je élaguer les deux ou est-ce suffisant de le faire dans la source et les suppressions d'instantanés sont propagées ?

@lfrancke Lorsque vous utilisez la commande copy vous listez spécifiquement les instantanés que vous souhaitez copier. D'autres, à la fois les instantanés existants, inexistants et préexistants, mais maintenant élagués et n'existant plus, ne sont pas applicables.

Si vous copiez des instantanés du référentiel A vers le référentiel B, puis les oubliez et les élaguez dans le référentiel A, ils ne seront pas oubliés et élagués automatiquement dans le référentiel B, vous devrez le faire vous-même dans le référentiel B.

Excellent, merci beaucoup @rawtaz pour la réponse rapide et utile.