企业官网建设流程全解析

做运维这行，最怕的不是服务挂了，而是服务没挂、磁盘先满了，或者是磁盘明明还有空间、应用却写不进去。我待过的几个机房里，存储层出事子的频率远高于 CPU 和内存，原因很朴素——CPU 和内存不够，监控一报警你加机器就行；存储一旦规划歪了，扩容要停机、迁移要备份、数据丢了就真没了。这篇内容聊的就是把LVM 逻辑卷管理、磁盘配额、RAID 磁盘阵列这三样东西捏在一起用的一套完整打法：从几块裸盘开始，做出一个既有冗余、又能弹性扩容、还能限制单个用户乱占空间的存储目录，最后跑通一整套配置流程。适合正在管服务器、准备上线新业务目录、或者被"磁盘满了但文件删不掉"这类问题折磨过的朋友。不管你是刚接触 Linux 存储的新手，还是已经用过 mdadm 但没系统串过 LVM 的老人，下面这些踩坑记录和参数取舍应该都能直接抄。

1. 整体方案设计与选型思路拆解

1.1 三套技术各自解决的是哪一类问题

很多人第一次接触这三个名词时会犯迷糊，觉得它们功能重叠，实际上分工非常清楚。RAID 解决的是"盘坏了数据还在不在"，它站在物理磁盘这一层，把多块硬盘组成一个逻辑设备，通过镜像或者校验码实现冗余，顺带提升一点读写吞吐。LVM 解决的是"空间不够了能不能不停机加"，它站在块设备这一层，把一块或多块物理设备（包括 RAID 阵列）抽象成卷组，再从卷组里切逻辑卷，逻辑卷可以随时变大、跨盘分布。磁盘配额解决的是"这台机器上多个用户共用一块盘，怎么防止某一个人把空间吃光"，它站在文件系统这一层，按用户、组或项目维度限制 inode 数量和块数量。

这三层叠起来，逻辑是这样的：底层硬盘做成 RAID 阵列保证不丢数据，阵列交给 LVM 变成可伸缩的卷组，逻辑卷格式化成文件系统挂到业务目录，最后在文件系统上开配额限制使用者。缺任何一层都会留下短板——只有 RAID 没 LVM，扩容得重新做阵列；只有 LVM 没 RAID，一块盘挂了整个卷组跟着废；两者都有但没配额，一个失控的日志进程就能把整台机器的写入堵死。

1.2 为什么要在同一套环境里叠加使用

我见过两种极端的做法。一种是什么都上，八块盘做 RAID6，上面套三层 LVM，再开项目配额，结果一台机器光存储配置就写了一百多行文档，后来扩容时没人敢动。另一种是什么都不上，四块盘各自挂载，应用自己往 /dev/sdb1 里写，盘一坏数据全没，还找不回来。

合理的做法是按数据重要性和增长预期来决定层级。我一般的判断标准是：数据丢了业务会停摆超过半天，就必须上 RAID；目录容量未来一年内预计增长超过 50%，就套 LVM；这块盘上有三个以上不同的使用者（不同的系统用户、不同的业务模块、不同的项目组），就开配额。三条都命中的场景其实很常见，比如日志归档目录、数据集存放目录、多租户的共享存储，这时候三层叠加才有意义。

1.3 环境与硬件选型的几个实际考量

盘的选择上，做 RAID 的硬盘尽量同型号、同容量、同批次，转速一致。原因不是玄学，是阵列的可用容量取决于最小那块盘，而重建速度取决于最慢那块盘，混插会让整个阵列的性能被拖到地板。我有一次图省事，拿两块 4T 和一块 2T 拼了个 RAID5，结果可用容量只有 4T，白白浪费了一块盘的空间。

系统层面，mdadm负责软 RAID，主流发行版的软件源里都有，不用额外编译。LVM2 工具包同理。配额这块要注意文件系统的差异：ext4 用usrquota,grpquota挂载参数配合quota系列命令；XFS 用uquota,gquota（或者等价的usrquota,grpquota）配合xfs_quota，两套命令完全不通用，别记混。

