それは本当にいいでしょう。

また、無意識のうちに含まれていた機密データを削除することもできます。

これは素晴らしい機能です！

このアイデアに関する開発者からのフィードバックはありますか？ それはとてもいいでしょう。 たとえば、git checkoutsから構築したプログラムが巨大なバイナリ（約100 MB）を作成していて、これらがResticバックアップに不必要にバックアップされていることを発見しました。 私はまだテスト段階にあるので、Resticを長い間使用していません。したがって、問題の古いスナップショットを削除しても問題はありません。 ただし、この問題は非常に簡単に発生する可能性があるため、すべてのスナップショットを忘れる以外に、長期的な解決策があるとよいでしょう。

すべてのスナップショットを復元し、不要なファイルを削除し、日付を手動で設定することでスナップショットを再バックアップするスクリプトを作成することは可能だと思いますが、明らかにそれには非常に長い時間がかかります。 Resticがこれをネイティブに実行できれば素晴らしいと思います。

ありがとう。

これには複数の有効なユースケースがあると思います。 持っているのは本当に良い機能のようです。 私はおそらくいつかそれを自分で使うでしょう。

おそらく実際には実装の労力は変わりませんが、UXの観点からは、まったく新しいコマンドを追加する代わりに、 backupコマンドを拡張することで、かなり目立たないようにすることができます。

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

したがって、スナップショットを変更するコマンドを提供する代わりに、これにより、既存のスナップショットIDに基づいて新しいバックアップを作成できます。 ファイルの削除は、除外ルールを使用して実現されます。
restic backupに関するすべてのドキュメントは、基本的に「再利用」できます（つまり、この新機能のために追加する必要はほとんどありません）。

@dnnrhttps ： //github.com/restic/restic/issues/1550#issuecomment-358536554を参照してください

ただし、ここではフォローしません。 古いスナップショットからデータを削除することは間違いなく別個の操作であり、独自のコマンドが必要です。 何かのようなもの：

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

また、 --snapshotsは、すべてのスナップショット（または指定された--tagすべてのスナップショット）を操作するために、おそらくallキーワードを受け入れる必要があります。 また、コマンドにはおそらくyes入力して確認する必要があります。

また、指定されたパターンに一致するパスを削除する--patternsオプションがあると便利です。

purgeは、コマンド名の1つの可能性です。 eraseも、 deleteと同様に良い選択かもしれません。 どちらを選択しても、操作によってデータが完全に削除されることが明確になり

まあ、それは明らかだと思ったので、後でソーススナップショットを削除するステップを省略しました（ forgetから、おそらくprune ）。

私の意見では、このようにすると、既存のコマンドの機能と重複する新しいコマンドを追加する場合と比較して、コマンドセットがより直交した状態に保たれます。 現在、 backup 、 forget 、 pruneあり、それらはすべて完全に別々のことをします。 あなたが説明するようにpurge追加すると、それが変わります。 私の提案はそうではありません。

1つのファイル操作を提案しているので、名前を変更できると便利です。

このタイプの操作には個別のコマンドが必要であるという@alphapapaに同意します。 それはpurgeかもしれません、それは悪い名前ではありません、そして再び将来的に他の同様の操作があるかもしれません、例えば@alvarolmはすでにファイルの名前を変更できることを提案しました。

そのため私は、おそらく追加思うrewriteコマンドは、このケースで最善の選択肢であり、このコマンドは例えば持たせる--purgeと--rename後者はに関連していると仮定すると、オプションを埋め込む。 したがって、最終的なコマンドは、たとえばrestic -r foo rewrite --purge snap1,snap2 path1 path2 ...とrestic -r foo rewrite --rename snap1,snap2 pathFrom pathToます。

とはいえ、名前の変更が実装に合理的なものであるかどうかは完全にはわかりません。バックアッププログラムの内容とはかなりかけ離れています。 しかし、確かに、なぜそうではありません。

パージ機能をバックアップコマンドの一部にするのは賢明ではないと思います。 ある観点では、それは問題ないと主張することができます-あなたはバックアップで操作を行っています。 しかし、その論理的根拠に基づいて、プルーニングとロック解除および忘却のアクションもバックアップコマンドの一部である必要があります。これらもバックアップ内のデータを維持するためのものだからです。 私はそれが意味をなさないと思うので、それは確かに別の操作/コマンド、例えばrewriteまたはpurgeであるべきだと思います。

@dnnr

