Restic: 来自不完整快照的数据。

嗯，嗯。 您需要一个特定的文件，还是只需要“所有数据”？ 数据在那里，restic可以将其提取出来，但这意味着围绕restic编写脚本（这将非常慢）或为restic添加自定义代码。

诚实的问题：数据对您有多重要？ 今天，我可以花一些时间为您一起破解一些东西，这应该使您可以访问几乎所有已上传到存储库的数据，但是它可能不像大多数代码那样“准备就绪”。 :)

数据对我来说非常重要，很遗憾，没有其他副本。 我知道这并不理想，但这是我要解决的问题。 我正在寻求硬件修复，以尝试使该卷恢复在线，但是目前看来还不太希望。 如果我可以指定一个目录，并且能够访问和下载该目录中的所有内容，那将是一个真正的救生员。 它包含大量数据（其中大部分是视频项目），因此更快的选择将是更好的选择。 话虽这么说，我真的不知道需要多少工作，我很欣赏这是免费软件，但是如果能够实现这一点，我将不胜感激。

好吧，我看看我能做什么。

非常感谢。

您可以从运行restic rebuild-index ，所以我们有了一个涵盖仓库中所有包装的新索引。

现在就开始。

哇，@ fd0真是太慷慨了。

如果我可以帮助测试与此相关的任何内容，请告诉我。

restic rebuild-index是否应要求我提供回购密码？ 还没有呢我确实怀疑由于回购中的数据量可能会花费很长时间。 我非常满意地让它运行整个周末，或者在必要时在下周运行。 我只想确保在长时间无人看管之前不需要密码。

嗯，应该尽早要求输入密码。 它需要解密存储库中所有文件的所有标头。 您是否可能导出了环境变量RESTIC_PASSWORD ，所以它不需要您输入密码？

它应该在早期打印如下内容：

repository ed6136ad opened successfully, password is correct

至少在以交互方式运行时（不将stdout重定向到日志文件）。

如果上传数据的最后15分钟不是那么重要，您也可以跳过rebuild-index ，我们以后总是可以这样做。

我没有设置RESTIC_PASSWORD环境变量，但是我将设置它并让命令运行。 它在约10分钟内未返回任何内容，因此我给了它ctrl-c并再次尝试。 我的语法正确，对不对？ restic -r b2:MY_BUCKET_NAME:/ rebuild-index无论如何，最后15分钟的数据与上传的总数据相比应该很小，所以我很乐意稍后再讲。

好的，那么暂时不要运行rebuild-index ，所以我们可以尝试恢复代码:)

我已将提交推送到分支recover-data ，只需构建restic（ go run build.go ）并按如下方式调用它：

$ restic -r b2:MY_BUCKET_NAME:/ recover

然后，它应该列出存储库中的所有树，找到根树，并创建一个引用所有根树的新快照：

repository abe002d6 opened successfully, password is correct
load index files
load 543 trees
tree (543/543)
done
found 2 roots
save tree with 2 nodes
saved new snapshot 26f25bf1

然后，您可以将快照还原为快照（在这种情况下26f25bf1 ），也可以仅使用restic mount来浏览快照。 您也可以列出它：

$ restic ls -l 26f25bf1 /
repository abe002d6 opened successfully, password is correct
snapshot aac6d0ed of [/recover] filtered by [/] at 2018-08-23 22:23:56.903268714 +0200 CEST):
drwxr-xr-x     0     0      0 2018-08-23 22:23:56 /0b9e25fb
drwxr-xr-x     0     0      0 2018-08-23 22:23:56 /d0d9386a

顶级目录是根据树ID命名的，因此它们有点晦涩难懂，但下一级具有常规名称。

让我知道这是否对您有帮助！

因此，添加一些背景故事：我读了github问题，然后去洗个澡，对自己说：“嗯，这并不难做到”。 原来，我是对的，事实并非如此。 如果此功能对其他人有帮助，我们可以稍后将其转换为适当的命令，但是现在我希望它对您有用，您可以访问已经上传到B2的数据。

它有多少数据？ 您恢复了多少？

祝好运！

