Linux香港服务器如何用mdadm创建RAID并完成文件系统格式化？

在香港 Linux 服务器上使用 mdadm 创建软件 RAID，完整流程不是只执行一条 mdadm --create 命令，而是要依次完成磁盘确认、分区、阵列创建、启动配置、文件系统格式化、挂载持久化和重启验收。下文以数据盘阵列为例，覆盖 RAID1、RAID5、RAID6 和 RAID10 的常用创建方式。

示例环境采用 Ubuntu 22.04/24.04、Debian 12，或 Rocky Linux、AlmaLinux 8/9 等常见发行版。示例使用 /dev/sdb 和 /dev/sdc 创建 RAID1，阵列设备为 /dev/md0，挂载目录为 /srv/data。所有涉及分区表、RAID 元数据和文件系统的命令都可能造成数据不可逆损失，执行前必须确认磁盘不是系统盘，也没有需要保留的数据。

围绕 Linux 数据盘、文件存储和数据库等场景，A5数据提供中国香港等地区的物理服务器资源，涵盖 SSD、NVMe 及大容量企业级机械硬盘方案。香港存储系列可搭配四块14TB企业级硬盘与H730控制器，为数据目录、文件系统及存储阵列部署提供硬件基础；同时，香港服务器的Xeon Gold、AMD EPYC平台也可承载建站、业务后台与多任务运行。

一、准备条件与方案确认

1. 明确操作系统和上线目标

先确认系统版本、内核和磁盘设备名称：

cat /etc/os-release
uname -r
lsblk -e7 -o NAME,PATH,SIZE,TYPE,FSTYPE,MOUNTPOINTS,MODEL,SERIAL

需要满足以下条件：

• 具备 root 权限，或账号可以使用 sudo。
• 服务器已经完成系统安装，系统盘与数据盘边界清晰。
• 数据盘已经在香港服务器控制台或虚拟化平台中挂载，并且操作系统可以识别。
• 通过 SSH 远程操作时，建议提前打开云平台的远程控制台或 KVM，避免网络中断后无法处理启动和挂载问题。
• 重要数据已经完成备份。RAID 提供的是磁盘冗余能力，不等同于备份。
• 计划使用的磁盘容量相近。不同容量的磁盘组阵列时，通常会按照最小成员容量计算可用空间。
• 服务器没有正在运行的数据库、虚拟机或应用写入这些数据盘。

香港机房、内地机房或其他地区的服务器，在 mdadm 创建阵列和格式化文件系统方面没有本质差异。地区主要影响网络连接、远程控制台和服务商磁盘挂载方式，不会改变 Linux 软件 RAID 的命令流程。

2. 选择 RAID 级别

不同 RAID 级别的最低磁盘数量、可用容量和故障边界不同，创建前应根据业务目标选择，而不是先创建后调整。

例如，使用两块容量相近的数据盘创建 RAID1 时，阵列可用空间约等于其中较小的一块；四块同容量磁盘创建 RAID10 时，可用空间约为总原始容量的一半。实际容量还会受到分区、RAID 元数据和文件系统的少量开销影响。

RAID5 和 RAID6 在阵列初始化、降级重建期间会产生较高磁盘负载。对数据库、虚拟机镜像和高频随机写入业务，通常需要结合 IOPS、重建时间和备份方案评估，不能只根据可用容量决定。

3. 确认哪些磁盘可以清空

执行下面命令查看系统盘、数据盘、挂载点和文件系统：

lsblk -o NAME,PATH,SIZE,TYPE,FSTYPE,FSVER,MOUNTPOINTS,PARTUUID,UUID
findmnt /
findmnt -r

示例状态：

NAME        PATH         SIZE TYPE FSTYPE MOUNTPOINTS
sda         /dev/sda     120G disk
├─sda1      /dev/sda1    119G part ext4   /
└─sda2      /dev/sda2      1G part swap   [SWAP]
sdb         /dev/sdb     960G disk
sdc         /dev/sdc     960G disk

只有在明确确认 /dev/sdb 和 /dev/sdc 是空闲数据盘后，才能继续。下列设备通常不应参与本示例：