提示：如果业务目录已经存在且正在被写入，改文件系统类型或者加配额参数都需要重新挂载，这一步会短暂中断写入。上线前规划好，比事后补救省十倍力气。

2. RAID 磁盘阵列的级别取舍与建阵实操

2.1 RAID 0/1/5/6/10 到底怎么选

选级别本质是在"容量、性能、冗余"这三个值之间做减法，没有全能选手。我把常用级别的实际表现整理成一张表，都是实机跑出来的体感，不是理论值：

容量算法要记牢：RAID5 有效容量 =（盘数 − 1）× 最小盘容量；RAID6 =（盘数 − 2）× 最小盘容量；RAID10 = 盘数 ÷ 2 × 最小盘容量。举例，四块 8T 盘：RAID5 得 24T，RAID6 得 16T，RAID10 得 16T。同样是 16T，RAID6 抗两块盘同时坏，RAID10 抗的是不同镜像组各坏一块，后者在重建时压力小得多，所以数据库类场景我几乎一律推 RAID10。

单盘容量超过 4T 的时候，我要多说一句：RAID5 的重建时间会非常长，一块 8T 盘做全量重建，机械盘动辄十几个小时，这段时间阵列处于降级状态，再坏一块就全没了。所以大盘我更倾向 RAID6，宁可少一块盘的容量，也要把重建期间的风险窗口堵上。

2.2 mdadm 建阵的完整命令与参数解释

假设机器上有四块空闲盘/dev/sdb、/dev/sdc、/dev/sdd、/dev/sde，各 8T，准备做 RAID5。第一步一定是确认盘没被占用，lsblk看一眼，有没有残留的分区表或者旧阵列成员标记。旧阵列残留是最常见的坑，mdadm --create会直接拒绝，报设备正忙。

清理旧标记用这条：

mdadm --zero-superblock /dev/sdb

四块盘都要跑一遍，报"Couldn't open"这类错误可以忽略，说明本来就没有超级块。接着建阵：

mdadm --create /dev/md0 \ --level=5 \ --raid-devices=4 \ --chunk=512 \ --bitmap=internal \ /dev/sdb /dev/sdc /dev/sdd /dev/sde

几个参数值得展开说。--chunk=512是条带大小，单位 KB，默认 512K。这个值决定了单次 I/O 落在几块盘上：业务以大文件顺序读写为主（备份、视频、日志归档），chunk 大一点更划算，512K 到 1M 都行；业务以小文件随机读写为主（数据库、大量小文件），chunk 小一点，128K 甚至 64K，让 I/O 能分散到更多盘上。设错了不会崩，但性能会打折。

--bitmap=internal是写意图位图，作用是阵列非正常关机后只重建脏块，不用全量同步。不加这个参数，一次意外断电就可能触发十几个小时的完整重建。代价是位图会占用阵列末尾一小块空间，几百 MB 级别，完全值得。

建完立刻用cat /proc/mdstat看状态，会看到[UUUU]和resync进度。同步期间阵列可用，但性能下降，如果业务已经在线，可以限速：

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

单位是 KB/s，200000 大约是 200MB/s。这个值调太低同步会拖很久，调太高会抢占业务 I/O，我一般设在磁盘顺序写带宽的 60% 左右。

2.3 阵列的持久化、状态监控与坏盘替换

建完阵列还有一步绝对不能漏：把阵列信息写进配置文件，否则重启后阵列名可能变化，/dev/md0变成/dev/md127，挂载直接失败。

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

这行输出大致是ARRAY /dev/md0 metadata=1.2 name=hostname:0 UUID=xxxx，UUID 是识别关键，别手抄，一定要用命令生成。写完重启验证一次，mdadm --detail /dev/md0能正常输出才算过。

