企业官网建设流程全解析

说实话，折腾过黑群晖的人，最怕看到的不是服务挂掉，而是存储管理里那四个字：存储空间损毁。第一反应基本都是“完了，数据是不是没了”。但玩过几天 Linux 的人都知道，在绝大多数 RAID1 场景下，“损毁”不等于“全丢”，它只是告诉你“镜像的两块盘之间，有一块跟阵列失联了”。数据其实还完整躺在那块健康盘上，问题在于怎么把掉队的那块盘拉回来，让阵列恢复可用状态。

这篇文章我会完全从命令行入手，用 SSH 登进 DSM 系统，讲解 RAID1 阵列重建的完整思路和操作流程。这套方法不挑设备，白群晖、黑群晖、各种自组 NAS 只要跑的是 DSM，原理都一样。适合手里设备已经出现“存储空间损毁”提示、或者想提前把修复流程搞明白的玩家。我会把每一步为什么要做、命令执行后应该出现什么结果、哪些地方容易翻车全都讲清楚，尽量做到保姆级。

1. 先搞清楚“存储空间损毁”背后发生了什么

1.1 RAID1 的镜像机制和降级原理

RAID1 的原理非常朴素：两块硬盘写一模一样的内容，一块挂了，另一块还能顶住。但这个“顶住”是有代价的——阵列进入降级状态，也就是磁盘阵列控制器视角里的 degraded。此时存储卷还能读写，可一旦剩下的这块盘再出问题，数据才是真的危险。

在 DSM 系统里，RAID1 并不是一个黑盒，底层完全由 Linux 的 md 多磁盘管理框架接管。你看到的“存储空间损毁”，在 mdadm 视角下通常是两种状态之一：阵列降级（有一块盘标记为 faulty 或 removed），或者阵列本身状态干净但文件系统层报错。前者是盘掉了、线松了、盘序乱了导致的；后者往往是被降级期间出现的异常写入、非正常断电折腾出来的。

理解这个区别很重要，因为修复动作完全不同。降级阵列要做的，是把故障盘从阵列中踢出去，然后重新加入一块好盘，让 md 层自动重建镜像；文件系统层损坏要做的，则是先确认阵列成员健康，再用 fsck 或 btrfs 工具修卷内部结构。这篇文章主要讲前一种，也是最常见的情况。

1.2 黑群晖下“损毁”常见的三种原因

结合我自己维护过的几台设备，DSM 报“存储空间损毁”，绝大部分是下面三类：

第一类是物理盘掉线。SATA 线接触不良、硬盘供电不稳、硬盘本身出现坏道导致 IO 超时，md 层在超时后会把盘踢出阵列。这种最常见，也是最容易误判的——很多人以为硬盘报废了，结果换根线就好了。

第二类是盘没坏，但阵列元数据乱了。比如异常重启、引导时两块盘的 superblock 状态不一致，mdadm 无法确定谁是正确成员，干脆降级或拒绝组装。

第三类是黑群晖特有现象：盘序变化。你插了块新盘、换了 SATA 口、动了引导参数，系统里 /dev/sda、/dev/sdb 的对应关系发生漂移，DSM 拿不到预期的盘位，就会把存储空间标记成损毁。这种情况在真机上不大容易犯，但在折腾黑群晖的人手里，几乎人人都踩过。

把这几种情况记在脑子里，后面操作时就有了判断依据，不会一上来就盲目重建。

2. SSH 入场：先给存储阵列做个体检

2.1 开启 SSH 与登录注意点

群晖默认不开 SSH。控制面板 → 终端机和 SNMP → 启用 SSH 功能，端口默认 22，不建议改到奇怪端口，自己家用怎么方便怎么来，但如果是暴露在公网环境，强烈建议用密钥登录并做 IP 白名单。

登录这一步，Windows 用户直接用系统自带的 OpenSSH 客户端，命令是：

ssh 你的用户名@你的群晖IP

如果你改过 SSH 端口，记得加参数：

ssh -p 端口号 你的用户名@你的群晖IP

