第一部分 · 速查表（先看这里）
T1 · 级别选型主表
S = 单盘容量，N = 盘数。重建速度一列是相对比较，绝对数值看 T2/T3。
T2 · 重建时间主表（按单盘容量 × 重建速率）
这是全篇最关键的一张表。重建时间 ≈ 单盘容量 ÷ 有效重建速率（校验型的额外开销见 T3）。
数据来源：按容量 ÷ 速率的标准估算模型。实际值受盘型号、阵列负载、控制器影响很大。
速率怎么取：消费级 NAS（群晖 DS / 威联通 TS 系列）轻载时通常 50–100 MB/s，边用边重建会掉到 30–60 MB/s。现代 16–22TB 氦气 CMR 盘外圈能跑 200–280 MB/s、内圈降到 100–140 MB/s，全盘平均约 150 MB/s。
T3 · 各级别的重建开销系数
T2 是"基准时间"，实际还要乘上级别开销。以 4TB 盘、80 MB/s 为基准的实测/估算对照：
12TB 实测组（4×12TB IronWolf + LSI 9300-8i，128KB 顺序写）：RAID 1 8.2h / RAID 10 19.3h / RAID 5 32.7h / RAID 6 58.4h。这组数字很直观地说明：同样 12TB 的盘，RAID 6 的重建窗口是 RAID 1 的 7 倍。
T4 · ZFS resilver 时间
ZFS 的 mirror 只重建已用空间，RAIDZ 必须遍历全部数据，两者差距很大：
社区经验线：resilver 超过 24 小时即视为不安全；OpenZFS 社区建议控制在 12 小时内，生产环境常以 4 小时为目标。这条线意味着——用 20TB 盘做单个大 RAIDZ2 vdev 是危险的，应该拆成多个小 vdev。
T5 · 备份速查（核心）
第二部分 · 恢复时间详解
2.1 为什么重建这么慢
重建不是"把数据拷回来"那么简单，瓶颈来自四处：
必须读全部幸存盘：校验型 RAID 每重建一个条带，都要把该条带在其余所有盘上的块全部读一遍再反算。盘越多，读放大越严重。
校验运算吃资源：RAID 5 算 XOR，RAID 6 还要算伽罗瓦域的 Q，控制器或 CPU 成为瓶颈。
最慢的盘定节奏：整条重建流水线的速度由阵列中最慢的那块盘决定，老盘往往是短板。
业务负载抢带宽：NAS 边重建边跑 Plex、Docker、备份任务，有效速度会掉 30–50%。
另外，硬件限制也会突然冒出来：盘数一多，可能撞上 HBA 带宽上限、电源 12V 轨供电不足或机箱散热导致的降速。
2.2 重建窗口 = 风险窗口
这是理解现代 RAID 选型的钥匙。重建期间阵列处于裸奔状态：
风险分级（按重建时长）：
对照 T2：一块 16TB 的盘在典型 NAS（50 MB/s）上要跑 3.7 天——直接落在危险区。这就是为什么"8TB 以上必须双校验"不是玄学，是算术。
2.3 URE：重建失败的头号杀手
URE（不可恢复读错误）指某扇区重试和 ECC 都读不出来。标称错误率（UBER）：
按 1-(1-UBER)^读取位数 估算的 RAID 5 重建失败概率：
读法：这不是"一定会坏"，是"赌不起"。消费级盘 + 16TB 以上，失败概率接近抛硬币。
2.4 怎么缩短重建窗口
第三部分 · 备份（核心章节）
3.1 RAID 挡得住什么，挡不住什么
一句话：RAID 保的是"服务不中断"，备份保的是"数据还在"。两者的失效场景几乎不重叠。
3.2 冗余 ≠ 备份
这是最容易被混为一谈的一对概念：
判断口诀：冗余是"多份一样的东西放在一起"，备份是"多份不一样时间点的东西放在不同地方"。冗余再多，也不能替代一份备份。
3.3 3-2-1 规则怎么落地
3 份副本：生产数据 1 份 + 本地备份 1 份 + 异地备份 1 份。
2 种介质：比如 阵列（HDD）+ 外置盘/磁带/对象存储，避免同一介质的共性缺陷。
1 份异地：放不同物理位置（另一栋楼、另一城市、云上），防盗窃/火灾/水浸。
每一条怎么算、怎么落地
"3" 怎么算——份数指独立的数据副本数，不是拷贝的份数。
❌ 错误算法：阵列里 4 块盘做 RAID 6 = 4 份？不，这算 1 份（一个阵列 = 一份逻辑数据）。
✅ 正确算法：NAS 上的数据（1）+ 外接 USB 盘的备份（2）+ 云端/异地 NAS 的备份（3）。
"2" 怎么算——介质类型要真的不同。
❌ 同一台 NAS 里两个存储池 = 1 种介质（同一个机箱、同一套控制器、同一份电源）。
✅ NAS 阵列（HDD RAID）+ 磁带/蓝光/云对象存储 = 2 种。
注意：两块外接 HDD 算同一种介质，但如果是"一块本地盘 + 一块异地盘"，靠异地这条独立成立。
"1" 异地怎么算——必须物理隔离。
❌ 同屋的另一个机柜、同一栋楼的另一层（火灾水浸一起完）。
✅ 另一栋建筑、另一城市、云对象存储（S3/OSS/COS）。
异地那份最好同时满足离线或不可变，才能防勒索病毒顺网络爬过去。
扩展规则 3-2-1-1-0
更严格的现代版本，专门针对勒索病毒：
3 份副本
2 种介质
1 份异地
1 份离线或不可变（immutable，写后不可改，防勒索和误删）
0 错误：定期做恢复演练验证，确保备份真的能读回来
3.4 这些"看起来像备份"的东西都不是备份
关键判断标准：如果你的主数据在某个瞬间被全部抹掉或加密，这份"备份"会不会同时遭殃？会 → 不是备份。
3.5 备份策略怎么设计
备份类型：
轮转策略（GFS：Grandfather-Father-Son）：保留每日（近期 7–14 份）、每周（4–8 份）、每月（12 份）、每年若干份，形成时间梯度。这样既能找回"昨天的误删"，也能找回"半年前被覆盖的版本"。
推荐组合（按规模）：
RPO / RTO（定备份频率的关键指标）：
RPO（恢复点目标）：能容忍丢多少数据 → 决定备份频率。RPO=1 小时就要每小时备份一次。
RTO（恢复时间目标）：能容忍多久恢复 → 决定备份介质和架构。RTO=30 分钟就不能用磁带慢慢倒。
3.6 没验证过的备份等于没有备份
必须定期做的三件事：
恢复演练：定期真的恢复一次，确认能读回来。只备份不验证是最常见的翻车点。
完整性校验：用带校验和的工具（Borg、restic、ZFS send），定期校验备份是否可打开。
监控告警：备份失败要有告警。静默失败的备份任务比没有备份更可怕——你以为有，其实没有。
一个残酷的现实：RAID 重建失败后找专业恢复，起步价通常在数千到数万元，且不保证成功。同样的钱，早就够做一套完整的备份方案了。
第四部分 · 原理备查（已懂可跳过）
4.1 三种基本手法
P = D1 ⊕ D2 ⊕ D3
丢 D2 时：D2 = P ⊕ D1 ⊕ D34.2 关键概念速记
4.3 实现层次对比
选型：要数据完整性和快照 → ZFS（配 IT 模式 HBA + ECC）；要简单省心 → 硬件 RAID（务必配 BBU/CacheVault）；资源受限 → mdadm。Btrfs 的 RAID 5/6 有已知问题，避免使用。
4.4 故障应急
掉盘后正确做法：
先判断是真故障还是线缆/背板问题，别急着重建。
拍照记录：盘序、型号、序列号、条带大小、控制器固件版本。
有备份就先复制关键数据出来，再动阵列。
确认新盘健康后替换，重建期间不要跑其他负载。
完成后跑一次完整一致性检查。
⚠️ 别把掉线的盘插回去"重建"：它离线期间其他盘已被改写过多条带，控制器可能误认为它的数据仍有效而不再同步，导致数据不一致。当作新盘走完整重建。
重建失败后的绝对禁忌：
❌ 反复重启重建（已受损的盘扛不住第二遍）
❌ 调换/混插硬盘（盘序绝不能变）
❌ 重置或初始化控制器（会清空配置、覆写数据）
❌ 异常状态下刷固件（可能覆盖元数据）
❌ 在成员盘上直接跑恢复软件（写操作二次破坏）
❌ 照着论坛旧帖子乱试
专业恢复流程：逐盘只读镜像（遇坏道跳过而非中止）→ 分析条带大小/盘序/校验分布 → 虚拟重组 → 文件系统解析导出。核心是"先镜像、后分析、全程只读"。
4.5 运维清单
[ ] 开启定期 scrub/patrol read（机械盘建议每月一次）
[ ] 开启 SMART 监控，关注 Reallocated/Pending Sectors
[ ] 分散采购批次，降低相关性故障
[ ] 配热备盘
[ ] 阵列留 10–20% 余量，别写满
[ ] 接 UPS + RAID 卡配 BBU/CacheVault
[ ] 用支持 TLER/ERC 的 NAS/企业盘
[ ] 备份并归档阵列配置文档
[ ] 旧盘退役前做安全擦除
[ ] 定期做恢复演练（最容易漏的一条）