干了十年 Oracle DBA，最怕半夜接到电话。不是怕加班，是怕听到那句“数据库起不来了”。这时候，备份就是你的救命稻草，没备份？那等着你的就是领导的黑脸和业务部门的咆哮。备份恢复这事儿，说简单也简单，不就是 RMAN 备份、归档日志、控制文件那几样吗？可真正遇到事儿了，很多人就慌了神。我见过太多人，备份脚本写得花里胡哨，恢复时连个基本的全库恢复都搞不定。别笑，这是真事儿。
备份恢复的核心，其实就三个字：可用性。你把备份文件堆得跟小山似的，但恢复时发现某个归档日志坏了，或者控制文件丢了，那这备份就是一堆废纸。所以，做备份不能光想着“我备份了”，还要想“我怎么才能恢复”。我的习惯是，每次做完备份，都模拟一次恢复。哪怕只做个全库恢复验证，也能提前发现很多坑。比如，备份文件权限不对，或者磁盘空间不足，这些在正式恢复时都是致命伤。别偷懒，这一步省不了。
再聊聊备份策略。很多人喜欢搞“全备+增量”，觉得这样省空间、省时间。但增量备份有个大坑：依赖链。你周天全备，周一到周六做增量，结果周三的增量坏了，周四到周六的增量全得从头来。恢复时间直接翻倍。我的建议是，核心业务库别省那点空间，直接全备。每天一次全备，周末再留个离线备份。非核心库可以考虑增量，但一定要做好增量完整性检查。另外，控制文件、参数文件这些元数据要单独备份，别指望跟着数据文件一起。我就吃过这亏，控制文件坏了，全库恢复只能靠猜测参数，累死。
说到恢复，很多人觉得 RMAN 是万能的。是，RMAN 能备份、能恢复，但有个前提：你得知道怎么用。最典型的是不完全恢复。比如误删了一张表，想恢复到删除前的某个时间点，这时要先确认 SCN 或时间点，然后执行 。很多人连当前 SCN 都查不到，更别说精准定位了。还有人恢复时忘了指定归档日志路径，结果 RMAN 傻等着找不到日志。这些细节平时不练，出事就抓瞎。
还有一种更常见的情况：异地恢复。比如生产库在 A 机房，灾备在 B 机房。某天 A 机房挂了，你得在 B 机房的服务器上恢复。这时除了数据文件，还要考虑目录结构、实例名、监听配置等。我见过最惨的一次，恢复时发现目标服务器的 ASM 磁盘组大小不一样，结果数据文件根本放不下。所以，异地恢复的测试必须定期做。别光想着备份文件能传过去，还得保证目标环境和源环境匹配。
备份恢复里还有个容易忽视的点：归档日志的管理。很多 DBA 只关注数据文件备份，觉得归档日志是小事。但恢复时，归档日志是串联时间线的关键。比如全备后只保留 7 天的归档日志，结果第 8 天出问题，你只能恢复到 7 天前的状态。更头疼的是，有些归档日志生成速度极快，白天业务高峰期一分钟就好几条。如果归档日志空间满了，数据库会直接挂起。我的建议是，归档日志的保留策略要根据业务的恢复时间目标来定。核心库至少保留 30 天，并且要做异地归档。别舍不得那点存储空间，恢复时就会知道值不值了。
说点个人经验。备份恢复这事儿，别指望一次搞定。要建立文档，把每个步骤、每个参数都记下来。例如 RMAN 的恢复命令，别光靠记忆，写下来。每次恢复演练后都要复盘，哪里卡住了，哪里出错了，下次怎么改进。我习惯每月做一次全库恢复演练，每季度做一次异地恢复演练。别觉得浪费时间，真遇到事儿时，这些演练就是最宝贵的经验。备份恢复的本质不是技术问题，而是管理问题。管理得好，技术只是工具；管理差，再牛的技术也救不了你。
