90%的开发都不太考虑这个，但只要出问题直接公司完蛋！
前不久的这条新闻或许大家已经有所耳闻：
位于法国斯特拉斯堡的 OVH 数据中心被大火烧毁。据悉，火灾导致多个数据中心无法服务，大量客户网站瘫痪，部分客户数据完全丢失且无法恢复，这是数据中心历史上史无前例的灾难性事件。
我们今天不讨论火灾的原因、OVH损失多少，而是想重点说说在这次火灾中受影响的用户与背后的系统设计缺陷。
在此次事件中损失最惨的是一家名叫Rust的游戏制造商，该游戏制造商失去了其公司名下游戏所有的欧洲服务器，储存在服务器上的数据全部丢失。
也许很多读者的第一反应是：玩家花费大量精力财力的账号没了，一定是伤心欲绝！
其实，从公司角度来说，他们的损失更为惨重，因为数据丢失也就意味着客户丢失，同时也意味着客户虚拟资产的丢失。这样的灾难对于企业来说，往往面临的就是一个结果：倒闭！
当知道会发生这个结果的时候，相信大家都会开始想起来，怎么不做备份啊之类的疑问？甚至也有读者可能会说，云服务商没有备份么？云服务商要赔钱！
然而大家是否有想过，当你来操盘负责系统架构设计的时候，你是否有去考虑和设计数据灾备的方案呢？是不是只顾着业务实现了？对于灾备的考虑是不是很多人都没有放到很重要的位置去看？
今天，就借最近这个血的教训，来跟大家聊聊这个很多开发人员都会忽略的点！
下面的内容是之前我在星球分享的一篇文章《前往架构师路上的建议（5）：新手架构最容易忽略的点！》，当时是因为连续参与了几家客户的培训和咨询之后，引发的关于数据灾备的思考。
最近因为培训与咨询业务，接触了不少创业公司。在给这些公司讲架构课的时候，发现这些创业公司在设计与实现过程中，都忽略了一个非常重要的点：数据灾备。
事后，我也思考了这个问题，为什么创业公司很容易遗漏这个点呢？可能是由于大多创业公司的开发团队核心人员，大多来自一二线互联网公司的高级开发人员（一般都是原企业缺少上升空间，但自身开发能力不错，如果看好创业方向，确实是很容易出来拼一下的）。而在做开发的时候，很多思考的范围都是在如何做好业务需求，让实现更容易在未来做扩展，对于性能可以水平伸缩。而对于数据的灾备，在大公司中，很多就是专职架构师或运维团队去主导和处理的。于是，这部分的设计，对于他们来说，可能比较陌生，就不容易想到。
所以，我将这点加到了这个系列中来，希望大家在成为架构师的路上，把这部分知识与技能都可以完善起来！
数据灾备的重要性
有的同学可能会问：我的数据库已经是主从结构、集群化架构了啊。如果有部分节点挂了，数据还是好的呀。这样做是不是就已经ok了呢？
我可以很明确的说：还不够！即使你是一家创业公司，也一样如此！在介绍一些灾备方案之前，我们先来说说数据灾备的重要性，我们为什么一定要做灾备？为什么你是创业公司，也一样是第一重要的事情！
要说明白这个重要性很简单，大家只要思考一个问题：如果你的业务系统跑了一阵，突然某一天，数据丢了，没有办法恢复！这个时候，你的公司还能不能继续经营和生存下去？（如果你觉得可以，欢迎留言说说你的业务领域以及如何起死回生。）
在历史上，AWS曾经也发生过因断电等原因导致数据丢失而引发的诉讼。由于数据丢失，导致相关企业无法正常运营，最终走向倒闭关门的境地。而所有的诉讼，无一例外的AWS完胜，其核心原因就是这些企业的应用架构上没有做好对数据的灾备方案，而非云计算及服务商的问题。也就是我们常说的，使用姿势不对导致的后果，运营商并不负责！
所以，从做架构开始，数据资产的第一重要性是你要谨记的。如果没有数据的灾备方案，你公司的业务随时可能因为一场事故而土崩瓦解！
数据灾备的实现方案
数据灾备的方案其实很简单，在做具体方案的时候，你主要做的就是根据你当前企业的情况可以付出多少成本，来确定做什么级别的备份。
具体方案的制定上，你需要思考两个问题：
第一个问题：哪些数据要灾备
虽然现在云服务的存储不贵，但是如果我们把所有的数据都去做了灾备，显然也是一种浪费。所以，对数据有选择性的做备份，才是一名好架构师的表现。
第二个问题：要应对多大的灾难
这个问题的根本就是备份数量以及备份地点的选择。
之前提到过如果数据库已经是高可用的，那么这里面的数据确实已经具备了一定的灾难应对能力，但为什么说这样的灾备级别不够呢？因为通常在线业务的数据库集群都在一个机房，甚至一个机架。由于物理上的部署原因，他所能应对的灾难是很优先的，对于机器级别的灾难，他可以应对，但是当遭遇火灾或更大的自然灾害的时候，这样的部署方案显然是无法应对的。
所以，对于创业公司来说，最基本的灾备方案除了同机房的高可用集群之外，还需要有一个异地机房的备份是最基本的要求。如果有必要，还能扩大这个范围（不光跨城市，还可以跨大陆板块等策略）或是扩大备份数量来进一步增加灾备级别。
最后，灵魂一问：你们公司目前的业务系统是否有做数据灾备呢？