Isso seria muito bom.

Também permitiria a remoção de dados confidenciais que foram incluídos involuntariamente.

Isso seria um ótimo recurso!

Algum feedback dos desenvolvedores sobre essa ideia? Seria muito bom. Por exemplo, acabei de descobrir que um programa que construí a partir de checkouts do git está criando binários enormes (quase 100 MB) e estão sendo armazenados em meus backups Restic desnecessariamente. Não uso o Restic há muito tempo, pois ainda estou em fase de testes, então não é um problema excluir os instantâneos antigos em questão. Mas esse problema pode acontecer com bastante facilidade, e seria bom ter soluções de longo prazo para ele, além de esquecer todos os instantâneos.

Suponho que seria possível escrever um script para restaurar cada instantâneo, excluir arquivos indesejados e refazer o backup do instantâneo definindo a data manualmente, mas obviamente isso levaria muito tempo. Seria ótimo se a Restic pudesse fazer isso nativamente.

Obrigado.

Acho que existem vários casos de uso válidos para isso. Parece ser um recurso muito bom de se ter. Eu provavelmente o usaria em algum momento.

Provavelmente não muda realmente o esforço de implementação, mas do ponto de vista de UX, isso pode ser feito com um perfil bastante discreto, estendendo o comando backup vez de adicionar um comando inteiramente novo:

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

Portanto, em vez de oferecer um comando que modifica os instantâneos, isso permitiria fazer um novo backup com base em um ID de instantâneo existente. A exclusão de um arquivo seria realizada com regras de exclusão.
Toda a documentação em restic backup poderia basicamente ser "reutilizada" (ou seja, quase nada precisaria ser adicionado para este novo recurso).

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

No entanto, eu não sigo você aqui. Remover dados de instantâneos antigos é definitivamente uma operação distinta e deve ter seu próprio comando. Algo como:

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

E --snapshots provavelmente deve aceitar uma palavra-chave all para operar em todos os instantâneos (ou todos os instantâneos com o --tag especificado). E o comando provavelmente deve requerer confirmação digitando yes .

Também seria bom ter uma opção --patterns , que excluiria os caminhos correspondentes aos padrões fornecidos.

purge é uma possibilidade para o nome do comando. erase também pode ser uma boa escolha, assim como delete . O que quer que seja escolhido, deve deixar claro que a operação exclui os dados permanentemente . Este é o software de backup do qual estamos falando, e todas as operações perigosas devem ser distintas, explícitas e exigir confirmação.

Bem, eu deixei de fora a etapa em que você excluiria o instantâneo de origem posteriormente (usando forget , então talvez prune ), porque pensei que era óbvio.

Na minha opinião, fazer assim manteria o conjunto de comandos mais ortogonal em comparação com a adição de um novo comando que se sobrepõe à funcionalidade dos comandos existentes. No momento, há backup , forget e prune e todos eles fazem coisas completamente diferentes. Adicionar purge como você o descreveu muda isso. Minha sugestão não.

uma vez que estamos propondo operações de um arquivo, seria bom poder renomear.

Concordo com @alphapapa que deve haver um comando distinto para este tipo de operação. Pode ser purge , não é um nome ruim, então, novamente, pode haver outras operações semelhantes no futuro, por exemplo, @alvarolm já sugeriu ser capaz de renomear arquivos.

Por essa razão, acho que adicionar um comando rewrite é a melhor alternativa neste caso, e fazer com que esse comando tenha, por exemplo, opções --purge e --rename , assumindo que o último seja relevante para implemento. Portanto, os comandos finais seriam, por exemplo, restic -r foo rewrite --purge snap1,snap2 path1 path2 ... e restic -r foo rewrite --rename snap1,snap2 pathFrom pathTo .

Dito isso, não estou totalmente certo de que renomear seja algo razoável de implementar - é muito mais do que um programa de backup. Mas com certeza, por que não.

Não acho sensato ter o material de purga como parte do comando backup. Em uma perspectiva, você pode argumentar que está tudo bem - você está fazendo uma operação em seu backup. Mas, com esse raciocínio, as ações de podar, desbloquear e esquecer também devem fazer parte do comando de backup, pois também tratam da manutenção de coisas em seu backup. Não acho que faça sentido, então acho que deveria ser uma operação / comando separado, por exemplo, rewrite ou purge .

@dnnr

