OpenZFS本机加密的快速入门指南
- 线程启动JournalBot
- 开始日期
按https://zfsonlinux.org/manpages/0.8.6/man8/zfs.8.html
代码:
encryption = off | on | aes-128-ccm | aes-192-ccm | aes-256-ccm | aes-128-gcm | aes-192-gcm | aes-256-gcm控制此数据集使用的加密密码套件(分组密码、密钥长度和模式)。要求在池上启用加密特性。要求在数据集创建时设置键格式。在创建数据集时选择encryption = on表示将选择默认的加密套件，目前为aes-256-gcm。为了提供一致的数据保护，必须在创建数据集时指定加密，之后不能更改加密。有关加密的详细信息和注意事项，请参阅加密部分。编辑:更新链接到最新的manpage版本，我链接到一个过时的旧版本。
Upvote
6（8/－2）
根据我的经验，你确实需要不想在没有AESNI的计算机上运行ZFS加密。他们对软件模式做了一些改进，但仍然非常缓慢。使用AESNI，它基本上以磁盘速度运行。没有的话，就是一团糟。
我最初是在一台老式i7-920上尝试加密的，这台i7-920很古老，但性能仍然相当好。那台硬件上的ZFS加密非常糟糕。在沉重的写负载下，系统实际上无法使用。换到4790K马上就修好了。
自从我的实验以来，软件改进已经被添加了，但我们最近在Ars论坛上有一个帖子试图使用没有使用硬件加速的ARM二进制文件，这对他们来说也是一场灾难。
编辑:如果你没有太多的卷，就像文章说的，你可以使用LUKS加密，它在任何硬件上都非常快。但是您可能需要编写脚本来解锁过程，除非您想在每个磁盘上输入一个密码。类似地，我还编写了加载和挂载ZFS键的脚本，因此您可能不会丢失任何东西。
它可能不太可靠，但AFAIK LUKS是一个非常薄的层，所以它的反应可能与直接将ZFS体积放在金属上相同。
Upvote
22（22/0）
Upvote
8（8/0）
实际的问题是，我试图读取池上的加密，而不是根文件系统:
．.．这不是我想要的
然后我做了大量的工作，试图找到要查询的正确字符串，假设它必须在feature@ wall后面的某个地方。什么都没找到。我在网上搜了一堆，没找到任何明确的信息。然后我问这里，然后
瞧，这正是我要找的。我找错了地方，用了错误的语法。feature@encryption是zpools的一个东西，但显然它只是文件集的直接“加密”。
编辑:注意，我可能已经直接设置了算法，而不是使用'on'。我花了几天时间研究ZFS并预先构建文件系统创建行。
代码:
zpool get feature@encryption(卷)NAME PROPERTY VALUE SOURCE(卷)feature@encryption active local．.．这不是我想要的
然后我做了大量的工作，试图找到要查询的正确字符串，假设它必须在feature@ wall后面的某个地方。什么都没找到。我在网上搜了一堆，没找到任何明确的信息。然后我问这里，然后
代码:
zfs get encryption (volume)/(fileset) NAME PROPERTY VALUE SOURCE (volume)/(fileset) encryption aes-256-gcm -瞧，这正是我要找的。我找错了地方，用了错误的语法。feature@encryption是zpools的一个东西，但显然它只是文件集的直接“加密”。
编辑:注意，我可能已经直接设置了算法，而不是使用'on'。我花了几天时间研究ZFS并预先构建文件系统创建行。
Upvote
5（5/0）
Upvote
16（16/0）
需要注意的一件事是，不幸的是，在引导期间远程SSH解锁zfs数据集只在openzfs的2.0或更高版本中。原始PR在:https://github.com/openzfs/zfs/pull/10027
但是，这仍然可以为旧的zfs版本设置!对于我的Ubuntu 20.04 NAS，我最终提取了openzfs 2.0的debian包(但没有安装它!)，并将相关文件从/usr/share/initramfs-tools复制到/etc/initramfs-tools，将我的密钥添加到/etc/dropbear-initramfs/，并重新构建initramfs。现在，我可以解锁我的NAS，而不必求助于将密钥文件放在u盘或类似的东西上。
一个附带的好处是，我目前有两个泳池;SSD启动池用于操作系统和应用程序，rust池用于大容量存储。我在同样加密的根池中放置了一个密钥文件，因此可以直接添加一个额外的调用来导入池，并在解锁根池后立即运行' zfs load-key -a '。
我很高兴我采用了这种方式，而不是运行2.0的后端口来获得解锁功能。我在主机上运行Docker，然后https://github.com/openzfs/zfs/issues/11480肯定是我在很长一段时间内看到的冲击生产系统的最令人心跳停止的文件系统问题之一。
但是，这仍然可以为旧的zfs版本设置!对于我的Ubuntu 20.04 NAS，我最终提取了openzfs 2.0的debian包(但没有安装它!)，并将相关文件从/usr/share/initramfs-tools复制到/etc/initramfs-tools，将我的密钥添加到/etc/dropbear-initramfs/，并重新构建initramfs。现在，我可以解锁我的NAS，而不必求助于将密钥文件放在u盘或类似的东西上。
一个附带的好处是，我目前有两个泳池;SSD启动池用于操作系统和应用程序，rust池用于大容量存储。我在同样加密的根池中放置了一个密钥文件，因此可以直接添加一个额外的调用来导入池，并在解锁根池后立即运行' zfs load-key -a '。
我很高兴我采用了这种方式，而不是运行2.0的后端口来获得解锁功能。我在主机上运行Docker，然后https://github.com/openzfs/zfs/issues/11480肯定是我在很长一段时间内看到的冲击生产系统的最令人心跳停止的文件系统问题之一。
Upvote
6（7/－1）
很好的介绍。
提示:当加密的子数据集被sanoid/syncoid复制时，数据集在复制目标处失去了它们继承的加密参数(例如，变成“prompt”而不是keylocation的路径)。当使用原始发送时。这可以在解锁目标上的子节点和父节点并使用“zfs change-key -i…”后修复。
另外，对加密性能进行基准测试。
我根据Jim大约一年前的fio文章编写了一个bash脚本，其中尝试了不同的算法和记录大小组合，用于带有USB3 HDD的树莓派。我的结论是512 kB记录大小比1M记录大小执行得更好，CCM优于GCM(显然，在我的例子中，是YMMV)。
(编辑:当fio使用大块写入时，512kb记录大小比1mb记录大小执行得更好，尽管“传统观点”认为1mb记录大小在这种情况下应该更好。我不知道这是否与USB硬盘性能或树莓本身有关，但由于这一组合是我用于场外备份的方法，所以我不关心原因。)
提示:当加密的子数据集被sanoid/syncoid复制时，数据集在复制目标处失去了它们继承的加密参数(例如，变成“prompt”而不是keylocation的路径)。当使用原始发送时。这可以在解锁目标上的子节点和父节点并使用“zfs change-key -i…”后修复。
另外，对加密性能进行基准测试。
我根据Jim大约一年前的fio文章编写了一个bash脚本，其中尝试了不同的算法和记录大小组合，用于带有USB3 HDD的树莓派。我的结论是512 kB记录大小比1M记录大小执行得更好，CCM优于GCM(显然，在我的例子中，是YMMV)。
(编辑:当fio使用大块写入时，512kb记录大小比1mb记录大小执行得更好，尽管“传统观点”认为1mb记录大小在这种情况下应该更好。我不知道这是否与USB硬盘性能或树莓本身有关，但由于这一组合是我用于场外备份的方法，所以我不关心原因。)
Upvote
4（4/0）
好文章!
关于这一点:
这让我可以将密码保存在macOS密钥链中，就像我将加密的非系统APFS卷、核心存储、磁盘映像等一样(对于任何想要做同样事情的人，请记住将/usr/bin/security添加到可以访问脚本密钥链条目的应用程序列表中，否则将不起作用)。
虽然如果处理得当，密钥文件可能是安全的，但提示符可以让你从任何你喜欢的地方提取密码，因此以这种方式自动化非常方便。
我是OpenZFS加密的忠实粉丝，它让事情变得简单多了，而且zfs能够发送加密的区块，这对于备份来说是非常棒的。
唯一缺少的功能是免费替换我的旧的(但仍然固执地在完美的工作秩序)Synology NAS，只支持BTRFS;幸运的是，它也做iSCSI，所以我仍然可以用ZFS发送给它，但这不是一个理想的方式。
关于这一点:
我知道你的目标可能是让事情变得简单，但我实际上在自动化中使用提示符(没有人工参与)而不是关键文件，因为我发现它更方便，例如，在macOS上你可以这样做:
代码:
Security find-generic-password -a "${dataset}" -w | ZFS load-key "${dataset}"这让我可以将密码保存在macOS密钥链中，就像我将加密的非系统APFS卷、核心存储、磁盘映像等一样(对于任何想要做同样事情的人，请记住将/usr/bin/security添加到可以访问脚本密钥链条目的应用程序列表中，否则将不起作用)。
虽然如果处理得当，密钥文件可能是安全的，但提示符可以让你从任何你喜欢的地方提取密码，因此以这种方式自动化非常方便。
我是OpenZFS加密的忠实粉丝，它让事情变得简单多了，而且zfs能够发送加密的区块，这对于备份来说是非常棒的。
唯一缺少的功能是免费替换我的旧的(但仍然固执地在完美的工作秩序)Synology NAS，只支持BTRFS;幸运的是，它也做iSCSI，所以我仍然可以用ZFS发送给它，但这不是一个理想的方式。
Upvote
4（4/0）
ZFS只能使用最基本的内核功能，因为它不是GPL，而且内核开发人员对非GPL代码几乎关闭了他们所做的所有事情。
实际上，在Linux-ZFS系统....中有两个代码堆栈Linux端和ZFS端。这可能是ZFS严重违反正常Linux分层的部分原因;因为它不能使用Linux提供的功能，所以它实现了几乎所有的硬件。它查找并管理自己的磁盘，管理自己的压缩、加密和错误检测，进行自己的重建，并提供自己的挂载名称空间。用户级程序看不出太大的区别，它们仍然只是与磁盘上的文件对话，但当它们在ZFS数据集上时，它们与一个完整的单独的代码库交互。
随之而来的唯一真正值得注意的问题是，默认情况下，ZFS获取系统中一半的RAM用作缓存。在内存压力下，它可能会缓慢地将其释放回系统，这可能会导致严重的问题。我很确定你可以调低RAM分配，尽管我还没有费心去查找如何调低，因为我目前运行的唯一系统是一个专用服务器，无论如何都会使用一半的内存用于缓存。
Upvote
9（10/－1）