Ce serait vraiment sympa.

Cela permettrait également de supprimer les données sensibles qui ont été incluses involontairement.

Ce serait une excellente fonctionnalité !

Des retours des devs sur cette idée ? Ce serait très sympa. Par exemple, je viens de découvrir qu'un programme que je construis à partir de git checkouts a créé d'énormes fichiers binaires (presque 100 Mo), et ceux-ci ont été sauvegardés inutilement dans mes sauvegardes Restic. Je n'utilise pas Restic depuis très longtemps, car je suis encore en phase de test, donc ce n'est pas un problème de supprimer les anciens snapshots en question. Mais ce problème peut survenir assez facilement, et il serait bon d'avoir des solutions à long terme, autres que d'oublier chaque instantané.

Je suppose qu'il serait possible d'écrire un script pour restaurer chaque instantané, supprimer les fichiers indésirables et sauvegarder à nouveau l'instantané en définissant la date manuellement, mais cela prendrait évidemment beaucoup de temps. Ce serait formidable si Restic pouvait le faire nativement.

Merci.

Je pense qu'il existe plusieurs cas d'utilisation valides pour cela. Cela semble être une très bonne fonctionnalité à avoir. Je l'utiliserais probablement moi-même à un moment donné.

Cela ne change probablement pas vraiment l'effort d'implémentation, mais d'un point de vue UX, cela pourrait être fait avec un profil plutôt bas en étendant la commande backup au lieu d'ajouter une toute nouvelle commande :

restic backup [flags] FILE/DIR/SNAPSHOT [FILE/DIR/SNAPSHOT] ...