日常巡检我主要看两个地方。cat /proc/mdstat一眼看健康度，[UUUU]全 U 正常，出现_就是有盘掉了或者被标记失败。mdadm --detail /dev/md0看细节，重点看State、Active Devices、Failed Devices三个字段。

盘真坏了怎么换？流程是标记失败、移除、拔盘、插新盘、添加、等重建：

mdadm --manage /dev/md0 --fail /dev/sdc mdadm --manage /dev/md0 --remove /dev/sdc # 物理更换后 mdadm --manage /dev/md0 --add /dev/sdc

新盘加进去会自动开始重建，/proc/mdstat里看到recovery进度条就是在干活。这时候千万别手贱去重启或者做别的重 I/O 操作，重建期间阵列最脆弱。

注意：换盘时新盘的容量必须大于等于原盘，否则--add会被拒绝。我遇到过一次，采购回来的"同型号"盘实际容量少了几个扇区，加不进去，白折腾一下午。买盘时核对一下blockdev --getsize64的输出。

还有一个容易被忽略的细节：软 RAID 的盘如果被fdisk或者分区工具动过，超级块会被覆盖，阵列就认不出来了。平时操作块设备前，先确认这块盘是不是阵列成员，lsblk -o NAME,SIZE,TYPE,MOUNTPOINT看清楚再动手。

3. LVM 的三层结构与弹性扩容实战

3.1 PV、VG、LV 到底谁是谁

LVM 的概念第一次看会觉得绕，我用一个生活化的类比：物理卷 PV 是砖头，卷组 VG 是砌好的墙，逻辑卷 LV 是从墙上凿出来的房间。砖头可以是一整块盘，也可以是 RAID 阵列，甚至可以是阵列上的一个分区。墙把所有砖头粘成一个连续的存储池，容量相加。房间从池子里划，划多大自己定，后续墙里还有空间就能继续把房间扩大。

三层里最关键的单位是PE（Physical Extent），默认 4MiB，是 LVM 分配空间的最小粒度。也就是说你划一个 10G 的逻辑卷，实际占用的是 2560 个 PE（10240 ÷ 4）。这意味着逻辑卷大小永远是 4MiB 的整数倍，lvcreate -L 1G没问题，-L 1000M会被向上取整。PE 大小可以在vgcreate时用-s指定，8M、16M、32M 都支持。PE 设大一点，卷组能管理的最大容量更大，元数据开销更小；PE 设小一点，碎片更少。一般业务场景默认 4M 就够用，除非你要做几十 TB 的超大卷组。

3.2 从阵列到可用目录的创建流程

接着上一节的 RAID5 阵列继续。第一步把阵列变成 PV：

pvcreate /dev/md0

然后建卷组，起个有意义的名字，别用默认的vg00，后期机器一多根本分不清：

vgcreate data_vg /dev/md0

接着划逻辑卷。这里有个实操建议：不要一次性把卷组空间全划完。四块 8T 做 RAID5，卷组可用约 24T，我只划 20T 给业务用，留 4T 在卷组里当缓冲。原因是逻辑卷扩容只能往大了扩、且有空间才能扩，一旦划满，后续想给某个卷加点空间就得先缩别的卷，而缩容比扩容危险十倍。

lvcreate -L 20T -n data_lv data_vg

格式化。这里的选择会影响后面配额怎么配：XFS 扩容方便、不支持缩容，适合只增不减的业务目录；ext4 扩缩都支持，适合容量需要来回调整的场景。

mkfs.xfs /dev/data_vg/data_lv

挂载到业务目录，/etc/fstab里写 UUID 而不是设备路径，理由和 RAID 一样，设备名可能变：

mkdir -p /data blkid /dev/data_vg/data_lv # 拿到 UUID

fstab 里加一行：

UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx /data xfs defaults 0 0

3.3 在线扩容：最常用的操作，也是最容易做错的操作

