在不丢失数据的情况下将 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 +devices

  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 应该只会影响奇偶校验驱动器，而不会影响其他现有数据。

OTOH 我的大多数 ZFS 机器都没有 ECC RAM。

• **在这种情况下启用 Linux 内核 RAM 检查！
  • Debian：GRUB_CMDLINE_LINUX_DEFAULT="memtest=17"或类似的/etc/default/grub
• 到目前为止，我还没有遇到过不好的经历，即使有时 NonECC-RAM 会出现故障。
• 具有非 ECC 的 ZFS 非常危险，因为 ZFS 是CoW，因此如果错误的 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 总是按预期工作。例如，前段时间一个驱动器坏了，我能够恢复数据。AFAICS 恢复已完成（根据最新的 SNAP 记录）。但这样的恢复过程可能需要很长时间（数周），而且在我看来，它并不像 ZFS 那样直接，特别是如果恢复过程必须中断并稍后重新启动（使用 SnapRAID，您应该确切地知道自己在做什么）正在做）。

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

• 管理 ZFS 轻而易举。你唯一需要定期做的事情就是：
  zpool scrub
  仅此而已。然后zpool status告诉你如何解决你的问题。
  （ZFS 已经有 10 多年的历史了。在 Linux 上。简单地说：ZFS 是一个救星。）

• OTOH 在 SnapRAID 上，您不需要任何规划。就去做吧。当需要出现时，随时改变你的结构。
  因此，您无需复制数据即可开始使用 SnapRAID。只需添加奇偶校验驱动器、配置即可。

• 但如果您遇到麻烦，SnapRAID 的管理要困难得多。您
  必须学习如何使用snapraid sync、、snapraid scrub和snapraid check 。大多数时候是有帮助的，但您常常会感到困惑，修复某些问题的正确方法可能是什么，因为没有明显的单一最佳方法（SnapRAID 就像瑞士军刀，但您需要了解自己，如何正确地解决问题）正确处理）。snapraid 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提供一些非常易于使用的 24/7 即时备份和恢复功能。

• ZFS 适用于文件系统，其中至关重要的是它们永远不会停机。几乎所有事情都可以即时修复，无需任何停机时间。
  仅当 ZFS 的冗余/自我修复不再能够修复损坏时，才会发生停机。但即便如此，ZFS 也非常有帮助，它会列出所有丢失的数据。通常。

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

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

• 继续使用 LVM！
  • 让每个驱动器成为完整的 PV。没有分区表。
    如果要加密驱动器，请将 PV 放入 LUKS 容器内。
  • 将每个这样的 PV 放入它自己的 VG 中。这样，故障驱动器就不会损害其他 VG。
    您可以将多个较小的驱动器聚合到同一个 VG 中，以使每个 LV（SnapRAID 设备）具有相似的大小。
  • 创建一堆大小相似的数据 LV，每个 LV 位于一个 VG 上。
  • 在 VG 上留出足够的空间 (100GB) 用于创建快照和对文件系统进行小幅调整。
  • 创建一堆比数据 LV 大（约 10%）的奇偶校验驱动器。
  • 在每个 PV 的末尾应该有一些可用空间（请参阅上面的足够空间）。
    这适用于最后创建超级块副本的现代文件系统。如果完全填满 PV，这些 FS (ZFS) 可能会检测到整个驱动器或 PV，而不是 LV。
    （如果您使用加密驱动器，则不会发生这种情况。）
• 在这些 LV 上为数据驱动器创建您选择的 FS。
• 也许使用 ZFS 作为 LV 上的奇偶校验驱动器。
  • （目前我这边还处于实验阶段。）
  • 每个 SnapRAID 奇偶校验驱动器都应该是它自己的池。
  • 这里不需要压缩/重复数据删除。
  • 请注意，这并不是非常直接完美，因为 ZFS 通常在 中创建它的 FS /。
  • 去zvol还是不去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（如 Samsung 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 个），然后才开始使它们变得高效，这样，只有在断电或重新启动后，一切都会出现，如果一切真的很好，但自然允许在所有其他情况下进行手动干预（这是最常见的情况，因为通常服务器只会在出现一些非常严重的问题时崩溃或重新启动，对吧？）。