Vertica 备份与恢复方案总览

编译：JiangChong

整合自 Vertica KB 5 篇备份恢复系列文章。

📝 文章说明：原文覆盖 Enterprise 模式下的 vbr.py 全量/增量/对象级备份、copycluster/replicate、AWS EBS/RAID-0 备份方案。译者根据 Vertica 26.2.x 官方文档 和 vault 已有知识，补充了 Eon 模式备份恢复（云存储配置、In-DB 恢复点、revive_db 复活、多 namespace 恢复、On-premises 双 endpoint 认证）、VBR S3 兼容存储配置（版本差异与升级陷阱）、VBR 常见故障排查、以及 backup 监控 SQL。

关联：Vertica 维护前准备 Checklist（备份是维护前第 2 步）| K-Safety 最佳实践

概述

备份是数据库日常运维的重要组成部分。Vertica 通过 vbr.py Python 脚本实现备份、恢复以及跨集群复制。根据数据量大小，可以进行全量和增量备份，也可以备份特定的表和 schema。同样，恢复时可以恢复整个数据库或只恢复特定表。Eon 模式下还可通过 revive_db 从公共存储直接复活数据库。

⚠️ 模式限制：不能将 Enterprise 模式备份恢复到 Eon 模式，反之亦然。Eon 数据库必须备份到云存储（S3/GCS/Azure），不支持本地文件系统备份位置。

术语约定： 主集群称为 source，目标集群称为 target。备份始终在 source 上执行，恢复始终在 target 上执行。

本文档示例使用 2 节点集群以便简洁，但实际生产环境应使用 3 节点、K-safety = 1 的集群。

---

场景决策树

根据你的实际情况选择对应方案：

你的备份/恢复需求是什么？
│
├─ 运行在 Eon 模式？
│   ├─ 所有计算节点丢失 → revive_db
│   ├─ 快速回滚误操作 → in-db 恢复点
│   └─ 灾难恢复/公共存储损坏 → Eon vbr 云存储备份恢复
│
├─ source = target（同一集群，备份到外部存储位置）
│   └─ → Part 1: 同集群备份与恢复
│
├─ source ≈ target（两个集群节点数、节点名、dbadmin、版本完全相同）
│   └─ → Part 2: 相似集群间复制
│
├─ source ≠ target（节点数或版本不同）
│   └─ → Part 3: 异构集群间复制
│
└─ 运行在 AWS 上
    └─ → Part 4: AWS 备份恢复指南

你的情况	选这篇文章
Eon 模式，节点丢失或数据损坏	Eon 模式下的备份与恢复
source = target，备份到外部存储位置	Part 1
source 和 target 是两个相同配置的集群（节点数、版本相同）	Part 2
source 和 target 节点数、版本不同	Part 3
在 AWS 上对 Vertica 集群做备份恢复	Part 4

---

Part 1: 同集群备份与恢复

原文：Copy and Restore Data from a Vertica Cluster to a Backup

适用条件： source = target（同一集群），将数据备份到外部备份位置，再恢复到同一集群。

本文示例环境： source 节点 IP 为 10.100.0.66 和 10.100.0.77，target 节点 IP 为 10.100.0.88 和 10.100.0.99。

1.1 备份类型

Vertica vbr.py 工具支持以下三种备份类型：

备份类型	说明	限制
全量备份与恢复（Full backup and restore）	完整复制数据库 catalog、schema、表及其他对象。提供备份时刻的数据库完整镜像	备份时对每张表加 U 锁，阻止 Tuple Mover 删除旧 container
对象级备份与恢复（Object-level backup and restore）	由一个或多个 schema/表（或对象组）组成。不包含整个数据库	仅包含指定对象
Hard-link 本地备份与恢复（Hard-link local backup and restore）	可以是全量或对象级备份。备份由完整的数据库 catalog 副本和一组指向对应数据文件的硬链接组成	仅本地文件系统；不能替代外部常规备份（不防本地系统故障）

1.2 初始化备份配置

Vertica 7.2 起必须先初始化备份位置。配置文件包含数据库快照的元数据和备份文件，用于支持增量备份。

# 第 1 步：创建备份配置文件
/opt/vertica/bin/vbr.py --setupconfig

交互式回答各提示：

Snapshot name (backup_snapshot): backup_snapshot
Number of restore points (1): 5
Specify objects (no default):                    ← 留空 = 全量备份
Object restore mode (coexist, createOrReplace or create) (createOrReplace): createOrReplace
Vertica user name (dbadmin): mydatabase

Node v_mydatabase_node0001
  Backup host name (no default): host1
  Backup directory (no default): backup_location

Node v_mydatabase_node0002
  Backup host name (no default): host2
  Backup directory (no default): backup_location

Config file name (backup_snapshot.ini): backup_snapshot
Saved vbr config to backup_snapshot.

# 第 2 步：初始化备份位置
/opt/vertica/bin/vbr.py -t init --config-file backup_snapshot.ini
# 输出：Initializing backup locations.
#       Backup locations initialized.

1.3 模式 A：全量备份 → 全量恢复

适用场景：

• 机房遭遇灾难，集群全部损失
• 数据库发生多节点、不可恢复的数据损坏，导致全部数据丢失

前提条件：

• target 集群与 source 集群节点数相同
• target 集群与 source 集群具有相同的 IP 地址、dbadmin 用户和数据库名
• source 和 target 运行相同的 Vertica 版本
• 必须已用备份配置文件在备份位置创建了全量备份

执行全量备份

在 source 集群上执行。下面是在 2 节点集群上创建全量备份的示例：

/opt/vertica/bin/vbr.py -t backup --config-file backup_snapshot.ini

# 输出：
# Starting backup of database mydatabase.
# Participating nodes: v_mydatabase_node0001, v_mydatabase_node0002.
# Snapshotting database.
# Snapshot complete.
# Approximate bytes to copy: 348431103 of 348431103 total.
# Copying backup metadata.
# Finalizing backup.
# Backup complete!