扩容分两种场景。卷组里还有空间，直接扩逻辑卷：

lvextend -L +2T /dev/data_vg/data_lv

卷组里没空间了，得先加 PV。物理上插一块新盘，做成 PV 加进卷组：

pvcreate /dev/sdf vgextend data_vg /dev/sdf

然后照常lvextend。加 PV 这一步是 LVM 最大的价值所在——整个过程业务不用停，文件系统不用卸载，数据不用迁移。

lvextend之后逻辑卷变大了但文件系统还没变大，这是新手最容易漏的一步。df -h看容量没变化就是因为这个。补上文件系统扩容：

# XFS xfs_growfs /data # ext4 resize2fs /dev/data_vg/data_lv

新版 LVM 支持一条命令搞定，加-r参数自动 resize 文件系统：

lvextend -L +2T -r /dev/data_vg/data_lv

我现在的习惯是一律带-r，少一步就少一个忘掉的机会。实测下来这条命令在 XFS 和 ext4 上都很稳。

3.4 缩容这件事，能不做就不做

lvreduce是 LVM 里风险最高的操作，做错一步就是文件系统损坏、数据全丢。顺序必须是：先卸载、先检查文件系统、先缩文件系统、再缩逻辑卷，一步都不能颠倒。

XFS 根本不支持缩容，硬缩就是数据毁掉。遇到 XFS 要缩，只有一条路：备份数据、删卷重建、导回数据。ext4 可以缩，但流程严格：

umount /data e2fsck -f /dev/data_vg/data_lv resize2fs /dev/data_vg/data_lv 15T lvreduce -L 15T /dev/data_vg/data_lv

e2fsck -f是强制检查，不能省，跳过这一步resize2fs会拒绝执行。而且resize2fs的目标值必须小于当前文件系统大小、大于已用空间，lvreduce的目标值必须大于等于缩完的文件系统大小，两个值留一点余量，别卡得刚刚好。

提示：我给团队定的规矩是"缩容必须两人复核、必须先有完整备份"。单个操作失误的代价是整块盘的数据，不值得为省几块盘的空间去赌。

3.5 快照：LVM 一个被低估的能力

LVM 还有一个很好用的功能是快照，原理是写时复制：创建快照的瞬间不复制数据，只记录原始卷的块映射，之后原卷被修改的块才会复制到快照空间里。所以快照空间不用给太大，一般给原卷的 10% 到 20%，够撑过一次备份窗口就行。

lvcreate -L 200G -s -n data_snap /dev/data_vg/data_lv

典型用法是备份前打快照，然后把快照挂到临时目录慢慢拷，原卷该写就写，互不干扰。快照满了会自动失效，所以备份任务结束后记得及时删掉，lvremove /dev/data_vg/data_snap。

4. 磁盘配额的实施细节与验证方法

4.1 开配额之前必须先确认的三件事

配额不是想开就能开，动手前得确认三件事，少一件都会白忙活。

第一，文件系统类型决定命令体系。前文提过，XFS 和 ext4 两套命令完全不通用。quota、repquota、edquota是 ext 系列的工具，xfs_quota是 XFS 的。在 XFS 上跑repquota会报"不支持"。

第二，挂载参数必须带上配额标志。XFS 用uquota,gquota，ext4 用usrquota,grpquota。这一步写在/etc/fstab里，然后重新挂载生效。已经挂载的目录改参数必须 remount，mount -o remount /data就行，不用卸载，写入会短暂中断几秒。

第三，配额对 root 用户无效。这是设计如此，root 是超级用户，任何限制都拦不住。所以配额要针对普通业务账号配置，用 root 跑业务进程的机器开配额基本没意义。

4.2 XFS 环境下的配额配置全流程

假设业务目录是/data，要给几个业务账号分别限制空间。第一步改 fstab：

UUID=xxxxxxxx /data xfs defaults,uquota,gquota 0 0

