下厨房数据丢失引发的自我反思

下厨房6月26日数据丢失事故总结

http://tech.xiachufang.com/?p=18

626技术故障的致歉信

http://blog.xiachufang.com/article/5601

刚录完mysql主从同步的视频，群里有人发了个链接，是一个数据丢失事故总结。自己吓一跳，我自己在数据上面也并不是那么上心。总有一天我也会出同样的错。必须反思下。

从总结当中发现了一些问题。虽然我没有指责他们的权利，但我也没有这个心思，只是对自己的反思， 因为自己也在数据漫游中整过很多问题。

大的备份数据重要性我就不讲了。

一眼看到的是流程啊，没有流程来规定这些东西出错，rm -rf真心不是人能抗拒的。我想到的是如下几点：

1、为什么机器下架不把他搬回公司再进行操作。反思的是，再三确定再三确定。特别是重大操作时。

2、应该从管理角度重视数据的问题，难道因为增加服务器就不进行备份，前后两个月零3天。预算？这事应该会很重视IT工作了。

3、应该从技术角度去规避数据问题，可以添加权限不允许删除，只允许增加数据。rm -rf 在主服务器上应该有限制，另外主服务器的权限一定只能掌握在部分人手里。

4、有主就有从，而主从是通过binlog来进行复制，并且本地sql线程执行。那么册了主的数据，从的数据应该还在啊？怎么会没了，因为不是drop表drop库而是rm -rf 文件。

5、一定要重视数据的备份以及流程，要有规范。

事帮发生之后产生的亮点比问题更多。

历时七天，数据恢复99%。

事故后恢复工作从数据来源分为4条线索进行：
1. 硬盘上数据的恢复（主线）
2. 从memcache导出的数据恢复
3. 从binlog里恢复
4. 从搜索引擎的快照里恢复页面

1、第一时间技术人员商讨怎么办？并制定一系列的措施。确定主线。

2、停止mysql服务，虽然是个技术恢复说是个错误。

3、找数据恢复公司。并不止一家。持续的进行恢复过程。

4、找技术牛人，数据恢复过程有牛人指导是完全不一样的。

5、强大的公关。网站状态发送以及道歉很诚肯。

6、数据云备份，应该还有更多的方案但是没发公布出来。

想到再继续补充。