关于恢复点： 如果在不同时间点多次备份数据库，Vertica 会记录每次备份之间的差异。每个时间点的备份称为一个恢复点（restore point）。

执行全量恢复

# === 在 target 上创建同名空库 ===
admintools -t create_db -d mydatabase -s v_mydatabase_node0001,v_mydatabase_node0002
admintools -t stop_db -d mydatabase

# === 在 target 上执行全量恢复（指定恢复到哪个时间点）===
/opt/vertica/bin/vbr.py -t restore --archive 20150914_150023 --config-file backup_snapshot.ini

# 输出：
# Starting full restore of database mydatabase.
# Participating nodes: v_mydatabase_node0001, v_mydatabase_node0002.
# Restoring from restore point: backup_snapshot_20150914_150023
# Syncing data from backup to cluster nodes.
# Restoring catalog.
# Restore complete!

--archive 参数用于指定恢复到哪个特定的恢复点（快照名）。

优点	限制
数据库在线运行时可备份	恢复时 target 数据库必须停机
支持多次增量备份	source 和 target 的节点数、IP 地址、数据库名、dbadmin、版本必须完全一致
可从完整数据库丢失中恢复	—
数据变化不大时增量备份非常快	—

1.4 模式 B：全量备份 → 恢复单表

适用场景： 假设你不小心 TRUNCATE 了一张表。如果全库恢复，会丢失上次备份后新增的所有数据。此时就适合只恢复被误删的那张表。

前提条件： 与全量恢复相同。

示例： 全量备份后，误 TRUNCATE store_sales 表。之后又创建了新表 table_order 并插入了数据。如果全库恢复到全量备份的时间点，会丢失 table_order。

-- 备份后做了误操作
TRUNCATE TABLE STORE.STORE_SALES;
-- 验证：表已空
SELECT COUNT(*) FROM STORE.STORE_SALES;  -- 0

-- 之后新增了数据
CREATE TABLE TABLE_ORDER (I INT);
INSERT INTO TABLE_ORDER VALUES (1);
COMMIT DURABLE;

只恢复 store_sales 表：

/opt/vertica/bin/vbr.py -t restore --archive 20150914_195908 \
  --config-file backup_snapshot.ini \
  --restore-objects "store.store_sales"

# 输出：
# Starting object restore of database mydatabase.
# Participating nodes: v_mydatabase_node0001, v_mydatabase_node0002.
# Objects to restore: store.store_sales.
# Restoring from restore point: backup_snapshot_20150914_195908
# Loading snapshot catalog from backup.
# Extracting objects from catalog.
# Syncing data from backup to cluster nodes.
# Finalizing restore.
# Restore complete!

验证结果：

-- store_sales 已恢复
SELECT COUNT(*) FROM STORE.STORE_SALES;  -- 5000000

-- table_order 未受影响
SELECT * FROM TABLE_ORDER;  -- 1

⚠️ 注意参照完整性： 如果要恢复的表有主键或外键约束，务必同时恢复关联的表以维护参照完整性。

优点	限制
支持多次增量备份	恢复时 source 和 target 约束同模式 A
可恢复特定表（非整库）	—
恢复时数据库可以在线运行	—
比全库恢复更快	—
数据变化不大时增量备份很快	—

1.5 模式 C：部分备份 → 恢复单表

适用场景： 数据库中大部分表数据不变（如 Products），但某些表（如 Sales）频繁变化。只需要备份和恢复这些特定表。

前提条件： 与全量备份恢复相同。

备份特定表

# 配置文件 objectbak.ini
[Misc]
snapshotName = objectbak
restorePointLimit = 5
objects = store.store_sales,public.new_table
objectRestoreMode = createOrReplace

[Database]
dbName = mydatabase
dbUser = dbadmin
dbPromptForPassword = False

[Transmission]

[Mapping]
v_mydatabase_node0001 = host1:/vertica/data/objbackup
v_mydatabase_node0002 = host1:/vertica/data/objbackup

/opt/vertica/bin/vbr.py -t backup --config-file objectbak.ini

# 输出：
# Starting backup of database mydatabase.
# Objects: ['public.new_table', 'store.store_sales']
# Participating nodes: v_mydatabase_node0001, v_mydatabase_node0002.
# Snapshotting database.
# Snapshot complete.
# Approximate bytes to copy: 51 of 108630328 total.
# Copying backup metadata.
# Finalizing backup.
# Backup complete!

注意：备份时只复制了 51 字节（仅 catalog 元数据），而数据库总共 108MB。因为这次备份只针对 2 张表。

从部分备份中恢复指定表

/opt/vertica/bin/vbr.py -t restore --config-file objectbak.ini \
  --restore-objects "store.store_sales"

# 输出：
# Starting object restore of database mydatabase.
# Participating nodes: v_mydatabase_node0001, v_mydatabase_node0002.
# Objects to restore: store.store_sales.
# Restoring from restore point: objectbak_20150914_203903
# Loading snapshot catalog from backup.
# Extracting objects from catalog.
# Syncing data from backup to cluster nodes.
# Finalizing restore.
# Restore complete!

优点	限制
数据库在线时备份	仅适用于表和分区
支持多次增量备份	source/target 约束同模式 A
可恢复特定表	—
比全量备份快，节省备份位置磁盘空间	—
恢复时其他表数据不丢失	—

1.6 模式 D：并排表恢复（Side-by-Side）

适用场景： 周一早上发现周末 10 个作业中 9 个通过、1 个失败。失败的作业以不可预测的方式修改了数据。你需要对比当前数据与周五的备份数据，找出差异。

前提条件： 与全量备份恢复相同。

完整步骤：

-- 第 1 步：将当前表重命名（保留修改后的版本）
ALTER TABLE STORE.STORE_SALES RENAME TO STORE_SALES_ORIGINAL;
ALTER PROJECTION STORE.STORE_SALES_SUPER RENAME TO STORE_SALES_ORIGINAL_SUPER;

