这是本节的多页打印视图。 点击此处打印.

返回本页常规视图.

还原备份

您可以使用 vbr 还原任务从 vbr 创建的备份中还原完整的数据库或选定的对象。通常，您可以为这两个操作使用相同的配置文件。最小的还原命令为：

$ vbr --task restore --config-file config-file.ini

您必须使用数据库管理员的帐户（而不是 root）登录。

对于完整还原，数据库必须为 DOWN 状态。对于对象还原，数据库必须为 UP 状态。

通常，您将还原到备份的群集。但是，如果原始群集不再可用，也可还原到备用群集。

还原操作必须在与您从中还原的备份相同的架构上完成。您无法先备份 Enterprise 模式数据库，然后在 Eon 模式下还原它，反之亦然。

您可以对 Permanent 节点类型执行还原任务。您无法在 Ephemeral、Execute 或 Standby 节点上还原数据。若要还原或复制到这些节点，必须先将目标节点类型更改为 PERMANENT。有关详细信息，请参考 设置节点类型。

Vertica 支持将对象复制和还原到目标数据库，但最多支持比当前数据库版本晚一个次要版本。例如，您可以将对象从 11.0.x 数据库复制或还原到 11.1.x 数据库。不同版本的还原或复制过程与相同版本的过程相同。

如果还原或复制的对象需要数据库中不存在的更高版本的 UDx 库，Vertica 将显示以下错误：

ERROR 2858:  Could not find function definition

通过在目标数据库中安装兼容库，您可以解决此问题。

还原 HDFS 存储位置

如果 Vertica 群集使用 HDFS 存储位置，则必须先进行一些额外配置，然后才能还原。请参阅备份和还原 HDFS 存储位置的要求。

HDFS 存储位置仅支持完整备份和还原。您无法在使用 HDFS 存储位置的群集上执行对象备份或还原。

1 - 从完整备份中还原数据库

您可以将完整的数据库备份还原到已备份的数据库，或者具有相同架构的备用群集。例如，若要设置测试群集来调查生产群集中的问题，则需要还原到备用群集。

要还原完整数据库备份，必须验证：

  • 数据库为 DOWN 状态。数据库运行期间不能还原完整备份。

  • 所有备份主机可供使用。

  • 备份目录中存在要还原数据的备份。

  • 备份要还原到的群集需具有：

    • 与创建备份所用的群集具有相同的节点数（Enterprise 模式），或至少与主子群集具有相同的节点数（Eon 模式）

    • 与创建备份使用的架构相同（Enterprise 模式或 Eon 模式）

    • 相同的节点名称

  • 目标数据库必须存在于要将数据还原到的群集。

    • 数据库可以完全为空，不含任何数据或架构。

    • 数据库名称必须与备份中的名称匹配

    • 数据库中的所有节点名称均必须与配置文件中的节点名称匹配。

  • 执行还原操作的用户是数据库管理员。

  • 如果您正在还原 Eon 模式数据库，您可能已满足Eon 模式数据库的要求。

您只能使用完整数据库备份还原完整数据库。如果保存了多个备份存档，您可以从最新备份或特定存档进行还原。

从完整数据库备份中还原时，会将每个备份的 OID 注入到完整数据库备份的还原编录中。该编录还接收所有存档。此外，OID 生成器以及当前时期都会设置为当前时期。

此外，您可以将完整备份还原到与您备份的数据库不同的数据库。请参阅将数据库还原到备用群集。

还原最近备份

通常，当节点或群集为 DOWN 状态时，您希望将群集返回到其最近状态。此操作需要还原完整的数据库备份。您可以通过在配置文件中标识名称，从存档还原任何完整数据库备份。

要从最近的备份中还原，请将 vbr 还原任务与配置文件一起使用。如果您的 密码配置文件不包含数据库超级用户密码，vbr 会提示您输入该密码。

以下示例显示如何使用 db.ini 配置文件进行还原：

> vbr --task restore --config-file db.ini
Copying...
1871652633 out of 1871652633, 100%
All child processes terminated successfully.
restore done!

还原存档

如果保存了多个备份，您可以指定要还原的特定存档。要列出已有存档，以便从中选择一个存档进行还原，请使用 vbr \--listbackup 任务并为其指定特定配置文件。请参阅查看备份。

要从存档中还原，请将 --archive 参数添加到命令行。该值是目录名称的 * date_timestamp * 后缀，用于识别要还原的存档。例如：

$ vbr --task restore --config-file fullbak.ini --archive=20121111_205841

