1．“吃狗粮”的灾备危机
在我司的工程实践中，最为常见的一个做法就是“吃狗粮”。也就是说，所有工程师的开发环境、测试环境都是由ZStack搭建的。最开始的时候，工程师们还蜗居在两间不大的办公室，其乐也融融。某天，随着一声声哀嚎，大家发现有位工程师不慎把主存储给误删掉了。
得益于ZStack的设计，整个环境半个小时成功恢复。原因有两点：
1.系统自动部署了备份服务，数据库每小时有定期备份；
2.ZStack本身无状态，只要数据库在，环境就能恢复。
有惊无险，上了一次“云头条”。
2．灾备很重要，但为何是混合云灾备
自己吃狗粮碰到的问题，用户必然也会遇到。进一步引申下来，在这个“删库跑路”、“误操作导致数据丢失”等消息常年霸占媒体头条的时代，我们需要严肃地思考一个问题：如果被删除的不仅仅是数据库记录，而是真实存储系统的数据，或者存储出了故障，怎么办？
我们需要灾备，但灾备不仅仅是数据备份。数据备份是最自然、最基础的需求。完成数据恢复后，用户真正需要恢复的是业务。在私有云的场景下，业务恢复的资源粒度可以是一台虚拟机，甚至是一个集群。如果说，“ You cannot sell a platform without a killing application running _disibledevent="font-family: 宋体; font-size: 14px;"> 正如同鸡蛋不能放在同一只篮子里，重要的数据也不能全都放在本地。随着硬件能力的不断进步，用户拥有单位资源的成本在不断降低，但是数据的潜在价值却在不断攀升。数据越庞大，业务规模越庞大，导致的代价也随之越来越高昂。拥有灾备能力，拥有系统化恢复业务的能力，才能全无后顾之忧。在云的世界里，“后悔药”其实是存在的。