# 第 2 步：从备份恢复原始表（此时两个版本同时存在）
/opt/vertica/bin/vbr.py -t restore --config-file objectbak.ini \
  --restore-objects "store.store_sales"

# 输出：
# Starting object restore of database mydatabase.
# ...
# Restore complete!

-- 第 3 步：查看两张表
\dt STORE_SALES*
--  Schema | Name                 | Kind  | Owner
--  store  | store_sales          | table | dbadmin
--  store  | store_sales_original | table | dbadmin

现在可以对比 store_sales_original（修改后的版本）和 store_sales（备份版本），然后将 store_sales 更新为正确的数据。通过分区交换合并两个表：

-- 第 4 步：按需交换分区
SELECT SWAP_PARTITIONS_BETWEEN_TABLES(
  'STORE.STORE_SALES', '1', '1', 'STORE.STORE_SALES_ORIGINAL'
);

优点	限制
可恢复已有表的备份	source/target 约束同模式 A
可在活表和备份表之间执行操作	仅适用于表和分区
备份后原表和恢复表同时可用	—

---

Part 2: 相似集群间复制（Enterprise Mode 专属）

原文：Copying Data Between Similar Vertica Clusters

⚠️ copycluster 仅支持 Enterprise Mode，Eon 数据库无效（来源：26.2.x 官方文档）。Eon 模式下用 vbr 备份恢复到另一个集群，或使用 Part 3 的 EXPORT/IMPORT。

适用条件： source 和 target 是两个完全相同的 Vertica 集群 —— 相同的节点数、节点名、dbadmin 用户、Vertica 版本（含 hotfix 版本号）。IP 地址可以不同。

本文示例环境： source 节点 IP 为 10.100.0.66 和 10.100.0.77，target 节点 IP 为 10.100.0.88 和 10.100.0.99。

2.1 模式 A：copycluster（全库复制）

--copycluster 选项将备份和恢复合并为一步操作。Vertica 从 source 备份数据并恢复到 target，整个过程在一个命令中完成。

⚠️ 警告： vbr --copycluster 会覆盖目标集群的所有现有数据。

前提条件：

• target 集群的 IP 地址与 source 不同
• source 和 target 共享相同的节点数、节点名、dbadmin 用户、数据库名、Vertica 版本
• source 和 target 之间配置了免密 SSH

完整步骤

# === 步骤 1：在 target 上安装同版本 Vertica ===
sudo /opt/vertica/sbin/install_vertica --accept-eula \
  --license '/opt/vertica/config/licensing/vertica_community_edition.license.key' \
  --point-to-point --dba-user-password-disabled --ssh-identity

# === 步骤 2：在 target 上创建同名空库 ===
admintools -t create_db -s 10.100.0.88,10.100.0.99 -d mydatabase
# 输出：
# Info: no password specified, using none
# Database with 1 or 2 nodes cannot be k-safe and it may lose data if it crashes
# Database mydatabase created successfully.

# === 步骤 3：停止 target 空库（copycluster 要求 target 停机）===
admintools -t stop_db -d mydatabase
# 输出：
# Info: no password specified, using none
# Connecting to database
# Issuing shutdown command to database
# Database mydatabase stopped successfully

# === 步骤 4：在 source 上创建配置文件 ===
# backup host 填写 target 节点的 IP 地址
/opt/vertica/bin/vbr --setupconfig

交互过程：

Snapshot name (backup_snapshot):
Number of restore points (1): 3
Object restore mode (coexist, createOrReplace or create) (createOrReplace): coexist
Vertica user name (dbadmin):

Node v_verticadb1_node0001
  Backup host name (no default): 10.100.0.88       ← target 节点 IP
  Backup directory (no default):

Node v_verticadb1_node0002
  Backup host name (no default): 10.100.0.99       ← target 节点 IP
  Backup directory (no default):

Change advanced settings? (n) [y/n]: n
Config file name (backup_snapshot.ini): copyclusterconfig.ini
Saved vbr config to copyclusterconfig.ini

# === 步骤 5：在 source 上执行 copycluster ===
# 确认 source 数据库处于 UP 状态后执行
/opt/vertica/bin/vbr --config-file copyclusterconfig.ini --task copycluster

# 输出：
# Starting copy of database mydatabase.
# Participating nodes: v_mydatabase_node0001, v_mydatabase_node0002.
# Enter vertica password:
# Snapshotting database.
# Snapshot complete.
# Syncing data to destination cluster.
# [==================================================] 100%
# Reinitializing destination catalog.
# Copycluster complete!

# === 步骤 6：在 target 上启动数据库并验证 ===
admintools -t start_db -d mydatabase
# 输出：
# Info: no password specified, using none
# Starting nodes:
#   v_mydatabase_node0001 (10.100.0.88)
#   v_mydatabase_node0002 (10.100.0.99)
# Starting Vertica on all nodes...
# Node Status: v_mydatabase_node0001: (DOWN) v_mydatabase_node0002: (DOWN)
# ...
# Node Status: v_mydatabase_node0001: (UP) v_mydatabase_node0002: (UP)
# Database mydatabase started successfully

# 验证数据已复制
vsql -c "\dt store_sales*"
#  List of tables
#  Schema | Name                 | Kind  | Owner
#  store  | store_sales          | table | dbadmin
#  store  | store_sales_fact     | table | dbadmin
#  store  | store_sales_original | table | dbadmin

优点	限制
可创建 source 数据库的完整副本	source 所有节点必须 UP
多次执行 copycluster 支持增量复制	target 必须停机
一步完成备份+恢复	节点数、节点名、数据库名、dbadmin、版本必须一致

2.2 模式 B：replicate（单表复制）

适用场景： source 有 50 张表且已在 target 上备份了 50 张。新增 5 张表，只需要把这 5 张表复制到 target。

特殊之处： source 和 target 可以有不同的节点名和数据库名。

前提条件

必须相同	可以不同
节点数	节点名
Vertica 版本	数据库名
dbadmin 用户名	IP 地址

