就把备份做好有多难

先把备份做好，再来跟我说你要改变世界、你有一个很好的idea、你要解决的痛点吧。

备份也是安全的一部分，属于数据的安全，跟安全一样，可见度很低，所以存在感也很低。备份做得很好，也永远不会是亮点，备份就像买保险，有可能你投入了非常大的资金和精力，最终都打了水漂，因为你可能一辈子不会用到，而且往往必须得出一次大的事故，才能重视起来。

很多人会混淆备份和容灾，容灾更多的是应用持续性的安全，两套差不多的设备，一套挂了另外一套跑起来业务不中断，但是容灾解决不了备份的问题，如果你在某个容灾系统里误删除了一块数据，容灾的那边也同样删除了。

你谈个恋爱都有个备胎，你的数据有备份么？

如果数据没有备份，可以认为这个数据是不存在的。

为什么听过那么多道理，依然过不好这一生？ 我承认我也没有做好。因为要做好确实很难，在有限的资源内。

近期比较大的数据丢失事件

一个空格引发的惨剧 http://coolshell.cn/articles/4875.html ，这个其实很早了

rm -rf /usr /lib/nvidia-current/xorg/xorg

除了rm -rf，其实Linux下面还有很多命令也是很致命的。比如tar加f参数写反了，rsync，dd把in和out写反了等等。

炉石传说

关于《炉石传说》服务器故障公告 http://hs.blizzard.cn/articles/16/8565

北京时间2017年1月14日15:20，我们的炉石数据库由于供电意外中断的原因而产生故障，导致数据损坏。

虽然暴雪与网易的工程师们已在事故发生后第一时间着手抢修，重启服务器并尝试数据恢复。但不幸的是，由于相关备份数据库也出现故障，这些尝试均未成功。

我们十分理解广大玩家的焦急的心情，也曾在事故发生后的最初两天尽力做出了各种数据修复的尝试，但效果及进度均不理想。在此期间游戏环境已变得不稳定，而游戏的维护时间也已超过24小时。

在尝试了各种解决方案后，暴雪和网易最后综合考虑，决定将所有游戏数据回档至事故发生前状态（即2017年1月14日15:20）。我们需要向大家说明，游戏回档是我们最后的无奈决定，暴雪和网易对被迫做出这个艰难的决定深表遗憾。

关于炉石传说的Oracle数据库故障不要以为你也可以幸免

GitLab

2017年2月1日GitLab数据库被误删，最终丢失一小部分线上数据（6个小时的issues、comments、merge requests等，代码和wiki文档不受影响）

GitLab有6种备份，当天全部失效。。。

从 gitlab 事件中吸取的教训 http://mp.weixin.qq.com/s/x0I1yyp2leUqc7RA7R5HwQ

如何评价 2017 年 2 月 1 日 GitLab 数据库被误删？

最近听到那么多公司备份失败的事情（网易啊，gitlab啊），我觉得他们应该来向微软取经。我们每年一度的IT部门的演习，就是假设西雅图已经被核弹毁灭，然后附近的山洞里面把磁带取出来，第二天就在另一座城市重新建好所有开发环境，继续干活的一个故事（虽然听起来有点没人性）。

备份解决什么问题

所有人都知道备份很重要，但也就是停留在嘴上的寒号鸟。备份除了最开始认为的解决自然灾害或者硬件损坏的问题以外，实际上现在还越来越多用在下面场景：

被黑客入侵，恢复数据
被黑客入侵，加密了文件或者数据库，恢复数据
误操作或软件Bug恢复数据
查找某个以往特定时间点的数据跟现在比对

备份背后的难题

