那真是太好了。

它还允许删除无意中包含的敏感数据。

这将是一个很棒的功能！

开发人员对这个想法有什么反馈吗？ 这将是非常好的。 例如，我刚刚发现我从 git checkouts 构建的程序一直在创建巨大的二进制文件（近 100 MB），并且这些已经被不必要地备份到我的 Restic 备份中。 我使用 Restic 的时间不长，因为我还在测试阶段，所以删除有问题的旧快照不是问题。 但是这个问题很容易发生，最好有长期的解决方案，而不是忘记每个快照。

我想可以编写一个脚本来恢复每个快照，删除不需要的文件，并通过手动设置日期来重新备份快照，但显然这需要很长时间。 如果 Restic 可以在本地做到这一点，那就太好了。

谢谢。

我认为有多个有效的用例。 似乎是一个非常好的功能。 我可能会在某个时候自己使用它。

它可能不会真正改变实现工作，但从 UX 的角度来看，这可以通过扩展backup命令而不是添加一个全新的命令来以相当低调的方式完成：

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

因此，不是提供修改快照的命令，而是允许基于现有快照 ID 进行新备份。 删除文件将通过排除规则来实现。
restic backup上的所有文档基本上都可以“重用”（也就是说，几乎不需要为这个新功能添加任何内容）。

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

但是，我不会在这里跟踪您。 从旧快照中删除数据绝对是一个不同的操作，应该有自己的命令。 就像是：

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

并且--snapshots可能应该接受all关键字来对所有快照（或具有指定--tag所有快照）进行操作。 该命令可能需要通过键入yes进行确认。

它也有一个--patterns选项，它会删除匹配给定模式的路径。

purge是命令名称的一种可能性。 erase和delete也可能是一个不错的选择。 无论选择什么，都应该明确该操作会永久删除数据。 这是我们所说的备份软件，任何危险的操作都应该是明确的、明确的，并且需要确认。

好吧，我省略了之后删除源快照的步骤（使用forget ，然后可能是prune ），因为我认为这很明显。

在我看来，与添加与现有命令的功能重叠的新命令相比，这样做会使命令集更加正交。 现在，有backup 、 forget和prune ，它们都做完全不同的事情。 添加purge就像您描述的那样，会改变它。 我的建议没有。

由于我们提出了一种文件操作，因此能够重命名会很好。

我同意@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

好吧，我省略了之后删除源快照的步骤（使用忘记，然后可能修剪），因为我认为这很明显。

这绝对不是很明显。 如果 Restic 为用户处理它也更好，而不是用户必须跟踪哪些快照 ID 已更改并需要忘记——如果用户重写 repo 中的所有快照，这将是一个相当大的负担。

在我看来，与添加与现有命令的功能重叠的新命令相比，这样做会使命令集更加正交。

我不明白你的意思。 情况正好相反。 这个提议的清除/删除/重写命令与backup根本不重叠——它从现有快照中删除数据。 其正交于现有命令。

现在，有备份、忘记和修剪，它们都做完全独立的事情。 像您描述的那样添加清除，会改变它。 我的建议没有。

再一次，不知道你在想什么。 purge与备份、忘记和修剪完全分开：

• backup ：创建给定路径的新快照。
• forget ：删除现有快照。
• prune ：从被遗忘的快照中垃圾收集未使用的 blob。
• purge / rewrite /whatever：从现有快照中删除文件。

您提议让backup命令以两种模式运行，一种是备份数据，另一种是删除数据。

@rawtaz是的， rewrite是一个很好的建议，因为它实际上重写了现有的快照。 我建议一个像这样的用户界面：

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

我建议不要使用逗号作为分隔符，因为它会使在脚本中构建命令行变得更加复杂。

备份：创建给定路径的新快照。

嗯，从某种意义上说，修改快照的内容就是创建一个新的快照（因为它与以前的快照不同）。 想想git commit --amend ，它会根据现有提交创建一个新提交。 这个类比实际上非常合适，因为这张票似乎正在迅速转向重新发明 Git。

您提议使备份命令以两种模式运行，一种是备份数据，另一种是删除数据。

我没那么说。 为什么会呢？ 有forget和prune ，它们非常适合删除东西。

