Oracle OS备份是一种常见的备份方法，下面就为您介绍两种Oracle OS备份的方式--冷备份（Cold backup）与热备份（Hot backup）。
Oracle OS备份：
Oracle OS备份有两类，冷备份（Cold backup）与热备份（Hot backup），操作系统备份与以上的逻辑备份有本质的区别。逻辑备份提取数据库的数据内容，而不备份物理数据块。而操作系统备份则是拷贝整个的数据文件。
i、冷备份
在文件级备份开始前数据库必须彻底关闭。关闭操作必须用带有normal、immediate、transaction选项的shutdown来执行。 数据库使用的每个文件都被备份下来，这些文件包括：
所有数据文件
所有控制文件
所有联机REDO LOG 文件
INIT.ORA文件(可选)
作冷备份一般步骤是：
a.正常关闭要备份的实例(instance);
b.备份整个数据库到一个目录
c.启动数据库
如
SVRMGRL>connect internal
SVRMGRL >shutdown immediate
SVRMGRL >! cp <file> <backup directory>
或
SVRMGRL >!tar cvf /dev/rmt/0 /u01/oradata/prod
SVRMGRL >startup
注意：如果利用脚本对数据库进行冷备份，必须对关闭数据库的命令进行逻辑检查，如果发生关闭数据库的命令不能正常执行而导致数据库没有正常关闭，那么，所有的冷备份将回是无效的。
ii、热备份
热备份是当数据库打开并对用户有效是的OS级的数据备份。热备份只能用于ARCHIVELOG方式的数据库。在数据文件备份之前，对应的表空间必须通过使用ALTER TABLESPACE …… BEGIN BACKUP以备份方式放置。然后组成表空间的数据文件可以使用类似冷备份的操作系统命令进行拷贝。在数据文件用操作系统命令拷贝后，应使用ALTER TABLESPACE …… END BACKUP命令使表空间脱离热备份方式。
热备份没有必要备份联机日志，但必须是归档状态，在实例恢复的时候，可能需要用到归档日志。当前联机日志一定要保护好或是处于镜相状态，当前联机日志的损坏，对于数据库的损坏是巨大的，只能以数据的丢失来进行数据库的恢复工作。
对于临时表空间，存放的是临时信息，在热备份是也可以考虑不用备份，如果临时文件发生故障，可以删除该数据文件与表空间，重建一个临时表空间。热备份的优点是显而易见的
---- a．可在表空间或数据文件级备份，备份时间短。
---- b．备份时数据库仍可使用。
---- c．可达到秒级恢复（恢复到某一时间点上）。
---- d．可对几乎所有数据库实体作恢复。
---- e．恢复是快速的，在大多数情况下在数据库仍工作时恢复。
操作系统作热备份的一般步骤为：
①连接数据库 SVRMGRL>connect internal;
②将需要备份的表空间（如User）设置为备份方式 SVRMGRL>Alter tablespace User begin backup;
③拷贝数据文件 SVRMGRL>!cp /u01/oradata/prod/user01.ora /backup/prod/user01.ora Or $cp cp /u01/oradata/prod/user01.ora /backup/prod/user01.ora
④在数据文件拷贝完成后，将表空间拖体备份方式 SVRMGRL>Alter tablespace User end backup;
⑤对所有需要备份的表空间重复2，3，4
⑥使用如下的命令备份控制文件ALTER DATABSE …… BACKUP CONTROLFILE
如备份成二进制文件 alter database backup controlfile to ‘new fielname’;
备份成文本文件 alter database backup controlfile to trace;
因为热备份的时候，用户还在操作数据库，所以，最好是每个表空间处于备份状态的时间最短，这样就要求一个表空间一个表空间的备份，不要一起使表空间处于备份状态而同时拷贝数据文件。
注意：如果在热备份的时候如果数据库中断（如断电），那么在重新启动数据库的时候，数据库将提示有数据文件需要恢复，你需要把正在断电时候的处于备份状态的数据文件通过ALTER TABLESPACE …… END BACKUP结束备份方式。具体哪个数据文件或表空间处于备份状态，可以通过v$backup与v$datafile来获得。
作为一个DBA，最重要任务之一可能就是恢复一个应用数据库。当数据库由于某种原因遭到损坏时，就需要将数据恢复到最近一次的正常状态。为了做到这一点，DBA需要制定一个备份策略，使之支持各种不同的恢复情况。因此，制定一个保证顺利恢复数据的备份流程应该是DBA的最高优先级任务。如果没有相应的规划，数据库恢复过程就无法成功完成，DBA也可能因此丢掉工作。在本文中，我将介绍一些关于开发、创建和测试备份策略的概念。
理解备份需求
没有人知道数据库将发生什么情况。它可能由于代码错误或硬件错误而遭到破坏，也可能由于数据中心火灾、水灾或其他灾难事件而丢失数据。为了恢复数据或减少数据库损失，必须根据特定要求备份数据库。
在创建备份策略之前，需要确定备份需求。所谓备份需求，是指需要确定允许丢失多少数据，以及需要多长时间才能恢复所丢失或损坏的数据。允许丢失多少数据，这通常称为恢复点目标（Recovery Point Objective, RPO），而用于恢复丢失数据的时间长度通常称为恢复时间目标（Recovery Time Objective, RTO）。
为了确定环境的RPO或RTO，必须与数据拥有者或客户面谈。客户可以确定他们的数据重要性，以及是否能够在数据库损坏或数据丢失之后重新创建或重新输入数据。下面是一些确定需求的问题列表：
- 数据发生变化的频率有多快？
- 当数据损坏或丢失时，是否能够重新输入或重新创建数据？
- 如果能够重新输入或重新创建数据，时间控制在什么范围才合理？
- 当执行恢复操作时，能够容忍的系统停机时间有多长？
- 能够容忍的数据丢失有多少？
客户需求将指导DBA确定需要设计、创建和测试哪一种备份和恢复策略。
远程、本地和第二备份位置
备份需求很重要，但还需要考虑保存数据库备份的位置。需要保证备份文件的可靠保存，以备在需要时使用，同时要保证它们不会受到服务器故障或数据中心整体事故的影响。因此，DBA需要考虑备份文件的本地存储位置，也可以考虑将备份文件存储在远程位置。
如果要存储在本地，则需要写入或存储备份文件，使得在发生数据库服务器故障或数据库损坏时能够随时使用。将备份文件直接保存在数据库服务器上，可以实现较快的备份写入速度，因为这个过程没有网络I/O操作。但是，如果将备份保存在数据库服务器上，那么当服务器出现故障时，就可能会丢失备份文件。另一种方法是将备份保存到网络磁盘上。这个就可以将备份文件与数据库服务器分离，但是这种方法并没有应对网络备份主机出现问题的第二位置。最好要将备份文件复制到其他备份位置，如磁带机或网络备份存储解决方案。采用这种方式之后，当主备份设备出现故障时，就仍然能够从第二个位置取回备份文件。DBA要保证在备份文件创建之后，马上将它们复制到第二个位置。这样可以最大程度缩短只有一个备份副本的时间。
在本地保存备份文件，就可以在需要恢复数据时快速获得备份文件。但是，当本地设施出现重大事故时，如火灾、水灾或其他自然灾害，又会发生什么结果？如果本地备份发生了问题，那么除非预先将备份文件复制到远程位置，否则就无法恢复数据。由于是开发备份解决方案，所以必须制定一个计划，将备份文件复制到一个安全的远程存储位置。
备份副本保存多长时间？
当确定特定数据库的备份需求时，还需要确定保存这些备份文件的时间长度。保存备份文件的时间越长，就需要为这些备份文件准备更大的磁盘空间。在确定备份文件保存时间时，并没有固定的答案或时间规定。首先需要评估具体环境，然后再确定需要多少个副本，以及这些副本的保存时间。在确定需要保存多少副本时，应该考虑以下问题：
- 数据库更新频率是多少？
- 发现数据问题需要多长时间？
- 恢复备份文件要多快才合理？
当确定保存的备份数量时，需要平衡恢复速度与所使用的空间大小。一旦确定了备份保存时间及所需要的副本数量，一定要让数据拥有者明确计划保存的副本数量及它们恢复回数据库的速度。一定避免这种情况：数据拥有者要求将数据库恢复到30天以前，而你只保存了14天的备份。
备份类型
数据库备份类型有很多种。下表列出了不同的备份类型及其用法的简单描述：
|
备份类型 |
描述 |
|
纯复制（COPY_ONLY） |
不影响正常备份顺序的FULL或TRANSACTION备份 |
|
完全（FULL） |
备份数据库的所有数据 |
|
增量（DIFFERENTIAL） |
备份从上一次FULL、PARTIAL或FILE备份之后发生变化的所有数据 |
|
事务日志（TRANSACTION LOG） |
备份事务日志信息（仅仅与处于FULL恢复模式的数据库相关） |
|
文件（FILE） |
备份一个或多个数据库文件或文件组 |
|
部分（PARTIAL） |
备份所有读写文件组，选择性备份一个或多个只读文件 |
这里每一种类型都有细微区别，它们有不同的用途。最常用的三种备份类型是：完全备份（FULL）、增量备份（DIFFERENTIAL）和事务日志备份（TRANSACTION LOG）。
要确定哪一种备份类型组合最适合你的环境。下面是一些指导方法：
- 如果不担心数据库备份时间写入恢复数据，那么可以执行FULL数据库备份。如果这种类型符合要求，那么还应该将数据库设置为SIMPLE恢复模式，以控制事务日志的增长速度。
- 如果数据库很大，需要较长时间才能完成备份，备份文件又非常大，或者数据库中并非有很多数据库会发生变化，那么可能更适合组合使用FULL或连续DIFFERENTIAL备份方式。
- 如果数据经常变化，而且希望能够及时恢复，那么要考虑组合使用FULL和TRANSACTION LOG备份，或者根据数据库大小使用DIFFERENTIAL备份。
- 如果知道只有特定的文件或文件组发生更新，则适合使用FILE和PARTIAL备份方式。
- 如果想要采用特殊备份方法，例如将数据库移到测试服务器进行测试，但是又不想破坏正常的生产备份过程，那么可以考虑使用COPY_ONLY备份方法。
当数据库环境中实现特定的数据库备份策略时，一定要完全理解RTO和RPO需求，以及每一种不同的备份类型与存储位置如何帮助您实现RTO和RPO时间要求。
建立备份解决方案
一旦确定了备份需求，以及用于保存备份的本地与远程位置，就可以考虑如何执行备份了。大部分人都会使用三种方法创建数据库备份：购买客户自定制（COTS）解决方案，使用SQL Server内置的维护计划方法，或者自行创建备份解决方案。每一种方法都有其自身的优点。
COTS解决方案一般会包含许多附加条件，而且有时候会有比维护计划或自行开发解决方案更多的特性。维护计划解决方案非常容易实现，并且有足够的功能为大多数组织实现可靠的备份解决方案。如果有一些特殊的备份需求，那么实现需求的唯一方法就是自行开发一个备份方案。在自行开发时，要考虑一个问题：DBA需要不停地维护这个解决方案，而COTS和维护计划解决方案则由供应商负责维护。
确认可以执行恢复操作
原因很简单，即使备份了数据库，也不意味着就能够从备份恢复数据库。在创建备份之后，还应该确认这些备份是有效的。
有几种方法可以确认备份有效，其中一种是适时地从保存的备份执行一次真正的数据库恢复操作。这种方法可能不适用于生产环境，但是至少应该定期进行测试，保证可以在非生产环境恢复所保存的备份。
有时候可以验证备份是否写入正确。这可以通过“BACKUP VERIFYONLY”命令实现。这个命令实际上会读取备份文件，然后验证备份的数据是否能够真正恢复。通过使用SQL Server的验证方法，能够检查备份是否写入正确。
恢复一个数据库备份仅仅意味着该备份是正确的，但是并不意味着所有备份是正确的。DBA应该考虑定期执行裸机恢复。要尝试这种方法，需要找一台未使用的主机，然后依次恢复操作系统、SQL Server软件和所有的数据库（包括系统数据库）。执行一次服务器完全恢复可以确认备份策略的有效性，并且也能够有效保证在真正发生灾难事故时能够执行完全恢复。
保证备份文件的安全
在创建备份计划时，需要考虑备份文件的保存位置，以及这些位置的安全性。由于备份文件包含了企业数据，所以需要保证这些备份位置是足够安全的。保证备份位置的安全性，才能保证备份文件不会意外落入外人手中。
如果数据库包含敏感数据，如信用卡号或个人身份数据，那么需要注意这些数据库备份文件的访问权限。如果数据库备份文件没有加密，并且他们有SysAdmin权限，那么其他人很容易通过恢复数据库备份而获取数据。
如果有保密要求，或者数据库存储了敏感数据，那么应该保证只有授权查看、管理和使用数据库备份的人员才允许访问备份位置。此外，可以要求应用程序在数据库中加密保存数据，或者采用某种方式加密数据库备份文件。加密备份文件的一种方法是在包含未加密保密数据的数据库中打开透明数据库加密（Transparent Database Encryption, TDE）。如果使用TDE加密备份文件，就需要开发一种方法，管理和恢复用于加密数据库的证书。如果不能恢复证书，就无法恢复TDE加密数据库。
规模安全性
在开发备份解决方案时，首先需要确定备份的RPO和RTO。确定了这些时间线，就可以指导选择符合要求的备份类型，以及恢复备份的位置。
规模安全性是开发备份策略时需要考虑的问题。正如动物世界一样，只有大量同种动物聚集时，一些特定物种才会感到安全。如果备份数量多于需求，那么DBA也会有安全感。
只有可以恢复所创建的数据库备份时，备份解决方案才会最终生效。DBA需要定期验证备份，而且应该考虑至少每一年左右执行一次全面服务器恢复测试。