这里有个很多人不知道的细节：DSM 的 SSH 登录用户名，必须是你有管理员权限的账号。默认 admin 或者你自己创建的 administrators 组账号都可以。登录进来之后，你会看到类似 Linux 的 shell 提示符，但这个环境比较精简，很多工具都没有，不过 mdadm、smartctl 这些关键工具是自带的。

登录后第一件事，先看一下系统时间和当前运行的内核，确认 DSM 服务正常：

uptime uname -a

2.2 一条条看懂体检报告

接下来是重头戏：看阵列状态。第一命令永远是：

cat /proc/mdstat

正常情况下你会看到类似下面的输出：

Personalities : [raid1] [raid6] [raid5] [raid4] [linear] [raid0] [raid10] md2 : active raid1 sdb3[1] sda3[0] 1953382464 blocks super 1.2 [2/2] [UU] bitmap: 1/8 pages [8KB], 32KB chunk

重点看[2/2]和后面的[UU]。[2/2]表示阵列总共需要 2 块盘、当前有 2 块盘工作；[UU]表示两块盘状态都健康。如果你是[2/1] [U_]，那就是有一块盘掉线了，对应位置显示下划线或者代表 faulty 的字符。

再看对应 RAID 设备的详细状态：

mdadm --detail /dev/md2

这里我会注意几个字段：

• State：是active, degraded还是clean，这决定了接下来做什么。
• Raid Devices和Working Devices：看是否缺盘。
• Number列表里的State：哪块盘是faulty，哪块是active sync。

如果是降级状态，mdadm --detail 的输出里会明确写出故障盘，例如/dev/sdb3显示faulty或者直接整行消失。

还需要用df -h和cat /etc/mtab把/dev/md2和存储卷/volume1对应起来。确认你修的是哪一个 md 设备，这一步别省，修错了后果很严重。

2.3 盘位定位：别把好盘当成故障盘

做任何操作之前，必须确认故障盘到底对应物理机箱里的哪个盘位。这是我的血泪教训：曾经有过一次盘序漂移，系统认为故障的是 /dev/sdb，实际上物理上出问题的却是另一块盘。如果盲操作，等于把好盘踢掉。

如何定位？两条路：

第一，用硬盘序列号。先列出所有磁盘的信息：

lsblk -o NAME,SIZE,MODEL,SERIAL,WWN

再看 mdadm 里记录的是哪块盘的哪块分区，例如/dev/sdb3，那就到lsblk输出里找到sdb对应的SERIAL，然后去机箱上对照盘体标签。

第二，黑群晖玩家常用的技巧：在/sys/block/sdX/device/里读厂商和型号信息：

cat /sys/block/sdb/device/model cat /sys/block/sdb/device/vendor

把序列号和型号抄下来，物理盘位上肯定有对应的标签纸，一对照就清楚了。如果机箱盘位不方便贴标签，至少也要在操作前确认阵列里两块盘的序列号分别指向哪两个盘位。

还有一个辅助手段，直接对疑似故障盘做 SMART 检测：

smartctl -a /dev/sdb

重点看SMART overall-health self-assessment test result是不是 PASSED，再看Reallocated_Sector_Ct、Current_Pending_Sector、Offline_Uncorrectable这几项有没有爆表。如果盘本身已经一堆坏道，就别再让它回阵列了，直接换新盘。

3. 手动重建 RAID1：从降级到恢复的完整流程

3.1 准备阶段：备份、快照，以及一颗冷静的心

先说一句可能得罪人的话：如果卷里是独一份的数据，而且你从来没做过备份，那在动手之前，先停一停。RAID 从来不是备份，它只是在两块盘之间同步副本。重建过程中最怕的是误操作把健康盘上的数据搞没。

最稳妥的做法是：在开始重建前，先把健康盘上的共享文件夹数据备份到外接硬盘或者另一台机器上。如果数据量太大实在不好备份，至少把最关键的资料拷出来。这一步不是浪费时间，是给自己留退路。

如果有条件，顺手给卷拍个快照。但在存储空间损毁的状态下，DSM 的快照可能已经不可用，所以别把宝押在快照上，老老实实备份核心数据。

3.2 确认故障盘，把它摘离阵列

假设我们通过cat /proc/mdstat和mdadm --detail /dev/md2确认了 md2 阵列降级，故障盘是/dev/sdb3。

