在不丢失数据的情况下将 LVM/EXT4 转换为 ZFS

Question

我有一个家庭媒体服务器，里面有 2 个 3TB 驱动器。它目前使用 mdraid (1)、LVM 和 EXT4 进行设置。设置是使用 ncurses Ubuntu Server 安装程序完成的。

目标

将设置转换为使用 ZFS (RAIDZ) 并添加第三个 3TB 驱动器。我想启用即时压缩和重复数据删除。转换不应要求重新安装 Ubuntu 和所有软件包。不应有数据丢失（当然，除非在此过程中磁盘崩溃）。

我该怎么做呢？

附加问题，使用 btrfs 执行此操作是否更好，因为据我了解，我可以用一个磁盘初始化阵列，复制数据，然后使用 btrfs 添加第二个磁盘，但不能使用 zfs？

我的/proc/mdstat：

Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md4 : active raid1 sdb2[1] sda2[0]
      2930070069 blocks super 1.2 [2/2] [UU]

unused devices: <none>

我的 pvs -v

    Scanning for physical volume names
  PV         VG   Fmt  Attr PSize PFree DevSize PV UUID
  /dev/md4   Data lvm2 a-   2,73t    0    2,73t MlZlTJ-UWGx-lNes-FJap-eEJh-MNIP-XekvvS

我的 lvs -a -o +设备

  LV     VG   Attr   LSize  Origin Snap%  Move Log Copy%  Convert Devices
  Data   Data -wi-ao  2,68t                                       /dev/md4(13850)
  Swap   Data -wi-ao  7,54g                                       /dev/md4(11920)
  Ubuntu Data -wi-ao 46,56g                                       /dev/md4(0)

Answer 1

短的：

• 我认为没有从 ext4 到 ZFS 的就地转换。

• 对于媒体服务器我建议SnapRAID反而

编辑：

在我进一步深入之前： 记得将 ECC RAM 与 ZFS 一起使用。 SnapRAID 的要求并不高，因为它在现有文件系统的用户空间中运行，因此坏的 RAM 只会影响奇偶校验驱动器，而不会影响其他现有数据。

另一方面，我的大多数 ZFS 机器都没有 ECC RAM。

• **在这种情况下启用 Linux 内核 RAM 检查！
  • Debian:GRUB_CMDLINE_LINUX_DEFAULT="memtest=17"或类似/etc/default/grub
• 到目前为止我还没有遇到过不好的经历，尽管有时 NonECC-RAM 会出现故障。
• 非 ECC 的 ZFS 极其危险就像 ZFS 一样奶牛因此，如果错误的 RAM 区域受到攻击，它可能会破坏 ZFS 顶层结构（包括其冗余），而不会引起注意，然后 ZFS 上的所有数据都会立即损坏。

更长：

ZFS 使用非常独特且非常特殊的内部结构，这与 ext4 的结构不太契合。（阅读：也许有人可以在某些 ext4 之上创建一些人工的 ZFS 结构，但我怀疑这种转换是否快速、可靠且易于使用。）

但是，SnapRAID 不需要您转换任何内容。只需将其与（几乎）任何现有文件系统一起使用，即可为其中的文件创建冗余，这样您就可以在驱动器发生故障或（静默）损坏时检查和恢复文件。

优点缺点：

• 如果必须为许多小文件创建冗余，SnapRAID 效率低下，因为每个文件都会在奇偶校验中创建一定的开销（填充）。

• SnapRAID 本身不提供压缩功能。
  在媒体服务器上，您通常不需要压缩，因为媒体通常已经压缩（MP4、JPG、PDF）。
  如果您碰巧使用允许压缩的文件系统，则可以使用它。但仅限于设备级别，而不是整个池（如 ZFS 那样）。

• SnapRAID 不提供块级重复数据删除。
  在媒体服务器上，该snapraid dup功能通常就足够了，因为媒体文件通常不会共享大量重复块。（例外：youtube-dl。如果您以相同的质量下载两次视频，则它们仅在几个字节上有所不同。并非总是如此。但很常见。只需在文件名中保留 Youtube 视频 ID 即可识别两个相似的文件。）

• ZFS 重复数据删除需要大量内存。计划每 1 TiB 数据使用 1 GiB RAM，越多越好！
  如果 RAM 不足，则需要添加一些超快速 SSD 缓存设备。ZFS 需要查找每个写入的重复数据删除块的 1 个随机扇区，因此如果 SSD 上“只有”40 kIOP/s，则将有效写入速度限制为大约 100 MB/s。（通常 ZFS 能够利用所有设备的并行带宽，因此如今您可以在消费硬件上轻松达到 1 GB/s 甚至更高的写入速度，但如果您启用重复数据删除并且没有大量 RAM，则无法实现。）