--archive 参数识别了在 11-11-2012 (_archive20121111) 这一天的 205841 (20:58:41) 创建的存档。您只需指定 _archive 后缀，因为配置文件确定了子目录的备份名称，并且 OID 标识符表明了备份是存档。

在 Eon 模式下还原失败

当还原操作失败时，vbr 可能会在公共存储位置留下额外的文件。如果您使用云中的公共存储，这些额外的文件将耗费您的成本。要移除它们，请重新启动数据库并使用实参 true 调用 CLEAN_COMMUNAL_STORAGE。

2 - 将数据库还原到备用群集

Vertica 支持将完整备份还原到备用群集。

要求

此过程类似于从完整备份中还原数据库过程，但具有下列额外的要求：

目标数据库必须：

  • 处于　DOWN 状态。

  • 与源数据库同名。

  • 具有与源群集相同数量的节点。

  • 具有与源群集相同的节点名称。

  • 使用与源数据库相同的编录目录位置。

  • 使用与源数据库相同的端口号。

过程

  1. 将用于创建备份的 vbr 配置文件复制到目标群集上的任意节点。

  2. 如果使用存储密码，请将密码配置文件复制到与 vbr 配置文件相同的位置。

  3. 在目标节点上，发出 vbr 还原命令。

    $ vbr -t restore -c full.ini

  4. 还原完成后，启动还原的数据库。

3 - 从对象级别备份中还原所有对象

要将对象级别备份中的所有对象还原到其最初提取时的数据库，请使用 vbr 还原任务以及创建备份所使用的配置文件，如以下示例所示：

$ vbr --task restore --config-file MySchema.ini
Copying...
1871652633 out of 1871652633, 100%
All child processes terminated successfully.
restore done!

数据库必须处于开启状态。

通过配置配置文件中的 objectRestoreMode 参数，您可以指定 Vertica 如何对重复的对象作出反应。

HDFS 存储位置不支持对象级别备份和还原。

将对象还原到已更改的群集

与从完整数据库备份进行还原不同，vbr 支持在向群集添加节点后还原对象级别备份。创建对象级别备份时不在群集中的任何节点都不参与还原。您可以在还原后重新平衡群集，从而在新节点之间分配数据。

删除节点、更改节点名称或更改 IP 地址后，不能还原对象级别备份。若尝试在执行此类更改后还原对象级别备份，将导致 vbr 失败并显示以下消息：

Preparing...
Topology changed after backup; cannot restore.
restore failed!

还原后的投影时期

所有对象级别备份和还原事件都被视为 DDL 事件。如果某个表不参与对象级别备份（可能由于节点处于关闭状态），还原备份会对投影产生以下影响：

  • 投影时期重置为 0。

  • 投影必须还原其不具有的任何数据（通过比较时期和其他恢复过程）。

还原期间的编录锁

与其他数据库一样，Vertica 事务将遵循严格的锁定协议，以便保持数据完整性。

将对象级别备份还原到处于 UP 状态的群集时，vbr 会首先复制数据并管理存储容器。如有必要，vbr 会拆分容器。此进程不需要任何数据库锁。

完成数据复制任务后，vbr 首先需要一个表对象锁 (O-lock)，然后需要一个全局编录锁 (GCLX)。

在某些情况下，当该进程尝试获取表中的 O 锁时，其他数据库操作（例如 DML 语句）会保持正在进行。在这种情况下，vbr 进程会被阻止，直到 DML 语句完成并释放锁为止。依次获得 O-lock 和 GCLX 锁之后，vbr 会阻止其他在同一个表上需要锁的操作。

当 vbr 持有其锁时，将阻止同时修改表。为了允许完成对象级别的还原，将取消数据库系统操作（例如将数据从内存传输到磁盘的 Tuple Mover (TM)）。

编录还原事件

每个对象级别备份都包含一个数据库编录部分，称为片段。片段包含选定对象、其依赖对象和主体对象。编录片段在结构上类似于数据库编录，但包含一个表示对象信息的子集。可以从编录片段中读取所还原的对象，并使用此类对象来更新全局和局部编录。

已还原备份中的每个对象将在编录中进行更新。如果对象不再存在，vbr 会将该对象从编录中删除。不在备份中的任何依赖对象也将从编录中删除。

vbr 实用程序将使用现有的依赖项验证方法来检查编录，并将还原事件添加到每个已还原表的编录中。该事件还包括发生该事件的时期。如果某个节点缺少还原表事件，则该节点将还原锚定在给定表上的投影。

Vertica 支持将对象复制和还原到目标数据库，但最多支持比当前数据库版本晚一个次要版本。例如，您可以将对象从 11.0.x 数据库复制或还原到 11.1.x 数据库。不同版本的还原或复制过程与相同版本的过程相同。