Bem, eu deixei de fora a etapa em que você excluiria o instantâneo de origem depois (usando esquecer, depois, talvez, podar), porque pensei que era óbvio.

Definitivamente não é óbvio. Também é melhor se o Restic cuida disso para o usuário, em vez de o usuário ter que manter o controle de quais IDs de instantâneo foram alterados e precisam ser esquecidos - o que seria um fardo se o usuário estivesse reescrevendo todos os instantâneos no repo.

Na minha opinião, fazer assim manteria o conjunto de comandos mais ortogonal em comparação com a adição de um novo comando que se sobrepõe à funcionalidade dos comandos existentes.

Eu não entendo o que você quer dizer. O oposto é o caso. Este comando purge / delete / rewrite proposto não se sobrepõe a backup - ele exclui dados de instantâneos existentes . É ortogonal aos comandos existentes.

No momento, há backup, esqueça e podar e todos eles fazem coisas completamente separadas. Adicionar uma purga como você descreveu muda isso. Minha sugestão não.

Novamente, não tenho ideia do que você está pensando aqui. purge é completamente separado do backup, esqueça e poda:

• backup : Cria um novo instantâneo de determinados caminhos.
• forget : Remove instantâneos existentes.
• prune : coleta de lixo blobs não usados ​​de instantâneos esquecidos.
• purge / rewrite / qualquer: Exclui arquivos de instantâneos existentes.

Você está propondo fazer o comando backup operar em dois modos, um dos quais faz backup dos dados e o outro exclui os dados.

@rawtaz Sim, rewrite é uma boa sugestão, porque literalmente reescreve os instantâneos existentes. Eu sugiro uma IU como:

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

Não recomendo o uso de vírgulas como separadores, porque torna a construção de linhas de comando em scripts muito mais complicada.

backup: Cria um novo instantâneo de determinados caminhos.

Bem, de certo modo, modificar o conteúdo de um instantâneo é criar um novo instantâneo (porque não é o mesmo instantâneo de antes). Pense em git commit --amend , que cria um novo commit baseado em um commit existente. Na verdade, a analogia é bem adequada, já que esse tíquete parece mover-se rapidamente para reinventar o Git.

Você está propondo fazer o comando backup operar em dois modos, um dos quais faz backup dos dados e o outro exclui os dados.

Eu não disse isso. Por que isso? Existem forget e prune , que são perfeitamente adequados para remover coisas.

Bem, de certo modo, modificar o conteúdo de um instantâneo é criar um novo instantâneo (porque não é o mesmo instantâneo de antes). Pense em git commit --amend, que cria um novo commit baseado em um commit existente. Na verdade, a analogia é bem adequada, já que esse tíquete parece mover-se rapidamente para reinventar o Git.

Você tem razão. Mas, ao mesmo tempo, o Restic não é git e não foi projetado para exigir conhecimento de endereçamento baseado em conteúdo para funcionar. Independentemente de como funciona nos bastidores, acho que, para os usuários, o comando que estamos propondo deve ser considerado para modificar um instantâneo existente, não criar um novo, portanto, deve ser um comando distinto.

Eu não disse isso. Por que isso?

Bem, você disse:

de um ponto de vista UX, isso pode ser feito com um perfil bastante baixo, estendendo o comando de backup em vez de adicionar um comando inteiramente novo

Talvez você deva explicar com mais detalhes.

Há esquecer e podar, que são perfeitamente adequados para remover coisas.

Vamos ser específicos. forget remove instantâneos e prune remove blobs . Estamos propondo um comando para remover arquivos dentro de instantâneos . Deve ser um comando distinto.

Eu gostaria de adicionar minha opinião:

Acho que ter uma maneira de modificar os instantâneos no repo é valioso, com base no feedback de quantas pessoas gostariam de ter algo assim.

O comando deve ser independente do comando backup , não apenas por razões de ortogonalidade (que é bastante parecido com Go), mas também por consideração prática: O comando backup já é complexo o suficiente para que eu gostaria de separar o outro comando dele.

Não gosto do nome purge , por causa da semelhança com prune . E quanto a change ? Então temos restic backup , restic restore e restic change .

Para as operações com suporte do comando, tenho visto solicitações para:

• Exclua arquivos, por exemplo, --delete
• Renomear arquivos, por exemplo, --rename

O primeiro é exatamente do que se trata (originalmente), mas há realmente casos de uso para renomear arquivos?