まあ、それは明らかだと思ったので、後でソーススナップショットを削除するステップを省略しました（forgetを使用して、おそらくプルーニングします）。

それは明らかに明らかではありません。 また、ユーザーがどのスナップショットIDが変更され、忘れる必要があるかを追跡する必要があるのではなく、Resticがユーザーのためにそれを処理する方がよいでしょう。これは、ユーザーがリポジトリ内のすべてのスナップショットを書き換える場合にかなりの負担になります。

私の意見では、このようにすると、既存のコマンドの機能と重複する新しいコマンドを追加する場合と比較して、コマンドセットがより直交した状態に保たれます。

どういう意味かわかりません。 逆の場合です。 この提案されたパージ/削除/書き換えコマンドは、 backupとまったく重複していません。つまり、既存のスナップショットからデータを削除します。 これは既存のコマンド

現在、バックアップ、忘却、整理があり、それらはすべて完全に別々のことをします。 あなたが説明するようにパージを追加すると、それが変わります。 私の提案はそうではありません。

繰り返しますが、ここで何を考えているのかわかりません。 purgeは、バックアップ、忘却、および整理とは完全に分離されています。

• backup ：指定されたパスの新しいスナップショットを作成します。
• forget ：既存のスナップショットを削除します。
• prune ：ガベージ-忘れられたスナップショットから未使用のblobを収集します。
• purge / rewrite / whatever：既存のスナップショットからファイルを削除します。

backupコマンドを2つのモードで動作させることを提案しています。一方はデータをバックアップし、もう一方はデータを

@rawtazはい、 rewriteは、既存のスナップショットを文字通り書き換えるため、良い提案です。 次のようなUIをお勧めします。

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

スクリプトでのコマンドラインの作成がはるかに複雑になるため、区切り文字としてコンマを使用しないことをお勧めします。

バックアップ：指定されたパスの新しいスナップショットを作成します。

ある意味で、スナップショットの内容を変更すると、新しいスナップショットが作成されます（以前と同じスナップショットではないため）。 git commit --amend考えてみてください。これは、既存のコミットに基づいて新しいコミットを作成します。 このチケットはGitの再発明に向けて急速に進んでいるように見えるため、類推は実際にはかなり適切です。

バックアップコマンドを2つのモードで動作させることを提案しています。1つはデータをバックアップし、もう1つはデータを削除します。

私はそれを言わなかった。 なぜだろう？ forgetとprune 、これらは物を取り除くのにまったく問題ありません。

ある意味で、スナップショットの内容を変更すると、新しいスナップショットが作成されます（以前と同じスナップショットではないため）。 git commit --amendを考えてみてください。これは、既存のコミットに基づいて新しいコミットを作成します。 このチケットはGitの再発明に向けて急速に進んでいるように見えるため、類推は実際にはかなり適切です。

あなたが正しい。 しかし同時に、Resticはgitではなく、コンテンツベースのアドレス指定の知識を必要とするようには設計されていません。 内部でどのように機能するかに関係なく、ユーザーにとって、提案するコマンドは、新しいスナップショットを作成するのではなく、既存のスナップショットを変更することを検討する必要があると思います。したがって、それは別個のコマンドである必要があります。

私はそれを言わなかった。 なぜだろう？

さて、あなたは言った：

UXの観点からは、これは、まったく新しいコマンドを追加する代わりに、バックアップコマンドを拡張することにより、かなり目立たない方法で実行される可能性があります。

たぶんあなたはもっと詳細に説明する必要があります。

物を取り除くのに完全に問題のない忘却と剪定があります。

具体的にしましょう。 forgetはスナップショットを削除し、 pruneはblobを削除します。 スナップショット内のファイルを削除するコマンドを提案してい

私の意見を追加したいと思います：

リポジトリ内のスナップショットを変更する方法があることは、このようなものを何人の人が望んでいるかというフィードバックに基づいて、価値があると思います。

このコマンドは、直交性の理由（非常にGoに似ている）だけでなく、実用的な考慮事項からも、 backupコマンドから独立している必要があります。 backupコマンドはすでに十分に複雑なので、私は他のコマンドをそれから分離したい。

prune類似しているため、 purgeという名前は好きではありません。 changeどうですか？ 次に、 restic backup 、 restic restore 、およびrestic changeます。

コマンドのサポートされている操作について、私は次の要求を見てきました：

• --deleteファイルを削除します
• ファイルの名前を変更します（例： --rename

