【问题标题】:Cryptographically Secure Backup加密安全备份
【发布时间】:2011-05-14 05:38:35
【问题描述】:

到目前为止,我一直在使用 rsync 从我的计算机备份到外部驱动器。备份数据由数以万计的小文件和数百个大文件(Maildir 电子邮件和我最喜欢的系列剧集)组成。这样做的问题是,如果我的备份磁盘的单个扇区发生故障,则可能单个消息可能已损坏,我认为这是无法容忍的。

我想到了一个替代方案,如下所示。共有三棵树:由我希望备份的数据组成的文件树、包含文件树在给定时刻的副本的备份树和包含备份树的文件哈希和元数据哈希的哈希树。整个散列树的散列也被保留。在备份之前,检查散列树的散列。此处的故障会使整个备份数据无效。检查成功后,将哈希树形状与备份树形状进行比较,并验证元数据哈希以确保备份树的元数据和形状一致。如果不是,则可以列出个别罪魁祸首。在此之后,执行 rsync 备份遍历。每当 rsync 更新文件时,都会计算其新的哈希和元数据哈希并将其插入哈希树。每当 rsync 删除一个文件时,该文件就会从哈希树中删除。最后计算并存储哈希树的哈希。

这个过程非常有用,因为哈希是为正确的数据计算的,这意味着即使文件树中的文件在插入哈希树后损坏,这种不一致不会使备份(或将来的备份)无效.然而,最重要的特性是,如果攻击者随意破坏备份介质,当且仅当它是正确的时,那里的信息才会被信任,除非攻击者破坏了哈希算法。此外,可以增量验证发送到备份或从中恢复的数据。

我的问题是:这样的备份方案是否合理实施?我的搜索告诉我,唯一可用的备份方案要么执行完整备份或差异备份(例如基于 tar),要么无法提供加密正确性保证 (rsync)。

如果没有类似的实现,也许我会写一个,但我想避免重新发明轮子。

【问题讨论】:

  • 我认为这属于服务器故障或超级用户。
  • 我想我听说过“默克尔树”这个短语与类似的概念一起使用?我认为驱动器的取证分析可能涉及这样的事情。您可以使用 hashdeep 之类的东西向数据添加哈希值。另见 tahoe-lafs

标签: hash cryptography backup


【解决方案1】:

Git-Annex 是给定可用工具的正确解决方案。它是 git 的扩展,它允许对任意大的文件提供强大的支持,在数据存储之间自动同步,具有可选的图形用户界面,跟踪您拥有的备份数量以及准确存储哪些文件的位置,并允许您设置规则它应该如何管理不同的内容。您还可以自定义用于验证内容完整性的加密哈希。

对于驱动器备份的需求,git-annex 与 bup 具有互操作性,它具有针对那些寻求定期备份整个系统的人的更多功能。

【讨论】:

    【解决方案2】:

    如果我必须解决问题,我会使用内置 AES 加密的驱动器的 RAID 阵列(以防止损坏),然后使用我使用的任何备份方法到。

    【讨论】:

    • 这不会阻止有权访问您计算机的攻击者更改阵列上的数据
    【解决方案3】:

    这听起来与Mercurial 存储系统的工作方式几乎完全相同。 'rsync 命令' 将使用 Mercurial 的 push 来实现,这非常具有网络效率。

    【讨论】:

      【解决方案4】:

      你所说的听起来很像Git。我认为它几乎可以满足您的描述。只需将“备份”过程实现为git commit。然后,您可以使用 git checkout 恢复到任何以前的版本。

      它具有惊人的存储效率和非常快速传输内容,这可能会为您节省大量备份时间。作为奖励,它是免费的、可移植的并且已经过调试!

      【讨论】:

      • 哦,是的,每个存储库都有完整的历史记录,因此您的常规机器和备份机器都有完整的历史记录,因此如果一侧发生损坏,您不太可能丢失数据。
      • git 和 mercurial 这样做,但它们不存储硬链接和创建时间之类的东西。它们也不是为这种用途而设计的;他们不会存储增量档案等。这些当然可以用脚本添加,但需要编写
      • @fuzzyTew 你说的都是对的。但是,OP 要求的是“更好的 rsync”,而不是正确的文件系统备份过程。我个人不建议在尝试备份完整系统时这样做,但它对于某些仅数据副本可能很有用,特别是如果您倾向于添加新文件而不是编辑现有文件时。如果您有更好的建议,请随时发布您自己的答案!
      猜你喜欢
      • 2017-11-08
      • 1970-01-01
      • 1970-01-01
      • 2010-10-24
      • 2015-09-18
      • 2012-07-05
      • 2011-03-09
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多