Acho que change soa mais como tirar algo e colocar algo dentro, em vez de modificar o conteúdo de algo.

Imagine que o repo / backup / instantâneo é um balde. Mudar é mais como trocar o próprio balde por outra coisa, ou tirar algo dele e colocar outra coisa, em vez de pegar algo no balde, modificá-lo um pouco e colocá-lo de volta.

Talvez algum nativo inglês / americano saiba o que é mais adequado :) Acho que se resume à lingüística.

Hm, modify então?

modify é definitivamente melhor do que change . Portanto, ou rewrite ou modify do que foi proposto até agora. Curioso o que os outros pensam :)

Se se trata apenas de excluir arquivos, faria sentido aprimorar o comando forget para trabalhar com instantâneos e arquivos? Ou isso seria muito complexo?

Se este novo recurso for sobre exclusão e renomeação (ou outra coisa), eu votaria em modify .

Obrigado pela sua contribuição @dimejo 👍

Eu acho que quando você está renomeando e / ou excluindo, você não está forget ting (pelo menos não no primeiro caso).

IMHO "reescrever" transmite o significado da melhor.

O comando forget também é muito complexo, não adicionaremos nada a ele se pudermos ajudá-lo;)

Se for um comando separado, chamá-lo de modify também seria meu favorito (também gostaria de modify-snapshot , embora seja um pouco longo). Também é genérico o suficiente para ser um local apropriado para todos os tipos de operações de modificação de arquivo (renomear, talvez até adicionar). No entanto, ainda acho que qualquer coisa além de remover arquivos cheira fortemente a degradação de recursos.

A propósito, acho que o restic se beneficiaria das categorias de comando, semelhantes ao que o Git tem com seus comandos de encanamento. No momento, restic -h lista todos os comandos em ordem lexical, misturando comandos de baixo nível (por exemplo, cat , list , que nunca serão necessários para usuários "normais") com os comandos principais de alto nível.

Você também pode considerar update .

+1 para rewrite , tem um belo toque orwelliano. :-)

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

Eu gostaria de propor um novo comando edit . Com base em todos os comentários sobre este problema, parece-me que podemos terminar com várias ações para edit one ou vários instantâneos.

Por enquanto, pode ser apenas algo como:

$ restic edit 40dc1520 remove dir/file

No futuro, poderíamos implementar a exclusão de um arquivo de vários instantâneos (lista de entrada de ID do instantâneo ou intervalo de datas).

Outros comandos no contexto de edição podem ser

• rename para renomear arquivos e pastas
• move para corrigir estruturas de arquivo / dir que podem ter mudado

Acredito que seja importante permitirmos que essas ações sejam executadas em um ou vários instantâneos (por ID ou possivelmente várias datas ou um intervalo).

Ainda não tenho certeza sobre o quanto o Restic deve ser capaz de fazer com os dados de backup. Quer dizer, ele serve para fazer backup de dados para preservar a aparência das coisas em um determinado momento. Não foi feito para ser um NAS.

Eu especialmente não vejo validade no caso de uso de renomear e remover arquivos. Quero dizer, por que você mudaria os arquivos em seu disco local e depois iria mexer em seus backups para manter sua árvore de arquivos em sincronia com seus dados atuais. Não faz sentido para mim. Você pode explicar melhor esse caso de uso?

@rawtaz
Meus pensamentos (quase) exatamente.

Eu diria que a validade da remoção de arquivos reside no cenário em que você descobre um erro em suas regras de exclusão depois de já ter feito backups com essas regras. Portanto, a remoção de arquivos serve basicamente como a aplicação retroativa de regras de exclusão. Parece que, independentemente da controvérsia neste tópico, todos concordam com aquele caso de uso específico.

Com relação às operações além disso (ou seja, renomear, adicionar), compartilho suas dúvidas. É um recurso creep e não está no escopo de uma ferramenta de backup, IMHO.

Eu concordo: excluir arquivos de instantâneos é importante, pois é muito fácil fazer backup acidental de arquivos que não se pretendia. Isso geralmente é necessário por motivos de segurança e de uso de disco. Ter esse recurso pode significar a diferença entre ser capaz de manter dados de backup antigos ou ter que "jogar fora o bebê com a água do banho".