前者はまさにこの問題（元々）の問題ですが、ファイルの名前を変更するための実際のユースケースはありますか？

changeは、何かの内容を変更するのではなく、何かを取り出して入れるように聞こえると思います。

repo / backup / snapshotがバケットであると想像してください。 変更は、バケット内の何かを拾い上げて少し変更して元に戻すのではなく、バケット自体を別のものと交換したり、バケットから何かを取り出して別のものを入れたりするようなものです。

おそらく、英語/アメリカ人のネイティブの人はどちらがより適切かを知っています:)それは私が思う言語学に要約されます。

うーん、 modifyじゃあ？

modifyはchangeよりも間違いなく優れています。 したがって、これまでに提案されたもののうち、 rewriteまたはmodifyのいずれかです。 他の人がどう思うか興味があります:)

これがファイルの削除のみに関するものである場合、スナップショットとファイルを操作するようにforgetコマンドを拡張することは理にかなっていますか？ それともこれは複雑すぎますか？

この新機能が削除と名前の変更（または他の何か）に関するものである場合、私はmodify投票します。

ご入力いただきありがとうございます@dimejo👍

名前を変更したり削除したりするときは、 forgetを使用していないと思います（少なくとも前者の場合はそうではありません）。

IMHOの「リライト」は最高の意味を伝えます。

forgetコマンドも非常に複雑なので、手伝ってもらえれば何も追加しません;）

別のコマンドにする場合は、 modifyと呼ぶのも私のお気に入りです（かなり長いですが、 modify-snapshotも欲しいです）。 また、あらゆる種類のファイル操作の変更（名前の変更、場合によっては追加）に適した場所になるほど一般的です。 ただし、ファイルを削除する以外のことは、フィーチャークリープの匂いが強いと思います。

ちなみに、Gitの配管コマンドと同様に、resticはコマンドカテゴリの恩恵を受けると思います。 現在、 restic -hはすべてのコマンドを辞書式順序で一覧表示し、低レベルのコマンド（たとえば、 cat 、 list 、「通常の」ユーザーには必要ありません）と主要な高レベルコマンド。

updateも検討してください。

rewrite +1、それはそれに素敵なオーウェルリングを持っています。 :-)

alter
discard
evict
expel
expunge
extrude
oust
..。
nuke ？ 😄

新しいeditコマンドを提案したいと思います。 この問題に関するすべてのフィードバックに基づいて、 edit 1つまたは複数のスナップショットに対して複数のアクションが発生する可能性があるように思われます。

当分の間、それは次のようなものになる可能性があります。

$ restic edit 40dc1520 remove dir/file

将来的には、複数のスナップショット（スナップショットIDまたは日付範囲の入力リスト）から1つのファイルの削除を実装する可能性があります。

編集コンテキストでの他のコマンドは次のようになります

• rename 、ファイルとフォルダーの名前を変更します
• moveは、変更された可能性のあるファイル/ディレクトリ構造を修正します

これらのアクションを1つまたは複数のスナップショットで（IDまたは場合によっては日付または範囲の数で）実行できるようにすることが重要だと思います。

バックアップされたデータでどの程度のresticを実行できるかはまだわかりません。 つまり、特定の時点での状態を保持するためにデータをバックアップすることを意味します。 NASを意図したものではありません。

特に、ファイルの名前を変更したり削除したりするユースケースでは妥当性がわかりません。 つまり、ローカルディスク上のファイルを変更してから、バックアップをいじって、ファイルツリーを現在のデータと同期させておくのはなぜですか。 それは私には意味がありません。 そのユースケースについて詳しく説明していただけますか？

@rawtaz
私の考えは（ほぼ）正確に。

ファイルを削除することの妥当性は、除外ルールを使用してバックアップを作成した後で、除外ルールに誤りを発見した場合にあると私は主張します。 したがって、ファイルの削除は基本的に、除外ルールの遡及適用として機能します。 このスレッドでの論争に関係なく、誰もがその特定のユースケースに同意しているようです。

それ以上の操作（名前の変更、追加）については、疑問を共有します。 これはフィーチャークリープであり、バックアップツールであるIMHOの範囲には含まれていません。

同意します。スナップショットからファイルを削除することは重要です。意図しないファイルを誤ってバックアップするのは非常に簡単だからです。 これは、セキュリティとディスク使用の両方の理由で必要になることがよくあります。 この機能があるということは、古いバックアップデータを保持できることと、「お風呂の水で赤ちゃんを捨てる」ことの違いを意味する可能性があります。