• 当前挂载 /、/boot、/boot/efi 的系统盘。
• 承载交换分区、数据库目录或应用目录的磁盘。
• 云平台通过临时方式挂载、重启后可能改变设备映射的磁盘。
• 仍然属于其他 RAID、LVM、ZFS 或存储池的设备。

如果磁盘名称是 NVMe 设备，分区名称通常是 /dev/nvme1n1p1，而不是 /dev/nvme1n1-part1。如果使用云硬盘，建议同时核对 MODEL、SERIAL 以及云平台控制台中的磁盘 ID，不能只凭 /dev/sdb 这样的设备名称判断。

二、安装 mdadm 和必要工具

Ubuntu、Debian 使用 apt：

sudo apt update
sudo apt install -y mdadm gdisk xfsprogs e2fsprogs

Rocky Linux、AlmaLinux 等使用 dnf：

sudo dnf install -y mdadm gdisk xfsprogs e2fsprogs

检查 mdadm 是否可用：

mdadm --version
command -v mdadm
command -v sgdisk

预期可以看到类似结果：

mdadm - v4.2 - 2021-12-30
/usr/sbin/mdadm
/usr/bin/sgdisk

如果发行版没有 sgdisk，它通常由 gdisk 软件包提供。若软件包安装失败，应先处理软件源、DNS 或系统订阅问题，不要直接从不明来源下载二进制文件。

三、检查磁盘状态并清理旧元数据

1. 检查是否存在旧的文件系统或 RAID 签名

对准备使用的磁盘进行检查：

sudo wipefs -n /dev/sdb
sudo wipefs -n /dev/sdc
sudo mdadm --examine /dev/sdb
sudo mdadm --examine /dev/sdc

wipefs -n 只读取并显示签名，不会修改磁盘。mdadm --examine 可以识别磁盘上是否存在 RAID superblock。

如果输出显示已有 linux_raid_member、RAID UUID、LVM2_member 或其他文件系统签名，先暂停操作，确认这些磁盘确实可以清空。不要因为设备没有挂载就认为它没有数据，未挂载的磁盘仍可能存放可恢复的数据或属于其他存储结构。

2. 必要时清理旧 RAID 元数据

只有在确认磁盘会被重新初始化时，才可以执行：

sudo mdadm --zero-superblock --force /dev/sdb
sudo mdadm --zero-superblock --force /dev/sdc

如果磁盘上还有旧分区表和文件系统签名，可以进一步清理：

sudo wipefs -a /dev/sdb
sudo wipefs -a /dev/sdc

这两个命令都会破坏已有识别信息。执行前应保存需要的文件、分区布局和 RAID UUID。清理旧元数据并不能恢复已格式化的数据，也不应作为“排障常规动作”随意执行。

清理后再次确认：

sudo wipefs -n /dev/sdb
sudo wipefs -n /dev/sdc
sudo mdadm --examine /dev/sdb
sudo mdadm --examine /dev/sdc

如果 mdadm --examine 报告没有可识别的 RAID superblock，且 wipefs -n 没有显示需要保留的签名，才适合进入分区步骤。

四、为 RAID 成员创建 GPT 分区

虽然 mdadm 可以直接使用整块磁盘，例如 /dev/sdb，但生产环境更适合为每块磁盘建立专用 RAID 分区。这样可以明确设备边界，并为后续磁盘管理保留更清晰的结构。

下面以 /dev/sdb 和 /dev/sdc 为例。命令中的设备名必须替换为已经确认的空闲磁盘。

1. 清除旧分区表并创建 RAID 分区

以下命令会删除目标磁盘上的 GPT、MBR 和分区信息：

sudo sgdisk --zap-all /dev/sdb
sudo sgdisk --zap-all /dev/sdc

sudo sgdisk --new=1:0:0 --typecode=1:fd00 --change-name=1:raid-data /dev/sdb
sudo sgdisk --new=1:0:0 --typecode=1:fd00 --change-name=1:raid-data /dev/sdc

fd00 是 GPT 下常用的 Linux RAID 分区类型标识。它本身不会创建阵列，只是帮助系统和运维人员识别该分区用于 Linux 软件 RAID。