Mas renomear ou mover arquivos em um instantâneo provavelmente não é uma boa ideia. Para ser franco, nunca ouvi falar de um software de backup que pudesse fazer isso, e parece um recurso estranho. Se um usuário realmente precisasse disso, poderia ser implementado fora da Restic restaurando o instantâneo, reorganizando os arquivos e fazendo o backup novamente com a data definida explicitamente (embora isso possa se tornar mais complicado no futuro quando a Restic começar a usar caminhos absolutos) .

Concedido, o recurso remove-path-from-snapshots também poderia ser implementado dessa maneira, mas como parece muito mais provável de ser necessário, acho que é razoável incluí-lo no Restic.

Portanto, obrigado a todos por seus comentários, temos um caminho claro a seguir: implementar um comando que permite remover arquivos de um instantâneo existente. O nome do comando será decidido quando chegarmos lá. Podemos revisitar os outros casos de uso quando houver necessidade.

Não acho que precisamos de mais discussão aqui, obrigado por participar!

Sugestão para o nome do comando: restic purge .

Estou ansioso por este recurso. Obrigado

@ fd0
Alguma atualização sobre este recurso? Adoraria usá-lo :)
Estamos usando o restic em um ambiente governamental e a exclusão de um único arquivo de um backup é necessária para eles. Poderíamos financiar parte do trabalho, se necessário!

Estou ansioso por isso também! Proponho usar algo como a estrutura de base para restic find .

restic purge [flags] PATTERN

Onde você poderia limitar purge a host (-H) snapshots (-s) or paths (--path)

Então, talvez um restic prune faria posteriormente a exclusão real

Isso seria muuuuito útil quando um arquivo imprevisto for salvo por erro (um grande vídeo em uma pasta de documentos ou talvez algum arquivo confidencial). Agora mesmo, executo restic find e excluo todos os instantâneos que contêm o arquivo. . Isso é menos do que desejável se o arquivo estiver no repositório (no tempo)

Obrigado !

Sem atualização, desculpe. Você será notificado ao se inscrever neste problema quando algo acontecer.

Parece que a maioria das pessoas deseja ser capaz de clone um backup dos metadados, mas excluir arquivos ofensivos - sem ter que restaurá-los todos em um local de rascunho. A ideia de clonar um backup iria copiar metadados com a capacidade de remover certos ponteiros.

É este o caso de uso?

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

rewrite e modify podem ser macros para o processo acima.

Para mim, isso seria realmente suficiente @nullcake

Nada mal, @nullcake.

Porém, com base em minha experiência anterior, geralmente detectei que fiz backup de cargas de coisas inúteis apenas alguns dias ou semanas depois. Quando eu tiver algum tempo para investigar. O que isso significa é que, quando eu entendo que preciso de algum --exclude específico, provavelmente há uma dúzia ou mais de backups afetados.

Claro, mesmo que qualquer tipo de limpeza seja implementado com base em um único backup, como você sugere, ainda seria um grande passo em frente. Nós, é claro, sabemos como fazer um script. ;)

Então, polegar para cima. :)

Embora seja uma ideia interessante, temo que o comando backup seja muito complexo, e adicionar outra "fonte" para um backup vai complicar ainda mais. Além disso, essa função funcionaria apenas em dados já no repo (apenas em metadados, para ser mais preciso). Um comando separado (por exemplo, purge ou algo assim) pode encapsular a funcionalidade muito bem.

O CrashPlan teve um comportamento interessante: quando um arquivo é excluído, ele é removido de todos os instantâneos existentes. Isso pode ser algo a se considerar.

Isso seria um ótimo recurso. Foi adicionado?

Não.

@ fd0 houve algum progresso nisso? Acabei de descobrir que não estava excluindo caches como pensava e adoraria removê-los.

Ainda outra sugestão para um nome de comando: scrub (embora eu esteja bem com purge também, o sinalizador --rename pareceria estranho para mim). Meus pensamentos:

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

Onde --replace=clean remove qualquer instantâneo modificado, prune limpa e executa prune depois. --diff mostra uma diferença para qualquer instantâneo modificado. --dry-run evita comprometer quaisquer alterações no repo.

Também são válidos todos os sinalizadores de restic backup --exclude de restic backup . Acho que --host e --time também fazem sentido (cada um substituindo os valores do instantâneo preexistente); --tag edição já é tratada por restic tag .