ただし、スナップショット内のファイルの名前を変更したり移動したりすることは、おそらく良い考えではありません。 率直に言って、これを実行できるバックアップソフトウェアについては聞いたことがなく、奇妙な機能のようです。 ユーザーが絶対にこれを必要とする場合は、スナップショットを復元し、ファイルを再配置し、明示的に設定された日付で再度バックアップすることで、Resticの外部に実装できます（ただし、Resticが絶対パスの使用を開始すると、これは将来さらに複雑になる可能性があります） 。

確かに、スナップショットからパスを削除する機能もこの方法で実装できますが、必要になる可能性がはるかに高いため、Resticに含めるのが妥当だと思います。

したがって、フィードバックをお寄せいただきありがとうございます。明確な方法があります。既存のスナップショットからファイルを削除できるコマンドを実装することです。 コマンドの名前は、そこに着いたときに決定されます。 必要に応じて、他のユースケースを再検討できます。

参加してくれてありがとう、ここでこれ以上議論する必要はないと思います！

コマンド名の提案： restic purge 。

この機能を楽しみにしています。 ありがとう

@ fd0
この機能に関する更新はありますか？ それを使いたいです:)
政府の環境でresticを使用しており、バックアップから1つのファイルを削除する必要があります。 必要に応じて、作業の一部に資金を提供することができます。

私もこれを楽しみにしています！ restic findの基本構造のようなものを使用することを提案します。

restic purge [flags] PATTERN

purgeをhost (-H) snapshots (-s) or paths (--path)制限できる場所

その後、おそらくrestic pruneが実際の削除を行います

これは、予期しないファイルがエラーによってバックアップされた場合に非常に役立ちます（ドキュメントフォルダー内の大きなビデオまたは機密ファイル）。今、 restic findを実行して、ファイルを含むすべてのスナップショットを削除します。 。ファイルがリポジトリ内にある場合（時間内）、これは望ましくありません。

ありがとう ！

更新はありません、申し訳ありません。 何かが起こったときにこの問題を購読することで通知を受け取ります。

ほとんどの人はバックアップのメタデータをcloneできることを望んでいるようですが、問題のあるファイルはすべてスクラッチの場所に復元する必要はありません。 バックアップのクローンを作成するというアイデアは、特定のポインターを削除する機能を備えたメタデータをコピーします。

これはユースケースですか？

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

rewriteとmodifyは、上記のプロセスのマクロである可能性があります。

私にとっては、それで十分です

悪くない、@ nullcake。

しかし、私の過去の経験に基づくと、通常、数日または数週間後に、価値のないものを大量にバックアップしていることに気づきます。 調査する時間があれば。 これが意味することは、私が特定の--excludeが必要であると理解するまでに、おそらく12以上のバックアップが影響を受けるということです。

もちろん、あなたが提案するように、単一のバックアップに基づいて何らかの種類のクリーンアップが実装されたとしても、それは大きな前進です。 もちろん、私たちはスクリプトの作成方法を知っています。 ;）

だから、親指を立てる。 :)

これは興味深いアイデアですが、 backupコマンドはすでに複雑すぎて、バックアップ用に別の「ソース」を追加するとさらに複雑になるのではないかと心配しています。 また、この関数は、すでにリポジトリにあるデータに対してのみ機能します（正確には、メタデータに対してのみ）。 別のコマンド（例： purgeなど）で機能をうまくカプセル化できます。

CrashPlanには、ファイルが除外されると、既存のすべてのスナップショットから削除されるという興味深い動作がありました。 それは考慮すべきことかもしれません。

これは素晴らしい機能です。 追加されましたか？

いいえ。

@ fd0これについて何か進展はありましたか？ 思ったようにキャッシュを除外していないことに気づき、削除したいと思っています。

コマンド名のさらに別の提案： scrub （ purgeでも問題ありませんが、 --renameフラグは私には奇妙に思えます）。 私の考え：

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

--replace=clean変更されたスナップショットを削除すると、 pruneクリーンアップされ、その後pruneします。 --diffは、変更されたスナップショットの差分を示します。 --dry-runは、リポジトリへの変更のコミットを回避します。

restic backupすべての--excludeフラグも有効です。 --hostと--timeも意味があると思います（それぞれが既存のスナップショットの値を置き換えます）。 --tag編集は、すでにrestic tagによって処理されています。