先看这块盘上是不是还有残留的 RAID 成员信息：

mdadm --examine /dev/sdb3

如果输出能看出它是 md2 的成员，但状态为 faulty 或 removed，那就执行摘除操作：

mdadm --fail /dev/md2 /dev/sdb3 mdadm --remove /dev/md2 /dev/sdb3

第一条命令是把盘标记为故障，第二条是从阵列中移除。如果第二步报Device or resource busy，说明这块盘仍在被系统访问，可以试试先停止相关服务，或者用：

mdadm --remove --force /dev/md2 /dev/sdb3

但 force 之前要确认没有进程在读写这块盘。群晖里最简单的方法是从 DSM 图形界面停用对应的存储空间，如果 DSM 界面还能操作的话。

3.3 清理故障盘残留的元数据

摘除之后，这块盘上的 superblock 信息还在。如果就这么直接重新加入，mdadm 可能会认错老朋友，拒绝重建。所以要先把残留的 RAID 元数据抹掉：

mdadm --zero-superblock /dev/sdb3

这一步执行后没有任何输出是正常的，可以用mdadm --examine /dev/sdb3再查一次，如果显示No md superblock found，说明已经清干净了。

这里有个容易翻车的细节：如果故障盘是整盘被替换成新盘，新盘连分区都没有，那还要先建分区。群晖的卷一般对应的是/dev/sdb3这种分区设备，不是整块/dev/sdb。如果你拿一块全新硬盘直接mdadm --add /dev/md2 /dev/sdb，大概率不会成功，因为 md 层期望的是分区。

如何给新盘分区？用 fdisk 或者 parted。群晖系统里通常自带 fdisk：

fdisk /dev/sdb

在 fdisk 交互界面里，依次输入g（创建 GPT 分区表），n（新建分区），分区号建议和原来一致，按回车用默认起始扇区，大小上创建全盘分区，最后w写盘。但要注意，群晖默认的数据分区在盘上的位置有特定规律，如果你完全照搬官方原盘的分区布局比较麻烦。一个更省心的办法是：直接用好的那块盘作参考，用sgdisk（如果系统有）把分区表拷贝过来：

sgdisk /dev/sda -R /dev/sdb sgdisk -G /dev/sdb

第一行复制分区表到新盘，第二行随机化新盘的 GUID，防止两块盘因为 GUID 冲突被系统认成同一块盘。没装 sgdisk 的话，可以用 fdisk 手动建分区，然后把分区类型改成 Linux RAID auto（fd）。新建分区不影响后续 mdadm 识别。

3.4 把盘重新加入阵列

现在到了关键一步，把盘加回去：

mdadm --add /dev/md2 /dev/sdb3

正常情况下，这条命令没有输出。随后再敲一次：

cat /proc/mdstat

你会看到类似这样的内容：

md2 : active raid1 sdb3[2] sda3[0] 1953382464 blocks super 1.2 [2/1] [U_] [=======>.............] recovery = 35.2% (688132992/1953382464) finish=184.6min speed=110000K/sec

注意，新加入的盘在[n]里的编号可能不是[1]而是[2]，这很正常，只要它在工作就行。[2/1]表示阵列有 2 个盘位、当前有 1 个可用，后面跟着的[U_]表示一个健康一个在恢复中。

有些情况下mdadm --add不生效，没有任何提示但/proc/mdstat里也没有 sdb3。这时大概率是上一步 superblock 没清干净，回去检查一下。

3.5 等待 rebuild 并监控进度

重建过程取决于硬盘容量和转速。一块 4TB 的盘，从 0 到 100% 通常要 8 到 20 个小时，具体看盘速和系统 IO 负载。重建期间系统负载会明显升高，所有读写都会变慢，这是正常的。

监控进度的方式是：

watch -n 5 cat /proc/mdstat

每 5 秒刷新一次，看 recovery 百分比和 finish 时间。也可以手动读内核参数：

cat /sys/block/md2/md/sync_action cat /sys/block/md2/md/sync_completed

重建过程中不建议重启机器，更不建议拔盘。如果实在需要重启，重启后cat /proc/mdstat一般会自动继续 resync，但保险起见，重启后先看一眼状态，如果卡住了要手动触发：

