1. SinoDB数据库备份和恢复实用程序
-
ontape
— 基本的磁带备份和恢复系统
— 易于使用 -
onbar
— 并行备份和恢复
— 易于使用
— 需要存储管理器程序
— 提供服务器时间点（point-in-time）的恢复
SinoDB数据库提供两种实用程序执行系统备份、逻辑日志备份、和所有的恢复活动。需要时可选择最适合的一种且仅使用那一种。
ontape 实用程序提供了基本的系统备份、日志备份及恢复能力，是在命令行中运行的。ontape 实用程序只能由 sinodbms 登录后执行。
onbar可以与动态服务器提供的存储管理器 （ISM）相结合进行工作。onbar也可以和其它第三方存储管理器配合。所有存储管理器支持的设备都可以用于onbar的备份和复原。除了其他有用的功能外，onbar还能恢复实例到指定时间点。
无论选择哪种实用程序，两者备份和恢复的总体过程是一样的。在本模块中，我们将使用 ontape 实用程序来探究SinoDB数据库服务器的备份和恢复过程。
注意：
ontape 和 onbar 两个实用程序是互相排斥的。使用一种实用程序进行的备份，不能用另一种实用程序复原。
SinoDB数据库服务器支持两种实用程序进行外部 备份和恢复。这允许 DBA 使用其他工具（如 cp 或 tar）来执行备份或恢复。在外部备份或还原期间，服务器上提供只读访问。
2. 什么是备份？
备份 是将全部（ontape 或 onbar）或部分（onbar）数据库服务器对象复制到存储介质中的过程。
备份 是将服务器的 dbspace、blobspace 及逻辑日志文件全部或部分子集复制到磁盘、磁带或光区等辅助存储上的过程。备份过程要确保创建一致的数据映像，即使系统处于在线、多用户模式接收正在进行的事务也是如此。有时，数据库服务器的dbspace、blobspace 和 sbspace 的备份也称为归档 （ archive ） 。
根据所选择的备份实用程序，可以对单个对象、多个对象或整个实例进行备份。备份单个数据库空间或数据库空间组的能力提供了最大的灵活性来满足业务需求。由于 dbspace 中可能包括多个数据库、单个数据库、单个表甚至表的单个分区，所以对于备份和恢复来说，dbspace 备份提供了比表级备份更好的粒度。
3. 增量备份
服务器提供三种不同级别的数据备份，分别为0级、1级和2级备份。
- 0 级
0级备份包含服务器的、或备份启动时处于指定状态的 dbspace的所有数据拷贝。0级是基线备份。
如果磁盘和其他介质完全毁坏且需要替换，则需要所有存储空间的0级备份以及所有相关逻辑日志备份，才能完整地复原所有数据。
-
1 级
1级备份包含自最后一个0级备份后服务器或指定的dbspace中的所有发生变化数据的拷贝。 -
2 级
2级备份包含自最后一个0级或1级备份后（取两者最近者），服务器中发生变化的所有数据拷贝。
4. 创建备份的步骤
当备份启动时，服务器会执行几个内部步骤，内部的准备如下：
-
服务器暂时冻结已经使用的逻辑日志文件的状态，检查空闲空间的大小，空闲空间必须至少为一个逻辑日志文件的一半。如果空闲空间少过一个逻辑日志文件大小的一半，则服务器中止备份。如果发生这种情况，需要备份逻辑日志文件并重新提交备份请求。
onbar会停止备份并自动进行逻辑日志备份，使得可以再次尝试备份。 -
服务器启动检查点。检查点标记备份的同步点。服务器使用时间戳来确定要备份的页面。在备份检查点之后创建或修改的任何页面都不会备份。也会从物理日志中备份那些已修改页面的前映像。
-
服务器在每个需要备份的chunk中，构建一个页面列表。不会备份那些在启动备份检查点时未使用的页。
-
服务器在物理日志中为备份的每个 dbspace创建一个临时表。该临时表用于存储在备份检查点后已修改页面的前映像。这些临时表会创建在 DBSPACETEMP 配置参数指定的 dbspace 中。如果临时空间不足，则服务器中止备份。
-
启动内部备份线程，开始生成备份数据。
5. 同步管理任务
以下的管理变更过程需要进行0级备份。也可以等到下一个定期的0级备份开始前才进行变更。
-
为确保能够恢复数据，在以下情况下必须对root dbspace 进行0级备份：
— 增加镜像
— 增加逻辑日志文件
— 更改物理日志的大小或位置
— 删除chunk或 dbspace -
为回收空间或创建新的 dbspace 或逻辑日志文件，进行以下操作后，也需要对所有受影响的 dbspace 进行0级备份：
— 改变了存储管理器的配置
— 在恢复前增加了 dbspace 或 blobspace
— 启动了含有逻辑日志文件的 dbspace 的镜像
— 增加逻辑日志文件（或使日志文件可用）
— 删除逻辑日志文件
— 更改物理日志的大小或位置
— 删除chunk（在重新使用含有该chunk的 dbspace 前）
6. 什么是逻辑日志备份？
逻辑日志备份是将一个或多个逻辑日志文件内容复制到辅助存储介质的过程。逻辑日志备份使得逻辑日志文件得以重新使用。
逻辑日志文件存储了服务器实例的检查点记录、各种包括 DDL 语句在内的管理活动及数据库的事务活动。每个服务器的逻辑日志文件数量都有限。服务器以循环方式使用逻辑日志文件，在日志文件中顺序写入记录。第一个日志文件写满后，服务器会写入第二个日志文件，以此类推。所有日志文件都写满后，服务器从第一个逻辑日志文件重新写入。在服务器重新使用一个日志文件前，必须先备份该日志文件。
即使服务器中没有数据库使用事务日志，由于有其他数据库操作需要继续记录到逻辑日志中，也必须 备份逻辑日志文件。
6.1 何时备份逻辑日志文件？
-
按需备份——逻辑日志文件的按需备份 将备份所有完整逻辑日志文件，直到当前日志文件为止。有时又称为自动 备份。
-
连续备份——逻辑日志文件的连续 备份是指在逻辑日志写满时就进行备份。
可以使用两种方法对逻辑日志文件进行备份。可以明确开始一个逻辑日志备份，或者使用连续逻辑日志备份：
按需 备份 （在ontape 中称为自动备份 ）要有明确地启动，对所有完整逻辑日志文件进行备份，并到当前日志文件时终止的备份过程。如果选择这个方法，建议要经常备份逻辑日志文件。
连续 备份是最合适有单独磁带设备用于备份和逻辑日志备份的情况。因此，可使用一个磁带设备专门用于连续地逻辑日志备份，另一个磁带设备用于数据库服务器的备份。使用此种方法，逻辑日志文件一旦写满，就会进行备份。
注意：与从备份中恢复页相比，恢复许多逻辑日志记录的速度较慢。为了在恢复过程中尽可能减少日志记录的前滚数量，需要经常对 dbspace 进行备份。
6.2 逻辑日志备份十分重要
需要经常备份逻辑日志文件的原因如下：
-
为了提供完整的事务恢复。
恢复由两部分组成：物理恢复和逻辑恢复。物理恢复应用于恢复备份中的数据。逻辑恢复则前滚备份开始后发生的事务。这些事务存储于逻辑日志中。如果没有备份那些日志，且日志没有存储在磁盘上，就无法重现这些事务。 -
为了防止逻辑日志写满而阻塞数据库服务器。
为了防止存储在逻辑日志中的事务信息丢失，数据库服务器要求：在重新使用日志前，需将其标记为已备份。如果所有的日志均被使用过且没有标记为已备份，服务器将被阻塞，直到逻辑日志备份完成。
动态服务器不允许在日志备份完成前覆盖该日志。但是，可以将 LTAPEDEV 配置参数设置为 /dev/null *。这样，服务器在日志写满时，即使没有备份数据，也将其标记为已备份。但是，如果在这种情况下需要复原，日志是无效的！ -
存储逻辑日志文件的磁盘可能出现故障。
如果丢失了存储逻辑日志文件的磁盘，就无法恢复已经写入日志文件、但是还没有备份到磁带上的所有事务。通过实施连续逻辑日志备份的策略，就尽可能地减少了存储在逻辑日志文件中但还没有备份的事务数量。作为额外的预防措施，也可镜像包含逻辑日志文件的 dbspace。如果主chunk出现故障，镜像chunk依然可用。 -
大多数恢复需要使用逻辑日志备份。
取决于使用的实用程序及其使用方法，完整恢复可能会需要逻辑日志。例如，恢复一个 dbspace（热恢复）需要将物理恢复的 dbspace 和其他 dbspace 同步。这需要使用从备份开始点到当前的所有逻辑日志。
每个实用程序都有特定的场景，在这些场景中，不需要在恢复中使用逻辑日志。如果选择不备份逻辑日志，则必须了解这样做的后果。
7. 使用简单大对象的数据库
对使用简单大对象的数据库的特殊考虑：
-
备份逻辑日志以确保blobpages前映像的及时重用。
-
转换逻辑日志，以便使用新添加的chunk
对于包含存储在 blobspace 中的简单的、二进制大对象（blob）数据的数据库，需要考虑以下问题。这些问题对日志管理决策有影响。
由于服务器不对简单blob数据进行日志的记录，如果更新了带日志数据库中的 BYTE 或 TEXT 列，则简单 blob 将写入 blobspace中的新 blobpages，并保留旧的 blobpage，直到记录对free-map页和free-map列表页（也称为 blob 位图页）所做的更改的逻辑日志被备份。类似地，当删除一个简单blob时，在记录对free-map页和blobbit-map页变更的逻辑日志备份完成前，不会释放blobpages页做重用。所以，为了确保及时重用blobpages页，应尽可能及时备份日志文件。
无论数据库是否使用事务日志，当创建了新的 blobspace或现有 blobspace 中增加了一个chunk时，只有记录这个活动的日志文件不再是当前日志后，新增的chunk才能使用。使用 onmode -l 切换到下一个日志。
记住，在执行备份请求时，如果 blobspace 不可用，则跳过该 blobspace 。
8. 备份智能大对象
-
智能大对象有真正的增量备份
-
sbspace 备份格式有其特定结构：
在所有级别的备份中都包含智能大对象，但是所有智能大对象的备份对备份级别不作要求。从 9.2 版本的动态服务器起，根据智能大对象页最后修改时间，对其进行有条件的备份。这意味着智能大对象有了真正的增量 备份。
决定备份哪些智能大对象是与系统的1级和2级备份判定相同。如果时间戳是位于前一个级别备份的时间戳与当前备份的时间戳之间，那么将对该页进行备份。
确定哪一个 sbspace 页需要备份的方法是与对dbspace 页备份的方法不同。无论何种级别的备份，都需要读取大对象页头的每个条目。在内存中创建一个必须备份的页面的列表。然后读取这些页面、比较时间戳。这一步决定是否会发送某一页面至备份客户端。无论是否有页头（page headers），由于智能大对象的子系统用于操作页面，因此双重级别的访问十分必要。
Sbspace chunk中的元数据区域的备份方法与常规 dbspace 的方法相同，都采用内部动态服务器例程。在智能大对象子系统中，智能大对象页的备份采取不同的备份方法。智能大对象页的备份过程如下：
-
在 sbspace 中放置一个锁，来通过需要备份的所有页面的大对象头的部分创建一个列表。该列表由所有已经使用的页面组成，被称为备份描述符页（backup descriptor page）。
-
发送该列表给服务器的备份线程，以便扫描并检索页面。尽可能使用大缓冲区（Large buffer）写操作。和其他 dbspace 页一样，通过备份线程，将要备份的页发送至备份程序客户端。
-
按上述顺序备份Sbspace的页。备份描述符页有特殊结构，用于记录备份的用户数据的偏移和大小。
8.1 Sbspace的恢复
sbspace 的恢复处理过程如下：
- 1.从磁带中复原元数据。
- 2.备份描述符控制页列出了随后的用户页面的位置。列表的物理地址和extent大小记录在内存表中。
- 3.恢复客户端从磁带中提取智能大对象页，并根据控制页指定的磁盘位置，将其传到将要写入的服务器中。
9. 日志抢救
在以下情况下需进行日志抢救：
- 实例脱机
- 磁盘中的日志文件尚未备份
数据库服务器进入脱机时，仍然可以进行逻辑日志备份。这称为日志抢救（log salvage） 。日志抢救可以备份所有尚未备份的、且没有损坏的逻辑日志文件。在恢复期间，就可以前滚这些日志文件，从而使数据丢失最小化。
为了确保在冷恢复开始前没有数据丢失，应该手动抢救逻辑日志文件。
警告： 在尚未备份或抢救的逻辑日志文件中的事务可能会丢失。
10. 其它备份步骤
除了使用备份实用程序，文件系统中还有一些内容必须手动备份：
- onconfig 配置文件
- sqlhosts 文件
- On-Bar 使用的管理文件
oncfg 文件
紧急启动文件
SinoDB数据库备份和恢复实用程序保障着客户的数据，但也不能代替对所有重要配置文件的正常操作系统备份。为了在紧急情况下的使用，需要有上述管理文件当前版本的备份副本。如果想要替换磁盘或者恢复到另一个的计算机系统中，则必须恢复这些文件。
另外，每个实用程序用于恢复系统的文件集各不相同。一旦决定使用何种实用程序，需要确保备份了成功恢复所需要的所有文件。
10. 物理和逻辑恢复
恢复过程由两部分组成：物理恢复和逻辑恢复。
物理恢复是使用 0级、1级和2级备份恢复 dbspace 和 blobspace 的过程。
逻辑恢复是使用逻辑日志备份磁带上的事务将服务器恢复到故障前状态的过程。逻辑恢复跟在物理恢复之后。
11. 热恢复与冷恢复
-
冷恢复
— 冷恢复发生于root dbspace 或存放日志的 dbspace 无法访问的时候
— 服务器必须处于脱机模式 -
热恢复
— 热恢复发生于root dbspace 和有逻辑日志的 dbspace 可以访问的时候
— 服务器必须处于联机模式 -
混合恢复
— 对关键 dbspace 进行冷恢复
— 对非关键 dbspace 进行热恢复
当出现以下情形时，需要进行恢复：
- 整个服务器系统不可用（无法启动服务器进入联机模式）。
- 有关键 dbspace不可用，如：root dbspace 或存放日志的 dbspace（一个或多个chunk标记为脱机）。
- 有非关键 dbspace 不可用（一个或多个chunk及其相关镜像chunk标记为脱机）。
前两个情形需要进行冷恢复（cold restore） 。冷恢复指服务器处于脱机模式，并且在关键 dbspace 恢复前服务器无法使用。如果非关键 dbspace 无法使用，则可以在联机模式下进行恢复，因此，恢复过程中服务器仍能继续活动。这称为热恢复（warm restore）。
某些时候，即使不是所有的 dbspace都可使用，尽可能快速恢复服务器也十分重要。这样就可能需要混合恢复（mixed restore）。 混合恢复是同时使用冷恢复和热恢复过程，达到完整恢复数据库服务器的目的。首先，仅对关键 dbspace（root dbspace 或存放物理或逻辑日志的 dbspace）进行冷恢复。也可以包括想要立即访问的 dbspace。冷恢复完成后，服务器处于联机模式，用户可以访问服务器。服务器保持在联机模式，对其他 dbspace 进行热恢复。
只有当备份了逻辑日志文件且这些文件可用于逻辑恢复的情况下，才能进行热恢复或混合恢复。