Ainsi, au lieu d'offrir une commande qui modifie les instantanés, cela permettrait de faire une nouvelle sauvegarde basée sur un ID d'instantané existant. La suppression d'un fichier serait réalisée avec des règles d'exclusion.
Toute la documentation sur restic backup pourrait fondamentalement être "réutilisée" (c'est-à-dire que presque rien n'aurait besoin d'être ajouté pour cette nouvelle fonctionnalité).

@dnnr Voir https://github.com/restic/restic/issues/1550#issuecomment -358536554

Cependant, je ne vous suis pas ici. La suppression de données d'anciens instantanés est certainement une opération distincte et devrait avoir sa propre commande. Quelque chose comme:

restic purge --snapshots abcd1234 deadbeef --paths /path/to/file1 /path/to/file2

Et --snapshots devrait probablement accepter un mot-clé all pour opérer sur tous les instantanés (ou tous les instantanés avec le --tag spécifié). Et la commande devrait probablement nécessiter une confirmation en tapant yes .

Il serait également bon qu'il ait une option --patterns , qui supprimerait les chemins correspondant aux modèles donnés.

purge est une possibilité pour le nom de la commande. erase pourrait également être un bon choix, ainsi que delete . Quel que soit le choix, il doit indiquer clairement que l'opération supprime définitivement les données . C'est un logiciel de sauvegarde dont nous parlons, et toute opération dangereuse doit être distincte, explicite et nécessiter une confirmation.

Eh bien, j'ai laissé de côté l'étape où vous supprimeriez l'instantané source par la suite (en utilisant forget , puis peut-être prune ) , car je pensais que c'était évident.

À mon avis, procéder ainsi garderait le jeu de commandes plus orthogonal par rapport à l'ajout d'une nouvelle commande qui chevauche la fonctionnalité des commandes existantes. À l'heure actuelle, il y a backup , forget et prune et ils font tous des choses complètement séparées. Ajouter un purge comme vous le décrivez, change cela. Ma suggestion ne le fait pas.

puisque nous proposons des opérations sur un fichier, ce serait bien de pouvoir le renommer.

Je suis d'accord avec @alphapapa qu'il devrait y avoir une commande distincte pour ce type d'opération. Cela pourrait être purge , ce n'est pas un mauvais nom, mais là encore, il pourrait y avoir d'autres opérations similaires à l'avenir, par exemple @alvarolm a déjà suggéré de pouvoir renommer les fichiers.

Pour cette raison, je pense que l'ajout d'une commande rewrite est peut-être la meilleure alternative dans ce cas, et que cette commande ait, par exemple, les options --purge et --rename , en supposant que cette dernière est pertinente pour mettre en place. Ainsi, les commandes finales seraient par exemple restic -r foo rewrite --purge snap1,snap2 path1 path2 ... et restic -r foo rewrite --rename snap1,snap2 pathFrom pathTo .

Cela dit, je ne suis pas tout à fait sûr que le renommage soit quelque chose de raisonnable à mettre en œuvre - cela va assez loin de ce qu'est un programme de sauvegarde. Mais bien sûr, pourquoi pas.

Je ne pense pas qu'il soit sage d'inclure les éléments de purge dans la commande de sauvegarde. Dans une perspective, vous pourriez affirmer que tout va bien - vous effectuez une opération sur votre sauvegarde. Mais avec cette logique, les actions d'élagage, de déverrouillage et d'oubli devraient également faire partie de la commande de sauvegarde, car elles concernent également la maintenance des éléments de votre sauvegarde. Je ne pense pas que cela ait de sens, donc je pense que cela devrait en effet être une opération/commande distincte, par exemple rewrite ou purge .

@dnnr

Eh bien, j'ai laissé de côté l'étape où vous supprimeriez l'instantané source par la suite (en utilisant oublier, puis peut-être élaguer), parce que je pensais que c'était évident.

Ce n'est certainement pas évident. Il est également préférable que Restic gère cela pour l'utilisateur, plutôt que de devoir garder une trace des identifiants d'instantanés qui ont changé et doivent être oubliés - ce qui serait un fardeau si l'utilisateur réécrivait tous les instantanés dans le référentiel.

À mon avis, procéder ainsi garderait le jeu de commandes plus orthogonal par rapport à l'ajout d'une nouvelle commande qui chevauche la fonctionnalité des commandes existantes.

Je ne comprends pas ce que tu veux dire. Le contraire est le cas. Cette commande de purge/suppression/réécriture proposée ne chevauche pas du tout backup - elle supprime les données des instantanés existants . Il est orthogonal aux commandes existantes.

À l'heure actuelle, il y a la sauvegarde, l'oubli et l'élagage et ils font tous des choses complètement séparées. Ajouter une purge comme vous la décrivez, change cela. Ma suggestion ne le fait pas.

Encore une fois, aucune idée de ce que vous pensez ici. purge est complètement séparé de la sauvegarde, de l'oubli et de l'élagage :

• backup : Crée un nouvel instantané des chemins donnés.
• forget : Supprime les instantanés existants.
• prune : Garbage-collecte des blobs inutilisés à partir d'instantanés oubliés.
• purge / rewrite /whatever : supprime les fichiers des instantanés existants.

Vous proposez de faire fonctionner la commande backup selon deux modes, dont l'un sauvegarde les données et l'autre supprime les données.

@rawtaz Oui, rewrite est une bonne suggestion, car il réécrit littéralement les instantanés existants. Je suggérerais une interface utilisateur comme :

restic --repo REPO rewrite --snapshots abcd1234 deadbeef --delete /path/to/file1 "*.unwanted-file-extension-glob"

Je déconseille d'utiliser des virgules comme séparateurs, car cela rend la construction de lignes de commande dans les scripts beaucoup plus compliquée.

backup : crée un nouvel instantané des chemins donnés.

Eh bien, dans un sens, modifier le contenu d'un instantané, c'est créer un nouvel instantané (parce que ce n'est pas le même instantané qu'avant). Pensez à git commit --amend , qui crée un nouveau commit basé sur un commit existant. L'analogie est en fait assez appropriée, car ce ticket semble évoluer rapidement vers la réinvention de Git.

Vous proposez de faire fonctionner la commande de sauvegarde selon deux modes, dont l'un sauvegarde les données et l'autre supprime les données.

Je n'ai pas dit ça. Pourquoi le ferait-il ? Il y a forget et prune , qui conviennent parfaitement pour supprimer des éléments.

Eh bien, dans un sens, modifier le contenu d'un instantané, c'est créer un nouvel instantané (parce que ce n'est pas le même instantané qu'avant). Pensez à git commit --amend, qui crée un nouveau commit basé sur un commit existant. L'analogie est en fait assez appropriée, car ce ticket semble évoluer rapidement vers la réinvention de Git.

Tu as raison. Mais en même temps, Restic n'est pas git, et il n'est pas conçu pour nécessiter une connaissance de l'adressage basé sur le contenu pour fonctionner. Indépendamment de la façon dont cela fonctionne sous le capot, je pense que, pour les utilisateurs, la commande que nous proposons devrait être envisagée pour modifier un instantané existant, pas pour en créer un nouveau, il devrait donc s'agir d'une commande distincte.

Je n'ai pas dit ça. Pourquoi le ferait-il ?

Eh bien, vous avez dit :

d'un point de vue UX, cela pourrait être fait avec un profil plutôt bas en étendant la commande de sauvegarde au lieu d'ajouter une toute nouvelle commande

Peut-être devriez-vous expliquer plus en détail.

Il y a l'oubli et l'élagage, qui conviennent parfaitement pour enlever des choses.

Soyons précis. forget supprime les instantanés , et prune supprime les blobs . Nous proposons une commande pour supprimer les fichiers dans les instantanés . Il devrait s'agir d'une commande distincte.

J'aimerais ajouter mon avis :

Je pense qu'il est utile d'avoir un moyen de modifier les instantanés dans le référentiel, en fonction des commentaires sur le nombre de personnes qui aimeraient avoir quelque chose comme ça.

La commande doit être indépendante de la commande backup , non seulement pour des raisons d'orthogonalité (ce qui est assez semblable à Go), mais aussi par considération pratique : la commande backup est déjà assez complexe donc je 'aimerais séparer l'autre commande de celui-ci.

Je n'aime pas le nom purge , à cause de la similitude avec prune . Qu'en est-il de change ? Ensuite, nous avons restic backup , restic restore et restic change .

Pour les opérations prises en charge de la commande, j'ai vu des demandes pour :

• Supprimer des fichiers, par exemple --delete
• Renommer les fichiers, par exemple --rename

Le premier est exactement l'objet de ce problème (à l'origine), mais existe-t-il vraiment des cas d'utilisation pour renommer des fichiers ?

