数据库管理-第190期 备份堪比生死（20240515）

作者：胖头鱼的鱼缸（尹海文）
Oracle ACE Associate: Database（Oracle与MySQL）
PostgreSQL ACE Partner
10年数据库行业经验，现主要从事数据库服务工作
拥有OCM 11g/12c/19c、MySQL 8.0 OCP、Exadata、CDP等认证
墨天轮MVP、认证技术专家、年度墨力之星，ITPUB认证专家、专家百人团成员，OCM讲师，PolarDB开源社区技术顾问，OceanBase观察团成员
圈内拥有“总监”、“保安”、“国产数据库最大敌人”等称号，非著名社恐（社交恐怖分子）
公众号：胖头鱼的鱼缸；CSDN：胖头鱼的鱼缸（尹海文）；墨天轮：胖头鱼的鱼缸；ITPUB：yhw1809。
除授权转载并标明出处外，均为“非法”抄袭

最近听到的一些言论，似乎得出备了以结论，即在很多场景，比如云上或多副本分布式环境中是不需要的。但是综合上一期的内容，加上最近看到的一些新闻，我还是认为，数据库的备份依然是必须且必需的。

1 DDL误操作

其实也就是类似于上一期的truncate，也可能是删除了某一列，这些DDL的误操作，并不会产生undo信息（其他数据库可能是版本快照之类的），在有些数据库上truncate还会直接删除物理文件。这种情况下就不可能想依靠undo或版本快照来恢复数据，当然还是可以通过一些外部工具从表空间数据文件或者操作系统来尝试恢复数据，这个难度和费用就可能不可估了。
那么无论在什么环境上，此类误操作都需要通过备份进行恢复。这里有人肯定会说，还有闪回技术，这里需要说明几点：

1. 不是所有的数据库都有闪回技术
2. 恢复DDL一般是要求全库闪回的，对生产数据库来说是灾难性的恢复操作
3. 闪回需要记录更多的东西，一方面可能影响性能，另一方面大多要放在生产数据库中，而备份可以放进便宜的存储中

2 强大的RMAN

其实针对上一期的恢复，主要还是我这边存储资源不足，如果存储足够，应该还是会通过时间点恢复来将对应的整个PDB恢复出来，以进行更多的操作。使用recover table来操作其实最终也几乎恢复了整个PDB，然后在把对应表通过expdp导出来。整个操作涉及了最近一次全量备份和从这次备份到恢复时间点的全部归档日志，实际需要使用的空间比PDB大的多，又因为很多数据已经转入了多了对象存储之中，恢复拉取数据的速度慢的感人，整体花了接近17个小时。
无论我们通过RMAN来恢复数据多么耗时，但是RMAN提供了全面且强大的备份及恢复功能，可以用各种姿势来恢复你需要的数据，当然这一些还是得看你怎么备份的，备份放在哪的。我认为RMAN的功能和设计理念是值得广大国产数据库学习的。

3 ZDLRA

ZDLRA，Zero Data Loss Recovery Appliance，零数据丢失恢复一体机，Oracle提供的针对Oracle数据库的最强大的备份设备。通过一次全量备份后，全程增量实时备份。并可以将备份开始后，任意时间点的任意数据以极快的方式恢复出来，而不需要除中转空间以外的所有硬件资源。这可以看做RMAN与DG之间的融合增强。单机架的ZDLRA可以实现24TB/小时的持续的增量备份拉取速度与恢复速度，而扩展机架的ZDLRA可以线性提升备份和恢复速度，18机架配置可以达到432TB/小时。
其核心特性：

• 实时重做传输
• 高效复制
• 自动磁带归档
• 端到端的数据验证
• 永久增量备份策略
• 节省空间的虚拟完全备份
• 备份操作分流
• 数据库级保护策略
• 数据库感知的空间管理
• 云级架构
• 统一的管理和控制

主要优势：

• 消除数据丢失风险
• 备份影响极低
• 数据库级可恢复性

对比其他一体机，NBU备份Oracle数据库就是通过对接RMAN来实现的，相对来说是比较易用的。但我看到过一些其他的备份设备，大多数只能通过逻辑备份方式来备份数据库；而有些情况下则需要通过备份操作系统逻辑卷快照的方式来备份数据库，这需要操作系统逻辑卷组预留一半以上的空间，且备份数据不是一致性的，完全不支持数据存储在类似于ASM等对磁盘有优化操作的环境之中。关于统一备份，ZDLRA也是有值得学习的地方。

总结

这里还没有说云上到底需不需要备份，前几天GCP的惨痛案例还历历在目，确实误操作是无法绝对避免的，这更多的是管理、流程、责任心和细心程度等的问题。但是我们不能将整个IT架构的命脉完全交给人，高可用确实重要，但是我认为，备份是守卫数据安全的最后一道保障。
老规矩，不知道写了些啥。