嗯，从某种意义上说，修改快照的内容就是创建一个新的快照（因为它与以前的快照不同）。 想想 git commit --amend，它会根据现有提交创建一个新提交。 这个类比实际上非常合适，因为这张票似乎正在迅速转向重新发明 Git。

你是对的。 但与此同时，Restic 不是 git，它的设计目的不是要求了解基于内容的寻址知识才能工作。 不管它在幕后如何工作，我认为，对于用户来说，我们建议的命令应该被视为修改现有快照，而不是创建新快照，因此它应该是一个独特的命令。

我没那么说。 为什么会呢？

嗯，你说：

从用户体验的角度来看，这可以通过扩展备份命令而不是添加全新的命令来以相当低调的方式完成

也许你应该更详细地解释一下。

有忘记和修剪，它们非常适合删除东西。

让我们具体点。 forget删除快照，而prune删除blob 。 我们提出了一个命令来删除快照中的

我想补充一下我的看法：

我认为有一种方法来修改 repo 中的快照是有价值的，根据反馈，有多少人想要这样的东西。

该命令应该独立于backup命令，不仅是出于正交性的原因（这很像 Go），而且出于实际考虑： backup命令已经足够复杂，所以我想将其他命令与其分开。

我不喜欢purge这个名字，因为它与prune相似。 change呢？ 然后我们有restic backup ， restic restore和restic change 。

对于命令的支持操作，我看到了以下请求：

• 删除文件，例如--delete
• 重命名文件，例如--rename

前者正是这个问题（最初）的问题，但真的有重命名文件的用例吗？

我认为change听起来更像是取出一些东西并放入一些东西，而不是修改一些东西的内容。

想象一下 repo/backup/snapshot 是一个存储桶。 改变更像是把桶本身换成别的东西，或者从桶里取出一些东西再放进去，而不是把桶里的东西捡起来，稍微修改一下，然后把它放回去。

也许一些母语为英语/美国人的人知道哪个更合适:) 我认为这归结为语言学。

嗯，然后modify ？

modify绝对比change 。 因此，到目前为止提出的建议是rewrite或modify 。 好奇其他人的想法:)

如果这只是关于删除文件，那么增强forget命令以处理快照和文件是否有意义？ 或者这会不会太复杂？

如果这个新功能是关于删除和重命名（或其他东西），我会投票给modify 。

感谢您的输入@ dimejo👍

我认为当你重命名和/或删除时，你不是forget ting（至少在前一种情况下不是）。

恕我直言，“重写”传达了最好的意思。

forget命令也非常复杂，如果我们能帮上忙，我们不会添加任何东西;)

如果它是单独的命令，调用它modify也是我的最爱（我也喜欢modify-snapshot ，即使它很长）。 它也足够通用，适合各种修改文件操作（重命名，甚至添加）。 但是，我仍然认为除删除文件之外的任何事情都带有强烈的功能蔓延气味。

顺便说一句，我觉得 restic 会受益于命令类别，类似于 Git 的管道命令。 现在， restic -h按词法顺序列出所有命令，将低级命令（例如， cat 、 list ，“普通”用户永远不需要）与主要的高级命令。

您也可以考虑update 。

+1 rewrite ，它有一个很好的奥威尔戒指。 :-)

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

我想提出一个新的edit命令。 根据有关此问题的所有反馈，在我看来，我们最终可能会对edit一个或多个快照执行多项操作。

就目前而言，它可能是这样的：

$ restic edit 40dc1520 remove dir/file

将来我们可以实现从多个快照中删除一个文件（快照 ID 或日期范围的输入列表）。

编辑上下文下的其他命令可能是

• rename重命名文件和文件夹
• move更正可能已更改的文件/目录结构

我相信我们允许在一个或多个快照上执行这些操作（通过 ID 或可能的多个日期或范围）是很重要的。

我仍然不确定 restic 应该能够对备份数据做多少。 我的意思是，它旨在备份数据以保留某个时间点的情况。 它并不意味着成为 NAS。

我尤其看不到重命名和删除文件用例的有效性。 我的意思是，您为什么要更改本地磁盘上的文件，然后摆弄备份以使其文件树与当前数据保持同步。 这对我来说没有意义。 你能详细说明那个用例吗？