如果还原或复制的对象需要数据库中不存在的更高版本的 UDx 库，Vertica 将显示以下错误：

ERROR 2858:  Could not find function definition

通过在目标数据库中安装兼容库，您可以解决此问题。

执行还原时，如果编录大小大于节点中可用总内存的 5%，则对象级还原可能会失败。在这种情况下，Vertica 建议从备份中还原单个对象。有关详细信息，请参考 还原单个对象。

另请参阅

4 - 还原单个对象

您可以使用 vbr 从完整或对象级别备份中还原单个表和架构：使用 ‑‑restore-objects 限定 restore 任务，并将要还原的对象指定为以逗号分隔的列表：

$ vbr --task=restore --config-file=filename --restore-objects='objectname[,...]' [--archive=archive-id]

具有以下要求和限制：

  • 数据库必须正在运行，且节点必须处于 UP 状态。

  • 表必须包含其架构名称。

  • 不要在 ‑‑restore-objects 列表的逗号分隔符之前或之后嵌入空格；否则，vbr 将空格解释为对象名称的一部分。

  • HDFS 存储位置不支持对象级别还原。要还原 HDFS 存储位置，必须执行完整还原。

如果架构具有磁盘配额且还原表将超过配额，则该操作将会失败。

默认情况下，‑‑restore-objects 将从最近的备份中还原指定的对象。您可以使用 ‑‑archive 参数从较早的备份中还原。

以下示例使用 db.ini 配置文件，该文件包含数据库管理员的密码：

> vbr --task restore --config-file=db.ini --restore-objects=salesschema,public.sales_table,public.customer_info
Preparing...
Found Database port:  5433
Copying...
[==================================================] 100%
All child processes terminated successfully.
All extract object child processes terminated successfully.
Copying...
[==================================================] 100%
All child processes terminated successfully.
restore done!

对象相关性

当您还原某个对象时，Vertica 不会自动还原任何依赖对象。例如，如果您还原一个包含视图的架构，则 Vertica 不会自动还原这些视图的表。有一个例外：如果数据库表通过外键链接，则必须将其一起还原，但配置文件 vbr 中的 drop_foreign_constraints 设置为 true 时则除外。

重复对象

通过配置 objectRestoreMode，您可以指定还原操作如何处理重复对象。默认情况下，它已设置为 createOrReplace。因此，如果存在重复对象，还原操作将使用存档版本覆盖它。

Eon 模式的注意事项

将对象还原到 Eon 模式数据库时，可能会将不需要的文件留在云存储中。这些文件并不会影响数据库的性能或数据的完整性。但是，它们可能会产生额外的云存储费用。要移除这些文件，请重新启动数据库并使用实参 true 调用 CLEAN_COMMUNAL_STORAGE。

另请参阅

5 - 将对象还原到备用群集

您可以使用还原任务将对象从一个数据库复制到另一个数据库。例如，您可以将表从开发环境“提升”到生产环境。还原到备用群集时，还原单个对象 中所述的所有限制均适用。

要还原到备用数据库，您必须更改用于创建备份的配置文件副本。更改位于 [Mapping] 和 [NodeMapping] 部分。从本质上来说，您为还原操作创建了一个配置文件。vbr 看起来就像目标数据库的备份，但它实际上描述了源数据库的备份。有关示例配置文件，请参阅将对象从备份还原到备用群集。

以下示例使用两个数据库，名为源数据库和目标数据库。源数据库包含一个名为 sales 的表。以下 source_snapshot.ini 配置文件用于备份源数据库：

[Misc]
snapshotName = source_snapshot
restorePointLimit = 2
objectRestoreMode = createOrReplace

[Database]
dbName = source
dbUser = dbadmin
dbPromptForPassword = True

[Transmission]

[Mapping]
v_source_node0001 = 192.168.50.168:/home/dbadmin/backups/

target_snapshot.ini 文件开始为 source_snapshot.ini 的副本。由于 [Mapping] 部分描述了 vbr 运行所在的数据库，因此我们必须更改节点名称以指向目标节点。此外，我们还必须添加 [NodeMapping] 部分并更改数据库名称：

[Misc]
snapshotName = source_snapshot
restorePointLimit = 2
objectRestoreMode = createOrReplace

[Database]
dbName = target
dbUser = dbadmin
dbPromptForPassword = True

[Transmission]

[Mapping]
v_target_node0001 = 192.168.50.151:/home/dbadmin/backups/
[NodeMapping]
v_source_node0001 = v_target_node0001

就 vbr 而言，我们正在从目标数据库的备份中还原对象。而事实上，我们是从源数据库中还原的。

