备份也能给你搞出点问题来

为什么做备份

为了防止数据丢失，防止一些灾难等等。管理上以及一些监管机构都对备份有要求。有的甚至要求保留几十天甚至180的要求。这些是为了防止故障，但是也有不少时候，没备份还没故障，结果备份导致了故障。

我就遇到过几次因为备份导致故障的

例如，系统卡主了。登录一看。

这是Oracle的逻辑备份。时至今日依然有这种做法。其实对于达到一定的体量就不适合逻辑备份了。应该是采用物理备份较好。

再例如

这是MySQL的物理备份，按理来说不应该出现这种。但是在极端情况下也出了。当然如果采用逻辑备份那么问题就更大了。

传统备份模式的不足

这里我并不是要全面否定。因为很多人还是不能接受。但是不太适用于现在。
不少人听过这个故事吧？
一位年轻有为的炮兵军官上任之后，到下属部队参观演习，他发现有一个班的11个人把大炮安装好，每个人各就各位，但其中有一个人站在旁边一动不动，直到整个演练结束，这个人也没有做任何事。军官感到奇怪：“这个人没做任何动作，也没什么事情，他是干什么的？”大家一愣，说：“原来在作训教材里就是讲这样编队的，一个炮班11个人，其中一个人站在这个地方。我们也不知道为什么。”军官回去后，经查阅资料才知道这一个人的由来：原来，早期的大炮是用马拉的，炮车到了战场上，大炮一响，马就要跳就要跑，一个士兵就负责拉马。到了现代战争，大炮实现了机械化运输，不再用马拉，而那个士兵却没有被减掉，仍旧站在那里。经过调查，得到的答案是：操练条例就是这样规定的。
其实和备份有很相似的地方。

当今数据量下我个人不赞成传统备份模式

我以前处理过单机Oracle 100TB。说实话，这样的数据库即使物理备份都不轻松了。所以一般大的数据库我个人认为应该是高可用大于备份。反正我们的目的是数据不丢，保证业务连续性。只要做到了，你管我用什么呢？

百度备份不备份我不知道，估计不怎么备份吧？谷歌也应该不备份。一向我觉得应该退出历史舞台的Hadoop也不备份，他们有自己的多副本。是不是没见哪个人去给Hadoop做过备份。既然这个逻辑（多副本）认可，那么其他的多副本模式也应该认可。

当今业务下我个人不赞成传统备份模式

比如一个系统每秒1000个事务，这种场景下。指望备份恢复数据吗？这时候需要的是高可用来堪当大任了。否则指望备份恢复，几个小时需要停止服务等恢复。恢复期间暂停业务不说，还是只能恢复到备份点。而备份点到现在的数据没有了。

我个人赞成备份

以上问题在30年前我觉得没有问题。但是今非昔比。
我也说了不是不要备份，而是
1、首推用高可用来支持。
2、备份一体机的技术可以满足当下高并发业务量的实时备份。（上线第一次全量，后续永远增量）
3、当然可以辅助其他手段。延迟复制（防止数据被误删除），MySQL 和PostgreSQL都有，还有Oracle这样的即使表都被删除了，也能从闪回中找得到。从这个角度上来说，连高可用都没有还能保证数据不丢。我见过有的系统就设置了保证15天的闪回。就算应用程序写错了。都找回来了。

我认为备份在心中

很多人觉得有备份可以大胆一些。其实我认为最好当做没有备份。就像如果生命可以复活大家就不珍惜了。如果只有一次，才格外珍惜。