通知内核重新读取分区表：

sudo partprobe /dev/sdb
sudo partprobe /dev/sdc
sudo udevadm settle

2. 验证分区结果

lsblk -o NAME,PATH,SIZE,TYPE,FSTYPE,PARTTYPE,PARTLABEL,MOUNTPOINTS /dev/sdb /dev/sdc
sudo sgdisk --print /dev/sdb
sudo sgdisk --print /dev/sdc

预期结构类似：

NAME  PATH         SIZE TYPE FSTYPE PARTTYPE                             PARTLABEL
sdb   /dev/sdb     960G disk
└─sdb1 /dev/sdb1   960G part        0xfd00                               raid-data
sdc   /dev/sdc     960G disk
└─sdc1 /dev/sdc1   960G part        0xfd00                               raid-data

如果系统没有出现 /dev/sdb1 或 /dev/sdc1，不要直接执行 mdadm --create。可以尝试重新运行 partprobe、udevadm settle，或通过维护窗口重启后再检查。若设备仍不一致，应核对云平台磁盘挂载状态和内核日志：

dmesg -T | tail -n 80

NVMe 示例：

sudo sgdisk --zap-all /dev/nvme1n1
sudo sgdisk --zap-all /dev/nvme2n1
sudo sgdisk --new=1:0:0 --typecode=1:fd00 --change-name=1:raid-data /dev/nvme1n1
sudo sgdisk --new=1:0:0 --typecode=1:fd00 --change-name=1:raid-data /dev/nvme2n1
sudo partprobe /dev/nvme1n1
sudo partprobe /dev/nvme2n1

后续创建 RAID 时应使用 /dev/nvme1n1p1 和 /dev/nvme2n1p1。

五、使用 mdadm 创建 RAID 阵列

1. 创建 RAID1

两块磁盘创建 RAID1 的命令如下：

sudo mdadm --create /dev/md0 \
  --metadata=1.2 \
  --level=1 \
  --raid-devices=2 \
  --name=hk-data \
  /dev/sdb1 /dev/sdc1

参数说明：

• /dev/md0：阵列设备名称。系统也可能自动分配 /dev/md127 等名称，因此名称不是唯一识别依据。
• --metadata=1.2：使用常见的 RAID 元数据格式。数据盘阵列通常可以使用该格式。
• --level=1：创建 RAID1。
• --raid-devices=2：阵列包含两块成员盘。
• --name=hk-data：设置阵列名称，便于识别。
• /dev/sdb1 /dev/sdc1：实际参与阵列的分区。

执行后，mdadm 可能提示阵列创建会破坏设备上的数据。确认设备无误后再输入 yes。

不要把 /dev/sdb、/dev/sdb1 与其他阵列成员混用，也不要在不清楚故障状态时使用 missing 参数。使用 missing 创建降级阵列只适用于有明确迁移或恢复计划的场景。

2. 创建其他 RAID 级别

RAID10 示例，至少需要四个成员分区：

sudo mdadm --create /dev/md0 \
  --metadata=1.2 \
  --level=10 \
  --raid-devices=4 \
  --name=hk-data \
  /dev/sdb1 /dev/sdc1 /dev/sdd1 /dev/sde1

RAID5 示例，至少需要三块成员盘：

sudo mdadm --create /dev/md0 \
  --metadata=1.2 \
  --level=5 \
  --raid-devices=3 \
  --name=hk-data \
  /dev/sdb1 /dev/sdc1 /dev/sdd1

RAID6 示例，至少需要四块成员盘：

sudo mdadm --create /dev/md0 \
  --metadata=1.2 \
  --level=6 \
  --raid-devices=4 \
  --name=hk-data \
  /dev/sdb1 /dev/sdc1 /dev/sdd1 /dev/sde1

这些命令只选择其中一种执行，不要连续执行多个级别。RAID5、RAID6 和 RAID10 的成员数量、容量和性能特征不同，阵列创建完成后不能通过简单修改 --level 来转换。

3. 验证阵列创建状态

立即查看内核状态：

cat /proc/mdstat

RAID1 初始化期间可能看到类似输出：