Je pense que change ressemble plus à retirer quelque chose et à y mettre quelque chose, plutôt qu'à modifier le contenu de quelque chose.

Imaginez que le dépôt/sauvegarde/instantané est un seau. Le changement, c'est plus comme échanger le seau lui-même contre quelque chose d'autre, ou en retirer quelque chose et y mettre une autre chose, plutôt que de ramasser quelque chose dans le seau, de le modifier un peu et de le remettre en place.

Peut-être qu'une personne de langue maternelle anglaise/américaine sait ce qui est le plus approprié :) Cela se résume à la linguistique, je pense.

Hum, modify alors ?

modify est définitivement meilleur que change . Donc soit rewrite soit modify de ce qui a été proposé jusqu'à présent. Curieux de savoir ce que les autres en pensent :)

S'il ne s'agit que de supprimer des fichiers, serait-il judicieux d'améliorer la commande forget pour qu'elle fonctionne avec des instantanés et des fichiers ? Ou serait-ce trop complexe ?

Si cette nouvelle fonctionnalité concerne la suppression et le renommage (ou autre chose), je voterais pour modify .

Merci pour votre contribution @dimejo 👍

Je pense que lorsque vous renommez et/ou supprimez, vous n'êtes pas forget ting (du moins pas dans le premier cas).