重新挂载并确认：

mount -o remount /data mount | grep /data

输出里能看到uquota,gquota就说明生效了。接着给具体用户设限额：

xfs_quota -x -c 'limit -u bsoft=500g bhard=550g user1' /data

bsoft是软限制，bhard是硬限制。软限制触发后系统只警告不拦截，同时启动一个宽限倒计时（默认 7 天），倒计时内不降到软限以下就升级成硬拦截；硬限制是直接拒绝写入，超过就报Disk quota exceeded。这两个值之间的间隔我一般留 10%，给用户留出清理的缓冲。

除了块限制，还有 inode 限制，对应参数是isoff、ihard：

xfs_quota -x -c 'limit -u isoft=100000 ihard=120000 user1' /data

inode 限制容易被忽略但很关键。一个用户可能只占了 1G 空间，但里面塞了一百万个小文件，把文件系统的 inode 耗尽，其他用户一个文件都建不了。这种情况在日志目录、缓存目录上特别常见，光限块数拦不住。

批量配置的话，把限额写进一个文件，用-c一条条喂进去更省事：

xfs_quota -x -c 'limit -u bsoft=500g bhard=550g user1' /data xfs_quota -x -c 'limit -u bsoft=200g bhard=220g user2' /data

4.3 ext4 环境下的配额配置流程

ext4 的流程稍微绕一点，因为要先quotacheck生成配额文件。fstab 改成：

UUID=xxxxxxxx /data ext4 defaults,usrquota,grpquota 0 0

重新挂载后生成配额数据库：

quotacheck -cum /data

-c创建、-u用户、-m强制（文件系统已挂载时必需）。然后开启配额：

quotaon -vug /data

给用户设限额用edquota，它会打开一个编辑器界面：

edquota -u user1

界面里blocks和inodes各有 soft 和 hard 两列，blocks默认单位是 KB，要写 500G 就是524288000，容易算错。我一般先用edquota -p user1 user2 user3复制一个模板，再单独微调，比每个都手算省事。

批量查看用repquota -aug，输出是一张表，各用户的已用量、软硬限、宽限状态一目了然。quota -u user1查单个用户。

4.4 配额的验证方法与告警设计

配完必须验证，不能配完就完事。最直接的办法是用被限制的账号往目录里写大文件，dd if=/dev/zero of=/data/test.bin bs=1M count=600000，超过 550G 的时候应该报错。注意要在被限制的用户下执行，root 跑不受限。

查看当前状态：

xfs_quota -x -c 'report -h' /data

-h是 human readable，输出是 G、M 单位，比原始字节数好读太多。-u只看用户，-g只看组，-i看 inode。

告警这块，配额本身不会主动通知你，得自己配。我一般写个定时任务扫报告，把超过软限 90% 的账号抓出来发通知：

xfs_quota -x -c 'report -h -u' /data | awk 'NR>4 && $2 ~ /[0-9]/ {print}'

实际脚本里还要做数值比较和去重，这里只给思路。重点是软限是预警位，硬限是兜底位，靠软限在用户把盘写爆之前把人叫醒，别等硬限触发才知道出事。

注意：宽限期可以改。默认 7 天，xfs_quota -x -c 'timer -u -b 3days' /data改成 3 天。设太短会让正常用户频繁踩线，设太长等于没设，3 到 7 天比较合理。

5. 三层技术串联的完整实战与容量规划

5.1 从裸盘到可用目录的完整工序

把前面的步骤串成一条完整的工序线，这是实际交付时我照着跑的清单。

第一步，清盘查状态。lsblk确认四块目标盘无挂载、无分区、无阵列标记。有旧标记就mdadm --zero-superblock清掉。

第二步，建 RAID5 阵列。mdadm --create /dev/md0 --level=5 --raid-devices=4 --chunk=512 --bitmap=internal /dev/sd{b,c,d,e}，然后cat /proc/mdstat确认同步开始。

