GitLab事件思考:是否用的快照恢复?

本文内容非商业用途可无需授权转载，请务必注明作者、微博ID：唐僧_huangliang，以便更好地与读者互动。

关于GitLab的rm –rf误删数据库事件，这两天我看了不少国内同行朋友、媒体写的分析和报道，不知国外对此事是否也同样热闹？

另一方面我也看到几位冷静的技术友人，对这类故障引发的刷屏有些感到不屑。事实上到目前为止，尽管看过各方面多角度的详实描述，我还没能完全确定GitLab的恢复是否用了快照技术。为什么这么说呢？

-第一阶段：人们讨论的中心是5种备份都没生效。于是我刚看到点信息时，闲聊中也说过备份管理员估计要下岗：）后来大家也都知道了，GitLab根本没有专职的备份管理员，甚至运维的人力也非常有限，以至于操作流程不规范。

-第二阶段：数据恢复了，丢失了6个小时。尽管该时间正好与最后一次手工LVM快照的时间点相仿，而且也有人认为就是这个操作救的命。但GitLab却并未明确写db1.staging.gitlab.com是来自LVM快照（经过与朋友的确认，这个中间阶段数据库更像是逻辑复制生成），虽然他们公布了此次故障前后的详细处理过程。

在这最关键的部分，却没看到有谁完全讲清楚，不能不说有点遗憾。我的翻墙技术和英文水平有限，知道在这个时候写东西不一定受欢迎，但还是想抛砖引玉。根据之前我写过2篇同类分析的感受，整理思路本身也是个学习的过程，而且有些不足还会收获到友人的指点和纠正。

前事不忘

《Salesforce曝数据丢失原因：存储阵列固件bug？》——当时写这个，主要想澄清不是因为存储导致的数据丢失。Oracle数据库压力过大I/O超时本身就可能“写坏”数据文件，有朋友指出如果配置了DataGuard，损坏的页面会被物理复制到备库，如果没开Flashback闪回就悲剧了。所以我们看到Salesforce事后表示要增加逻辑复制。

《炉石传说故障另类分析：这锅RAID卡电池背吗？》——写这个之前看到同行的预判，以为是MySQL+本地存储；后来盖老师的分析更靠谱，应该是Oracle+EVA存储。我只想解释下如今RAID卡BBU技术发展到什么水平，而如果是太老的设备，电池还是有失效需要更换的时候。

后事之师

GitLab的rm –rf敲错了机器，确切说是选错了命令行终端窗口。那么怎样做才能更好地避免这种人为失误呢？

我们看到GitLab自己提出的改进措施中包含下面几条：

“为不同的环境改变Linux终端的格式或者颜色，例如红色代表生产环境，黄色代表测试环境。针对所有用户在shell提示符处显示机器的完整名字，例如db1.staging.gitlab.com，而不是仅仅是“db1”。”

“针对postgresql的文件夹拒绝执行rm -rf这样的命令？可以设置命令执行保护或者针对数据库文件夹有对应的备份措施。”

“每小时执行一次LVM快照（Hourly LVM snapshots of the production databases，https://gitlab.com/gitlab-com/infrastructure/issues/1098）”

1、人肉运维的风险和预防

首先我不是运维专家，只是简单讨论下前面这2条。有人在这时强调自动化运维的好处，而在我来看程序和脚本也都是人写的，也需要复核、测试以及维护。说句不好听的，如果某个人的操作权限特别大，把脚本改乱了也有可能吧。因此，在这里我更多想到的是流程，比如许多容灾都能做到自动切换，但实际配置还是手动。除了怕误切之外，还有的要领导签字，一般人担不起这个责任。

如果有流程，规定执行某些高危操作之前，确认下操作的主机是很基本的要求吧？这样要求没错，但是如果只有一个人执行，漏洞还是明显的，谁都无法保证自己头脑总是特别清醒。

一位前同事去了阿里云，有回听他说做一次代码的变更，需要3个人一起才能组合出完整的密码。2个人不够吗？记得08年我参与一次数据库的迁移，手工敲15个LUN的dd命令（当时是Oracle 10G裸设备），旁边一位兄弟帮着看。由于加班和停机时间有限，最后他觉得这样我们两个都紧张索性让我自己搞了。如果再多一位呢？每人所担的责任又会小一些，当然即使这样也无法彻底杜绝出错。

所以我看到有位朋友说的好——“鲁棒的系统和规范的操作是基础”，就是即使3个人都出错了，也还要设计有恢复的手段。

2、快照不是备份

根绝@左耳朵耗子在《从Gitlab误删除数据库想到的》一文中所写：“最终，gitlab从db1.staging上把6个小时前的数据copy回来，结果发现速度非常的慢，备份结点只有60Mbits/S，拷了很长时间（陈皓注：为什么不把db1.staging给直接变成生产机？因为那台机器的性能很差）。”

如果按照这个理解，db1.staging应该是备机上的备库，至少不是生产机本地的LVM快照。而根据另外一些报道，GitLab在故障前6小时创建LVM快照是用于预发布环境。我对LVM快照的理解不够深入，下面以商业存储（阵列）的思路来讨论下。

首先，快照不代表备份，除非对生成的快照进行过复制或者备份。否则我们只有一份数据，并且它最擅长的就是恢复逻辑错误（也包括rm -rf）。

其次，快照有个好处就是可以立即挂载验证，也支持快速回滚。为了保护现场或者出现意外，在回滚之前也可以再打个快照。当然这里如果安全要求更高，或者阵列有坏盘/电池失效工作在降级状态，先做一个物理上隔离的备份还是有必要的。而我们看到GitLab在恢复前对备机上的库先做了备份（Backupdb1.staging.gitlab.com data），此时也没有说使用生产机本地的LVM快照。

3、快照的一致性问题