objectRestoreMode 三种选项

模式	行为	适用场景
coexist	创建带前缀 backup_<timestamp>_<object_name> 的表，与已有表共存	需要对比或合并数据
createOrReplace	在 target 创建同名表；如果有同名表则先删除再创建	直接覆盖
create	仅在 target 创建同名表；如果有同名表则不覆盖	避免意外覆盖

完整步骤（以 coexist 模式为例）

在 source 上创建数据：

-- 创建一张新表并插入数据
CREATE TABLE cluster1_table1 (i INT NOT NULL) PARTITION BY i;

COPY cluster1_table1 FROM stdin;
1
2
3
4
5
\.

SELECT * FROM cluster1_table1;
i
---
2
3
5
1
4
(5 rows)

-- 还有一张不需要复制的表
\dt
Schema |         Name              | Kind  | Owner
public | cluster1_table1           | table | dbadmin
public | table_that_wont_be_moved  | table | dbadmin

在 source 上创建 replicate 配置文件：

/opt/vertica/bin/vbr --setupconfig

交互过程：

Snapshot name (backup_snapshot):
Destination Vertica DB bin directory (only required for object replication) (/opt/vertica/bin):
Number of restore points (1): 3
Specify objects (no default): public.cluster1_table1
Object restore mode (coexist, createOrReplace or create) (createOrReplace): coexist
Vertica user name (dbadmin):
Save password to avoid runtime prompt? (n) [y/n]: n

Node v_mydatabase_node0001
  Backup host name (no default): 10.100.0.88
  Backup directory (no default): /vertica/backuplocation

Node v_mydatabase_node0002
  Backup host name (no default): 10.100.0.99
  Backup directory (no default): /vertica/backuplocation

Change advanced settings? (n) [y/n]: n
Config file name (test1.ini): object_specific_replication.ini
Saved vbr config to object_specific_replication.ini.

生成的配置文件内容：

# object_specific_replication.ini
[Misc]
snapshotName = backup_snapshot
dest_verticaBinDir = /opt/vertica/bin
restorePointLimit = 3
objects = public.cluster1_table1
objectRestoreMode = coexist

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

[Mapping]
v_mydatabase_node0001 = 10.100.0.88:/vertica/backuplocation
v_mydatabase_node0002 = 10.100.0.99:/vertica/backuplocation

修改配置文件（如果 target 数据库名不同）：

[Database]
dbName = targetdb          # ← 改成 target 的数据库名
dbUser = dbadmin

[Mapping]
v_mydatabase_node0001 = 10.100.0.88:/vertica/backuplocation
v_mydatabase_node0002 = 10.100.0.99:/vertica/backuplocation

执行 replicate：

vbr -t replicate -c object_specific_replication.ini

# 输出：
# Configured backup directories in Mapping are ignored for object replication.
# Starting replication of objects ['public.cluster1_table1'] from mydatabase.
# Participating nodes: v_mydatabase_node0001, v_mydatabase_node0002.
# Enter vertica password:
# Snapshotting the source database.
# Snapshot complete.
# Copying catalog snapshot from source to destination.
# Preparing destination database for replicating objects.
# Prep complete, start syncing files.
# Complete syncing files, removing snapshot from the source database.
# Finalizing object replication.
# Object replication complete!

coexist 模式下的数据合并（仅在 coexist 模式下需要）：

-- 在 target 上查看：备份表以 backup_<ts>_public 前缀存在
\dt
Schema                                | Name            | Kind  | Owner
backup_snapshot_20160203221054_public | cluster1_table1 | table | dbadmin
public                                | cluster2_table2 | table | dbadmin

-- cluster2_table2 当前数据（target 本地已有）：
SELECT * FROM public.cluster2_table2;
i
----
15
13
12
14
11
(5 rows)

-- 将备份表的分区数据移动到 target 本地表
-- 两表必须有完全相同的 schema、投影和分区定义
SELECT MOVE_PARTITIONS_TO_TABLE(
  'backup_snapshot_20160203221054_public.cluster1_table1',
  1, 5, 'public.cluster2_table2'
);
输出：5 distinct partition values moved at epoch 17.

-- 合并后的数据：
SELECT * FROM cluster2_table2;
i
----
5
3
2
11
15
15
13
12
4
1
(10 rows)

数据移动后，备份源表（带 backup_ 前缀的表）不再有数据。MOVE_PARTITIONS_TO_TABLE 将数据从原位置移除。

优点	限制
source 和 target 都可以在线	表必须有相同的 schema 和投影定义
支持多次增量备份	需手动迁移 UDF/库（两端必须一致）
可选择单独的表进行迁移	—
比全量备份快，节省磁盘空间	—
source 和 target 可以有不同数据库名和 dbadmin	—
支持双向同步到不同备份位置	—

---

Part 3: 异构集群间复制

原文：Copying Data Between Dissimilar Vertica Clusters

适用条件： source 和 target 节点数不同、Vertica 版本不同。

如果 source 和 target 相似，使用 Part 2 的 vbr.py 方案即可。但跨版本、跨规模的场景需要以下方案。

3.1 方法 A：Vertica EXPORT / IMPORT（推荐）

使用 Vertica 内置的导出/导入功能，将数据从旧版本复制到新版本。即使两个集群的以下方面完全不同，也能轻松复制数据库：

• Vertica 版本
• 节点数
• 数据库名
• dbadmin 用户名

⚠️ 注意： 如果两个集群运行不同版本的 Vertica，务必从最新的版本执行导出/导入，以避免向后兼容性问题。如果两个集群规模不同，务必确保 target 集群有足够空间容纳 source 集群的数据。

相关文档：

• Understanding Vertica Import and Export
• Configuring Network to Import and Export Data
• Export to Vertica（产品文档）

