当心
保护备份位置并严格限制已有权访问数据库中所有数据的用户对备份的访问权限,这一点十分重要。破坏备份意味着破坏数据库。vbr
提供了几个与管理备份相关的任务:列出备份、检查备份的完整性、选择性删除备份等。此外,vbr
还提供了一些参数,允许您限制其使用系统资源。
vbr
提供了几个与管理备份相关的任务:列出备份、检查备份的完整性、选择性删除备份等。此外,vbr
还提供了一些参数,允许您限制其使用系统资源。
您可以通过以下三种方式查看备份:
使用 vbr
,列出驻留在本地或远程备份主机上的备份(需要配置文件)。
使用 DATABASE_BACKUPS 系统表,查看有关备份的历史信息。因为 database_backups
系统表包含历史信息,因此当您删除备份时不会更新此系统表
打开 vbr 日志文件检查备份的状态。该日志文件存在于您从中运行 vbr 的节点上,且位于 vbr 配置参数 tempDir 指定的目录/tmp/vbr
。
若要列出备份主机上的备份,请将 vbr \--task listbackup
与特定配置文件组合使用。以下示例显示了如何使用完整备份配置文件 bak.ini
列出备份:
$ vbr --task listbackup --config-file /home/dbadmin/bak.ini
下表包含有关从 vbr
listbackup 任务返回的每个输出列的信息:
以下示例显示了一个从三节点群集到单个备份主机 bkhost 的完整备份列表。
backup backup_type epoch objects include_patterns exclude_patterns nodes (hosts) version file_system_type
bak_20160414_134452 full 749 v_vmart_node0001(bkhost), v_vmart_node0002(bkhost), v_vmart_node0003(bkhost) v10.0.0 [Linux]
bak_20160413_174544 full 659 v_vmart_node0001(bkhost), v_vmart_node0002(bkhost), v_vmart_node0003(bkhost) v10.0.0 [Linux]
将 --list-all
参数与 listbackup
任务一起使用,查看指定配置文件中列出的主机和路径上存储的所有快照的列表。
$ vbr --task listbackup --list-all --config-file /home/dbadmin/Nightly.ini
以下示例显示了使用配置文件 Nightly.ini 的 --list-all
任务。该配置文件引用主机 doca01、doca02 和 doca03 以及路径 /vertica/backup
。输出显示这些位置不仅包含使用 Nightly 创建的备份,而且还包含使用名为 Weekly.ini 的配置文件创建的备份。
backup backup_type epoch objects include_patterns exclude_patterns nodes(hosts) version file_system_type
Weekly_20170508_183249 full 3449 vmart_1(doca01), vmart_2(doca01), vmart_3(doca01) v10.0.0 [Linux]
Weekly_20170508_182816 full 2901 vmart_1(doca01), vmart_2(doca02), vmart_3(doca03) v10.0.0 [Linux]
Weekly_20170508_182754 full 2649 vmart_1(doca01), vmart_2(doca02), vmart_3(doca03) v10.0.0 [Linux]
Nightly_20170508_183034 object 1794 sales_schema vmart_1(doca01), vmart_2(doca02), vmart_3(doca03) v10.0.0 [Linux]
Nightly_20170508_181808 object 1469 sales_schema vmart_1(doca01), vmart_2(doca02), vmart_3(doca03) v10.0.0 [Linux]
Nightly_20171117_193906 object 173 sales_schema vmart_1(doca01), vmart_2(doca02), vmart_3(doca03) v10.0.0 [Linux]
您还可以将 --json
和 --list-output-file
参数与 listbackup
任务一起使用,以 JSON 分隔格式将相同的内容输出到显示器或输出文件。有关详细信息,请参考 vbr 引用。
可使用以下查询列出有关备份的历史信息。objects
列列出了在对象级别备份中包括了哪些对象。请不要在还原存档时使用 backup_timestamp
值。相反,应在还原存档时使用 vbr \--task listbackup
提供的值。
=> SELECT * FROM v_monitor.database_backups;
-[ RECORD 1 ]----+------------------------------
backup_timestamp | 2013-05-10 14:41:12.673381-04
node_name | v_vmart_node0003
snapshot_name | schemabak
backup_epoch | 174
node_count | 3
file_system_type | [Linux]
objects | public, store, online_sales
-[ RECORD 2 ]----+------------------------------
backup_timestamp | 2013-05-13 11:17:30.913176-04
node_name | v_vmart_node0003
snapshot_name | kantibak
backup_epoch | 175
node_count | 3
file_system_type | [Linux]
objects |
-[ RECORD 13 ]---+------------------------------
backup_timestamp | 2013-05-16 07:02:23.721657-04
node_name | v_vmart_node0003
snapshot_name | objectbak
backup_epoch | 180
node_count | 3
file_system_type | [Linux]
objects | test, test2
-[ RECORD 14 ]---+------------------------------
backup_timestamp | 2013-05-16 07:19:44.952884-04
node_name | v_vmart_node0003
snapshot_name | table1bak
backup_epoch | 180
node_count | 3
file_system_type | [Linux]
objects | test
-[ RECORD 15 ]---+------------------------------
backup_timestamp | 2013-05-16 07:20:18.585076-04
node_name | v_vmart_node0003
snapshot_name | table2bak
backup_epoch | 180
node_count | 3
file_system_type | [Linux]
objects | test2
Vertica 可以确认备份文件以及识别这些文件的清单的完整性。备份完整性检查默认将结果输出到命令行。
quick-check
任务会从配置文件指定的备份位置收集所有备份元数据,并将该元数据与备份清单进行比较。快速检查不会验证对象本身。此任务会输出备份位置的对象与备份清单中列出的对象之间的任何差异的例外列表。
使用以下格式执行快速检查任务:
$ vbr -t quick-check -c configfile.ini
例如:
$ vbr -t quick-check -c backupconfig.ini
full-check
任务会对照文件系统元数据验证备份清单中列出的所有对象。全面检查包含与快速检查相同的步骤。您可以包括可选的 --report-file
参数,以便将结果输出到分隔的 JSON 文件中。此任务将输出标识以下不一致性的例外列表:
不完整的还原点
损坏的还原点
缺少的备份文件
未引用的文件
使用以下模板执行完整检查任务:
$ vbr -t full-check -c configfile.ini --report-file=path/filename
例如:
$ vbr -t full-check -c backupconfig.ini --report-file=logging/fullintegritycheck.json
Vertica 可以重建备份清单,并移除不需要的备份对象。
quick-repair
任务将基于备份位置中包含的清单来重新构建备份清单。
使用以下模板执行快速修复任务:
$ vbr -t quick-repair -c configfile.ini
collect-garbage
任务将重新构建备份清单,并删除清单中没有的备份对象。您可以包括可选的 --report-file
参数,以便将结果输出到分隔的 JSON 文件中。
使用以下模板执行垃圾回收任务:
$ vbr -t collect-garbage -c configfile.ini --report-file=path/filename
您可以使用 vbr
移除现有的备份和还原点。使用 remove
任务时,vbr
将更新受移除影响的清单,并维持其完整性。如果备份存档包含多个还原点,移除一个还原点不会影响其他还原点。移除最后一个还原点时,vbr
会完全移除备份。
使用以下表单执行移除任务:
$ vbr -t remove -c configfile.ini --archive timestamp
可以使用存档参数移除多个还原点。要获取特定还原点的时间戳,请使用 listbackup 任务。
要移除多个还原点,请使用逗号分隔符:
--archive="restore_point1, restore_point2"
要移除包含范围的还原点,请使用冒号:
--archive="restore_point1: restore_point2"
要移除所有还原点,请指定 all
的存档值:
--archive="all"
以下示例展示了如何从现有备份中移除还原点的过程:
$ vbr -t remove -c backup.ini --archive 20160414_134452
Removing restore points: 20160414_134452
Remove complete!
vbr
配置参数之一是 tempDir。此参数指定 vbr
写入日志文件和其他某些临时文件(大小可忽略不计)的数据库主机位置。默认位置为每个数据库主机上的 /tmp/vbr
目录。可通过在配置文件中指定其他路径来更改此默认位置。
临时存储目录还包含用于描述进度、吞吐量和每个节点遇到的任何错误的本地日志文件。每次运行 vbr
时,脚本均会创建一个单独的日志文件,每个文件均以时间戳命名。使用默认设置时,日志文件通常在每个备份的每个节点占用大约 4 KB 的空间。
vbr
日志文件不会自动移除,因此您必须根据需要手动移除较旧的日志文件。
默认情况下,vbr
允许单个 rsync 连接(用于 Linux 文件系统)、10 个并发线程(用于云存储连接)以及无限带宽(用于任何备份或还原操作)。您可以在配置文件中更改这些值。有关这些参数的详细信息,请参阅配置文件参考。
您可能需要增加并发连接数。如果有很多 Vertica 文件,更多连接可以显著提升性能,因为每个连接可以增加并发文件传输数。
有关详细信息,请参考 [transmission] 中的以下参数:
total_bwlimit_backup
total_bwlimit_restore
concurrency_backup
concurrency_restore
另请参考 [CloudStorage] 中的以下参数:
cloud_storage_concurrency_backup
cloud_storage_concurrency_restore
您可以通过 total_bwlimit_backup
和 total_bwlimit_restore
数据传输参数限制网络带宽使用。有关详细信息,请参考 [transmission]。