• 请注意，我从未遇到过需要使用 SnapRAID 来恢复数据的问题。因此，我不能保证 SnapRAID 确实能够恢复数据。
  编辑： 我这边已经遇到足够多的麻烦了，而 SnapRAID 总是能按预期工作。例如，前段时间一个驱动器坏了，我能够恢复数据。据我所知，恢复已经完成（从最新的 SNAP 中）。但这种恢复过程可能需要很长时间（数周），而且在我看来，它不像 ZFS 那样简单，特别是如果恢复过程必须中断并随后重新启动（使用 SnapRAID 时，您应该确切知道自己在做什么）。

• 在 ZFS 上，您必须提前规划。在开始使用 ZFS 之前，您需要提前了解并规划 ZFS 驱动器整个生命周期的各个方面。
  如果您能做到这一点，那么没有比 ZFS 更好的解决方案了，相信我！
  但是，如果您忘记了将来会发生意外的事情，那么您就完蛋了。然后，您需要从头开始使用 ZFS：
  创建一个新的第二个全新且独立的 ZFS 池并将所有数据传输到那里。ZFS
  支持您这样做。但您无法避免暂时复制数据。就像您在引入 ZFS 时需要的那样。

• 管理 ZFS 轻而易举。您唯一需要定期做的就是：
  zpool scrub
  就这样。然后zpool status告诉您如何解决问题。
  （ZFS 已经存在 10 多年了。在 Linux 上。简而言之：ZFS 是救星。）

• 另一方面，在 SnapRAID 上，您不需要任何规划。只需开始即可。并在需要时随时更改结构。
  因此，您无需复制数据即可开始使用 SnapRAID。只需添加奇偶校验驱动器，进行配置即可。

• 但是，如果您遇到麻烦，SnapRAID 的管理难度要大得多。
  您必须学习如何使用snapraid sync、snapraid scrub和。 大多数情况下，这很有帮助，但您常常会感到困惑，什么可能是修复某些问题的正确方法，因为没有明显的最佳方法（SnapRAID 就像一把瑞士军刀，但您需要自己了解如何正确处理它）。snapraid checksnapraid fixsnapraid status

• 请注意，在 Linux 上，您在 ZFS 上有两种不同的选择：

  • ZFSonLinux 是一个内核扩展。Ubuntu
    20.04 上较新的内核可能不兼容。
    编辑：您可以从旧版 ZFSonLinux 甚至 ZFS-FUSE 升级到最新版 ZFSonLinux，没有任何问题。但是，如果要切换到新功能，则无法返回旧版本。
  • ZFS-FUSE 通常速度稍慢，并且独立于内核。
  • 两者各有利弊，这超出了本答案的范围。
  • 如果 ZFS 不可用（也许您需要修复某些东西），您的所有数据将无法访问。
  • 如果设备出现故障，则根据所使用的冗余，要么所有数据都可以完全访问，要么所有数据完全丢失。

• 编辑：

  • 如今 (2021)，ZFS-FUSE 显然已经老化，变得有些不稳定，看起来用户空间代码与最新内核存在一些不兼容问题（可能在 FUSE 级别）。它没有崩溃，也没有损坏现有数据，但 IO 突然停止，因此 FS 变得无响应，直到被终止并重新启动（这会使旧的挂载点处于某种半关闭状态，以防仍有东西访问已失效的挂载点）。 切换到 ZFSonLinux 为我解决了这个问题。
  • 但 ZFS-FUSE 仍有其用途，因为它是一个完整的用户空间进程。您可以终止并重新启动它，因此无需重新启动内核即可轻松控制它。
  • 所以我的建议是：使用 ZFS-FUSE 进行 ZFS 实验。当你适应之后，再切换到 ZFSonLinux。

• SnapRAID 是 GPLv3，完全是用户空间的附加组件。

  • 如果 SnapRAID 不可用，您的所有数据仍然保持完整且可访问。
  • 如果一个设备出现故障，其他设备上的所有数据仍然完整且可访问。

通常，媒体服务器具有长期保存旧数据并且不断增长的特性。这正是 SnapRAID 的设计目的。

• SnapRAID 允许稍后添加新驱动器甚至新的奇偶校验。

• 您可以在所有驱动器上混合使用不同的文件系统。SnapRAID 只是增加了冗余。

• SnapRAID 并非用于备份。
  在媒体档案中，您通常根本不需要备份。

• ZFS RAIDZ 也不是用来备份的。
  但是，zfs send与它结合使用，可以zfs snapshot提供一些非常易于使用的全天候即时备份和恢复功能。

• ZFS 适用于文件系统，对于文件系统而言，永远不要停机至关重要。几乎所有问题都可以即时修复，无需停机。
  只有在 ZFS 的冗余/自我修复无法修复损坏时才会发生停机。但即便如此，ZFS 也非常有用，它会列出所有丢失的数据。通常如此。

• 另一方面，SnapRAID 可以恢复数据，但这是离线方式。
  因此，在恢复之前，数据不可用。
  找出丢失的数据也很有帮助。但这比 ZFS 更困难。

使用 SnapRAID 的最佳实践建议（ZFS 超出了这个答案）：