优点	限制
source 和 target 集群大小、节点名、dbadmin、IP、投影和 schema 可全部不同	比 vbr.py 慢
不需要 source 和 target 的所有节点都 UP	需手动迁移 UDF/库（两端必须一致）
支持跨版本数据迁移	—
支持基于 epoch（AHM 之后的所有 epoch）的增量传输	—
可使用特定查询迁移数据	—

3.2 方法 B：第三方工具

可通过 Vertica 支持的第三方应用程序在不同集群间复制数据。数据分别加载到 source 和 target。

例如 Attunity Replicate： 专为大数据分析设计的数据加载加速工具。详见 Qlik (Attunity) 网站上的 Data Management for the Vertica Analytics Platform。

优点	限制
专业的数据同步和加速能力	需要额外购买 license

---

Part 4: AWS 备份恢复指南

原文：Vertica on Amazon Web Services Backup and Restore Guide

适用条件： Vertica 集群运行在 AWS EC2 上。完成本文档步骤的前提是你已有一个部署了数据的 Vertica on AWS 集群。

本文使用 VMart 示例数据库演示从多种故障中恢复的方法。

4.0 K-Safe 集群配置

K-safe 集群通过在其他节点存储 buddy 数据，防止单节点故障导致数据丢失。要成为 K-safe，集群至少需要 3 个节点。详见 K-Safety 最佳实践 和 Designing For K-Safety。

4.1 策略一：从 K-Safe 故障中恢复（无需备份）

适用： 隔离的单节点故障，集群仍为 UP 状态。

从 K-safe 故障恢复不需要备份。如果节点宕机且无法重新连接，必须重新创建该节点。

如果主节点故障，必须先重新分配 Elastic IP，然后将 .pem 密钥文件复制到其他运行中的节点以进行恢复。

步骤 A：创建目标节点

创建目标 AWS 实例时，必须满足以下条件：

要求	说明
子网/网络/VPC	与 source 集群节点位于相同子网、网络和 VPC，且网络配置相同
集群放置组和可用区	与 source 集群节点位于相同的集群放置组和可用区
内网 IP 地址	必须与 source 节点的 IP 地址相同（通过实例创建时的 Network Interfaces 选项指定）
版本兼容性	使用与 source 集群节点相同的 Vertica AMI 版本和 hotfix 版本
实例类型	使用与 source 集群节点相同的实例类型

步骤 B：恢复节点

# 1. 在所有节点上删除故障节点的 .pem key 信息
#    /root/.ssh/known_hosts
#    /home/dbadmin/.ssh/known_hosts

# 2. 在主节点上运行 install_vertica 脚本
#    指定你自己的密钥文件、-Y 选项为 point-to-point、禁用 dba 用户密码
sudo /opt/vertica/sbin/install_vertica -i ~/userkey.pem -Y \
  --point-to-point --dba-user-password-disabled --dba-user dbadmin

# 3. SSH 到目标节点，配置存储以匹配 source 集群
#    创建与 source 节点匹配的空 catalog 和 data 目录
mkdir -p /vertica/data/VMart/v_vmart_node0003_catalog
sudo chown dbadmin:verticadba /vertica/data/VMart

# 4. 使用 admintools 重启目标节点
#    指定目标节点的 IP 地址和数据库名
admintools -t restart_node -s 10.0.10.15 -d VMart

目标节点将从其 buddy 节点恢复数据，使集群恢复 K-safe 状态。恢复时间取决于数据库大小。

4.2 策略二：全量备份（EBS）

适用： 非 K-safe 损失，如多节点故障或全集群故障。

全量备份捕获数据库在特定时间点的完整镜像，是最安全、最稳定的备份方式。

存储注意事项

• 如果使用 ephemeral 存储，必须做全量备份（ephemeral 不持久）。
• 备份卷必须使用 EBS 存储。
• 需要一个完整备份 = 正确格式化并挂载的备份卷 + AWS EBS snapshot + 备份配置文件。

准备备份卷

# 1. 查找每个 source 节点的 data catalog 大小
df -h /vertica/data/
# 关注 Used 列的数字

# 2. 找出所有 source 节点中最大的 data catalog，
#    在此基础上增加 20–50% 的安全余量

# 3. 创建并挂载一个新的 EBS 卷到每个 source 节点
#    卷大小 = 最大 catalog + 安全余量

# 4. 验证新卷已出现在每个节点上
ls /dev

# 5. 在所有节点上执行（使用 Vertica 支持的文件系统）：
sudo mkfs.ext4 /dev/xvdf
sudo mkdir /vertica/backup
sudo mount /vertica/backup
sudo bash -c "echo '/dev/xvdf /vertica/backup ext4 defaults 0 0' >> /etc/fstab"
sudo chown dbadmin:verticadba /vertica/backup

# 6. 验证挂载成功
df -h

创建备份

# 创建配置文件
/opt/vertica/bin/vbr.py --config-file vmart_backup.ini --task backup

# 执行全量备份
/opt/vertica/bin/vbr.py --config-file vmart_backup.ini --task backup

# 验证 vbr.py 无错误完成
# 在每个节点的备份卷上创建 EBS snapshot
# 保存 admintools.conf：/opt/vertica/conf/admintools.conf

• 如果配置文件依赖密码文件，可能需要将密码文件复制到每个节点才能运行 vbr.py。
• 完整初始备份 = EBS snapshot + 备份配置文件 + admintools.conf。
• 后续可做增量备份：重复创建备份 + 创建 snapshot（只保存与首次的差异部分）。
• Snapshot 是异步的，上一个 snapshot 还在进行时可以开始写下一个备份。

从全量备份恢复

如果集群故障，使用备份配置文件和备份卷的 snapshot 从最近一次全量备份恢复。

# === 步骤 1：创建 target 集群 ===
# 新实例必须与 source 集群匹配：
#   - 相同网络/VPC（target 节点之间相同，但不必与 source 相同）
#   - 相同的实例数和节点数
#   - 相同的节点内网 IP 地址
#   - 相同的 AMI 和 Vertica 版本，相同 hotfix 版本
# 可以不同：可用区、实例类型

