Restic: 未加密的备份

创建于 2017-06-10  ·  25评论  ·  资料来源: restic/restic

我想禁用加密,因为我将备份存储到加密分区,并希望避免双重加密开销。 是的,纵深防御等等,但能够做到这一点还是很好的。

discussion feature suggestion

最有用的评论

我已经多次听到此功能请求,并且我认为它存在问题。 由于我似乎找不到它,因此在此处跟踪此功能请求。 简短的版本是:我们最终可能会在某个时候添加一个禁用加密的选项,但目前这不在路线图上。

长版是:

  • 加密不再昂贵,至少如果您有 AES-NI(硬件加速加密),这在当今非常普遍(至少在笔记本电脑和服务器中)
  • restic 不仅关心加密,还关心真实性和数据签名。 我们需要找到一种无需加密的方法来实现这一点,因此无论如何我们都需要保留密钥/密码。
  • 一旦我们拥有允许未加密备份的代码路径,攻击者就有可能找到一种方法来诱使客户端将未经加密的数据保存到(原始)加密存储库中。 之前其他备份程序也发生过这种情况,所以我们需要非常小心,这需要我们目前没有的时间和资源。

当我找到它们时,我可能会添加更多的点。

所有25条评论

我已经多次听到此功能请求,并且我认为它存在问题。 由于我似乎找不到它,因此在此处跟踪此功能请求。 简短的版本是:我们最终可能会在某个时候添加一个禁用加密的选项,但目前这不在路线图上。

长版是:

  • 加密不再昂贵,至少如果您有 AES-NI(硬件加速加密),这在当今非常普遍(至少在笔记本电脑和服务器中)
  • restic 不仅关心加密,还关心真实性和数据签名。 我们需要找到一种无需加密的方法来实现这一点,因此无论如何我们都需要保留密钥/密码。
  • 一旦我们拥有允许未加密备份的代码路径,攻击者就有可能找到一种方法来诱使客户端将未经加密的数据保存到(原始)加密存储库中。 之前其他备份程序也发生过这种情况,所以我们需要非常小心,这需要我们目前没有的时间和资源。

当我找到它们时,我可能会添加更多的点。

想要未加密备份(本地)的另一个原因是中央存储库可以由多个用户共享 - 即在我的家庭服务器上,我想通过 HTTPS 向它发送备份,但让它们都被删除到一个公共存储库中,即使它们在逻辑上与单个用户分开呈现。

攻击者有可能找到一种方法来欺骗客户端将未经加密的数据保存到(最初)加密的存储库中。

嗯,我认为这个想法是存储库是否加密,因此不可能将未加密的数据保存到加密的存储库中......如果加密存储库以某种方式被具有相同的未加密存储库替换名称和位置,用户应该注意到没有询问密码。 也许可以打印红色粗体闪烁文本的警告,即存储库未加密:)。

@wrouesnel你已经可以做到了,通过主机名来区分! (前几天我也在想同样的事情):)

@alexeymuranov你如何确定用户输入的密码是加密目录的加密密码,还是用于验证未加密目录真实性的MAC密码? 更多--switches ? 它变得非常混乱非常快。

我想有这个选项来进行本地备份。 例如,我每天都在我的服务器上运行我的 ~/Music 目录的备份,但我不需要对其进行加密。 备份不是为了防止硬件故障或丢失(我有其他备份),而只是为了防止事故和比特腐烂。 而且服务器的功率相当低,因此加密开销是一个问题。

@alphapapa为此有rsync
编辑:和文件权限/属性。 顺便说一句,“硬件故障”和“bitrot”有什么区别?

@cfcsrsync不会去重。

为此,有 rsync。

@cfcs众所周知,镜像不是备份。 ;) 使用 Obnam,我保留了一系列备份,类似于 restic: keep = 7d,8w,12m,3y自从我几乎丢失了我的 GPG 密钥(因为它在我没有注意到的情况下被神秘地截断为 0 字节,并且截断的文件被备份反复),我不得不从 CD-R 上的多年备份中挖掘它,我认识到保留旧备份数据的重要性。

顺便说一句,“硬件故障”和“bitrot”有什么区别?

在您需要腐烂数据之前,Bitrot 通常不会被检测到,并且不会使整个设备无法读取。 硬件故障是例如磁盘完全故障、系统无法启动等。

正如 Alexey 指出的那样,rsync 不进行重复数据删除,也不提供旧备份数据的修剪,也不提供数据完整性检查等。rsync 是一个很好的工具,我经常使用它,但不进行备份

加密不再昂贵,至少如果您有 AES-NI(硬件加速加密),这在当今非常普遍(至少在笔记本电脑和服务器中)

除非你的软件是用 go 编写的。 Go 的 crypro 是仅适用于英特尔以外的任何软件的软件 - 因此,使用 arm 设备时,您会遇到相同文件集的“预计备份时间 - 14 天”,而使用我的 NAS 上基于 openssl 的官方备份解决方案在不到 30 分钟的时间内完成.