第三步，持久化阵列配置。mdadm --detail --scan >> /etc/mdadm.conf，重启后阵列名必须还能对上/dev/md0。

第四步，创建 PV 和 VG。pvcreate /dev/md0、vgcreate data_vg /dev/md0，pvs、vgs确认结果。

第五步，划逻辑卷。卷组 24T 只划 20T，lvcreate -L 20T -n data_lv data_vg，lvs确认。

第六步，格式化并挂载。mkfs.xfs /dev/data_vg/data_lv，blkid拿 UUID，写 fstab，mount -a验证。

第七步，开配额。fstab 加uquota,gquota，mount -o remount /data，xfs_quota -x -c 'limit ...'逐个配置。

第八步，验证。用测试账号跑 dd 打满，确认硬限生效；xfs_quota -x -c 'report -h' /data看报告正常；reboot一次确认所有配置能自动恢复。

第八步的reboot验证千万别省。我吃过一次亏，fstab 里 UUID 抄错一位，当场没问题，第二天机房断电重启，机器直接卡在紧急模式起不来，一堆业务停了两小时。

5.2 容量规划的计算过程与余量设置

规划容量不是拍脑袋，得按公式算。以四块 8T 盘、RAID5、XFS、配额为例：

RAID 层可用容量 =（4 − 1）× 8T = 24T。文件系统元数据和日志占用大约 2% 到 5%，实际可用约 22.8T 到 23.5T。LVM 划 20T，卷组里留 4T 缓冲。20T 里给配额分配，假设五个业务账号：两个各 500G、两个各 2T、一个 10T，合计 15T，剩下 5T 是公共空间和其他用途。

这个分配里有两处余量。卷组余量 4T用于后续哪个账号超了能临时扩容，不用重新规划整块盘。文件系统余量 5T保证硬限加起来不会真的把盘占满——如果五个账号的硬限加起来正好等于 20T，那五个账号同时写满的时候文件系统会最先崩，配额还没来得及拦。我给的经验值是：所有硬限之和不超过文件系统容量的 85%。

还有一块经常被算漏：RAID 重建时的性能衰减。RAID5 降级状态下读性能基本不变，但写性能会掉到 30% 左右，因为每一笔写都要重算校验码。所以业务高峰期的磁盘使用率我一般控制在 70% 以内，留 30% 给重建和突发。

5.3 一块盘坏掉之后的完整处理流程

这是整套方案的实战检验。假设某天巡检发现/proc/mdstat显示[UUU_]，/dev/sde掉了。

先看细节确认是盘挂了还是被误标记：

mdadm --detail /dev/md0 dmesg | grep -i sde

dmesg里如果有大量 I/O 错误、超时、复位信息，基本就是物理故障。确认后按流程换盘。换的过程中业务不受影响，阵列降级但照常读写，只是性能下降。

新盘插上后，lsblk确认识别到，mdadm --manage /dev/md0 --add /dev/sde加回去，看着/proc/mdstat的 recovery 进度跑完。8T 盘大概要几小时到十几小时，视磁盘速度而定。这段时间里我建议把非关键的大 I/O 任务（批量备份、日志归档）推迟，把重建带宽让出来。

重建完成后mdadm --detail /dev/md0的State应该回到clean，Active Devices : 4，Failed Devices : 0。如果想主动扫一遍全盘有没有潜在坏块：

echo check > /sys/block/md0/md/sync_action

这个动作只读不改数据，比 repair 安全，适合作为例行巡检。

5.4 扩容的两种路径与执行时机

扩容路径一：卷组有余量。直接lvextend -L +2T -r /dev/data_vg/data_lv，秒级完成，业务无感。

扩容路径二：卷组没余量。这一步要动硬件，流程是插新盘、pvcreate、vgextend、lvextend -r。其中vgextend会做一次元数据写入，但也不影响正在读写的逻辑卷。

