在我的服务器上,我使用 SSD 作为启动驱动器,并在 RAID6 设置中使用 11 个 6TB HDD 作为附加存储。然而,在主板遇到一些问题后,我将主板更换为只有 4 个 SATA 端口的主板,因此我将 RAID6 设置的大小从 11 个驱动器减少到 4 个驱动器。由于阵列上存储的实际数据小于 6TB,因此数据应该能够容纳在减少的存储空间中。
我相信我使用了以下页面上的说明来缩小数组。由于是很久以前的事了,我实际上不记得这些是否是所使用的页面或说明,也不记得许多细节:
- https://superuser.com/questions/834100/shrink-raid-by-removing-a-disk
- https://delightlylinux.wordpress.com/2020/12/22/how-to-remove-a-drive-from-a-raid-array/
在 7 个未使用的驱动器上,我相信我将超级块归零:sudo mdadm --zero-superblock
。
对于我想要使用的 4 个驱动器,我无法安装。我不相信我在阵列上使用了任何分区。
sudo mount /dev/md127 /mnt/md127
mount: /mnt/md127: wrong fs type, bad option, bad superblock on /dev/md127, missing codepage or helper program, or other error.
从/var/log/syslog
:
kernel: [ 1894.040670] EXT4-fs (md127): bad geometry: block count 13185878400 exceeds size of device (2930195200 blocks)
由于13185878400 / 2930195200
== 4.5
,9 / 2
我认为缩小文件系统或类似的问题存在问题。由于 RAID6 有 2 个备用驱动器,从 11 个(9 个活动驱动器,2 个备用驱动器)变为 11 个(2 个活动驱动器,9 个备用驱动器)?到 4(2 个活动,2 个备用)可以解释为什么块计数远高于设备大小的精确倍数4.5
。
来自设备的其他信息:
sudo mdadm --detail /dev/md127
/dev/md127:
Version : 1.2
Creation Time : Wed Nov 24 22:28:38 2021
Raid Level : raid6
Array Size : 11720780800 (10.92 TiB 12.00 TB)
Used Dev Size : 5860390400 (5.46 TiB 6.00 TB)
Raid Devices : 4
Total Devices : 4
Persistence : Superblock is persistent
Intent Bitmap : Internal
Update Time : Sun Apr 9 04:57:29 2023
State : clean
Active Devices : 4
Working Devices : 4
Failed Devices : 0
Spare Devices : 0
Layout : left-symmetric
Chunk Size : 512K
Consistency Policy : bitmap
Name : nao0:0 (local to host nao0)
UUID : ffff85d2:b7936b45:f19fc1ba:29c7b438
Events : 199564
Number Major Minor RaidDevice State
9 8 16 0 active sync /dev/sdb
1 8 48 1 active sync /dev/sdd
2 8 32 2 active sync /dev/sdc
10 8 0 3 active sync /dev/sda
sudo mdadm --examine /dev/sd[a-d]
/dev/sda:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x1
Array UUID : ffff85d2:b7936b45:f19fc1ba:29c7b438
Name : nao0:0 (local to host nao0)
Creation Time : Wed Nov 24 22:28:38 2021
Raid Level : raid6
Raid Devices : 4
Avail Dev Size : 11720780976 sectors (5.46 TiB 6.00 TB)
Array Size : 11720780800 KiB (10.92 TiB 12.00 TB)
Used Dev Size : 11720780800 sectors (5.46 TiB 6.00 TB)
Data Offset : 264192 sectors
Super Offset : 8 sectors
Unused Space : before=264112 sectors, after=176 sectors
State : clean
Device UUID : 07f76b7f:f4818c5a:3f0d761d:b2d0ba79
Internal Bitmap : 8 sectors from superblock
Update Time : Sun Apr 9 04:57:29 2023
Bad Block Log : 512 entries available at offset 32 sectors
Checksum : 914741c4 - correct
Events : 199564
Layout : left-symmetric
Chunk Size : 512K
Device Role : Active device 3
Array State : AAAA ('A' == active, '.' == missing, 'R' == replacing)
/dev/sdb:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x1
Array UUID : ffff85d2:b7936b45:f19fc1ba:29c7b438
Name : nao0:0 (local to host nao0)
Creation Time : Wed Nov 24 22:28:38 2021
Raid Level : raid6
Raid Devices : 4
Avail Dev Size : 11720780976 sectors (5.46 TiB 6.00 TB)
Array Size : 11720780800 KiB (10.92 TiB 12.00 TB)
Used Dev Size : 11720780800 sectors (5.46 TiB 6.00 TB)
Data Offset : 264192 sectors
Super Offset : 8 sectors
Unused Space : before=264112 sectors, after=176 sectors
State : clean
Device UUID : 3b51a0c9:b9f4f844:68d267ed:03892b0d
Internal Bitmap : 8 sectors from superblock
Update Time : Sun Apr 9 04:57:29 2023
Bad Block Log : 512 entries available at offset 32 sectors
Checksum : 294a8c37 - correct
Events : 199564
Layout : left-symmetric
Chunk Size : 512K
Device Role : Active device 0
Array State : AAAA ('A' == active, '.' == missing, 'R' == replacing)
/dev/sdc:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x1
Array UUID : ffff85d2:b7936b45:f19fc1ba:29c7b438
Name : nao0:0 (local to host nao0)
Creation Time : Wed Nov 24 22:28:38 2021
Raid Level : raid6
Raid Devices : 4
Avail Dev Size : 11720780976 sectors (5.46 TiB 6.00 TB)
Array Size : 11720780800 KiB (10.92 TiB 12.00 TB)
Used Dev Size : 11720780800 sectors (5.46 TiB 6.00 TB)
Data Offset : 264192 sectors
Super Offset : 8 sectors
Unused Space : before=264112 sectors, after=176 sectors
State : clean
Device UUID : 0fcca5ee:605740dc:1726070d:0cef3b39
Internal Bitmap : 8 sectors from superblock
Update Time : Sun Apr 9 04:57:29 2023
Bad Block Log : 512 entries available at offset 32 sectors
Checksum : 31472363 - correct
Events : 199564
Layout : left-symmetric
Chunk Size : 512K
Device Role : Active device 2
Array State : AAAA ('A' == active, '.' == missing, 'R' == replacing)
/dev/sdd:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x1
Array UUID : ffff85d2:b7936b45:f19fc1ba:29c7b438
Name : nao0:0 (local to host nao0)
Creation Time : Wed Nov 24 22:28:38 2021
Raid Level : raid6
Raid Devices : 4
Avail Dev Size : 11720780976 sectors (5.46 TiB 6.00 TB)
Array Size : 11720780800 KiB (10.92 TiB 12.00 TB)
Used Dev Size : 11720780800 sectors (5.46 TiB 6.00 TB)
Data Offset : 264192 sectors
Super Offset : 8 sectors
Unused Space : before=264112 sectors, after=176 sectors
State : clean
Device UUID : e1912abb:ba98a568:8effaa66:c1440bd8
Internal Bitmap : 8 sectors from superblock
Update Time : Sun Apr 9 04:57:29 2023
Bad Block Log : 512 entries available at offset 32 sectors
Checksum : 82a459ba - correct
Events : 199564
Layout : left-symmetric
Chunk Size : 512K
Device Role : Active device 1
Array State : AAAA ('A' == active, '.' == missing, 'R' == replacing)
在网上查找后,我尝试使用fsck
、e2fsck
、 和resize2fs
来尝试解决该问题。然而,我尝试这样做并没有取得任何进展,而且我可能由于不小心更改了磁盘上的数据而使问题变得更糟。
和resize2fs
,
sudo resize2fs /dev/md127
resize2fs 1.46.5 (30-Dec-2021)
Please run 'e2fsck -f /dev/md127' first.
由于我无法resize2fs
实际执行任何操作,因此我使用e2fsck
它遇到了许多错误。由于存在数千个错误,我在程序完成之前就退出了。
sudo e2fsck -f /dev/md127
e2fsck 1.46.5 (30-Dec-2021)
The filesystem size (according to the superblock) is 13185878400 blocks
The physical size of the device is 2930195200 blocks
Either the superblock or the partition table is likely to be corrupt!
Abort<y>? no
Pass 1: Checking inodes, blocks, and sizes
Error reading block 3401580576 (Invalid argument) while getting next inode from scan. Ignore error<y>? yes
Force rewrite<y>? yes
Error reading block 3401580577 (Invalid argument) while getting next inode from scan. Ignore error<y>? yes
Force rewrite<y>? yes
Error reading block 3401580578 (Invalid argument) while getting next inode from scan. Ignore error<y>? yes
Force rewrite<y>? yes
Error reading block 3401580579 (Invalid argument) while getting next inode from scan. Ignore error<y>? yes
Force rewrite<y>? yes
Error reading block 3401580580 (Invalid argument) while getting next inode from scan. Ignore error<y>? yes
Force rewrite<y>? yes
Error reading block 3401580581 (Invalid argument) while getting next inode from scan. Ignore error<y>? yes
Force rewrite<y>? yes
Error reading block 3401580582 (Invalid argument) while getting next inode from scan. Ignore error<y>? yes
Force rewrite<y>?
我的假设是,报告的驱动器大小可能存在一些不一致。我不认为 RAID 上有任何分区,也没有任何 LVM 卷。
sudo fdisk -l
...
Disk /dev/sda: 5.46 TiB, 6001175126016 bytes, 11721045168 sectors
Disk model: WDC WD60EZAZ-00S
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk /dev/sdb: 5.46 TiB, 6001175126016 bytes, 11721045168 sectors
Disk model: WDC WD60EZAZ-00S
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk /dev/sdc: 5.46 TiB, 6001175126016 bytes, 11721045168 sectors
Disk model: WDC WD60EZAZ-00S
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk /dev/sdd: 5.46 TiB, 6001175126016 bytes, 11721045168 sectors
Disk model: WDC WD60EZAZ-00S
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk /dev/md127: 10.92 TiB, 12002079539200 bytes, 23441561600 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 524288 bytes / 1048576 bytes
当前使用的 4 个驱动器上的数据可能会也可能不会被fsck
/更改e2fsck
,但数据也应该位于具有归零超级块的其他 7 个未使用驱动器上。对我来说,从哪个驱动器恢复数据并不重要,因此从任何驱动器分组中恢复的工作解决方案将受到高度赞赏!
如果需要任何其他信息,我将非常乐意提供。
答案1
您的 ext4 文件系统比您的块设备(12TB 块设备上的 54TB 文件系统)大得多。e2fsck
并且resize2fs
在这种情况下可能会非常不合作。文件系统讨厌大块丢失。
debugfs
为了快速恢复数据,您可以在灾难模式下试试运气:
# debugfs -c /dev/md127
debugfs 1.47.0 (5-Feb-2023)
debugfs: ls -l
| (this should list some files)
| (damaged files usually show with 0 bytes and 1-Jan-1970 timestamp)
debugfs: rdump / /some/recovery/dir/
这应该复制文件(使用不相关的 HDD 进行恢复存储),但某些文件可能会导致类似Attempt to read block from filesystem resulted in short read
或类似的错误。
为了真正修复文件系统,通常最好恢复原始设备大小,然后从那里开始。有时,缩小块设备是可逆的。但就你的情况而言,这是不可逆的。
您可以将 RAID 增加到 11 个设备,但即使驱动器顺序正确,它也不会恢复任何丢失的数据,甚至会覆盖剩余磁盘上可能留下的任何数据。 mdadm 在每个增长操作中都会移动偏移量,因此布局会完全错误。
因此,超出截止点的任何内容都会丢失。
此外,(再次)重塑所有这些数据将需要很长时间,而且结果不会比仅仅增加一些虚拟驱动器容量(循环设备和 dm-线性、或 LVM 精简卷或类似的全为零)更好。
最好的情况是,您可以通过重新创建来部分逆转它(在写时复制覆盖上使用 mdadm --create )您原来的 11 个驱动器 RAID 6 缺少 4 个驱动器(因为驱动器完全归零)。
但至多这会给您带来断开连接的数据块,并且它们之间有许多间隙,因为这超出了 RAID 6 可以恢复的范围。它甚至更加复杂,因为您不再拥有元数据(需要知道原始偏移量,该偏移量已经在当前的 raid 上更改,以及驱动器顺序)。
如果您能做到这一点,您可以将当前的 RAID (0-12TB) 和恢复的 raid (12TB-54TB) 与 dm-线性 拼接在一起(全部位于写时复制覆盖层之上),然后看看可以找到什么。
但这个过程比较复杂,成功的概率也很低。对于存储在收缩操作保留的 12TB 之外的任何数据,一些小于块/条带文件的数据可能会幸存,而较大的文件将全部损坏。