# === 步骤 2：从 source 备份的 snapshot 创建 EBS 卷 ===
#   为每个节点创建一个卷并挂载到 target 集群的对应节点
#   ⚠️ device mapping 必须正确：例如 node 1 的备份 snapshot
#   必须恢复到新集群的 node 1 上

# === 步骤 3：挂载备份位置 ===
# 在所有节点上，以与 source 相同的文件路径挂载：
sudo bash -c "echo '/dev/xvdf /vertica/backup ext4 defaults 0 0' >> /etc/fstab"
sudo mkdir /vertica/backup
sudo mount /vertica/backup

# 验证备份目录下有数据
ls /vertica/backup/

# === 步骤 4：创建同名空库 ===
# 参考备份的 admintools.conf，使用相同的 dbadmin 用户名/密码、数据路径、数据库名
# 停止数据库（如果正在运行）

# === 步骤 5：执行恢复 ===
/opt/vertica/bin/vbr.py --config-file vmart_backup.ini --task restore

# === 步骤 6：启动数据库，完成恢复 ===

4.3 策略三：Hard-Link 备份（RAID-0）

AWS 上的 hard-link 备份与传统裸机 Vertica 安装截然不同。 由于 RAID-0 软件设备由多个 EBS 卷组成，对每个 EBS 卷做 snapshot 存在极其微小的时间差，会导致备份不一致。因此必须先冻结或卸载 RAID-0 文件系统，然后再做 snapshot。不能在使用 ephemeral 卷的安装上执行 hard-link 备份。

两种执行方式可选：

方法 A：admintools stop（需要停机）

在执行以下步骤之前，需要首先创建一个启用了 hard-link 备份的配置文件（参见 Vertica 文档 Configuring the Hard Link Local Parameter）。如果备份时数据库已停机，恢复时无需 vbr.py 备份和恢复脚本，直接挂载 snapshot 卷即可。但如想维护多个时间点备份，仍可用 vbr.py。

适用于 SLA 允许停机足够长以发起 snapshot 的场景。

# 1. 停止数据库
admintools -t stop_db -d VMart

# 2. 在每个节点上卸载数据卷
umount /vertica/data

# 3. 创建整个集群所有 RAID-0 卷的 EBS snapshot
#    记录每个卷对应的 snapshot ID（恢复时需要）

# 4. 在每个节点上重新挂载数据卷
mount /vertica/data

# 5. 启动数据库
admintools -t start_db -d VMart

必须保存以下文件：

• 每个节点的 RAID-0 配置文件：/etc/mdadm.conf
• 备份配置文件：vmart_backup.ini
• [可选] admintools 配置文件：/opt/vertica/conf/admintools.conf

方法 B：fsfreeze（秒级冻结，几乎不停机）

用 fsfreeze 命令冻结集群，无需停止集群。用户几乎感觉不到性能影响。必须使用 vbr.py 从 fsfreeze 方式创建的备份中恢复。在执行之前，同样需要先创建一个启用了 hard-link 备份的配置文件。

# 1. 在 RAID-0 设备上创建 hard-link 备份（使用已配置 hard-link 的配置文件）
/opt/vertica/bin/vbr.py --config-file vmart_backup.ini --task backup

# 2. 冻结整个集群的 RAID-0 卷（保证 EBS snapshot 一致性）
#    ⚠️ 冻结期间暂停所有数据库/SQL 操作
for IP in 10.0.10.13 10.0.10.14 10.0.10.15; do
  ssh $IP sudo fsfreeze --freeze /vertica/data
done

⚠️ 绝对不要在没有冻结的情况下对 RAID-0 卷做 snapshot！ 没有冻结会直接导致 snapshot 无效。必须检查 fsfreeze --freeze 的返回码，确认设备已冻结再继续。

# 3. 创建所有 RAID-0 卷的 EBS snapshot
#    记录每个卷对应的 snapshot ID

# 4. 所有 EBS 卷所有节点的 snapshot 都已启动后，解冻文件系统
#    注意：无需等待 snapshot 完成即可解冻
for IP in 10.0.10.13 10.0.10.14 10.0.10.15; do
  ssh $IP sudo fsfreeze --unfreeze /vertica/data
done

必须保存以下文件：

• 每个节点的 RAID-0 配置文件：/etc/mdadm.conf
• 备份配置文件：vmart_backup.ini
• [可选] admintools 配置文件：/opt/vertica/conf/admintools.conf

从 Hard-Link 备份恢复

# 1. 创建 target 集群（要求同全量备份恢复：相同网络/VPC、节点数、内网 IP、AMI/hotfix）

# 2. 从备份的 snapshot 创建 EBS 卷

# 3. 挂载新卷之前，先停止并卸载 target 集群上已有的 RAID 卷

# 4. 将新 EBS 卷挂载到 target 集群的对应节点和卷位置
#    ⚠️ device mapping 必须正确：node 1 卷 /dev/xvdf 的 snapshot →
#    新集群 node 1 卷 /dev/xvdf

# 5. 用保存的 mdadm.conf 重建 RAID-0 设备
#    恢复 /etc/mdadm.conf

# 6. 卷挂载完成后，重新挂载 RAID
for IP in 10.0.10.13 10.0.10.14 10.0.10.15; do
  ssh $IP sudo mount /vertica/data
done

# 7. 创建同名空库（相同 dbadmin 用户名/密码、数据路径、数据库名）
#    执行恢复
/opt/vertica/bin/vbr.py --config-file vmart_backup.ini --task restore

两种 Hard-Link 备份方式对比

比较维度	admintools stop	fsfreeze
停机时间	需要完全停机	秒级冻结
适用条件	SLA 允许停机	不能停机的生产环境
恢复工具	可不通过 vbr.py（停机备份的卷直接挂载即可用）	必须通过 vbr.py
多时间点备份	可用 vbr.py	可用 vbr.py

---

Eon 模式下的备份与恢复