Personalities : [raid1]
md0 : active raid1 sdc1[1] sdb1[0]
      937328640 blocks super 1.2 [2/2] [UU]
      [>....................]  resync =  4.8% (45112320/937328640) finish=145.0min speed=101234K/sec

unused devices: <none>

这里的 [UU] 表示两个成员都在线；如果看到 [_U] 或 [U_]，说明阵列处于降级状态。初始化期间出现 resync 是正常现象，但磁盘负载和业务 I/O 延迟可能上升。

进一步查看详细状态：

sudo mdadm --detail /dev/md0

重点关注：

State : clean, resyncing
Active Devices : 2
Working Devices : 2
Failed Devices : 0
Spare Devices : 0

初始化完成后，预期状态应接近：

State : clean
Active Devices : 2
Working Devices : 2
Failed Devices : 0

示例输出中的容量和同步时间只是判断格式的参考，不代表某一台服务器的实测结果。同步时间会受到磁盘类型、阵列级别、阵列容量、系统负载和内核限速参数影响。

可以使用下面的循环观察同步过程：

while grep -Eq 'resync|recovery|reshape' /proc/mdstat; do
    date
    cat /proc/mdstat
    sleep 30
done

如果业务允许，也可以在阵列尚未完成同步时继续进行文件系统创建，但初始化期间磁盘负载通常更高。生产环境一般建议等待阵列进入 clean，再进行大规模业务导入。

六、保存阵列配置并确保重启后自动组装

阵列当前能够使用，不代表服务器重启后一定会自动组装。需要保存阵列 UUID，并重新生成 initramfs。

1. 查看阵列 UUID

sudo mdadm --detail --scan

示例：

ARRAY /dev/md0 metadata=1.2 name=hk-data UUID=2b6f5d2a:6bd25f8e:0d9b4a77:3e0a6d19

2. Ubuntu 和 Debian 配置

先备份配置文件：

sudo cp -a /etc/mdadm/mdadm.conf /etc/mdadm/mdadm.conf.bak.$(date +%F-%H%M%S)

检查已有配置：

sudo grep -E '^(DEVICE|ARRAY|MAILADDR)' /etc/mdadm/mdadm.conf

如果文件中没有本阵列对应的 ARRAY 行，再追加：

sudo mdadm --detail --scan | sudo tee -a /etc/mdadm/mdadm.conf

如果文件中已经有相同 UUID 的 ARRAY 行，不要重复追加，应保留一条有效配置。

更新 initramfs：

sudo update-initramfs -u

3. Rocky Linux 和 AlmaLinux 配置

先备份配置文件：

sudo cp -a /etc/mdadm.conf /etc/mdadm.conf.bak.$(date +%F-%H%M%S)

查看现有配置：

sudo grep -E '^(DEVICE|ARRAY|MAILADDR)' /etc/mdadm.conf

确认没有相同 UUID 后追加：

sudo mdadm --detail --scan | sudo tee -a /etc/mdadm.conf

重新生成 initramfs：

sudo dracut -f

不同发行版的软件包可能提供不同的监控服务名称，可以先查询：

systemctl list-unit-files | grep -E 'mdadm|mdmonitor'

如果系统存在对应的 mdmonitor.service 或 mdadm.service，再根据发行版启用。没有该服务时，不要硬执行不存在的服务名称；/proc/mdstat 和 mdadm --detail 仍然可以用于状态检查。

七、在阵列设备上创建文件系统

1. 确认格式化对象是 /dev/md0

文件系统必须创建在阵列设备 /dev/md0 上，而不是成员分区 /dev/sdb1 或 /dev/sdc1 上。

执行前再次确认：

lsblk -f
findmnt /dev/md0
sudo mdadm --detail /dev/md0

如果 findmnt /dev/md0 有输出，说明阵列已经被挂载，不能直接格式化。先确认是否存在需要保留的数据。

2. 使用 XFS

XFS 适合较大的数据目录和连续文件场景。格式化命令如下：

sudo mkfs.xfs -f -L hk_data /dev/md0

其中 -f 表示强制覆盖已有文件系统签名，具有破坏性。不要对已经包含业务数据的阵列直接执行。