哇！ 太快了！ 非常感谢！ 我只是克隆了该存储库，现在就尝试构建它。 我还弄清楚了为什么重建索引不起作用。 这是我们服务器所在的网络上的DNS问题。 我解决了这个问题，并获得了Fatal: unable to create lock in backend: repository is already locked by PID 41208所以显然我的上传毕竟没有被优雅地停止。 unlock命令似乎已经清除了当前内容，并且正在运行rebuild-index。

今天我会做很多事情，但是周末我要去密歇根州北部约15分钟，我认为那里的互联网访问不是很好。 星期一回来时，这将引起我的全力注意，我将为您提供更多详细信息:-)

非常感谢你做的这些！ 抱歉，让您挂起电话，但星期一将与您联系。

如果此功能对其他人有帮助，我们可以稍后将其转换为适当的命令

我将竭尽所能为您提供帮助。 我的上传速度为1 Mbps，因此我的初始备份可能需要3到6个月的时间。 如您所说，有一种在完成之前进行恢复的方法将是一项出色的功能，尤其是如果它不太困难的话。 让我知道如何为您服务！ 非常感谢您为此工作！ ：D

另外，我认为您的解决方案非常出色。 优雅而简单。

抱歉，让您挂起电话，但星期一将与您联系。

不用担心，我只是好奇它是否有效：sunglasses：

数据在B2是安全的，并且不会消失。 即使recover命令也不会更改任何数据，它只会读取数据，添加另一个文件和快照，仅此而已。

因此，为您提供一些背景知识（也许稍后再将其扩展为博客文章）：在幕后，restic存储库包含不同类型的文件，例如snapshot和data文件：

• data文件包含一堆较短的tree或data blob，末尾有一个标头，用于描述文件中的内容以及确切位置
• snapshot文件仅包含一个描述快照的微型JSON文档，该文档引用了tree

使用restic保存文件时，它会被切成data blob，这些blob会收集起来并一起保存在存储库中的一个或多个文件中。 然后，文件名和data blob的引用列表（ID）一起保存在树中。 在完成目录的Restic归档后，文件列表（ data blob的名称和引用）将作为tree blob保存到另一个data文件中。

对于子目录，restic将子目录的名称与tree blob的引用存储在一起，以描述另一个tree 。

在restic backup运行的最后，我们有一个根tree ，该根目录没有被任何其他树引用，但包含对所有顶级树的所有引用，因此（间接）包含所有文件和备份中的子目录。 作为最后一步， restic创建一个新的snapshot文件，该文件引用根tree 。

如果您告诉restic忘记特定的快照，则不再引用根树。 restic prune会检测到此情况，并删除树和所有其他不需要的tree和data blob。

通常，仅当成功保存其中的所有文件和子目录后，才会将tree保存在存储库中。 因此，只要存在tree blob，我们就可以假定它引用的数据（包括子目录）也在那里。

如果在备份过程中中止了restic，则回购中将有一堆tree blob以及它们引用的文件中的数据。 因此，要恢复数据，restic只需要执行以下操作：

• 列出所有树ID，并注意已引用的树（最初：无）
• 对于每棵树：
  
  
  
  • 加载树
  
  
  • 对于树中的每个条目：
    
    
    
    
    
    • 如果是目录，则引用另一棵树，将该树标记为列表中的引用
    
    
    
  
  

接下来，再次浏览树列表，丢弃所有我们看到的参考树。 其余的树是根树，这意味着它们是（或已被）快照直接引用的树，或者是由于restic backup中止运行而“悬挂”的树。

作为最后一步，创建一个列出所有根树的新树，将其保存到存储库，然后创建引用该新树的新快照。

然后，您可以正常使用此新快照，但目录的隐名（只是我们找到的根树的短树ID）除外。

合并之前，我认为我们应该做以下事情：

• 在recover添加一个选项，该选项不包括现有快照引用的根树，因此我们只能得到真正悬挂的根树。 也许这种行为甚至应该是默认行为，大多数用户可能对他们可以通过现有快照访问的数据不感兴趣...
• 还要在新快照中提供未引用的data blob，以便用户可以将tree对象中尚未包括的文件部分拼凑在一起。
• 为新树和新快照设置明智的元数据。 目前非常丑陋（仅能正常工作）。
• 更好的进度报告，这现在很棘手