Algum desenvolvedor tem orientação sobre como isso pode ser implementado? Parece-me (olhando rapidamente) que a maior parte do código pode ir em um arquivo cmd_scrub.go ; talvez apenas algumas adições de API à biblioteca interna necessárias, uma vez que parece ser principalmente operações de índice, mas talvez isso seja ingênuo. Alguma dificuldade estimada (suponho que o teste será a maior parte dela em qualquer caso)?

uma vez que este é um problema muito antigo .. há alguma chance de obter esse recurso?

Por tudo que monitoram isso para atualizações e acertam do Google, não há necessidade de esperar que esse problema nunca se concretize, apenas use duplicatas por enquanto, ele tem suporte de primeira classe para remover arquivos pós-fatos de instantâneos.

Por tudo que monitoram isso para atualizações e acertam do Google, não há necessidade de esperar que esse problema nunca se concretize, apenas use duplicatas por enquanto, ele tem suporte de primeira classe para remover arquivos pós-fatos de instantâneos.

Estou usando o restic há cerca de um ano e parei de esperar que os recursos fossem implementados. Não quero dizer que tudo deva ser adicionado ao repouso, mas há coisas básicas que devem estar lá. Estou pensando em me afastar do restic: o repositório é muito frágil e pode ser quebrado facilmente.

Ontem apaguei um instantâneo porque incluía arquivos que não deveriam estar no backup (esqueci de adicionar uma exclusão). Desde então, tenho erros no meu repositório e ainda não fui capaz de repará-lo. Eu não deveria ter que deletar um instantâneo inteiro porque alguns arquivos foram incluídos por engano.

@MorgothSauron Eu geralmente

Desejo agradecer a todos por suas contribuições sobre este assunto. Como vimos, muitas pessoas desejam, em particular, a capacidade de remover arquivos de um instantâneo. Acho que todos cometemos erros de vez em quando ao fazer backup;)

No momento, o tempo disponível para o mantenedor e o desenvolvedor é necessário em outras partes do restic, portanto, não prevejo que esse problema seja implementado em um futuro previsível. Também vou lançar um novo servidor de descanso assim que puder e, então, começarei a examinar alguns outros problemas.

Dito isso, se alguém fizer um RP sólido que seja bem e claramente escrito, bem testado e sem bugs, e produzido em coordenação com os mantenedores, ele definitivamente será considerado para inclusão. Este problema específico é aquele em que @ fd0 já deu sua aprovação sobre a direção, então o foco pode ser principalmente na produção de uma implementação sólida (que sabemos que não corromperá os repositórios) em vez de "devemos adicionar este recurso", o que é bom .

Tal RP deve ser básico e funcionar como um ponto de partida que, se necessário, pode ser aproveitado. Um exemplo do que quero dizer com isso é que deveria, para começar:

• Basta ser um novo comando (por exemplo, rewrite já que é o mais votado nesta edição).
• Faça uma lista de instantâneos como seu (s) argumento (s) primário (incluindo suporte para all ), por exemplo, all ou 098db9d5 ou 098db9d5 af92db33 .
• Faça uma lista de um ou mais --exclude <pattern> para listar os caminhos que devem ser excluídos / removidos do instantâneo (em outras palavras, aqui está o --exclude que estava faltando durante o backup), por exemplo, --exclude="*.o" , --exclude=*.unwanted , --exclude="*.o" --exclude=*.unwanted --exclude=.DS_Store .

A lógica aqui é obter um início mínimo como uma prova de conceito e um produto mínimo viável. Depois de ser testado, podemos ajustá-lo conforme necessário, por exemplo, adicionando os outros --exclude-* argumentos do comando backup . Se fizermos um comando rewrite como este, ele terá praticamente a mesma interface do comando backup que deve "corrigir":

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

Em uma nota relacionada, talvez o trabalho feito por @middelink em https://github.com/restic/restic/issues/323 possa ser usado como inspiração ou base para a implementação, já que faz algum processamento de instantâneos existentes. Vou ver se podemos avançar com este muito em breve.

@rawtaz

Obrigado pelo feedback atencioso!

Olá.

Eu adicionei o rascunho da implementação rewrite perto do comentário de @rawtaz

Ele funciona aqui com repo de teste, passa restic check --read-data sem erros, mas não testei muito. Portanto, sugiro fortemente não usá-lo com dados importantes.