3. 使用 ext4

如果业务需要更通用的 Linux 文件系统，可以使用 ext4：

sudo mkfs.ext4 -F -L hk_data /dev/md0

XFS 和 ext4 选择其一，不要在同一个阵列设备上连续执行两个格式化命令。格式化完成后查看结果：

sudo blkid /dev/md0
lsblk -f

示例：

/dev/md0: LABEL="hk_data" UUID="8f5e9c7a-2b9d-4f49-9b6a-2a1d8e24c501" TYPE="xfs"

如果使用 ext4，TYPE 应显示为 ext4。

八、挂载文件系统并配置开机自动挂载

1. 创建挂载目录

sudo mkdir -p /srv/data
sudo mount /dev/md0 /srv/data

验证挂载状态：

findmnt /srv/data
df -hT /srv/data

预期可以看到类似结果：

TARGET    SOURCE    FSTYPE OPTIONS
/srv/data /dev/md0  xfs    rw,relatime,attr2,inode64

执行简单读写测试：

sudo touch /srv/data/.raid-write-test
sudo stat /srv/data/.raid-write-test
sudo rm -f /srv/data/.raid-write-test

这只能验证当前挂载点具有基本读写能力，不能证明阵列已经具备完整的故障恢复能力。

2. 使用 UUID 写入 /etc/fstab

获取文件系统 UUID：

sudo blkid -s UUID -o value /dev/md0

备份 fstab：

sudo cp -a /etc/fstab /etc/fstab.bak.$(date +%F-%H%M%S)

XFS 示例：

UUID=8f5e9c7a-2b9d-4f49-9b6a-2a1d8e24c501 /srv/data xfs defaults,x-systemd.device-timeout=30s 0 2

ext4 示例：

UUID=8f5e9c7a-2b9d-4f49-9b6a-2a1d8e24c501 /srv/data ext4 defaults,x-systemd.device-timeout=30s 0 2

将对应的一行追加到 /etc/fstab：

sudo nano /etc/fstab

或者使用编辑器直接修改。不要把 XFS 示例和 ext4 示例同时写入。

nofail 可以让数据盘异常时系统继续启动，但也可能导致应用启动后把数据写入根分区下的空目录。因此，是否增加 nofail 应根据业务要求决定：

• 数据盘不是系统启动必需项，但服务器必须尽快进入系统：可以考虑 nofail。
• 应用必须依赖 /srv/data，数据盘缺失时不应启动：不建议盲目使用 nofail，应让挂载失败暴露出来。
• 生产环境可以由 systemd 挂载依赖和应用服务依赖共同控制，而不是只依赖一个 fstab 参数。

3. 验证 fstab 配置

先检查语法：

sudo findmnt --verify

如果当前目录已经挂载，可以先卸载再通过 fstab 挂载：

sudo umount /srv/data
sudo mount /srv/data

验证：

findmnt /srv/data
df -hT /srv/data

mount /srv/data 会按照 /etc/fstab 中的挂载项执行。如果出现错误，应先修正 fstab，不要直接重启远程服务器。

九、重启前后的结果检查

1. 重启前检查

维护窗口内执行：

sudo mdadm --detail /dev/md0
cat /proc/mdstat
findmnt /srv/data
df -hT /srv/data
sudo findmnt --verify

至少应满足：

• 阵列设备存在，且状态为 clean 或业务明确接受的同步状态。
• Active Devices 与计划的成员数一致。
• Failed Devices 为 0。
• /srv/data 已通过 UUID 挂载。
• 文件系统类型与格式化方案一致。
• fstab 没有重复或错误的挂载行。
• 阵列 UUID 已写入对应发行版的 mdadm 配置文件。
• Ubuntu/Debian 已执行 update-initramfs -u。
• Rocky/AlmaLinux 已执行 dracut -f。

2. 重启后检查

远程服务器重启应选择业务维护窗口，并确保具备控制台访问能力：

sudo reboot

系统恢复后执行：

cat /proc/mdstat
sudo mdadm --detail /dev/md0
lsblk -f
findmnt /srv/data
df -hT /srv/data