两种路径都建议放在业务低峰做。虽然理论上在线，但xfs_growfs在大文件系统上会花几分钟，期间元数据锁有一定影响。我的习惯是凌晨两点窗口执行，扩完立刻df -h和xfs_quota -x -c 'report -h' /data对一遍数。

6. 常见问题与排查技巧实录

6.1 高频问题速查表

下面这张表是我这几年攒下来的，基本都是真出过的问题：

6.2 几条用血换来的避坑经验

第一条，别信"这块盘不会坏"。我经手的机器里，硬盘故障是最高频的硬件问题，比内存、电源高一个数量级。做阵列的时候多买一块同型号的冷备盘放机柜里，坏盘直接换，比等采购流程快三五天。冷备盘不用插上去，闲置状态就行，插上去反而增加运行时间。

第二条，fstab 里别写设备名。/dev/sdb这种名字会随插拔顺序变化，/dev/md0会随组装顺序变化，/dev/data_vg/data_lv相对稳一点但也不绝对。大写特写：一律用 UUID。blkid拿一遍，抄进去，mount -a验证通过，再重启验证一遍。

第三条，配额一定要限 inode。我见过一个案例，某台机器的/var/log分区只用了 8% 的空间，但 inode 用了 99%，因为里面堆了几百万个小日志文件，结果所有服务都写不进日志。块限制拦不住这种情况，必须把 inode 硬限一起配上。巡检的时候df -i和df -h要一起看。

第四条，软限和硬限要留间隔，硬限总和要留余量。软硬限贴在一起，用户踩线就直接被拒绝，没有任何缓冲清理时间，体验极差。硬限总和等于盘容量，配额就形同虚设，因为盘先满了。这两个数值得一起算。

第五条，阵列降级不等于安全。降级状态下数据还在，但已经失去冗余了。这时候如果再来一次意外断电导致阵列不同步，或者另一块盘也出问题，数据就可能救不回来。所以发现降级要立刻安排换盘，别抱着"还能用先用着"的心态拖，我见过拖了两周然后第二块盘也坏了的，最后靠备份恢复，损失了两天的增量数据。

第六条，备份策略和 RAID 是两回事。RAID 防的是硬件故障，防不了误删除、防不了文件系统损坏、防不了人为误操作。rm -rf下去，RAID 会忠实地把每块盘上对应的数据都删掉。所以配额、RAID、LVM 这三样配好之后，备份还得单独做，这是另一个话题，但别把它们混为一谈。

第七条，配置文档要跟着改。每次扩卷、加盘、改配额，都要同步更新文档。我接手过一台别人留下的机器，卷组里有一块盘的 PV 是在哪台设备上都没记录，pvs显示/dev/sdf但实体机上找不到对应位置，最后是拆开机箱一块块看序列号对出来的。文档这件事平时不起眼，出问题时能救命。

6.3 一套可复用的巡检脚本思路

日常巡检我不用逐个命令敲，写个脚本一次出结果。核心就几个检查点：cat /proc/mdstat看阵列状态里有没有_；mdadm --detail看Failed Devices是不是 0；pvs、vgs、lvs看三层有没有异常标记；df -h和df -i一起看使用率；xfs_quota -x -c 'report -h'看有没有账号接近或超过软限。

脚本输出我要求做到"一眼判生死"：全部正常就打印一行 OK，有异常就把异常项和对应命令打出来。定时任务每小时跑一次，异常就发告警。这套东西搭起来大概半天，但能把"磁盘悄无声息地满掉"这类事故拦在发生之前。

实际配置的时候，我最大的体会是：这三样技术单独学都不难，难的是搞清楚它们之间的边界和顺序。RAID 建好才能给 LVM，LVM 挂好才能开配额，顺序错了就得推倒重来。另外就是老老实实做重启验证，配置写完不重启就当没写完，这个习惯帮我躲过好几次深夜被叫起来处理开机故障的场面。