对此进行小幅更新：在上周四离开之前，我开始了rebuild-index 。 那在我拿回read: connection reset by peer之前就死了。 我昨天以更大数量的b2并行连接重新启动了它，它似乎运行良好。 现在只有5％，但我希望它需要一段时间。 b2存储桶中大约有90TB，而我正在备份的目录中大约有110-120TB。

老实说，restic在上传过程中保持如此稳定让我印象深刻。 在尝试Restic之前，我尝试过在Mac上使用cloudberry，但无法使它用于大量数据。 我使用Restic在家备份我的笔记本电脑，我很喜欢它，所以我想为此做个尝试。 由于我什至还没有完成我的初始上传，所以我不知道像prune这样的事情会怎样，但是如果您需要有关大量数据的Restic表现的数据，我很乐意为您提供最新信息。 如果我能在一周之内完成维护每周备份所需的所有操作，我认为它将是处理这些备份的理想之选。

目前，我有几个问题：在尝试recover之前，应该让此rebuild-index运行完成吗？ 如果不这样做，我会丢掉任何东西吗？ 我一直在考虑这个问题，我想我想尽可能地在第一时间恢复尽可能多的数据，因为需要花费一些时间来运行这么多的数据，但是如果更好地杀死它，请运行recover首先rebuild-index ，我可以做到。 使用--quiet标志运行rebuild-index或recover像使用backup命令一样加快速度吗？

好的！ 我建议您执行以下操作：

• 中止rebuild-index
• 运行restic recover
• 看一下新创建的快照包含哪些数据

如果您想尝试，则可以再次运行rebuild-index并从存储库中抓取剩余的兆字节数据。 可能不到几百兆字节，并且很可能不会显示快照中尚未包含的任何新数据。 但是你可以试试看:)

rebuild-index运行时，您无法访问存储库。

使用--quiet标志运行rebuild-index或进行恢复是否会像使用backup命令那样加快速度？

不。

我让事情运行一整夜，它似乎已经装满硬盘并失败了：

found 755 roots Fatal: unable to save new tree to the repo: fs.TempFile: open /var/folders/tq/67qp8py137n_5nzf563qlylr0000gn/T/restic-temp-pack-913168611: no space left on device

是否有一种简单的方法可以告诉您此操作将要下载多少数据，或者可以减少该工具下载的数量？

另外，如果我要释放此磁盘空间是restic cache --cleanup的方法呢？

不，那只会删除30天未使用的缓存目录。 只需删除缓存目录，该目录应位于主目录中。

您究竟运行了哪个命令？ rebuild-index和recover都不应该在硬盘上保存大量数据，除了元数据缓存...

此刻不在我的办公桌前。 但这就像： ./restic -o b2.connections=x -r b2:mybucket:/ recover我想我把x设置成一个很大的值。 那可能是问题的一部分。 我可以不用-o b2.connections=x位来重新启动它。 我找到了缓存目录并将其删除。

首先，很棒的工具。
我还需要通过缓慢的连接备份TB级的数据，并有可能在备份仍未完成的情况下失败。 是否有建议的方式一次仅备份几个文件？

是否有建议的方式一次仅备份几个文件？

通常有效的方法（我听说过）是保存源数据的各个部分（例如，单个目录），完成后将所有目录保存在一起。 当源数据未更改时，由于内置重复数据删除功能，restic应该几乎不上传任何内容。

此类问题最好的场所是位于https://forum.restic.net的论坛，那里的问题（和答案！）更容易被发现。

@pauletg怎么样了？

我在＃2056中提出了新命令recover 。

自从我上一篇博文以来，我在静态恢复方面没有取得太大进展。 好消息是我们设法恢复了服务器，并且崩溃时数据没有受到损害，所以我有了数据。 在完成之前，recover命令似乎已填满了我计算机的硬盘。 这可能是由以下几个因素引起的：我的备份很大，并且我使用大量的b2连接进行上载，而我用于恢复的计算机上的HD相对较小。 我敢肯定，如果我的备份大小更合理，那可能会很好用。 让我知道是否还有其他信息对您有帮助。 非常感谢您为此工作，并为笔记本电脑备份提供此功能非常好。

感谢您的反馈！ 如果您愿意（并且有很多时间），可以使用--no-cache重试此操作，但这将花费更长的时间。 ＃2056合并后，我将解决此问题。

如果您还有其他反馈意见，请告诉我们！ :)