以下命令将 sales 表从源数据库备份还原到目标数据库：

$ vbr --task restore --config-file target_snapshot.ini --restore-objects sales
Starting object restore of database target.
Participating nodes: v_target_node0001.
Objects to restore: sales.
Enter vertica password:
Restoring from restore point: source_snapshot_20160204_191920
Loading snapshot catalog from backup.
Extracting objects from catalog.
Syncing data from backup to cluster nodes.
[==================================================] 100%
Finalizing restore.
Restore complete!

6 - 还原硬链接本地备份

使用还原任务从硬链接本地备份中还原时，其方式与从完整备份中还原的方式相同。如果您使用硬链接本地备份来备份到外部介质，则还需额外执行一些步骤。

与远程存储之间传输备份

当存在完整的硬链接本地备份时，您可以将备份传输到其他存储介质，例如磁带或本地安装的 NFS 目录。将硬链接本地备份传输到其他存储介质可能会复制与硬文件链接关联的数据文件。

将备份文件返回到硬链接本地备份主机时，可以使用其他目录。但在还原备份之前，还必须更改配置文件中的 backupDir 参数值。

完成以下步骤，可从外部介质还原硬链接本地备份：

  1. 如果原始备份目录不再存在，在一个或多个本地备份主机节点上，重新创建该目录。

    用于还原硬链接备份文件的目录结构必须与创建备份时存在的目录结构完全相同。例如，如果在以下备份目录中创建硬链接本地备份，您可以重新创建该目录结构：

    /home/dbadmin/backups/localbak

  2. 将备份文件复制到原始备份目录，如配置文件中为每个节点所指定的一样。有关详细信息，请参考 [Mapping]（/zh-cn/admin/backup-restore/config-file-reference/mapping/）。

  3. 使用以下三个选项之一还原备份：

    1. 要还原备份的最新版本，请将备份文件移动到以下目录：

      /home/dbadmin/backups/localbak/node_name/snapshotname

    2. 若要还原其他备份版本，请将备份文件移动到此目录：

      /home/dbadmin/backups/localbak/node_name/snapshotname_archivedate_timestamp

  4. 备份文件返回到原始备份目录后，请使用原始配置文件调用 vbr。验证配置文件是否指定 hardLinkLocal = true。然后，按如下方式还原备份：

    $ vbr --task restore --config-file localbak.ini

7 - 已还原对象的所有权

对于完整还原，对象拥有备份数据库中的所有者。

执行还原时，Vertica 将数据插入现有数据库对象中。还原默认不会影响被还原对象的所有权或权限。但是，如果还原的对象尚不存在，Vertica 将重新创建该对象。这种情况下，被还原对象由执行还原的用户所有。Vertica 不会还原与被还原对象相关的授予、角色或客户端身份验证。

如果还原对象的存储策略无效，vbr 将应用默认存储策略。由于 HDFS 存储位置、表不兼容以及还原时最小-最大值不可用等原因，还原的存储策略可能会变得无效。

有时，Vertica 会遇到不需要还原的编录对象。当这种情况发生时，Vertica 会为该对象生成一条警告消息，然后继续还原。

示例

假设您具有归用户 Alice 所有的完全备份，包括 Schema1。Schema1 包含 Table1（归 Bob 所有），他最终会将所有权传递给 Chris。用户 dbadmin 会执行还原。以下场景可能会影响这些对象的所有权。

场景 1：

Schema1.Table1 已在自从创建备份后的某个点移除。dbadmin 执行还原时，Vertica 将重新创建 Schema1.Table1。作为执行还原的用户，dbadmin 将取得 Schema1.Table1 的所有权。由于 Schema1 仍存在，Alice 将保留该架构的所有权。

场景 2：

Schema1 及包含的所有对象已移除。当 dbadmin 执行还原时，Vertica 会重新创建架构和所有包含的对象。dbadmin 获得 Schema1 和 Schema1.Table1 的所有权。

场景 3：

Schema1 和 Schema1.Table1 都存在于当前数据库中。当 dbadmin 回退到较早的备份时，对象的所有权仍保持不变。Alice 拥有 Schema1，Bob 拥有 Schema1.Table1。

场景 4：

Schema1.Table1 存在，且 dbadmin 要回退到较早的版本。在执行备份之后，Schema1.Table1 的所有权已更改为 Chris。当 dbadmin 还原 Schema1.Table1 时，Alice 仍为 Schema1 的所有者，Chris 仍为 Schema1.Table1 的所有者。还原不会将 Schema1.Table1 的所有权从 Chris 还原为 Bob。