就像在讨论复制/双活技术的时候，有些人认为基于存储实现无法保证一致性那样，快照也面临类似的问题。这大致属于企业存储的常识性问题，一致性可以从两个角度来看。

A．多个卷（LUN）之间的时间点一致性：试想一下，如果数据库的数据文件和日志文件放在不同的存储卷上，而它们的快照不是严格在同一个时间生成，这样能够正常恢复数据吗？如果是Oracle Redo log比data的时间较新或许还有办法，但这种情况还是应尽量避免。

如今的中高端存储阵列已经普遍支持快照一致性组。

B．快照数据的应用一致性：如果没有特别的一致性处理，快照状态可能不是在一个完整交易结束时生成，此时就像服务器断电/宕机后的数据库存储状态相似。所幸这种情况大多数可以修复，可能会丢少量数据，只要不是运气特别不好的话。

当然，存储厂商们也想出了更好的应对方式：

以上面示意图为例，位于RAC服务器节点上的APM（Application Protection Manager）agent就是Dell SC阵列快照功能的Oracle数据库一致性代理程序。

当管理节点上的APM Orchestrator发出快照指令时，数据库服务器缓存中的脏数据落盘，在存储阵列生成快照的瞬间短暂冻结写入，完成后恢复正常。这对于应用数据快照的可恢复性有很大帮助。

4、快照的性能问题

快照的好处不少，但是却有许多用户没有打开，其中一个主要原因就是怕影响性能。

早期的存储快照，较多采用了左边的COFW（Copy on First Write）方式，LVM快照也属于这一种。COFW实现比较简单，当对快照保护的数据块写入时，需要有一个拷贝的过程，增加了2次I/O，此时对性能影响比较明显。

至于右边的ROW（Redirect on Write）快照，有点像WAFL和ZFS文件系统的原理，新数据不覆盖原有快照数据块直接写到新位置，同时修改元数据指针。这种方式可能带来的问题就是打乱数据的顺序布局，可能会影响读性能，同时元数据维护量增大。

上图引用自Dell EMC World 2016大会资料。VMAX在打了1,000份快照之后，Oracle数据库仍然没有明显的的性能影响，表明SnapVX在这里使用的是ROW快照技术。

我想在这里强调的一个关键是“全闪存”，SSD的随机读和顺序读性能相差无几，所以All Flash配置是不是就不用再担心ROW快照的性能影响了？

值得注意的是，EMC高端VMAX、中端Unity/VNX上的Pool LUN还是基于传统的RAID技术改良，不是真正的宽条带化（RAID 2.0）。像Dell SC等底层细粒度打散的宽条带化RAID技术，其元数据设计能够轻松支持更多的数量的快照。（Unity也标称支持16,000个快照，我在去年的《EMC World：新统一存储Unity把硬件做到极致？》一文中提到过）

在实际应用中，个人认为单一LUN数百个/存储系统总共数千-上万个快照支持，应该能够满足大多数需求。

5、快照的容量开销与应对

快照保留的历史数据越多，额外占用的容量就越大，这一点也要在存储配置规划时考虑进去。比如预估每次快照之间的数据变化量，结合保留时间计算一下。

在如今闪存价格还不算便宜的情况下，我想给大家提出一个参考思路：

上图本身介绍的是Dell SC存储的数据压缩功能——最新的版本支持主存储压缩，也就是中间“被快照冻结并用于读访问”的浅绿色部分数据页面（Frozen accessible data pages）。而在SCOS 6.7之前更早引入的是冷数据压缩，橙色的Frozen inaccessibledata pages就是那些被主机写I/O覆盖过的历史快照数据块，我画了一个圈。后者在平时LUN操作中不会被访问，只是在快照挂载/回滚时才用到，因此不在意性能，最适合放在大容量NL HDD上。

引用这份资料我并不是想介绍压缩技术，而是因为这个压缩是在自动分层存储的数据调度（Data Progression）时执行，而Dell SC的分层机制正是由Replay（快照）所触发。

如果只配置全闪存，最左边蓝绿色部分可写入的活动数据页面是RAID 10保护，位于最上层Tier1 SSD；浅绿色部分可以在同一组SSD上的RAID 5（跨RAID分层），也可以是“写密集型+读密集型”SSD分层中的Tier2第二层，如下图。

此时再加入橙色的Tier3 HDD分层，就可以像上面说的那样只放历史快照数据，不影响全闪存部分的性能。

写到这里，可以看出商业存储设备在快照方面做出了许多增强，基于快照实现了一些“花样”技术。进入到全闪存时代，快照仍然是阵列的一个重要功能。比如IBM收购自TMS完全针对闪存设计的FlashSystem，也是添加SVC、XIV网关（参见《FlashSystem A9000系列解析：不只是XIV替换了SVC》）具备快照等软件功能后才适合用于核心业务。这也是在传统存储上改良的全闪存阵列、闪存友好型阵列仍具备强大生命力的原因吧。

最后有必要说一下，快照也不是万能的，大家该做备份、数据库复制的还要多管齐下，才能避免遇到像GitLab这样的麻烦哦：）

注：本文只代表作者个人观点，与任何组织机构无关，如有错误和不足之处欢迎在留言中批评指正。进一步交流技术，可以加我的QQ/微信：490834312。如果您想在这个公众号上分享自己的技术干货，也欢迎联系我：）

尊重知识，转载时请保留全文。感谢您的阅读和支持！《企业存储技术》微信公众号：huangliang_storage

原文链接：http://mp.weixin.qq.com/s?__biz=MzAwODExNjI3NA==&mid=2649775364&idx=1&sn=23217dc24d84ef675f26f726054182c5&chksm=83773c59b400b54f34b07dc4bad2d55b3733d88138e71852df18b74061571631efc22736879c#rd