检查阵列是否被正确组装：

sudo mdadm --detail --scan

检查内核是否出现磁盘或文件系统错误：

dmesg -T | grep -Ei 'md|raid|sd[a-z]|nvme|xfs|ext4|error|fail' | tail -n 100

如果业务服务依赖该挂载点，还应确认服务启动顺序和应用实际读写路径。尤其要避免数据盘挂载失败后，应用在根分区的 /srv/data 空目录中继续写入。

十、常见异常与处理方法

1. mdadm --create 提示设备已经属于 RAID

先查看现有阵列：

cat /proc/mdstat
sudo mdadm --detail --scan
sudo mdadm --examine /dev/sdb1
sudo mdadm --examine /dev/sdc1

如果这些分区属于已有阵列，不要继续执行 --create。可以根据 UUID 尝试组装已有阵列：

sudo mdadm --assemble --scan

--assemble 用于组装已有阵列，--create 用于创建新阵列，两者不能混用。只有在确认旧阵列数据不需要保留时，才考虑停止旧阵列并清除 superblock。

2. 阵列显示为降级状态

如果 /proc/mdstat 中出现：

md0 : active raid1 sdb1[0]
      937328640 blocks super 1.2 [2/1] [U_]

说明只有一个成员在线。应先确认磁盘是否被系统识别：

lsblk
dmesg -T | tail -n 100
sudo mdadm --detail /dev/md0

常见原因包括：

• 磁盘没有挂载到服务器。
• 分区设备名称写错。
• 成员盘存在 I/O 错误。
• 阵列创建时磁盘状态就不完整。
• 云平台重启后磁盘设备映射发生变化。

不要在没有确认故障盘和替换盘的情况下执行 --fail、--remove 或 --add。错误地移除正常成员可能让阵列从降级变成不可用。

3. 初始化或重建速度过慢

查看同步进度和磁盘错误：

cat /proc/mdstat
iostat -xz 5 3
dmesg -T | tail -n 100

如果没有安装 iostat，Ubuntu/Debian 可安装 sysstat：

sudo apt install -y sysstat

Rocky/AlmaLinux：

sudo dnf install -y sysstat

同步慢可能是磁盘本身性能、阵列容量、业务并发写入或内核同步限速导致。若服务器正在承载生产业务，不建议未经评估直接大幅提高同步速度，因为这可能增加业务 I/O 延迟。

4. 文件系统挂载失败

确认文件系统类型、UUID 和设备：

lsblk -f
sudo blkid /dev/md0
sudo findmnt --verify

检查 fstab 是否存在以下问题：

• UUID 写错。
• 把 /dev/sdb1 写成挂载对象，而不是 /dev/md0 的文件系统 UUID。
• XFS 文件系统却填写了 ext4，或反过来。
• 挂载目录不存在。
• 同一个 UUID 或目录存在重复挂载行。

创建目录并手动测试：

sudo mkdir -p /srv/data
sudo mount /dev/md0 /srv/data

如果手动挂载也失败，再查看文件系统和内核日志。不要在没有备份的情况下直接使用 fsck -y 或强制修复命令。XFS 不使用传统的 fsck 流程，通常应使用 xfs_repair，且修复前必须卸载文件系统并准备备份。

5. 重启后没有自动组装阵列

检查：

cat /proc/mdstat
ls -l /dev/md*
sudo mdadm --detail --scan

然后确认：

• Ubuntu/Debian 的 /etc/mdadm/mdadm.conf 中存在正确的 ARRAY 行。
• Rocky/AlmaLinux 的 /etc/mdadm.conf 中存在正确的 ARRAY 行。
• initramfs 已重新生成。
• 成员盘在启动时已经被系统识别。
• 没有重复或过期的 UUID 配置。

如果远程重启后无法登录，应通过服务器控制台查看启动日志，不要反复重启或直接清理磁盘。

6. 出现 I/O error 或磁盘掉线

发现以下现象时，应优先停止高风险操作：

I/O error
ataX: hard resetting link
blk_update_request: I/O error
md0: recovery interrupted

处理顺序建议为：