echo repair > /sys/block/md2/md/sync_action

repair会重置同步状态继续跑，但只有在确认阵列没有新错误时才用。

等到[2/2] [UU]出现，同时mdadm --detail /dev/md2里显示State: clean，重建算是完成了。但别高兴太早，此时还要检查文件系统层是否正常。

3.6 重建完成后，验证文件系统与重新挂载

md 层恢复了，DSM 不一定立刻认账。查看卷对应的实际文件系统类型：

blkid /dev/md2

输出里TYPE="btrfs"或TYPE="ext4"。

如果是 ext4，可以对阵列做只读检查：

e2fsck -f -n /dev/md2

-n表示只检测不修复，确认错误不多再考虑-f -y自动修复。注意：在存储空间已经挂载的情况下不要跑 e2fsck，否则可能把卷搞坏。群晖的卷位置挂载很特殊，通常会自动挂到/volume1，所以如果 DMS 还没认出来，不要急着手动 mount，先确保 md 层全绿，然后重启系统让 DSM 自己重新识别。

如果是 btrfs，查错手段是：

btrfs device stats /dev/md2 btrfs filesystem check /dev/md2

但 btrfs check 在卷已挂载时不能执行，而且--repair参数风险极高，非救援场景不要碰。通常群晖会在 btrfs 元数据出问题时自动修复，如果你的情况是刚重建完，先重启看 DSM 是否自动挂载。

如果重启后 DSM 依然显示存储空间损毁，但/proc/mdstat是干净的 [UU]，那问题大概率在文件系统层，需要用 LiveCD 启动到 Linux 环境做 fsck。不过这是另一个话题，后面常见问题里我会讲排查思路。

4. 实操高频问题与黑群晖专属避坑

4.1 常见报错速查表

把我在实操里遇到过的典型报错整理一下，方便你对照排查。

很多报错表面看是命令执行失败，实际是状态机没到位，比如盘还在阵列里就尝试 add、元数据没清就 add、设备还被 vold 占用就 remove。遇到报错别慌，先用cat /proc/mdstat和mdadm --detail /dev/mdX确认现状，再决定下一步。

4.2 黑群晖的特殊情况：盘序错乱、SATA 控制器、引导参数

黑群晖和原厂群晖最大的区别在于底层硬件不固定，主板上多了各种 SATA 控制器、PCIe 转 SATA 卡、直通卡，导致盘序问题特别突出。开机后/dev/sda可能不是物理上第一个盘位，这直接影响你对阵列成员盘位号的判断。

最稳的做法是用序列号盘位，不要用 sdX 字母。每次操作前执行：

lsblk -o NAME,SERIAL,MODEL,SIZE

记录每个 sdX 的序列号，再和机箱上的盘位进行映射。这个过程很枯燥，但值得花几分钟做，因为整个重建流程中最大风险就是选错盘。

另外一个黑群晖特有问题：引导参数SataPortMap配置不当。如果这个参数没设置对，某些 SATA 控制器端口可能不被识别，导致拔插硬盘后盘序漂移，DSM 和管理层找不到原来的卷。遇到开机后 mdstat 里找不到 md2，但盘上数据完好时，优先检查引导配置，再手动mdadm --assemble。

4.3 如果两块盘都掉线了怎么救

这是个极端情况，但真的会发生。某次异常断电后，系统可能对两块盘都失去信任，md 设备直接显示 inactive 或者干脆不出现。这种时候不要急着--zero-superblock，因为所有盘上的元数据都是宝贵线索。

先用mdadm --examine /dev/sda3 /dev/sdb3看两块盘各自的 superblock 信息，重点看 UUID 和 Events（事件计数）。Events 是阵列每次状态变化时递增的计数器，谁的 Events 大，谁的数据就更新。

正常操作是：

mdadm --assemble --scan --force

如果失败，指定具体设备：

mdadm --assemble /dev/md2 /dev/sda3 /dev/sdb3 --force