Tentei obter uma sintaxe muito próxima do comando backup . Portanto, --exclude , --iexclude e --exclude-file são suportados (mas não testados). Idealmente, também quero ver a opção --exclude-if-present (o fluxo de trabalho ideal para mim é algo como 'opa, não é necessário fazer backup, adicione CACHEDIR.TAG e restic rewrite '). Mas é muito complexo porque, nesse caso, precisaremos rewrite no mesmo host onde o backup foi feito e acessar o sistema de arquivos para coletar esses arquivos (mais toneladas de magia com caminhos relativos). Então, não agora ...

Além disso, não gosto da ideia de substituir os instantâneos por padrão, então o comportamento padrão atualmente é apenas criar um novo instantâneo com a tag rewrite . Mas a substituição também é possível por --inplace arg.

Qualquer comentário seria muito apreciado.

Ei Dmitry,

Obrigado por esta implementação, ótimo trabalho!

Até agora, ele funciona perfeitamente no Linux com um pequeno repositório de teste de 600 arquivos + vários snapshots de teste. Restaurar funciona e diff mostra pastas excluídas corretamente. Farei testes mais intensivos em um repositório real "clone" com muitos GB de dados com mais de 100 instantâneos. Também tentarei os repositórios originados do Windows.

Uma proposição: tem a opção de especificar uma tag para os instantâneos que continham as exclusões em uma passagem de reescrita. (mantendo a tag " rewrite " em instantâneos recém-criados.)

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

Isso ajudaria a identificar os instantâneos que ainda contêm "_thisfileshouldberemoved.txt_". Por outro lado, o --inplace mais direto funciona como esperado.

Mais uma vez, um trabalho muito bom.

@NovacomExperts Sim, minha motivação inicial era manter a 'edição do histórico o mais segura possível. É muito fácil excluir algo importante com --exclude * e quase nenhuma maneira de recuperar isso (com o backup, é apenas uma questão de iniciar um novo backup novamente). Algo como --dry-run mas com capacidade de obter o instantâneo real e excluir explicitamente o instantâneo de origem após verificar se está tudo bem.

Concordo plenamente que, atualmente, isso não foi totalmente alcançado. É fácil 'observar' novos instantâneos, mas muito difícil excluir o antigo. Além disso, não gosto de rewrite nome de instantâneo codificado. Talvez seja melhor ter --inplace por padrão e ---keep-source-tagged before-rewrite --tag-destination after-rewrite ou algo assim. ( --add-tag está claro, se é um instantâneo antigo ou um novo).

Em qualquer caso, vou esperar o feedback dos mantenedores. Não quero perder muito tempo se estiver indo na direção errada.

PS. Meu repo restic primário está em torno de ~ 2 TB agora. Vou tentar mais tarde depois de fazer o instantâneo do LVM.

@dionorgua Sua motivação inicial está totalmente correta. Vou votar para mantê-lo assim, com a opção "perigosa" --inplace mais longe possível do usuário (definitivamente não por padrão). Eu preferiria um erro de argumento ausente em --keep-source-tagged / --tag-destination que --inplace por padrão.

Mas eu concordo, vamos aguardar um feedback sobre isso.

Ontem, esqueci o repo de teste clonado (65 GB) dentro de uma pasta cujo backup foi feito pelo restic durante a noite. Eu poderia ter forget o instantâneo de ontem, mas fui "all in" e tentei sua implementação. Depois de forget + prune , removi com sucesso os 65 GB de um repositório de 400 GB. Tudo bem, nenhum erro encontrado.

Eu testo mais intensamente com dados que abrangem vários instantâneos.

Saúde

Substituí a solicitação de pull # 2720 errada por uma nova porque a antiga foi criada a partir do branch master. Acabei de adicionar uma verificação de erro ausente. Desculpe pelo barulho extra

Hm, modify então?

Muito tarde para isso, mas _rectify_ é minha sugestão para o comando delete-specific-file-from-backup.

2731 é emocionante, muito obrigado!

Muito tarde para isso, mas retificar é minha sugestão para o comando delete-specific-file-from-backup.

Devo dizer que não é um bom nome para isso. Retificar implica que há algo errado que precisa ser corrigido / retificado. Embora isso possa ser verdade em um dos casos de uso, nem sempre é o caso. Um usuário pode querer apenas remover alguns dados de instantâneos existentes para liberar espaço para tudo o que sabemos, enquanto mantém o resto do instantâneo. A formulação tem que ser mais neutra do que retificar, eu acho.