数据大了备份很慢?方法不对吧

这是所有数据库的常识。有人说把历史数据归档，这样线上库就小了。对，但是你归档库不备份吗？

10TB的你试试，物理备份还好办些，但是也耗时不少。逻辑备份就不要想了，可能一周都不行，关键还是要恢复呢。真的出了问题你指望这个备份吗？基本指望不上。

比如你凌晨1点备份的，全备份。（传统行业18点到第二天早上9点没有写入，没有数据变化了）然后用的下午13点出问题了。9点到13点的4个小时怎么办？

我知道很多人说有归档啊。对，有归档，你可以还原。就是需要些时间。这里说的出问题有几种。

1、硬件故障（概率极低），现在的硬件技术，我从业快20年了，真没见到过几次硬件故障导致数据库不能用的（亲自经历过一次就是自己误操作把阵列格式化了，现在想想当时蠢到家了，好在还没正式使用的数据，当时太丢人了）

这种我建议你有一个镜像库。从库。我虽然极力反对OLTP 主从情况下切换。（除非你人工确认是一致性的 以及本来就是多写比如Oracle的RAC 或者18C开始的DML重定向 以及MySQL MGR这种 ）但是当主库遭遇着火或者雷击等灭顶之灾的不可抗拒力的情况下，从库相对来说比你的备份更加趋于全面。

2、误操作。这种是最多的。比如原始数据如下。

图片

一失手没有带where条件的更新。

update f set b=‘a’ 这里就4条，真实环境可能几百万几千万。而且还被改了两次。

图片

图片

怎么能知道以前的呢？这里说个老的技术，都快20年前了。别说DBA了，就是开发都知道的功能。闪回。

根据不同时间断面查询表在不同断面的数据。原始数据

图片

图片

第二次变化，即当前。

图片

其他数据库暂无这个功能，不过需要其他手段去做。比如解析日志，逆运算等等。

因为政治因素大家要替换Oracle，从技术上来说他真的解脱我们。可惜呀。

再加上很多决策者不希望性能由数据库决定（但是一个系统中的瓶颈基本就在数据库，数据库是系统压力的最关键），而是由开发来决定。（觉得这样可控，其实我觉得数据库好控制，开发取决于人这才是完全不可控）

这和备份有什么关系？有，误操作的对Oracle来说闪回就解决了（空间够大，闪回时间越长），我空间不够怎么办（世界上就一种病叫穷–来自《我不是药神》）

MySQL PG 需要DBA介入了。有没有能解脱人力的？几年前听过一次技术交流说到备份一体机，才知道还有这个玩意？但是实际上早就有了，只是我孤陋寡闻而已。它的原理就是只做一次全量备份，然后每天做增量，并且给你恢复（这是重点区别于我们传统只备份不恢复检查，当遇到问题需要恢复时候发现居然可能不能用）这样每天只要做增量，而且是恢复好了放在那里，保留N天。就看你要保持多少天了。比如30天，如果你需要任意30天内的某天的数据。直接去查询。其类似这样闪回保留过去某一时间断面的数据版本一样，他保留过去某天当天备份时间点的数据版本。

重点：

1每天增量再也不用每周全量这样的痛苦操作。

2每天还做了备份的检查，因为做了恢复。

3想用随时用，不需要专人去恢复。

4避免恢复需要的长时间等待

5有的机器只能做一种数据库，比如Oracle的只能做Oracle的，但是不少供应商的可以做很多中数据库的。

6空间也稍许节约了。

下一篇我们从另外一个角度谈谈备份。