--force让 mdadm 相信两块盘能组成阵列，强制组装。但这一步有风险：如果两块盘上的数据本来就不同步，mdadm 只能根据事件计数选择较新的一份，另一份会被当作过期成员丢弃。所以强制组装前，一定要先备份那种看不出来价值却非常重要的文件，单独克隆镜像也可以，但对家用玩家来说，至少要做到“确认两块盘中的一份数据你能接受”。

4.4 重建期间的操作禁忌

重建不是打游戏，没有后悔药。下面这几件事是绝对的红线：

第一，不要在重建过程中拔硬盘。重建期间阵列对故障容错能力极低，拔走健康盘等于让阵列失去全部数据副本。

第二，不要在重建过程中重启系统。如果非要重启，也至少等重建完成或确认 sync 能断点续跑。

第三，不要同时执行两个阵列的重建。有多块盘同时掉线的场景，务必逐块处理。

第四，不要盲目跑btrfs check --repair或e2fsck -y这类带自动修复的命令。文件系统修复工具在错误的时机运行，很可能把原本可读的数据改成不可读。

还有一个小技巧：如果重建速度慢到无法忍受，可以临时提升同步速度参数：

echo 200000 > /proc/sys/dev/raid/speed_limit_min echo 500000 > /proc/sys/dev/raid/speed_limit_max

单位是 KB/s。但这会让磁盘长时间高负载，如果你的盘本来就半死不活，还是会卡住，问题不在速度参数，而是盘本身健康不达标。

5. 修复后的收尾与防复发建议

5.1 重建完成后必做的几件事

等[UU]全绿，第一件事不是去 NAS 上看电影，而是把这几件事做完，才算真正收工。

确认 DSM 存储管理器状态。登录 DSM 图形界面，看一眼存储空间是否已经恢复为“正常”。如果你是在 DMS 提示损毁的情况下走的命令行重建，图形界面刚打开时可能还显示异常，等一两分钟再刷新，它通常会自动同步状态。

做一次完整 SMART 检测。对刚刚归队的那块盘执行：

smartctl -t long /dev/sdb

长检测少则两三个小时，多则十几小时。跑完后用smartctl -l selftest /dev/sdb看检测结果，如果最后一行是Completed without error，这块盘才是真正健康的状态。

顺手把 mdadm 的配置刷新一遍，让系统对当前阵列记录更准确：

mdadm --detail --scan >> /etc/mdadm.conf

群晖系统一般会自动维护这个文件，但手动执行没有坏处，尤其是黑群晖换过引导、插过盘之后。

5.2 让 RAID1 更抗造的日常策略

阵列重建这件事，治标更要治本。吃过一次亏之后，我给自己定了几条规矩，分享出来供参考。

第一，别再裸奔了，RAID1 只是冗余，不是备份。至少把照片、文档、数据库定期同步到另一台机器或者网盘，哪怕是 rsync 单向推送到冷备盘，也比什么都没有强。

第二，加一块热备盘。DSM 支持在存储池里设置热备盘（Hot Spare），只要阵列出现降级，备盘立刻自动顶上并开始重建，把人工干预时间从几小时压缩到几分钟。对不擅长命令行的人来说，这是性价比最高的保险。

第三，定期看 SMART 指标。每个月花几十秒跑一次：

smartctl -a /dev/sda

重点关注Reallocated_Sector_Ct和Current_Pending_Sector，这两个数值只要持续上涨，就是盘在向你告别。

第四，给 NAS 配上 UPS。RAID 重建过程中突然断电，等于把刚缝好的伤口又撕开，而且很可能造成新盘和旧盘的事件计数不一致，让系统重新陷入“不知道该信谁”的状态。

如果你照着这个流程走完了，最后注意一件事：重建完成后，把 DSM 里“存储空间损毁”的历史日志清理或忽略掉，避免之后误判为阵列又有问题。很多人在这一步被误导，反复折腾一个已经健康的阵列。

我在多次手动重建过程中最大的体会是：RAID1 阵列本身并不脆弱，脆弱的是我们对盘位、盘状态、元数据这三样东西的确认习惯。只要每一步都先确认再动手，不靠猜、不靠赌，绝大多数“损毁”都能在命令行下救回来。尤其是黑群晖玩家，命令行的灵活性其实比图形界面高得多，只是要求你用之前，先把每一步的原理想清楚。