@rawtaz
我的想法（几乎）完全正确。

我认为删除文件的有效性在于您在使用这些规则进行备份后发现排除规则中有错误的情况。 所以删除文件基本上是作为排除规则的追溯应用。 似乎不管这个线程中的争议如何，每个人都同意这个特定的用例。

关于除此之外的操作（即重命名、添加），我和您一样有疑问。 恕我直言，这是功能蠕变，不在备份工具的范围内。

我同意：从快照中删除文件很重要，因为很容易意外备份不打算备份的文件。 出于安全和磁盘使用的原因，这通常是必需的。 拥有此功能可能意味着能够保留旧的备份数据或必须“把婴儿和洗澡水一起倒掉”之间的区别。

但是在快照中重命名或移动文件可能不是一个好主意。 坦率地说，我从未听说过可以做到这一点的备份软件，这似乎是一个奇怪的功能。 如果用户绝对需要这个，它可以在 Restic 之外通过恢复快照、重新排列文件并使用明确设置的日期再次备份来实现（尽管当 Restic 开始使用绝对路径时，这可能会变得更加复杂） .

当然，remove-paths-from-snapshots 功能也可以通过这种方式实现，但由于它似乎更有可能被需要，我认为将它包含在 Restic 中是合理的。

所以，感谢大家的反馈，我们有一个明确的前进方向：实施一个命令，允许从现有快照中删除文件。 当我们到达那里时，命令的名称将被决定。 当需要时，我们可以重新审视其他用例。

我认为我们不需要在这里多讨论，谢谢参与！

命令名称的建议： restic purge 。

我很期待这个功能。 谢谢

@fd0
此功能有任何更新吗？ 很想用它:)
我们在政府环境中使用 restic，需要从备份中删除单个文件。 如果需要，我们可以资助一些工作！

我也很期待这个！ 我建议使用类似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

还不错，@nullcake。

但是，根据我过去的经验，我通常会在几天或几周后检测到我备份了大量无价值的东西。 当我有时间调查时。 这意味着当我明白我需要一些特定的 --exclude 时，可能有十几个或更多的备份受到影响。

当然，即使像您建议的那样基于单个备份实施任何类型的清理，这仍然是向前迈出的一大步。 我们当然知道如何编写脚本。 ;)

所以，竖起大拇指。 :)

虽然这是一个有趣的想法，但我担心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避免提交对 repo 的任何更改。

来自restic backup所有--exclude标志也是有效的。 我猜--host和--time也有意义（每个都替换预先存在的快照的值）； --tag编辑已经由restic tag 。

是否有任何开发人员对如何实现这一点有指导？ 在我看来（粗略看）大部分代码都可以放在cmd_scrub.go文件中； 也许只是对内部库添加一些 API 是必要的，因为它似乎主要是索引操作，但这可能很幼稚。 任何估计的难度（我认为在任何情况下测试都将是大部分）？

因为这是一个非常非常古老的问题..是否有机会获得此功能？

对于所有监控更新并从谷歌点击它的人来说，没有必要等待这个问题永远不会发生，同时使用 duplicati，它具有一流的支持，可以从快照中删除文件事后事实。

对于所有监控更新并从谷歌点击它的人来说，没有必要等待这个问题永远不会发生，同时使用 duplicati，它具有一流的支持，可以从快照中删除文件事后事实。

我已经使用 restic 大约一年了，我不再等待要实现的功能。 我并不是说所有的东西都应该添加到 restic 中，但是应该有一些基本的东西。 我正在考虑远离 restic：存储库非常脆弱，很容易被破坏。

昨天我删除了一个快照，因为它包含了不应该在备份中的文件（我忘记添加一个排除项）。 从那以后，我的存储库中有错误，但我还无法修复它。 我不应该删除整个快照，因为某些文件被错误地包含在内。

@MorgothSauron我通常也只是删除了包含它的快照，这是它似乎在restic中的唯一解决方案，但同样，duplicati现在可以通过一个命令来完成，所以我已经改变了并且没有问题。

我要感谢大家对此事的投入。 正如我们所见，许多人特别希望能够从快照中删除文件。 我想我们在备份时都会偶尔犯错误;)

