☰

将 raid1 转换为 raid5 时出现问题

tag-icon • tag-icon linux raid raid5 raid1
将 raid1 转换为 raid5 时出现问题

我有一个干净的 raid1，我尝试按照以下步骤将其转换为 raid5： https://dev.to/csgeek/converting-raid-1-to-raid-5-on-linux-file-systems-k73

mdadm --create /dev/md0 --level=5 --raid-devices=2 /dev/sdX1 /dev/sdY1 经过几乎一整夜的步骤后 ，我最终得到了一个似乎损坏的阵列。

我的理解是，这个阵列不完整（因为它只包含 2 个磁盘），但应该可以挂载。但是当我尝试挂载时，我只得到：mount: /mnt/temp: wrong fs type, bad option, bad superblock on /dev/md127, missing codepage or helper program, or other error

顺便说一句：阵列标识符/dev/md127在重新启动后更改为

cat /proc/mdstat给我

Personalities : [raid6] [raid5] [raid4] [linear] [multipath] [raid0] [raid1] [raid10]
md127 : active (auto-read-only) raid5 sdc1[0] sdd1[2]
      3906884608 blocks super 1.2 level 5, 512k chunk, algorithm 2 [2/2] [UU]
      bitmap: 0/30 pages [0KB], 65536KB chunk

unused devices: <none>

和mdadm --detail /dev/md127

/dev/md127:
           Version : 1.2
     Creation Time : Mon Apr 10 15:10:08 2023
        Raid Level : raid5
        Array Size : 3906884608 (3725.90 GiB 4000.65 GB)
     Used Dev Size : 3906884608 (3725.90 GiB 4000.65 GB)
      Raid Devices : 2
     Total Devices : 2
       Persistence : Superblock is persistent

     Intent Bitmap : Internal

       Update Time : Tue Apr 11 02:29:34 2023
             State : clean
    Active Devices : 2
   Working Devices : 2
    Failed Devices : 0
     Spare Devices : 0

            Layout : left-symmetric
        Chunk Size : 512K

Consistency Policy : bitmap

              Name : zentaur:0  (local to host zentaur)
              UUID : 5a7b31a9:cbee2d37:fd0aed8a:8efafc98
            Events : 7548

    Number   Major   Minor   RaidDevice State
       0       8       33        0      active sync   /dev/sdc1
       2       8       49        1      active sync   /dev/sdd1

分区表似乎有问题。使用

fdisk -l

它给了我

Disk /dev/md127: 3.64 TiB, 4000649838592 bytes, 7813769216 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 524288 bytes / 524288 bytes

下一步尝试使用以下命令获取超级块： mke2fs -n /dev/md127

mke2fs 1.46.2 (28-Feb-2021)
Creating filesystem with 976721152 4k blocks and 244187136 inodes
Filesystem UUID: 5710f0da-129a-4a5c-8af9-18093a8feffd
Superblock backups stored on blocks:
        32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
        4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,
        102400000, 214990848, 512000000, 550731776, 644972544

但使用其中任何一种方式安装设备都不起作用。

我现在被困住了 我可以做什么或尝试访问数据吗？还是只需将第 3 个磁盘添加到 raid5 阵列即可？

非常感谢大家！

更新

感谢上帝，我设法访问了（希望是大部分）数据。我想分享我所采取的路径以供进一步参考。

我尝试的第一件事是直接在没有分区表的 raid 阵列 (/dev/md0) 上使用“foremost”。这只是部分成功，因为它运行非常速度很慢，结果好坏参半。许多文件损坏，没有目录结构，没有文件名。但有些文件结果正确（内容方面）——所以我抱有希望。

然后我从这个页面开始：https://raid.wiki.kernel.org/index.php/Recovering_a_failed_software_RAID（章节“使用覆盖文件将硬盘设为只读”）。假设数据可以位于原始磁盘上，我按照说明创建了覆盖。这里有一点需要注意：在步骤 3 中，使用了页面，blockdev --getsize ....但在我的版本 (2.36.1) 中，该参数被标记为“已弃用”，并且不起作用。我不得不改用blockdev --getsz。

有了覆盖后，我摆弄了一下，最后使用了“testdisk”，让它分析覆盖设备/dev/mapper/sdX1。选择“EFI GPT”分区类型后，它找到了一个我可以使用的分区表。从这里开始，这个过程非常简单。testdisk 显示了磁盘的旧文件结构，我能够将“丢失”的文件复制到备份硬盘上。这个过程仍在运行，但抽样测试很有希望，大多数数据都可以恢复。

答案1

使用命令

mdadm --create /dev/md0 --level=5 --raid-devices=2 /dev/sdX1 /dev/sdY1

你基本上删除了驱动器上的所有数据，因为你被告知mdadm要创建一个新的数组，而不是重新塑造现有的数组。

你真正想要的是mdadm --grow。从管理手册页：

Grow   Grow (or shrink) an array, or otherwise reshape it in some
              way.  Currently supported growth options including
              changing the active size of component devices and changing
              the number of active devices in Linear and RAID levels
              0/1/4/5/6, changing the RAID level between 0, 1, 5, and 6,
              and between 0 and 10, changing the chunk size and layout
              for RAID 0,4,5,6,10 as well as adding or removing a write-
              intent bitmap and changing the array's consistency policy.

一般来说，绝不遵循一些随机指南，但没有完全理解建议命令的含义。

编辑：看来 mdadm 的最新版本做了正确的事来保护用户免受此类错误的影响：尝试测试阵列，我确实可以在之前的 raid1 阵列上创建一个 raid5 阵列而不会丢失文件系统。但是，这不是我所依赖的任何东西，因为对位图/块/元数据版本的任何更改都可能损坏您的数据 - 重塑阵列的正确工具仍然是grow子命令。

答案2

基本上，该mdadm --create ...命令保留了原始数据（至少在一个磁盘上）。我更新了我的问题，并附上我为找到可以恢复的数据所采取的步骤

相关内容