以上 Part 1~4 均基于 Enterprise 模式。Eon 模式（计算-存储分离）的 vbr.py 备份操作与 Enterprise 基本一致，但有以下关键差异和独有功能。本节基于 26.2.x 官方文档 补充。

核心差异

Eon 模式同样执行全量/对象级备份和恢复，但数据流向不同：

	Enterprise 模式	Eon 模式
备份目标	本地文件系统或 NFS	云存储（S3/GS/HDFS），通过 [CloudStorage] 配置
配置关键参数	[Mapping] 节点→备份路径	cloud_storage_backup_path + cloud_storage_backup_file_system_path
copycluster	✅ 支持	⚠️ HDFS 公共存储的 Eon 不支持 copycluster
数据冗余	全靠备份	公共存储本身持久（S3 11个9）+ 备份 = 双重保护

Eon 独有：In-Database 恢复点

Eon 模式支持 in-db restore points（来源：26.2.x 文档）——一种零拷贝的数据库快照：

• 存储在数据库内部（communal storage 中），不需要额外备份副本
• 可以快速将数据库回滚到之前的某个时间点
• 限制：与 vbr 备份不同，如果公共存储损坏，恢复点也丢失
• 适合：快速回滚误操作（如错误的数据加载）而不需要从外部备份恢复

-- 第 1 步：创建归档（archive），限制最多保留 15 个恢复点
CREATE ARCHIVE vertica_restore LIMIT 15;

-- 第 2 步：保存恢复点到归档
SAVE RESTORE POINT TO ARCHIVE vertica_restore;

查看所有恢复点：

SELECT * FROM ARCHIVE_RESTORE_POINTS;

回滚到恢复点（需要 revive_db，使用 --restore-point-archive + --restore-point-index 或 --restore-point-id）：

# 使用索引（1 = 最新恢复点）
admintools -t revive_db --communal-storage-location=s3://bucket/path \
  -s host1,host2,host3 -d dbname \
  --restore-point-archive vertica_restore --restore-point-index 1

# 或使用对象 ID
# admintools -t revive_db ... --restore-point-archive vertica_restore --restore-point-id <object_id>

归档管理：ALTER ARCHIVE（修改所有者/限制数）、DROP ARCHIVE [CASCADE]（删除归档）、REMOVE RESTORE POINT FROM ARCHIVE（删除单个恢复点）。

恢复点是 vbr 备份的补充而非替代——两者各司其职：恢复点用于快速回滚，vbr 用于灾难恢复。

Eon 的 vbr 云存储配置

Eon 数据库备份到云存储，需使用 [CloudStorage] 配置段（非 [Mapping]）：

[CloudStorage]
cloud_storage_backup_path = s3://my-backup-bucket/backup/
cloud_storage_backup_file_system_path = /vertica/backup/
cloud_storage_encrypt_at_rest = sse
cloud_storage_ca_bundle = /etc/ssl/certs/ca-bundle.crt

⚠️ 每个备份路径只能用于一个数据库，不能多个数据库共用同一路径。

多 namespace 数据库：Eon Mode 默认只有一个 default_namespace。如果创建了多个 namespace，vbr 中使用点号前缀表示对象：.namespace.schema.table（如 .store_1.orders.*）。对象级备份/恢复/replicate 时可通过 --target-namespace 指定目标 namespace。

HDFS 存储限制：如果数据库有 HDFS 存储位置，HDFS 上的数据仅支持全量备份，不支持对象级备份。且 HDFS 目录必须开启快照功能。

Eon 恢复的额外要求

Eon 模式恢复到 target 数据库时，除 Enterprise 已有的要求外，还需满足：

要求	说明
节点数	target 至少与 source 的 primary subcluster 节点数相同
节点名	必须与 source 相同
catalog 目录	必须与 source 使用相同的 catalog 目录路径
端口号	必须与 source 相同
对象级恢复到已有 namespace	shard count、shard boundary、node subscription 必须与 source namespace 一致

恢复时可以只恢复 primary subcluster，secondary subcluster 不要求匹配。

Eon On-Premises 备份的认证配置

如果 Eon 使用本地 S3 兼容存储（非 AWS），公共存储和备份目标可能不是同一个 endpoint，需要分别配置环境变量：

# 公共存储的认证（communal storage）
export VBR_COMMUNAL_STORAGE_ENDPOINT_URL='http://your-s3.local'
export VBR_COMMUNAL_STORAGE_ACCESS_KEY_ID='access-key-1'
export VBR_COMMUNAL_STORAGE_SECRET_ACCESS_KEY='secret-key-1'

# 备份目标的认证（backup storage）—— 可能是不同的 endpoint
export VBR_BACKUP_STORAGE_ENDPOINT_URL='http://backup-s3.local'
export VBR_BACKUP_STORAGE_ACCESS_KEY_ID='access-key-2'
export VBR_BACKUP_STORAGE_SECRET_ACCESS_KEY='secret-key-2'

⚠️ Eon on-premises 备份不支持 AWS IAM profile 认证。

revive_db 复活（终极恢复手段）

当所有计算节点丢失但公共存储完好时，可从公共存储直接复活数据库：

admintools -t revive_db \
  --communal-storage-location=webhdfs://hacluster/verticaeon/<dbname> \
  -s 'v001,v002,...' --force -d <dbname>
admintools -t start_db -d <dbname> -F

revive_db 只能恢复公共存储中仍然完好的数据。如果公共存储也损坏，必须使用 vbr 备份恢复。

---

VBR S3 兼容存储配置

来源：某客户 Vertica 数仓备份到 S3 兼容对象存储报错问题处理报告

VBR 支持将备份存储到 S3 兼容的对象存储（如日立 HCP、MinIO 等），但版本间配置方式有重大变化：

版本	配置方式	注意
v9.1	直接修改 /opt/vertica/bin/vbr 脚本中的 s3_endpoint_url	hack 方式，升级后失效
v9.3+	通过环境变量配置	升级到 9.3+ 后必须迁移到环境变量方式
v11+	环境变量 + VBR_* 前缀变量	推荐使用