原始数据很大，比如我们的网盘系统，数据在多个服务器内冗余存放，在多个服务器内是安全的，也就是只要服务器不全部挂掉，数据就是安全的。但是解决不了异地备份和误删除等操作的问题，如果你为了做备份，网盘本身存储容量很大，你需要买更大的存储来存放。
原始数据都是小文件，比如我们的邮件系统、BBS系统，文件级备份一次时间很久，备份过程中文件又有更新。当然这些可以通过Windows VSS或者LVM或者虚拟机快照解决。
我们的Coremail邮件系统，Outlook等客户端有个配置完邮件POP3设置收信到本地后自动清理7天前邮件的默认配置，有用户因为错误配置导致Web上去后邮件都丢失了找到我们，我们也爱莫能助，邮件系统本身没有提供单用户恢复过往所有邮件的功能。虽然我不认为把所有邮件都放在邮件服务器是一个安全的做法。
Log持续写入，文件又很大，导致备份时间久，甚至VMWare的备份直接失败。
为了解决小文件的问题，一个解决方法是先在本机做个tar，然后一次性传输大文件到远端，然而也会遇到更新问题，还有一个问题是每日的tar可能还没完成，那边rsync已经开始运作，导致备份的都是不全错误的文件。
我目前在用的开源软件Bacula和商业软件Acronis True Image不知道为什么Purge机制不起作用，经常备份空间满。
备份的源端加密计算量很大，对系统CPU性能要求较高。备份会对正在运行的系统造成压力。
备份会占用网络流量，多个备份同时运行会造成网络风暴。有天潘竹虹跑到我电脑前吼我，你在干啥？全部主楼的带宽都被你占满了。其实是因为快放假了，我正在下行传输寒假需要看的电影，上行放假前例行检查发现备份出错，重新跑备份，24小时上下行带宽是满的。
备份是否是有效的备份？是否有经过验证？
当然，基于虚拟机的无Agent备份减轻了非常大的压力。但是不是所有都是虚拟机的。
还有直接基于存储LUN的备份，很快，恢复也很慢。
基于数据库binlog等可以做到秒级的恢复，只是听过没有实践过。
有时候为了备份方便，给备份用户开放了较大的权限，比如无密码访问数据库等等，导致可能被攻击。
恢复麻烦，我有个备份很大，某天为了找其中的一个小文件，想恢复备份，然而恢复到的目的机器空间已经不足，而且需要重建读数据的环境，折腾了半天。
备份对云服务用户不透明，做得好的云服务系统，用户可以自行做备份计划，可以自行恢复，然而我们目前购买的备份系统好像做不到，恢复需要管理员介入，导致管理员工作量大，不一定愿意随时给用户做恢复，使得这项特性缺失。
是否还要有备份的备份。
进行恢复时面对最终用户的通知机制？如何做到信息透明？敢透明不？

我认为一套完整的备份应该是

通常一个系统上线，我认为应当以系统加入监控和验证完备份才算是完整部署上线完毕。

一套完整的备份方案应当是：

如果可以，应当有个备份管理员（最好这个管理员也要有备份），啥事不干，就干备份，有事没事恢复数据玩。然而有些备份是加密的，必须拉上系统管理员、数据库管理员一起玩。
清理所有需要备份的数据，得非常得清晰。定义备份策略，冷备热备，备份多久，可以承受备份到哪些远程地理位置。
新建的系统如何保证一定加入备份？负责的系统多了，很难做到事事具备。
应用必须是备份友好的，应用开发初期就必须考虑备份，考虑恢复的便利性，比如网站群系统，对于备份不应当是整个系统全备份，而是各个子站独立备份，这样子恢复才较为容易。应用需要备份的应当是应用的数据库、上载的文档、应用特殊的配置文件，SSL证书等等。其他应用源代码、安装部署程序由于可以重新下载可以不备份，日志可不备份。做得更好的应当把所有这些提交到源代码库，部署使用Puppet，Ansible等自动化部署工作自动部署，以便自动化恢复系统。
监控，确认备份有效。
定期演练，确认备份有效和恢复时长，制定灾难处理流程（Disaster Recover Process），形成自动化脚本。

我目前的备份机制

我的工作用机和个人数据每天备份一次，备份在同一个建筑物内的不同楼层。由于潘竹虹事件，我重新梳理了备份数据，不再更新的和持续更新的文件夹分离，不再更新的文件夹每个月备份一次，减少了非常多的网络带宽，备份速度也快了很多。

想想我们全家的照片，未来儿媳妇子孙辈要看的照片数据都在我这，我感到肩上的压力很大。

群晖的NAS备份据说便宜又好用，我还没测试过。

而我直接负责的系统，每天使用开源软件Bacula备份，然而目前运行效果不是很理想，包括前面说的备份半截数据，Purge机制不生效导致空间满等问题。我们去年底已经采购了某厂商的备份系统，接下来希望会好点。当然，即使有商业系统，我自己的开源方案也会继续保留，毕竟备份不嫌多。