我也想看看这个功能。 我使用 SSH 进行传输,并将备份存储在 LUKS/cryptsetup 加密卷上,因此加密只会增加丢失加密密钥的风险。 此外,加密增加了更多的错误倾向并给 CPU 增加了不必要的负载。

然而,当我备份到不受信任的目标时,加密非常有用。

人们可能会受到保护,包括密码和备份的文本文件...

我还使用 luks/dm-crypt 加密备份目标。 它是我挂载到 /Backup/ 的外部 USB 磁盘
您可以在该位置(/Backup/restic_password)创建一个密码文件,然后使用 --password-file 将其提供给 restic。 存储库位于 /Backup/restic_repo/ 下
使密码文件不可变很重要,否则如果不小心丢失就搞砸了:chattr +i /Backup/restic_password
另外我只是使用“restic”作为密码,以防万一。

如果您备份到云提供商等不受信任的目标,Restic 的加密功能非常有用。 但是,如果您只使用存储在家里的外部驱动器或地下室的 NAS,那么强制加密有点疯狂。 普通用户无论如何都会忘记密码。

允许未加密的备份将允许 ZFS 或 BtrFS 或 NTFS 或任何文件系统压缩备份。

(如果需要,可以在较低层通过 dmcrypt 进行加密)

允许未加密的备份将允许 ZFS 或 BtrFS 或 NTFS 或任何文件系统压缩备份。

同样,没有压缩和强制加密在我的备份服务器上占用了太多空间。 我的用例(一些图像,很多小的 xml/txt/csv 文件)将从不加密(所以 ZFS 可以做它的事情)或压缩(~2.3 压缩比 zstd,5)中受益匪浅。

如果您使用 ZFS,为什么不使用zfs send快照?

在许多情况下,ZFS 快照不足以进行备份。 如果文件中有未检测到的损坏,或者如果您想拥有数年的保存集,ZFS 快照并没有多大帮助。 例如,假设您正在使用 FreeNAS 并希望维护一年的每周备份。 FreeNAS 中内置的调度和快照管理_真的_不足以正确实现这一点。 这不是“企业”。

如果你有一个更精细的调度系统,它可能会工作得更好。 还有一个问题是 zfs send 需要快照存在才能发货; 您还必须管理快照计划并确保您的快照和发送计划同步(手动),以便您达到 RTO/RPO。

是的……我说的是 FreeNAS 上的企业功能。 但这就是关心...

加密不再昂贵,至少如果你有 AES-NI

AES-NI 要求排除了许多较旧的服务器(在某些情况下,备份尤其重要!)。

我正在帮助某人在非洲农村的一组服务器上运行一些更好的备份,这些备份使用了 10 多年的捐赠硬件(其中一些甚至仍然是 32 位的!)。 我担心加密只会增加太多开销,所以我想现在我需要寻找其他地方。

+1 不加密

这会很有用

+1 不加密

这会很有用

请在原始问题上使用点赞功能而不是“+1”-ing,以避免淹没观察者的收件箱。 谢谢!

此功能的状态如何?

我需要从公司所有用户都可以访问的内部 samba 服务器备份文件(共享文档,如用户手册翻译),它们在公司范围内并不是真正的机密。 在这种情况下备份加密毫无意义,无论如何我都使用 jailkit 来提高备份的安全性,并且我使用启用了压缩的 btrfs 文件系统。 无论如何,我都会以其他方式备份诸如 VM 磁盘转储之类的东西。 在我的用例中,加密不是问题,防止数据丢失是唯一的优先事项。 使用像“restic”这样的密码是一种愚蠢的解决方法。

请执行此操作。

@mrkafk使用restic 加密的实际问题是什么? 即使您不需要它,您也需要非常具体的原因才能使其成为问题,因为您的 CPU 很可能支持硬件加密。

我已经描述了我的实际问题:鉴于特定的上下文我不需要它,而据我所知,它至少消除了 btrfs 文件系统中的压缩增益。 我有大量文件要备份,这就是为什么我首先使用启用了压缩的 btrfs,因为使用 RAID-1 来实现硬件冗余我需要大量磁盘空间(如果不是这样,我宁愿使用ext4)。 此外,使用相当于假密码的内容进行加密并进行不必要的加密感觉......很愚蠢。

好的,从你写的东西中我发现了一个实际问题,即 BTRFS 压缩不如没有加密时那么有效。 那是个很好的观点。 除此之外,由于restic的加密,我没有看到任何限制你的东西。

如果没有加密,就不可能丢失加密密钥。 这对于备份尤其重要。

梅布斯

如果没有加密,就不可能丢失加密密钥。 这对于备份尤其重要。

这已经被讨论过,就像世界明天已经结束:) https://github.com/restic/restic/issues/1786

此页面是否有帮助?
0 / 5 - 0 等级