有一天，接到一个CASE，说数据库中两台服务器的电源同时损坏，无法使用。第二天上班前需要恢复所有的数据库。当时是晚上12点。首先了解了学校的数据库：数据库的操作系统是Solaris操作系统。数据库的备份只是Rman的备份，是放在storage上的。幸运的是，现场有一台小型机可供回收，并有一张光纤卡可以识别小型机。首先将光纤存储卡连接到可供恢复的小型机上，识别存储上数据库的rman备份，然后安装数据库软件，恢复数据库数据，打开数据库。整个过程大约需要5个小时或更长时间。基于以上案例，我来和大家探讨一下备份方案的制定：1.恢复最早的时间点是什么时候？对于用户来说，用户只关心数据库当前状态是否正常。至于对数据做了哪些操作，什么时候进行的，并不重要；某些业务类型可能希望查看之前做过的操作，甚至因为特殊需要将数据库恢复到之前的某个时间点。这两个要求主要与备份保留策略有关。对于前者，一般建议根据冗余数量来选择备份保留策略。如果只想保证数据库的稳定运行，根据数据的大小，可以适当保存几个最近的备份。为什么需要保存最新的副本？一份还不够吗？备份本身就是在做冗余，所以从可靠性的角度来说，备份当然要有冗余，至少要保证有两个备份，这样即使一个副本因为某种原因损坏了，还是有一个替代的。如上例，只有一个备份其实是非常危险的。如果出现异常情况，数据无法恢复，造成的损失将无法估量。当然，根据副本的数量，所需的磁盘空间会呈指数级增长，要保留的备份副本的数量必须根据磁盘的容量来确定。如果你不仅要查看，还要将数据恢复到以前的时间点，那么你必须确保有在目标时间点（或之前）创建的备份，以及相关的归档文件。基于这样的需求，建议选择基于冗余时间的备份保留策略，备份保留时间可以设置为最早恢复时间。2.系统什么时候空闲？由于系统需要读写大量的数据，这期间必然会占用较多的系统资源。如果在数据库繁忙期进行备份任务，不仅备份时间长，还可能影响业务系统的正常运行。我们目前通常的做法是在凌晨两点执行备份任务。对于大多数企业来说，这段时间访问系统的次数最少。始终进行备份。3、数据库的数据量有多大？虽然说不考虑硬件因素，但是备份操作本身，考虑到执行效率，不可能完全忽略硬件。备份所需的时间还是以用户使用独立存储为准。基于性能。按照每秒100M左右的磁盘读写速率，对200GB左右的数据做一次备份操作大概需要半小时左右（对应的恢复操作也是这个时间左右，一般会长一些，因为需要重做日志appliedduringrecovery)，就备份操作而言，每天在系统不忙的时候分配几个小时，这个时间对于大多数应用来说是可以接受的。因此，我们为一般学校制定的备份策略是每周六进行全量备份，每天备份归档日志，每周六全量备份后删除之前备份的归档日志。4.估计可能给出的恢复时间。一般情况下，正常的系统是不会进行恢复操作的。当需要对数据库系统进行恢复操作时，就意味着系统出现了问题，尽管这个问题可能是零星的，但处理问题所需的时间可能是一定的。例如，在数据量一定的情况下，可以预估恢复数据文件和应用日志的时间。对于一些核心业务系统，任何没有通知的短期服务中断甚至是一场灾难。在这种情况下，一旦出现重大问题，单靠RMAN是不可能实现快速恢复的。因此，数据库管理员需要通过其他方式（如存储层镜像或数据库容灾等）来保证系统的高可用性，而不是仅仅依靠备份。而一些非核心业务系统可能只需要在每周甚至每月的某个特定时间使用（比如选课系统）。对于这类数据库系统，由于有大量的时间进行恢复，因此制定备份策略也比较费时。也可以轻松一些。例如，不需要每天都创建备份，而是只在发生数据修改时才执行备份任务。备份和恢复绝对不是彼此孤立的。恢复依赖于备份。备份策略基本上决定了恢复的方式、可以恢复的数据以及恢复的效率。因此，备份策略的制定取决于您的恢复需求和恢复策略。5.总结：关于如何做数据库备份，我的建议是，如果条件允许，可以在数据库服务器本地和存储上做一个Rman备份。如果是小型机系统，建议做rman备份（rman除了可以在同平台间恢复外），还需要做一个逻辑备份，把这个备份放在remote端。备份完成后，需要每隔一段时间（一般为三个月）对整个数据库进行一次恢复测试，以保证数据库备份文件的可用性。
