初始情况
我在亚马逊上有一个 8 TB 的 EBS 驱动器（ext4，直接安装，没有分区）
我很久没有使用 sw-raid 了，所以我的假设可能是错误的，我可以通过这种方式缩小磁盘。
目标
我想在生产系统中将此 EBS 驱动器缩小到 5TB（-3TB）。
该驱动器将以 100-200mb/秒的速度持续写入（生产数据库和工具）
问题
Amazon 不提供 EBS 缩减服务，我能找到的唯一解决方案（过去也使用过）是创建第二个 EBS 并复制所有内容，通常使用“rsync”。
这不是一个选项，EBS 很慢，而且考虑到我的系统会永久更改大于 2TB 的文件（数据库文件），rsync 永远无法跟上这些更改。
主意 我考虑过将我的 EXT4 8TB 磁盘“转换”为 RAID-1（最初缺少第二个磁盘）。我会使用元数据版本，在磁盘末尾添加元数据（我可以为此缩小文件系统）。
第一个问题
在创建 8TB 磁盘的 md0 时，有什么可以阻止我再次将其安装为 EXT4 并忽略它是 raid 磁盘？
据我了解，唯一的变化实际上是添加（附加）了“元数据”，因此它仍然应该“合法地”是普通的 ext4 磁盘？
是真的吗？将其安装为 MD0 并写入时是否仍然如此？
鉴于这是无风险的，我现在将创建缺少第二个磁盘的 md0，并将其挂载（因此服务器会停机几分钟）
现在我想将文件系统 resize2fs 缩小 3TB，然后我想使用 mdadm --grow (shrink) 将 md0 缩小到 5TB 总大小。
现在我想将第二个 EBS 驱动器 (5TB) 作为第二个磁盘添加到 raid 并使其同步。
第二个问题 我可以这样做吗？通过这种方式添加 5TB 磁盘？
第三个问题
我现在要移除原来的 8TB 磁盘，要么继续使用单磁盘 md0，要么直接挂载 md0 的 ext4，根本不再使用 raid。
如果 mdadm 不适合，LVM 是否可用？（我选择 mdadm 是因为它似乎与 ext4 兼容，因此完成后我可以直接返回直接挂载。使用 LVM 则不可能）
就这样，抱歉，文章太长了。我想我漏掉了什么。不可能那么简单，因为没有其他文章或答案提到使用 mdadm 来解决这个问题。
答案1
听起来是个不错的冒险计划。您描述的技术方法听起来很可靠，应该可行。不过，这需要提前在单独的机器上进行测试，并且需要更多时间来验证迁移部分，尤其是因为它应该是实时的。
仅总结一下阅读上述问题后的一些笔记：
- 所涉及的风险是业务风险。您将其描述为具有 100-200MB 数据库写入的实时系统。这些数据可能来自一些正在进行的业务。除了技术细节之外，需要明确的是，此迁移包含使实例停止业务数小时的风险。不仅出于恢复目的，我建议在计划中断期间使用离线数据库进行迁移。
- 这个想法听起来不错，而且很有可能成功。测试和投入一些时间来获取所有需要的细节是必要的。
- 您说磁盘上没有分区表，因此缩小 ext4 并使用磁盘末尾的元数据创建 mdraid 应该没问题。这不会影响 ext4 分区的数据。它肯定不会处理磁盘开头的元数据，因为这与 ext4 元数据重叠。
- 元数据被添加到磁盘末尾，但不是直接添加。确切位置取决于硬盘属性，如块大小、块数量和其他一些详细信息。这也是此设置的绊脚石。如果另一个管理员扩大了 ext4，它最终会杀死 mdadm 元数据。
- 可以使用磁盘创建 raid
missing，只需要指定哪个磁盘missing。 - 因为
raid-1我认为可以将其视为常规磁盘的假设是正确的。只要使用，/dev/sd<x>块复制和元数据更新（实际上是 raid 机制）就不会处于活动状态。因此需要将挂载迁移到/dev/md<x>以便同步稍后附加的卷。 - 添加 5 TB 磁盘应该可行，此时这是 mdadm 的核心功能，用于替换故障
raid-1磁盘。在此阶段，上述过程无关紧要。 - 我会在迁移后移除 RAID，因为元数据块将在下一次增长后某个未定义的时间点消失。这可能会导致卷上的数据完全失效。如果 RAID 应该保留以进行类似这样的最终进一步操作，那么在开始时使用元数据创建它很重要，并且仅在其之上使用 ext4
/dev/<mdx>。 - 选择 mdadm 而不是 lvm 应该是首选方法。两者都使用内核级 raid 块层。mdadm 比 lvm 更灵活。通常情况下，如果需要结合使用 raid 和 lvm，则 mdadm 用于 raid 部分。由于应该可以轻松扩展 ebs 和 ext4，因此将 lvm 排除在设置之外应该没问题。
实用技巧：对此类大小的磁盘使用最新的 ext4 工具。