此时，restic 的其他部分需要可用的维护人员和开发人员时间，因此我预计在可预见的未来不会实施此问题。 我还将尽快发布一个新的休息服务器，然后将开始研究其他一些问题。

也就是说，如果有人制作了一个可靠的 PR，它写得很好，清晰，经过良好测试，没有错误，并与维护者协调制作，肯定会被考虑包含在内。 这个特定问题是@fd0已经对方向给予祝福的问题，因此重点可以主要放在产生可靠的实现（我们知道不会损坏存储库）而不是“我们是否应该添加此功能”，这很好.

这样的 PR 应该是基本的，并作为一个起点，如果需要，可以在此基础上进行构建。 我的意思的一个例子是初学者应该这样做：

• 只是一个新命令（例如rewrite因为这是本期投票最多的命令）。
• 将快照列表作为其主要参数（包括对all ），例如all或098db9d5或098db9d5 af92db33 。
• 使用一个或多个--exclude <pattern>的列表来列出应该从快照中排除/删除的路径（换句话说，这是备份时丢失的--exclude ），例如--exclude="*.o" 、 --exclude=*.unwanted 、 --exclude="*.o" --exclude=*.unwanted --exclude=.DS_Store 。

这里的基本原理是获得一个最小的开始，作为概念和最小可行产品的证明。 一旦被测试，我们可以根据需要调整它，例如通过添加来自backup命令的其他--exclude-*参数。 如果我们像这样创建rewrite命令，它将具有与backup命令几乎相同的界面，它旨在“纠正”：

~restic -r /some/repo 全部重写 --exclude=" .o" --exclude= .unwanted --exclude=.DS_Storerestic -r /some/repo rewrite 098db9d5 af92db33 --exclude=" .o" --exclude= .unwanted --exclude=.DS_Store~

在相关说明中，也许@middelink在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 替换。

任何反馈将不胜感激。

嘿德米特里，

感谢您的实施，伟大的工作！

到目前为止，它在 Linux 上运行良好，有一个包含 600 个文件的小型测试仓库 + 几个测试快照。 恢复工作，差异显示正确排除的文件夹。 我将对“克隆”真实存储库进行更深入的测试，其中包含大量 GB 数据和 100 多个快照。 我还将尝试 Windows 源代码库。

一个建议：可以选择为包含重写过程中排除项的快照指定标签。 （在新创建的快照上保留“ 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有点不清楚，是旧快照还是新快照）。

无论如何，我会等待维护者的反馈。 如果它朝错误的方向移动，不想花太多时间。

附注。 我的主要 restic 存储库现在大约为 2TB 左右。 制作LVM快照后稍后再试。

@dionorgua您最初的动机是完全正确的。 我会投票保持这样，尽可能远离用户的“危险”选项--inplace （绝对不是默认情况下）。 默认情况下，我更喜欢--keep-source-tagged / --tag-destination上的缺失参数错误而不是--inplace 。

但我同意，让我们等待对此的反馈。

昨天，我忘记了一个文件夹中的克隆测试存储库（65 GB），该文件夹是一夜之间由 restic 备份的。 我可以有forget昨天的快照，但“全力以赴”并尝试了您的实现。 在forget + prune ，我成功地从 400GB 存储库中删除了 65GB。 一切都很好，没有发现错误。

我对跨越多个快照的数据进行了更密集的测试。

干杯

我已经用新的替换了错误的 #2720 拉取请求，因为旧的请求是从主分支创建的。 刚刚添加了一项缺失的错误检查。 对不起，额外的噪音

嗯，然后modify ？

这很晚了，但 _rectify_ 是我对 delete-specific-file-from-backup 命令的建议。

2731令人兴奋，非常感谢！

这已经很晚了，但我对 delete-specific-file-from-backup 命令的建议是 rectify。

我不得不说这不是一个好名字。 纠正意味着有一些错误需要纠正/纠正。 虽然在其中一个用例中可能是这样，但情况并非总是如此。 用户可能只想从现有快照中删除一些数据以释放我们所知道的所有空间，同时保留快照的其余部分。 我认为，措辞必须比纠正更中立。