これをどのように実装できるかについてのガイダンスを持っている開発者はいますか？ （大雑把に見て）ほとんどのコードはcmd_scrub.goファイルに入れることができるように思えます。 主にインデックス操作であるように思われるため、内部ライブラリに必要なAPIをいくつか追加するだけかもしれませんが、それは単純なことかもしれません。 推定される難しさはありますか（いずれにせよ、テストがその大部分になると思います）？

これは非常に古い問題なので、この機能を利用できる可能性はありますか？

これを監視して更新を確認し、Googleからヒットするすべての場合、この問題が発生しないのを待つ必要はありません。当面はduplicatiを使用するだけで、スナップショットから事後ファイルを削除するためのファーストクラスのサポートがあります。

これを監視して更新を確認し、Googleからヒットするすべての場合、この問題が発生しないのを待つ必要はありません。当面はduplicatiを使用するだけで、スナップショットから事後ファイルを削除するためのファーストクラスのサポートがあります。

私は約1年間resticを使用していて、機能が実装されるのを待つのをやめました。 すべてをresticに追加する必要があるという意味ではありませんが、そこにあるべき基本的なことがあります。 私はresticから離れることを考えています：リポジトリは非常に壊れやすく、非常に簡単に壊れることがあります。

昨日、バックアップに含めるべきではないファイルが含まれていたため、スナップショットを削除しました（除外を追加するのを忘れました）。 それ以来、リポジトリにエラーがあり、まだ修復できていません。 一部のファイルが誤って含まれているため、スナップショット全体を削除する必要はありません。

@MorgothSauron私は通常、それを含むスナップショットも削除しました。これは、それが制限されているように見える唯一の解決策ですが、繰り返しますが、duplicatiはしばらくの間、単一のコマンドでそれを行うことができるので、それ以来変更し、問題はありませんでした。

この件についてご意見をお寄せいただき、ありがとうございました。 これまで見てきたように、多くの人々は特にスナップショットからファイルを削除する機能を望んでいました。 私たちは皆、バックアップするときにたまに間違いを犯すと思います;）

現時点では、resticの他の部分で利用可能なメンテナと開発者の時間が必要であるため、この問題が近い将来に実装されるとは予想していません。 また、できるだけ早く新しいRESTサーバーをリリースし、その後、他のいくつかの問題の調査を開始します。

とは言うものの、誰かがきちんと明確に書かれ、@ fd0がすでに方向性に祝福を与えている問題であるため、「この機能を追加する必要があるか」ではなく、主に堅実な実装（リポジトリが破損しないことがわかっている）の作成に焦点を当てることができます。これは良いことです。 。

このようなPRは基本的なものであり、必要に応じて構築できる出発点として機能する必要があります。 私が意味することの例は、それが初心者のためにあるべきであるということです：

• 新しいコマンドを1つだけ作成します（たとえば、この問題で最も投票されているのはrewriteです）。
• スナップショットのリストを主要な引数（ allサポートを含む）として使用します（例： allまたは098db9d5または098db9d5 af92db33 。
• 1つ以上の--exclude <pattern>リストを取得して、スナップショットから除外/削除する必要のあるパスをリストします（つまり、バックアップ時に欠落していた--excludeを次に示します）。例： --exclude="*.o" 、 --exclude=*.unwanted 、 --exclude="*.o" --exclude=*.unwanted --exclude=.DS_Store 。

ここでの理論的根拠は、概念実証および最小限の実行可能な製品として最小限のスタートを切ることです。 テストが完了したら、必要に応じて調整できます。たとえば、 backupコマンドから他の--exclude-*引数を追加します。 このようにrewriteコマンドを作成すると、「修正」することを目的としたbackupコマンドとほぼ同じインターフェイスになります。

〜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〜

関連するメモとして、 https： //github.com/restic/restic/issues/323で

@rawtaz

思いやりのあるフィードバックをありがとう！

やあ。

@rawtazによるコメントの近くにドラフトrewrite実装を追加しました

ここではテストリポジトリで動作し、エラーなしでrestic check --read-data合格しますが、あまりテストしていません。 したがって、重要なデータには使用しないことを強くお勧めします。