1. 保留当前日志和 mdadm --detail 输出。
2. 查看香港服务器控制台中的磁盘状态和硬件告警。
3. 确认是否为云硬盘临时掉线、宿主机问题或实际磁盘故障。
4. 对仍然在线的数据进行备份。
5. 在维护窗口内执行成员盘更换和重建。

不要通过 --force 强行把不确定的设备加入阵列，也不要因为阵列显示降级就立即执行格式化。

十一、分阶段回滚方法

回滚方式取决于操作进行到了哪一步。越接近格式化和业务写入阶段，越不能依赖命令恢复数据。

1. 尚未创建阵列

如果只完成了磁盘识别或分区，还没有创建 RAID，可以停止操作。若要恢复原分区布局，应使用事先保存的分区表备份；没有备份时，不应凭记忆重建原分区表。

2. 已创建阵列但尚未写入数据

确认阵列中没有需要保留的数据后，可以停止阵列并清除成员 superblock：

sudo umount /srv/data 2>/dev/null || true
sudo mdadm --stop /dev/md0
sudo mdadm --zero-superblock --force /dev/sdb1
sudo mdadm --zero-superblock --force /dev/sdc1

如需将磁盘重新交给其他系统使用，再执行签名清理：

sudo wipefs -a /dev/sdb1
sudo wipefs -a /dev/sdc1

如果 /etc/fstab 已经增加挂载项，应先删除对应行，再执行：

sudo findmnt --verify

3. 已完成格式化但尚未写入业务数据

可以卸载文件系统并停止阵列，但格式化已经覆盖了原有文件系统的关键结构，不能把它视为可逆操作：

sudo umount /srv/data
sudo mdadm --stop /dev/md0

是否继续清除 superblock，应根据后续用途决定。若原阵列中存在需要恢复的数据，不要执行 wipefs -a，应立即停止写入并使用专业数据恢复方案。

4. 已有业务数据并正在使用

不要直接执行以下命令：

mdadm --stop
mdadm --zero-superblock
wipefs -a
mkfs.xfs -f
mkfs.ext4 -F

这些操作可能导致业务中断、阵列无法组装或数据进一步覆盖。应先完成业务迁移、备份和维护窗口确认，再按照数据迁移方案下线阵列。

十二、上线验收与回滚检查项

上线验收

• [ ] 已通过 lsblk、序列号或云平台控制台确认目标磁盘。
• [ ] 系统盘、启动分区、交换分区未被加入数据阵列。
• [ ] RAID 级别和成员数量符合业务设计。
• [ ] mdadm --detail /dev/md0 显示成员数量正确。
• [ ] Failed Devices: 0，阵列状态为 clean。
• [ ] /proc/mdstat 中没有异常降级、恢复失败或 I/O 错误。
• [ ] 文件系统创建在 /dev/md0 上，而不是成员分区上。
• [ ] lsblk -f 显示正确的文件系统类型和 UUID。
• [ ] /srv/data 可以正常挂载、读取和写入。
• [ ] /etc/fstab 使用文件系统 UUID，且已经通过 findmnt --verify。
• [ ] 对应发行版的 mdadm 配置文件已保存阵列 UUID。
• [ ] initramfs 已重新生成。
• [ ] 重启后阵列能够自动组装，文件系统能够自动挂载。
• [ ] 业务服务没有在挂载失败时误写入根分区目录。
• [ ] 已记录阵列级别、磁盘序列号、UUID、挂载点和回滚命令。

回滚检查

• [ ] 记录了原始分区表和磁盘信息。
• [ ] 已备份 /etc/fstab、mdadm 配置和 initramfs 生成前后的状态。
• [ ] 回滚前已确认阵列中没有仍需保留的数据。
• [ ] 已卸载 /srv/data，没有进程持续占用。
• [ ] 仅在确认无数据需求后执行 mdadm --stop。
• [ ] 仅在确认磁盘可清空后执行 --zero-superblock 或 wipefs -a。
• [ ] 若阵列已经承载业务数据，优先迁移和备份，不直接清理磁盘。
• [ ] 回滚完成后重新执行 lsblk、mdadm --detail、findmnt --verify，确认系统没有残留错误挂载项。