IMHO "réécrire" transmet le meilleur sens.

La commande forget est également très complexe, nous n'ajouterons rien à cela si nous pouvons l'aider ;)

S'il s'agit d'une commande séparée, l'appeler modify serait également mon préféré (j'aimerais aussi modify-snapshot , même si c'est assez long). Il est également suffisamment générique pour être un endroit approprié pour toutes sortes d'opérations de modification de fichiers (renommer, peut-être même ajouter). Cependant, je pense toujours que tout ce qui va au-delà de la suppression de fichiers sent fortement le fluage des fonctionnalités.

Soit dit en passant, je pense que restic bénéficierait de catégories de commandes, similaires à ce que Git a avec ses commandes de plomberie. À l'heure actuelle, restic -h répertorie toutes les commandes dans l'ordre lexical, en mélangeant les commandes de bas niveau (par exemple, cat , list , qui ne seront jamais nécessaires aux utilisateurs "normaux") avec les commandes principales de haut niveau.

Vous pouvez également envisager update .

+1 pour rewrite , il a une belle sonnerie orwellienne. :-)

alter
discard
evict
expel
expunge
extrude
oust
...
nuke ? ??

J'aimerais proposer une nouvelle commande edit . Sur la base de tous les commentaires concernant ce problème, il me semble que nous pourrions nous retrouver avec plusieurs actions pour edit un ou plusieurs instantanés.

Pour le moment, cela pourrait être juste quelque chose comme :

$ restic edit 40dc1520 remove dir/file

À l'avenir, nous pourrions implémenter la suppression d'un fichier à partir de plusieurs instantanés (liste d'entrée de l'ID d'instantané ou de la plage de dates).

D'autres commandes sous le contexte d'édition peuvent être

• rename pour renommer des fichiers et des dossiers
• move pour corriger les structures de fichier/répertoire qui peuvent avoir changé

Je pense qu'il est important que nous permettions à ces actions d'être exécutées sur un ou plusieurs instantanés (par ID ou éventuellement un nombre de dates ou une plage).

Je ne sais toujours pas combien restic devrait pouvoir faire avec les données sauvegardées. Je veux dire, il est destiné à sauvegarder des données pour préserver à quoi ressemblaient les choses à un certain moment. Ce n'est pas censé être un NAS.

Je ne vois surtout pas la validité dans le cas d'utilisation du renommage et de la suppression de fichiers. Je veux dire, pourquoi voudriez-vous modifier les fichiers sur votre disque local, puis jouer avec vos sauvegardes pour que son arborescence de fichiers soit synchronisée avec vos données actuelles. Cela n'a pas de sens pour moi. Pouvez-vous détailler ce cas d'utilisation ?

@rawtaz
Mes pensées (presque) exactement.

Je dirais que la validité de la suppression de fichiers réside dans le scénario où vous découvrez une erreur dans vos règles d'exclusion après avoir déjà effectué des sauvegardes avec ces règles. Ainsi, la suppression de fichiers sert essentiellement à l'application rétroactive des règles d'exclusion. Il semble que quelle que soit la controverse dans ce fil, tout le monde est d'accord sur ce cas d'utilisation particulier.

Concernant les opérations au-delà de cela (c'est-à-dire renommer, ajouter), je partage vos doutes. C'est une fonctionnalité qui ne fait pas partie de la portée d'un outil de sauvegarde, à mon humble avis.

Je suis d'accord : il est important de supprimer des fichiers des instantanés, car il est très facile de sauvegarder accidentellement des fichiers que l'on n'avait pas l'intention de faire. Cela est souvent nécessaire pour des raisons de sécurité et d'utilisation du disque. Avoir cette fonctionnalité pourrait faire la différence entre pouvoir conserver d'anciennes données de sauvegarde ou devoir "jeter le bébé avec l'eau du bain".

Mais renommer ou déplacer des fichiers dans un instantané n'est probablement pas une bonne idée. Pour être franc, je n'ai jamais entendu parler de logiciel de sauvegarde capable de faire cela, et cela semble être une fonctionnalité étrange. Si un utilisateur en avait absolument besoin, il pourrait être implémenté en dehors de Restic en restaurant l'instantané, en réorganisant les fichiers et en le sauvegardant à nouveau avec la date définie explicitement (bien que cela puisse devenir plus compliqué à l'avenir lorsque Restic commencera à utiliser des chemins absolus) .

Certes, la fonctionnalité remove-paths-from-snapshots pourrait également être implémentée de cette façon, mais comme elle semble beaucoup plus susceptible d'être nécessaire, je pense qu'il est raisonnable qu'elle soit incluse dans Restic.

Alors, merci à tous pour vos retours, nous avons une solution claire : implémenter une commande qui permet de supprimer des fichiers d'un instantané existant. Le nom de la commande sera décidé quand nous y arriverons. Nous pouvons revisiter les autres cas d'usages lorsque le besoin s'en fait sentir.

Je ne pense pas que nous ayons besoin de plus de discussion ici, merci d'avoir participé !

Suggestion pour le nom de la commande : restic purge .

J'attends cette fonctionnalité avec impatience. Merci

@fd0
Une mise à jour sur cette fonctionnalité? J'adorerais l'utiliser :)
Nous utilisons restic dans un environnement gouvernemental et la suppression d'un seul fichier d'une sauvegarde est requise pour eux. Nous pourrions financer une partie des travaux si besoin !