backupコマンドに非常に近い構文を取得しようとしました。 したがって、 --exclude 、 --iexclude 、および--exclude-fileがサポートされます（ただし、テストされていません）。 理想的には、 --exclude-if-presentオプションも表示したいと思います（私にとって理想的なワークフローは、「おっと、バックアップする必要はなく、 CACHEDIR.TAGとrestic rewrite追加する」のようなものです）。 ただし、このような場合は、バックアップが作成されたのと同じホストでrewriteし、ファイルシステムにアクセスしてこれらのファイル（および相対パスを使用した大量の魔法）を収集する必要があるため、かなり複雑です。 だから今は...

また、デフォルトでスナップショットを置き換えるという考えは好きではないので、現在のデフォルトの動作は、 rewriteタグを使用して新しいスナップショットを作成することです。 ただし、 --inplace argで置き換えることもできます。

フィードバックをいただければ幸いです。

ねえドミトリー、

この実装に感謝します、素晴らしい仕事です！

これまでのところ、600ファイルの小さなテストリポジトリといくつかのテストスナップショットを使用して、Linuxで完全に機能します。 復元は機能し、diffは正しく除外されたフォルダを表示します。 数百のスナップショットを含む数GBのデータを含む「クローン」の実際のリポジトリでより集中的なテストを行います。 また、Windowsソースのリポジトリも試してみます。

1つの提案：リライトパスの除外を含むスナップショットのタグを指定するオプションがあります。 （新しく作成されたスナップショットに「 rewrite 」タグを保持します。）

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

これは、「_ thisfileshouldberemoved.txt_」がまだ含まれているスナップショットを識別するのに役立ちます。 一方、より直接的な--inplaceは、期待どおりに機能します。

再び非常に良い仕事。

@NovacomExpertsはい、私の最初の動機は、履歴編集を可能な限り安全に保つことでした。 --exclude *重要なものを除外するのは非常に簡単で、これから回復する方法はほとんどありません（バックアップでは、新しいバックアップを再開するだけです）。 --dry-runようなものですが、実際のスナップショットを取得し、問題がないことを確認した後、ソーススナップショットを明示的に削除する機能を備えています。

現在、これが完全には達成されていないことに完全に同意します。 新しいスナップショットを「観察」するのは簡単ですが、古いスナップショットを削除するのは難しすぎます。 さらに、ハードコードされたrewriteスナップショット名は好きではありません。 たぶん、デフォルトで--inplaceを使用し、 ---keep-source-tagged before-rewrite --tag-destination after-rewriteなどを使用する方がよいでしょう。 （ --add-tagは、古いスナップショットか新しいスナップショットか、少し不明確です）。

いずれにせよ、メンテナからのフィードバックをお待ちしております。 それが間違った方向に動いた場合、多くの時間を費やしたくありません。

PS。 私の主要なレスティックレポは現在約2TBです。 LVMスナップショットを作成した後、後で試してみます。

@dionorguaあなたの最初の動機は完全に正しいです。 「危険な」オプション--inplaceをユーザーから可能な限り遠ざけて、そのように維持するために投票します（デフォルトでは絶対にありません）。 デフォルトでは、 --inplaceよりも--keep-source-tagged / --tag-destinationで引数が欠落しているエラーを優先します。

しかし、私は同意します、これについてのフィードバックを待ちましょう。

昨日、resticによって一晩バックアップされたフォルダー内のクローンテストリポジトリ（65 GB）を忘れました。 昨日のスナップショットはforgetたが、「オールイン」して実装を試みました。 forget + prune後、400GBのリポジトリから65GBを正常に削除しました。 すべて良好で、エラーは見つかりませんでした。

複数のスナップショットにまたがるデータを使用して、より集中的にテストします。

乾杯

古いものはマスターブランチから作成されたため、間違った＃2720プルリクエストを新しいものに置き換えました。 欠落しているエラーチェックを1つ追加しました。 余分なノイズでごめんなさい

うーん、 modifyじゃあ？

これには非常に遅れていますが、delete-specific-file-from-backupコマンドの提案は_rectify_です。

2731はエキサイティングです、たくさんありがとう！

これには非常に遅れていますが、delete-specific-file-from-backupコマンドに対する私の提案はrectifyです。

私はそれがそれの素晴らしい名前ではないと言わなければなりません。 Rectifyは、修正/修正が必要な問題があることを意味します。 これはユースケースの1つに当てはまるかもしれませんが、常にそうであるとは限りません。 ユーザーは、既存のスナップショットから一部のデータを削除して、スナップショットの残りの部分を保持しながら、私たちが知っているすべてのスペースを解放したい場合があります。 言葉遣いは、修正するよりも中立的でなければならないと思います。