一、背景：
2020年9月，公司主要服务器的存储空间RAID5突然降级，恢复过程中RAID重建失败，导致存储空间损毁，开启了一段难忘的故障恢复经历。
故障恢复后，痛定思痛，深刻地认识到数据安全性、可靠性的重要程度，特此写下此篇文章，在已有条件下，重新规划资源，做好日常备份和梳理好故障出现时的操作手册。
我先会回顾故障，列举出一些问题，挨个进行说明讨论，最后从备份和故障恢复2个方面进行总结。
二、发散说说：
1、磁盘阵列（RAID）故障率
磁盘阵列使用得多的还是RAID5，也是在搭建群晖时会被默认推荐的一种RAID，RAID5允许出现某一块成员盘出现物理故障，剩下的成员盘可以利用异或运算计算出故障盘中的数据，提供服务。当RAID5硬盘出现故障时，此时系统管理员会及时替换出现故障的硬盘，对RAID进行修复，如果在修复过程中不幸又有一块硬盘出现了故障，则会导致RAID彻底崩溃。
按照常规的理解，RAID5出现一块硬盘挂掉的概率是n，则同时两块硬盘出现故障的概率是n^2，理论上这个概率是很小的。
实际情况如何呢？
一句话结论：现代大容量硬盘组成的RAID 5单盘故障后，重建失败的概率相当高，不可忽略；但数据本身还是基本安全的（会丢失部分文件），只是可能需要一个比较麻烦的恢复方案。
（具体可参考：raid5 磁盘阵列真的不安全么？ - 木头龙的回答 - 知乎https://www.zhihu.com/question/20164654/answer/348274179）
文章里面提到了两个硬盘的关键参数：MTBF（平均无故障时间）和BER（误码率）导致的URE，误码率是当今RAID技术最大的问题，下面贴出一个直观的RAID重建概率图表（转载自上面的知乎回答）。
（ 现在各家硬盘厂商的Datasheet中通常叫Non-recoverable Read Error rate，网上包括维基通常用Unrecoverable Read Error rate（URE，本文均使用此缩写），也就是[1]所提到的“写入硬盘的数据，在读取时遇到不可修复的读错误的概率”。）
（因为MTBF导致的重建失败概率与URE导致的重建失败的概率相比，这也是一个相当低的概率，所以该表中未体现MTBF导致的重建失败概率）
2、磁盘阵列（RAID）和备份
磁盘阵列能代替备份吗？
不能。重要数据请务必做好备份。
1）、磁盘阵列是可能会发生故障的，一旦发生故障导致了存储空间降级，没有备份就显得很被动了。存储空间降级时，为了避免存储空间进一步被损毁，应该做的是停止服务然后备份。如果你有备份的话，该吃吃该喝喝，等新硬盘到达后，大胆重建RAID。
2）、当发生故障时，我们除了关心数据是否完整以外，更关心的还是中断的服务何时能够恢复。修复RAID是需要时间和耐心，当有一份额外的备份时，我们可以先让备份数据部署运行起来提供临时服务，再慢慢细细地去修复RAID。
3、采用何种备份策略
在说备份策略的时候，我实际上会考虑几个因素：数据完整、物理存储位置、备份频率、恢复服务的时间。
这些因素综合起来组成了可靠性，而往往和可靠性一起需要被考虑到的是成本。
拿我使用的NAS来说，厂商提供了一个高可靠性的套件——High Availability。
关于该套件的介绍：“在集群设计中，活动服务器负责运行所有服务并将数据同步到无源服务器，后者会待机并在活动服务器不可用时接管服务”
简单地说，可以在出现意外事故时提供硬件和数据冗余解决方案，在数分钟内恢复运行。这种方案数据完整、备份频率是实时的、恢复服务的时间为数分钟，堪称完美，但是运行该套件需要两台完全一样的设备，成本需要double。
相比之下，操作性更强的应该是对关键数据进行常规性备份。
网上看到的有数据备份的3-2-1原则，两地三中心的容灾备份方案。
结合我们的实际情况，我思考了一下最适合我们的冷备方案：
1）、本地设备持有完整原始数据；
2）、同一局域网、同一机房下，每日定时备份计划，备份到本地另一台设备；
3）、每日定时备份计划，备份到异地设备；
4、谈谈群晖中的各类备份套件
1）、Hyper Backup
可备份共享文件夹内的文件，备份时可去除重复文件、压缩备份文件大小，备份和还原性能低，备份频率为每天，综上只能考虑作为冷备工具。
2）、Snapshot Replication
快照套件，仅支持Btrfs文件系统，存储效率高、备份和还原性能高，备份频率可配置5分钟（共享文件夹）、15分钟（iSCSI LUN）, 综上可以用作低频热备工具。
3）、USB Copy
适用于USB插入事件触发的复制任务，设备常年在机房，所以基本用不到。
4）、Cloud Sync
适用于与百度云这类的公有云数据进行同步。
5）、Virtual Machine Manager
本地快照
远程复制 （需要购买VMM Pro许可证）
5、公司关键数据分布
1）、Virtual Machine Manager
该套件运行了公司服务器的虚拟机，负责运行公司的CRM系统、医学影像管理系统。
2）、iSCSI Manager
使用该套件为公司关键的机器分配了LUN连接，例如，影像拍摄电脑保存本地影像的Raw、DCM文件，客服电脑保存微信聊天记录等；
3）、File Station
可将重要的存储文件大致分为客户资料、公司管理资料 两大部分。
三、现阶段公司系统的要求
结合现阶段公司的情况，当发生故障导致服务中断时，我们要求：
数据完整不丢失；
能够在10分钟-30分钟内迅速恢复服务；
故障的原因可能有许多：设备的故障、硬盘的故障、感染勒索病毒等；
在没有高可靠性套件High Availability的情况下，我们只能手动去排除故障，恢复服务。需要在短时间内恢复服务，我们需要提前写好故障手册指导我们在遇到故障时，能够处理得仅仅有条。同时，我们也需要定义好各服务的优先级，让我们能够优先恢复那些最迫切需要恢复的服务。
1、服务优先级（服务说明）：
医学影像管理系统>CRM系统>客户资料共享文件>案例搜索器>CRM附加系统>公司管理资料
2、服务优先级（套件说明）：
Virtual Machine Manager>LUN>Java>File Station
四、备份方案
以下均实施：
1、使用Hyper backup 对服务器设备的 DSM配置、关键应用、关键数据文件夹 进行备份。
备份1：主群晖设备（3018xs）网线直通备份群晖设备（918+）, 不加密备份，频率为每天1次；
备份2：主群晖设备（3018xs）通过公网备份到异地群晖设备，进行加密备份，频率为每天1次；
2、使用Snapshot Replication 对服务器设备的关键共享文件夹、iSCSI LUN 进行备份。
备份1：主群晖设备（3018xs）网线直通备份群晖设备（918+）,不使用加密连接复制快照，频率为每5分钟（共享文件夹）、每15分钟（LUN）；
备份2：主群晖设备（3018xs）通过公网备份到异地群晖设备，使用加密连接备份复制快照，频率为每5分钟（共享文件夹）、每15分钟（LUN）；
3、使用Virtual Machine Manager 对虚拟机进行备份。
备份1： 主群晖设备（3018xs）网线直通备份群晖设备（918+）,不启用加密传输复制快照，频率为每5分钟；
备份2： 主群晖设备（3018xs）通过公网备份到异地群晖设备，启用加密传输复制快照，频率为每15分钟；
五、故障手册
做的RAID6
1、硬盘故障
检查挂掉硬盘数，
如果是挂掉一个，检查硬盘情况，根据硬盘情况重新拔插硬盘或更换新硬盘对RAID进行重建；
如果是挂掉二个，检查最新备份情况，及时确认备份无误后，待晚上无人使用时再次确认备份无误且为最新后，根据硬盘情况重新拔插硬盘或更换新硬盘对RAID进行重建；
2、RAID重建过程中出现存储空间损毁
切断用户可访问网络暂停相关服务，启用临时服务（详见第5条）
3、设备故障
联系设备商修理或更换设备，启用临时服务（详见第5条）
4、设备硬盘物理损毁或遗失
启用临时服务（详见第5条），购入设备、硬盘，重组服务
5、启用临时服务
I、影像管理器电脑切换回本地保留路径，不再保存在LUN中；
II、检查最近的虚拟机备份快照，对备份的虚拟机快照进行故障转移，恢复虚拟机服务；
III、改变备用设备IP地址，改成主设备IP地址，进行替换；使用最新的“共享文件夹快照”还原至备用设备中相应路径；由于事先配置好相同账号，此时共享文件夹服务将恢复；
IV、备用设备启动案例搜索器程序，恢复案例搜索器服务；
V、检查部署在外网的应用程序是否能否正常访问到虚拟机中的数据库；
有相同需求、兴趣的朋友，可以加个VX，一起讨论：shaochengchengip