J'attends ça aussi avec impatience ! Je propose d'utiliser quelque chose comme la structure de base pour restic find .

restic purge [flags] PATTERN

Où vous pourriez limiter les purge à host (-H) snapshots (-s) or paths (--path)

Alors peut-être qu'un restic prune ferait ensuite la suppression réelle

Ce serait tellement utile lorsqu'un fichier imprévu est sauvegardé par erreur (une grande vidéo dans un dossier de documents ou peut-être un fichier confidentiel) En ce moment, je lance un restic find puis supprime chaque instantané contenant le fichier. C'est moins que souhaitable si le fichier est loin dans le repo (dans le temps)

Merci !

Pas de mise à jour, désolé. Vous serez averti en vous abonnant à ce problème lorsque quelque chose se produit.

Il semble que la plupart des gens souhaitent pouvoir clone les métadonnées d'une sauvegarde, mais excluent les fichiers incriminés - sans avoir à les restaurer tous dans un emplacement de travail. L'idée de cloner une sauvegarde copierait les métadonnées avec la possibilité de supprimer certains pointeurs.

Est-ce le cas d'utilisation ?

• restic backup --exclude <something> --clone <original backup id> [new feature]
• restic forget <original backup id>
• restic prune

rewrite et modify pourraient être des macros pour le processus ci-dessus.

Pour moi, cela suffirait en effet @nullcake

Pas trop mal, @nullcake.

Cependant, sur la base de mon expérience passée, c'est généralement que je détecte que je sauvegarde des tonnes de choses sans valeur quelques jours ou semaines plus tard. Quand j'ai le temps d'enquêter. Cela signifie qu'au moment où je comprends que j'ai besoin de --exclure spécifique, il y a probablement une douzaine de sauvegardes ou plus affectées.

Bien sûr, même si tout type de nettoyage est mis en œuvre sur la base d'une seule sauvegarde, comme vous le suggérez, ce serait toujours un grand pas en avant. Nous savons bien sûr comment scénariser. ;)

Alors, bravo. :)

Bien que ce soit une idée intéressante, je crains que la commande backup soit déjà bien trop complexe, et l'ajout d'une autre "source" pour une sauvegarde la compliquera encore plus. De plus, cette fonction ne fonctionnerait que sur les données déjà présentes dans le référentiel (uniquement sur les métadonnées, pour être précis). Une commande séparée (par exemple purge ou plus) pourrait bien encapsuler la fonctionnalité.