9.3+ 环境变量示例：

export VBR_COMMUNAL_STORAGE_ENDPOINT_URL='http://your-s3-endpoint.com'
export VBR_BACKUP_STORAGE_ENDPOINT_URL='http://your-s3-endpoint.com'
export VBR_COMMUNAL_STORAGE_ACCESS_KEY_ID='your-access-key'
export VBR_COMMUNAL_STORAGE_SECRET_ACCESS_KEY='your-secret-key'
export VBR_BACKUP_STORAGE_ACCESS_KEY_ID='your-access-key'
export VBR_BACKUP_STORAGE_SECRET_ACCESS_KEY='your-secret-key'

⚠️ 升级陷阱：从 v9.1 升级到 v9.3+ 后，原有脚本 hack 失效，VBR 会拼接出错误的 S3 URL（如 https://bucket.s3.bucket.amazonaws.com/），必须在升级前迁移到环境变量方式。

---

VBR 常见故障排查

1. Mapping 简写 [] 不兼容

现象：

Error: Error accessing remote storage: faild accessing remote storage...
ssh_exchange_identification: Connection closed by remote host

根因：某些版本（如 v11.1.1-6）的 VBR 不支持 Mapping 中的 [] 简写（表示本地 localhost）。

修复：将 [] 替换为实际 IP 地址：

# 错误：
v_cicdb_node0001 = []:/data/backups

# 正确：
v_cicdb_node0001 = [10.27.70.60]:/data/backups

2. DNS/防火墙阻断备份

现象：扩容后新增节点无法解析 S3 endpoint，备份失败。

排查：

• 检查新增节点到 DNS 服务器的 53 端口（TCP/UDP） 是否通
• 检查到对象存储的 80/443 端口 是否通

3. SSH/rsync 超时

备份到远程文件系统时，检查：

# rsync 版本一致性
cls_run rpm -qa | grep rsync

# SSH 连通性
ssh dbadmin@<backup_host>

# rsync 可用性
rsync test.txt <backup_host>:~/

如果 SSH 连接频繁断开，配置 /etc/ssh/sshd_config：

TCPKeepAlive yes
ClientAliveInterval 30
ClientAliveCountMax 99999

---

监控备份状态

查看历史备份信息（来源：DATABASE_BACKUPS）：

-- 查看所有备份记录
SELECT database_name, backup_timestamp, backup_type,
       backup_size_bytes, is_full_backup
FROM v_monitor.database_backups
ORDER BY backup_timestamp DESC;

---

备份方案选择决策框架（更新）

你的数据库模式？
├── Eon 模式
│   ├── 所有节点丢失？→ revive_db（前提：公共存储完好）
│   ├── 误删表/数据损坏？→ vbr.py catalog 恢复
│   └── 公共存储损坏？→ 公共存储的跨区域复制/snapshot
│
└── Enterprise 模式
    ├── source = target？→ Part 1 同集群备份恢复
    ├── source ≈ target？→ Part 2 相似集群复制
    ├── source ≠ target？→ Part 3 EXPORT/IMPORT
    └── AWS 环境？→ Part 4 EBS/RAID-0

| 方案 | 适用场景 | 节点数 | 版本 | 工具 | 停机要求 | 模式限制 | |------|----------|:---:|:---:|------|:---:| | 全量备份恢复 | 同集群灾难恢复 | 必须相同 | 必须相同 | vbr.py | target 恢复时停机 | Enterprise / Eon | | 全量备份→恢复单表 | 误删表，部分恢复 | 必须相同 | 必须相同 | vbr.py | 无需停机 | Enterprise / Eon | | 部分备份→恢复单表 | 只备份变化频繁的表 | 必须相同 | 必须相同 | vbr.py | 无需停机 | Enterprise / Eon | | 并排表恢复 | 对比备份前后差异 | 必须相同 | 必须相同 | vbr.py | 无需停机 | Enterprise / Eon | | copycluster | 整库 A→B | 必须相同 | 必须相同 | vbr.py | target 停机 | ⚠️ Enterprise 专属 | | replicate | 同步特定表到另一集群 | 必须相同 | 必须相同 | vbr.py | 无需停机 | Enterprise / Eon | | EXPORT/IMPORT | 异构集群迁移 | 可不同 | 可不同 | SQL | 无需全部 UP | Enterprise / Eon | | K-safe 节点恢复 | AWS 单节点故障 | 必须相同 | 必须相同 | admintools | 无需停机 | Enterprise / Eon | | EBS 全量备份 | AWS 多节点/全集群故障 | 必须相同 | 必须相同 | vbr.py + EBS | 备份时在线 | Enterprise / Eon | | RAID-0 hard-link | AWS 高性能备份 | 必须相同 | 必须相同 | vbr.py + fsfreeze | admintools:停机 / fsfreeze:秒级 | Enterprise / Eon |

---

与维护 Checklist 的关系

Vertica 维护前准备 Checklist
│
├─ 步骤 1: 检查节点依赖  → [K-Safety 最佳实践](../03.performance-tuning/k-safety-best-practices.md)
│
├─ 步骤 2: 备份数据库     → 本文（5 篇整合）
│   ├─ 标准备份（vbr.py）       → Part 1 全量备份
│   ├─ 冷备份（手动复制目录）     → Part 1 → 维护 Checklist §2 方法 B
│   ├─ 集群复制                 → Part 2 copycluster
│   └─ AWS 环境                → Part 4 EBS / RAID-0 hard-link
│
├─ 步骤 3: 安全关机
│
└─ 步骤 4: 验证关机

扩展阅读

• ROS Bundling 最佳实践 — 减少文件数量以加速备份
• Vertica 维护前准备 Checklist — 维护前完整流程（备份是第 2 步）
• K-Safety 最佳实践 — K-safety 与节点依赖
• Vertica RAID 存储方案 — RAID 存储选型指南
• Vertica Eon 模式数据库的备份 — Eon 模式备份方案