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

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

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

你谈个恋爱都有个备胎,你的数据有备份么?

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

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

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

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

文章目录

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

一个空格引发的惨剧,这个其实很早了

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

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

炉石传说

关于《炉石传说》服务器故障公告

北京时间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 事件中吸取的教训

如何评价 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机制不生效导致空间满等问题。我们去年底已经采购了某厂商的备份系统,接下来希望会好点。当然,即使有商业系统,我自己的开源方案也会继续保留,毕竟备份不嫌多。

镇楼