CrashPlan avait un comportement intéressant : lorsqu'un fichier est exclu, il est purgé de tous les instantanés existants. Cela pourrait être quelque chose à considérer.

Ce serait une excellente fonctionnalité. A-t-il été ajouté ?

Nan.

@fd0 y a-t-il eu des progrès à ce sujet ? Je viens de découvrir que je n'excluais pas les caches comme je le pensais et j'adorerais les supprimer.

Encore une autre suggestion pour un nom de commande : scrub (même si je suis d' purge avec --rename me semblerait étrange). Mes pensées:

restic scrub [--dry-run] [--replace=<clean|prune>] [--diff] [--all | snapshot-ID...]

Où --replace=clean supprime tout instantané modifié, prune nettoie et exécute prune par la suite. --diff affiche une différence pour tous les instantanés modifiés. --dry-run évite de valider toute modification du référentiel.

Sont également valides tous les drapeaux --exclude de restic backup . Je suppose que --host et --time également un sens (chacun remplaçant les valeurs de l'instantané préexistant) ; --tag édition est déjà gérée par restic tag .

Des développeurs ont-ils des conseils sur la façon dont cela pourrait être mis en œuvre? Il me semble (d'un coup d'œil rapide) que la plupart du code peut aller dans un fichier cmd_scrub.go ; peut-être que quelques ajouts d'API à la bibliothèque interne sont nécessaires car il semble qu'il s'agisse principalement d'opérations d'indexation, mais c'est peut-être naïf. Une difficulté estimée (je suppose que les tests seront de toute façon l'essentiel) ?

puisqu'il s'agit d'un très très ancien problème. Y a-t-il une chance d'obtenir cette fonctionnalité ?

Pour tout ce qui surveille les mises à jour et les frappe depuis Google, il n'est pas nécessaire d'attendre que ce problème ne se concrétise jamais, utilisez simplement duplicati pour l'instant, il dispose d'un support de première classe pour supprimer les fichiers post-fact des instantanés.

Pour tout ce qui surveille les mises à jour et les frappe depuis Google, il n'est pas nécessaire d'attendre que ce problème ne se concrétise jamais, utilisez simplement duplicati pour l'instant, il dispose d'un support de première classe pour supprimer les fichiers post-fact des instantanés.

J'utilise restic depuis environ un an maintenant et j'ai arrêté d'attendre que les fonctionnalités soient implémentées. Je ne veux pas dire que tout devrait être ajouté dans restic, mais il y a des choses de base qui devraient être là. J'envisage de m'éloigner de restic : le référentiel est très fragile et peut se casser très facilement.

Hier, j'ai supprimé un instantané car il incluait des fichiers qui n'auraient pas dû être dans la sauvegarde (j'ai oublié d'ajouter une exclusion). Depuis lors, j'ai des erreurs dans mon référentiel et je n'ai pas encore pu le réparer. Je ne devrais pas avoir à supprimer des instantanés entiers car certains fichiers ont été inclus par erreur.

@MorgothSauron Je viens généralement de supprimer les instantanés qui le contenaient également, ce qui semble être la seule solution dans restic, mais encore une fois, duplicati peut le faire via une seule commande depuis un certain temps maintenant, j'ai donc changé depuis et je n'ai eu aucun problème.

Je tiens à remercier tout le monde pour leur contribution à ce sujet. Comme nous l'avons vu, de nombreuses personnes ont notamment souhaité avoir la possibilité de supprimer des fichiers d'un instantané. Je suppose que nous faisons tous des erreurs de temps en temps lors de la sauvegarde ;)

À ce stade, le temps disponible pour le mainteneur et le développeur est nécessaire sur d'autres parties de restic, donc je ne prévois pas que ce problème soit implémenté dans un avenir prévisible. Je vais également publier un nouveau serveur de repos dès que possible, puis je commencerai à examiner d'autres problèmes.

Cela dit, si quelqu'un fait un PR solide qui est bien et clairement écrit, bien testé et sans bogues, et produit en coordination avec les responsables, il sera certainement considéré pour inclusion. Ce problème spécifique est celui où @fd0 a déjà donné sa bénédiction sur la direction, donc l'accent peut être principalement mis sur la production d'une implémentation solide (dont nous savons qu'elle ne corrompre pas les dépôts) plutôt que "devrions-nous ajouter cette fonctionnalité", ce qui est bien .

Un tel PR devrait être basique et servir de point de départ sur lequel, si nécessaire, on peut s'appuyer. Un exemple de ce que je veux dire par là est qu'il devrait pour commencer:

• Soyez juste une nouvelle commande (par exemple rewrite puisque c'est la plus votée dans ce numéro).
• Prenez une liste d'instantanés comme argument principal (y compris la prise en charge de all ), par exemple all ou 098db9d5 ou 098db9d5 af92db33 .
• Prenez une liste d'un ou plusieurs --exclude <pattern> pour lister les chemins qui doivent être exclus/supprimés de l'instantané (en d'autres termes, voici le --exclude qui manquait lors de la sauvegarde), par exemple --exclude="*.o" , --exclude=*.unwanted , --exclude="*.o" --exclude=*.unwanted --exclude=.DS_Store .

La justification ici est d'obtenir un démarrage minimal en tant que preuve de concept et produit minimum viable. Une fois testé, nous pouvons l'ajuster au besoin, par exemple en ajoutant les autres arguments --exclude-* de la commande backup . Si nous créons une commande rewrite comme celle-ci, elle aura à peu près la même interface que la commande backup qu'elle est censée "corriger":

~restic -r /some/repo rewrite all --exclude=" .o" --exclude= .unwanted --exclude=.DS_Storerestic -r /some/repo rewrite 098db9d5 af92db33 --exclude=" .o" --exclude= .unwanted --exclude=.DS_Store~

Sur une note connexe, peut-être que le travail effectué par @middelink dans https://github.com/restic/restic/issues/323 pourrait être utilisé comme source d'inspiration ou comme base pour la mise en œuvre, car il effectue un certain traitement des instantanés existants. Je vais voir si on peut bouger avec celui-ci trop tôt.

@rawtaz

Merci pour les commentaires réfléchis!

Salut.

J'ai ajouté le brouillon rewrite implémentation de @rawtaz

Cela fonctionne ici avec le dépôt de test, passe restic check --read-data sans erreur, mais ne l'a pas beaucoup testé. Je suggère donc fortement de ne pas l'utiliser avec des données importantes.

J'ai essayé d'obtenir une syntaxe très proche de la commande backup . Donc --exclude , --iexclude et --exclude-file sont supportés (mais pas testés). Idéalement, je veux aussi voir l'option --exclude-if-present (le workflow idéal pour moi est quelque chose comme 'oops, pas besoin de sauvegarder, ajoutez CACHEDIR.TAG et restic rewrite '). Mais c'est assez complexe car dans ce cas, nous aurons besoin de rewrite sur le même hôte où la sauvegarde a été effectuée et d'accéder au système de fichiers pour collecter ces fichiers (plus des tonnes de magie avec des chemins relatifs). Donc pas tout de suite...

De plus, je n'aime pas l'idée de remplacer les instantanés par défaut, donc actuellement, le comportement par défaut consiste simplement à créer un nouvel instantané avec la balise rewrite . Mais le remplacement est également possible avec --inplace arg.

Tous commentaires serait grandement apprécié.

Salut Dmitry,

Merci pour cette réalisation, beau travail !

Jusqu'à présent, cela fonctionne parfaitement sous Linux avec un petit dépôt de test de 600 fichiers + plusieurs instantanés de test. La restauration fonctionne et le diff affiche correctement les dossiers exclus. Je ferai des tests plus intensifs sur un véritable référentiel "clone" avec de nombreux Go de données avec plus de 100 instantanés. Je vais également essayer les dépôts sous Windows.

Une proposition : avoir la possibilité de spécifier une balise pour les snapshots qui contenaient les exclusions sur une passe de réécriture. (en conservant la balise " rewrite " sur les instantanés nouvellement créés.)

restic rewrite --add-tag mytag -i thisfileshouldberemoved.txt all

Cela aiderait à identifier les instantanés qui contiennent toujours "_thisfileshouldberemoved.txt_". D'un autre côté, le --inplace plus direct fonctionne comme prévu.

Encore du très bon travail.

@NovacomExperts Oui, ma motivation initiale était de garder «l'édition de l'histoire aussi sûre que possible». Il est très facile d'exclure quelque chose d'important avec --exclude * et presque aucun moyen de récupérer à partir de cela (avec la sauvegarde, il suffit de recommencer une nouvelle sauvegarde). Quelque chose comme --dry-run mais avec la possibilité d'obtenir un instantané réel et de supprimer explicitement l'instantané source après avoir vérifié que tout va bien.

Je suis tout à fait d'accord pour dire qu'actuellement, cela n'est pas entièrement atteint. Il est facile d'« observer » les nouveaux instantanés, mais trop difficile de supprimer les anciens. De plus, je n'aime pas le nom de l'instantané rewrite codé en dur. Peut-être qu'il vaut mieux avoir --inplace par défaut et ---keep-source-tagged before-rewrite --tag-destination after-rewrite ou quelque chose comme ça. ( --add-tag n'est pas clair, qu'il s'agisse d'un ancien ou d'un nouveau snapshot).

En tout cas j'attends les retours des mainteneurs. Je ne veux pas passer beaucoup de temps s'il va dans la mauvaise direction.

PS. Mon référentiel restic principal est d'environ ~ 2 To maintenant. J'essaierai plus tard après avoir fait un instantané LVM.

@dionorgua Votre motivation initiale est tout à fait correcte. Je voterai pour que ça reste comme ça, avec l'option "dangereux" --inplace plus loin possible de l'utilisateur (certainement pas par défaut). Je préférerais une erreur d'argument manquant sur --keep-source-tagged / --tag-destination que --inplace par défaut.

Mais je suis d'accord, attendons des retours à ce sujet.

Hier, j'ai oublié le dépôt de test cloné (65 Go) dans un dossier qui a été sauvegardé par restic pendant la nuit. J'aurais pu avoir l'instantané d'hier forget mais j'ai fait "all in" et j'ai essayé votre implémentation. Après forget + prune , j'ai réussi à supprimer les 65 Go d'un référentiel de 400 Go. Tout va bien, aucune erreur trouvée.

Je teste plus intensément avec des données qui s'étendent sur plusieurs instantanés.

À votre santé

J'ai remplacé cette mauvaise demande d'extraction #2720 par une nouvelle car l'ancienne a été créée à partir de la branche principale. Je viens d'ajouter un contrôle d'erreur manquant. Désolé pour le bruit supplémentaire

Hum, modify alors ?

Très tard pour cela, mais _rectify_ est ma suggestion pour la commande delete-specific-file-from-backup.

2731 est excitant, merci beaucoup !

Très tard pour cela, mais rectifier est ma suggestion pour la commande delete-specific-file-from-backup.

Je dois dire que ce n'est pas un bon nom pour ça. Rectify implique qu'il y a quelque chose qui ne va pas qui doit être corrigé/rectifié. Bien que cela puisse être vrai dans l'un des cas d'utilisation, ce n'est pas toujours le cas. Un utilisateur peut vouloir simplement supprimer certaines données des instantanés existants pour libérer de l'espace pour tout ce que nous savons, tout en conservant le reste de l'instantané. Le libellé doit être plus neutre que rectifier, je pense.