如果没有备份副本，数据库管理员就无法还原数据库，所以DBA在恢复之前倾向于考虑备份是合乎逻辑的。 但是，对我来说，这种逻辑一直是错误的。

使用诸如Oracle Recovery Manager或RMAN等工具完成的数据库备份实际上只起了一个作用，即：恢复由于某些故障而丢失的数据，否则将无法恢复。

数据库管理员（DBA）经常不理解恢复驱动备份，而不是其他方式。为了避免数据库恢复管理过程中可能的故障，DBA在实施备份策略和软件支持之前必须对其恢复要求有良好的处理。

Oracle Recovery Manager是一款可靠的备份和恢复工具，我可以理解为什么许多Oracle DBA认为它是最好的或首选的技术选项。在RMAN存在之前，DBA需要知道现在被称为用户管理备份的各种细节。在那个时候，我书架上放了一本书，它提供了很多不同的恢复方案。

一种情况涵盖了数据文件的丢失，另一种情况涉及整个数据库的丢失等等。 DBA必须确定哪种情况适用于现有恢复工作，并实施适当的步骤。

RMAN实现了帮助我们实现了自动化。它知道最后一次备份，并可以弄清楚接下来要备份什么。它还知道哪些数据库部分丢失并可以自动处理恢复。RMAN的确是我们所拥有的一个很好的工具。

RMAN并不适用于所有情况

不管怎么说，RMAN并不是没有错误。它并不是可以解决所有情况的完美工具。例如，RMAN不能在10分钟内恢复20 TB数据库，但基于硬件的磁盘快照可以。同样，RMAN无法将在一个操作系统上运行的数据库还原到Oracle认证的任何其他操作系统，但Oracle数据泵可以。

也许这些要求不适用于你的环境。如果RMAN满足你所有的恢复要求，请继续使用它。但是，除非你完全了解可能需要恢复数据的方案，RMAN才能满足你的需求。

最好的做法是首先记录恢复要求。现在跳过备份——首先重点关注恢复和弄清楚相关情况，以及每个服务级别协议（SLA）的预期恢复时间。

可接受的数据丢失量也应该是SLA的一部分。例如，SLA可能会声明DBA必须能够实现零数据丢失，并在整个数据中心故障后10分钟内建立并重新启动数据库。或者说可能会失去一天的数据，而且一天的损失是可以接受的。另外，记录任何依赖备份的额外业务流程，如数据传输或数据库复制和克隆。

覆盖所有的数据库恢复基础

在确定了恢复要求之后，就实施覆盖所有恢复要求的备份策略。有时，像RMAN这样的单一工具可以处理SLA中概述的备份和恢复需求。而其他时候，DBA可能必须使用多种方法，例如将RMAN和Data Pump一起实现。

DBA是企业中的数据监护人，DBA最重要的作用并不是做备份。相反，它能够恢复数据。如果公司丢失数据而无法拿回数据，负责受影响数据库的DBA可能就需要另谋高就了。

公司正在依靠DBA进行数据保护。为了提供这一点，DBA知道他们需要如何恢复数据是至关重要的。只有这样他们才能考虑备份。