• 留在 LVM！
  • 使每个驱动器成为完整的 PV。没有分区表。
    如果要加密驱动器，请将 PV 放入 LUKS 容器内。
  • 将每个这样的 PV 放入其自己的 VG。这样，故障驱动器不会损害其他 VG。
    您可以将多个较小的驱动器聚合到同一个 VG 中，以使每个 LV（SnapRAID 的设备）的大小相似。
  • 创建一组类似大小的数据 LV，每个 VG 上一个。
  • 在 VG 上留出足够的空间（100GB）来创建快照和对文件系统进行小幅调整。
  • 创建一组比数据 LV 更大（约 10%）的奇偶校验驱动器。
  • 每个 PV 的末尾应该有一些可用空间（请参阅上文的“足够的空间”）。
    这适用于在末尾创建超级块副本的现代文件系统。如果您完全填满 PV，这些 FS（ZFS）可能会检测到整个驱动器或 PV，而不是 LV。
    （如果您使用加密驱动器，则不会发生这种情况。）
• 为这些 LV 上的数据驱动器创建您选择的 FS。
• 也许可以使用 ZFS 作为 LV 上的奇偶校验驱动器。
  • （我这边目前还在实验中。）
  • 每个 SnapRAID 奇偶校验驱动器都应该是它自己的池。
  • 这里不需要压缩/重复数据删除。
  • 请注意，这不是非常直接完美，因为 ZFS 通常在中创建其 FS /。
  • 要不要使用 zvol，这在我看来还是一个未解的问题。

如何配置和管理 SnapRAID 超出了本答案的范围。

为什么使用 ZFS 进行奇偶校验：

好吧，当数据驱动器出现故障（扇区不可读）时，您可以复制可读文件。这样可以轻松找到不可读文件。然后您就可以恢复它。

复制仍然可读的数据可大大加快恢复过程。

但是，SnapRAID 奇偶校验只是一个大文件。如果您复制此文件，您需要确保它没有无声损坏。ZFS 独立于 SnapRAID 确保这一点。如果有损坏，ZFS 会通知您，这样您就知道必须检查奇偶校验文件。

如果只存在一些缺陷扇区，则检查整个文件需要很长时间，因为必须完全读取所有驱动器的所有数据。

很可能有一种方法可以只检查奇偶校验文件中损坏的部分。但我不确定，因为我还不需要这样做。

为什么不使用 BTRFS？

• ZFS 多年来一直运行得非常稳定、安静且完美。
• 另一方面是2019 2021 和 BTRFS仍存在大量严重问题。
  • 编辑：对我来说，如果基本功能不完全可靠，那就很严重了，也就是说，如果出现问题，它们不能增加麻烦。也许我只是缺乏经验，但阅读文档后，我还不知道如何使用 BTRF 实现这一目标。
• 例如，如果将 BTRFS 完全填满，其反应将变得不可预测且不稳定。
  相比之下，ZFS 不存在此类问题。
• 如果您对 SnapRAID 不够谨慎，有时可能会遇到完全奇偶校验，因为您希望奇偶校验驱动器使用所有可用空间的 95% 以上。
  （如果 SnapRAID 必须将许多小文件放入奇偶校验中，则效率会有点低。）
  这对于 ZFS 来说没有问题（在几乎填满的池上速度会变慢一点，但在这里没问题）。

编辑：为什么要加密？

也可以看看我使用 LUKS 的方式

加密只是一种能够更换驱动器而不必担心其上数据的方法。如果从系统中删除了加密驱动器，则所有数据都会自动变为不可读（只要加密无法破解），因为密钥对于计算机是唯一的。

同一台计算机上的所有设备都获得相同的密钥，位于 USB 拇指驱动器中或其他旧的临时介质（可以彻底销毁的介质）。备份打印在纸上。

如今，有了 SSD，我通常有一个专用的“小型”（128 GB 到 256 GB）系统 SSD，它未加密并带有（未加密的）密钥以及（未加密的）完整基础系统。

使用 EVO 型 Micro-SD（如三星 Endurance），您甚至可以从 Micro-SD 启动整个系统，如 Raspberry-PI（只要您不需要高交换吞吐量就可以工作）。

一旦从系统中移除，系统 SSD 就会被毁坏。无更换，无保修。

/etc/crypttab通常看起来像这样：

# <target name> <source device>         <key file>      <options>
swap /dev/vg_system/lv_swap /dev/urandom swap,cipher=aes-xts-plain,size=256

所有加密驱动器 (LUKS) 都由脚本激活。这样做的好处是 ZFS（或其他程序）不会在启动时激活数据驱动器。因此，一切（系统除外）都处于完全（可能是手动）控制之下。

如果某些东西应该在启动时自动出现，那么可以通过一些（精心编写的）脚本来完成，这些脚本由 的重启规则执行cron。

这些脚本首先测试所有驱动器的完美健康状态（在我这边有超过 40 个），然后才开始使它们投入使用，这样如果一切正常，一切都会在断电或重启后恢复，但在其他所有情况下自然允许手动干预（这是最常见的情况，因为通常服务器只有在出现一些非常严重的问题时才会崩溃或重启，对吗？）。