This is the multi-page printable view of this section. Click here to print.
vbr provides several tasks related to managing backups: listing them, checking their integrity, selectively deleting them, and more. In addition, vbr has parameters to allow you to restrict its use of system resources.
You can view backups in any of three ways:
Use vbr to list the backups that reside on the local or remote backup host (requires a configuration file).
View historical information about backups using the DATABASE_BACKUPS systems table. Because the database_backups system table contains historical information, it is not updated when you delete the backups
Open the vbr log file to check the status of a backup. The log file resides on the node where you have run vbr, in the directory specified by the vbr configuration parameter tempDir, by default set to /tmp/vbr.
To list backups on the backup hosts, use vbr --task listbackup with a specific configuration file. The following example shows how you can list backups, using a full backup configuration file, bak.ini:
$ vbr --task listbackup --config-file /home/dbadmin/bak.ini
The following table contains information about each output column returned from a vbr listbackup task:
| Output Column | Description |
|---|---|
backup |
The name of the generated backup. Vertica names the backup by combining the name of the vbr configuration file with a timestamp. Use the timestamp to identify an archive when you perform a restore. |
backup_type |
The type of the backup, either full or object. |
epoch |
The epoch when the backup was created. |
objects |
The objects being backed up. For a full backup, this field is blank. |
include_patterns |
Any wildcard patterns included in your object backup tasks using the includeObjects parameter in your configuration file. For a full backup, this field is not displayed. |
exclude_patterns |
Any wildcard patterns included in your object backup tasks using the excludeObjects parameter in your configuration file. For a full backup, this field is not displayed. |
nodes (hosts) |
Enterprise Mode only. The hosts that received the backup and the database node names that provided the backups. |
version |
The version of Vertica used to create the backup. |
file_system_type |
The storage location file system of the Vertica hosts that comprise this backup. Returns Linux, HDFS, GCS, or S3. |
communal_storage |
Eon Mode only. The communal storage location for the backup. |
The following example shows a list of full backups of a three node cluster to a single backup host, 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]
Use the --list-all parameter with the listbackup task to view a list of all the snapshots stored on the hosts and paths listed in the specified configuration file.
$ vbr --task listbackup --list-all --config-file /home/dbadmin/Nightly.ini
The following example shows a --list-all task using the configuration file Nightly.ini. That configuration file references the hosts doca01, doca02, and doca03 and the path /vertica/backup. The output shows that these locations contain not just the backups created using Nightly, but also backups created using a configuration file called 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]
You can also use the the --json and --list-output-file parameters with the listbackup task to output the same content in JSON delimited format to a display or to an output file. For more information, refer to vbr reference.
Use the following query to list historical information about backups. The objects column lists which objects were included in object-level backups. Do not use the backup_timestamp value when restoring an archive. Instead, use the values provided by vbr --task listbackup, when restoring an archive.
=> 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 can confirm the integrity of your backup files and the manifest that identifies them. By default, backup integrity checks output their results to the command line.
The quick-check task gathers all backup metadata from the backup location specified in the configuration file and compares that metadata to the backup manifest. A quick check does not verify the objects themselves. Instead, this task outputs an exceptions list of any discrepancies between objects in the backup location and objects listed in the backup manifest.
Use the following format to perform quick check task:
$ vbr -t quick-check -c configfile.ini
For example:
$ vbr -t quick-check -c backupconfig.ini
The full-check task verifies all objects listed in the backup manifest against filesystem metadata. A full check includes the same steps as a quick check. You can include the optional --report-file parameter to output results to a delimited JSON file. This task outputs an exceptions list that identifies the following inconsistencies:
Incomplete restore points
Damaged restore points
Missing backup files
Unreferenced files
Use the following template to perform a full check task:
$ vbr -t full-check -c configfile.ini --report-file=path/filename
For example:
$ vbr -t full-check -c backupconfig.ini --report-file=logging/fullintegritycheck.json
Vertica can reconstruct backup manifests and remove unneeded backup objects.
The quick-repair task rebuilds the backup manifest, based on the manifests contained in the backup location.
Use the following template to perform a quick repair task:
$ vbr -t quick-repair -c configfile.ini
The collect-garbage task rebuilds your backup manifest and deletes any backup objects that do not appear in the manifest. You can include the optional --report-file parameter to output results to a delimited JSON file.
Use the following template to perform a garbage collection task:
$ vbr -t collect-garbage -c configfile.ini --report-file=path/filename
You can remove existing backups and restore points using vbr. When you use the remove task, vbr updates the manifests affected by the removal and maintains their integrity. If the backup archive contains multiple restore points, removing one does not affect the others. When you remove the last restore point, vbr removes the backup entirely.
Use the following template to perform a remove task:
$ vbr -t remove -c configfile.ini --archive timestamp
You can remove multiple restore points using the archive parameter. To obtain the timestamp for a particular restore point, use the listbackup task.
To remove multiple restore points, use a comma separator:
--archive="restore_point1, restore_point2"
To remove an inclusive range of restore points, use a colon:
--archive="restore_point1: restore_point2"
To remove all restore points, specify an archive value of all:
--archive="all"
The following example shows how you can remove a restore point from an existing backup:
$ vbr -t remove -c backup.ini --archive 20160414_134452
Removing restore points: 20160414_134452
Remove complete!
One of the vbr configuration parameters is tempDir . This parameter specifies the database host location where vbr writes its log files and some other temp files (of negligible size). The default location is the /tmp/vbr directory on each database host. You can change the default location by specifying a different path in the configuration file.
The temporary storage directory also contains local log files describing the progress, throughput, and any errors encountered for each node. Each time you run vbr, the script creates a separate log file, each named with a timestamp. When using default settings, the log file typically uses about 4KB of space per node per backup.
The vbr log files are not removed automatically, so you must delete older log files manually, as necessary.
By default, vbr allows a single rsync connection (for Linux file systems), 10 concurrent threads (for cloud storage connections), and unlimited bandwidth for any backup or restore operation. You can change these values in your configuration file. See Configuration file reference for details about these parameters.
You might want to increase the number of concurrent connections. If you have many Vertica files, more connections can provide a significant performance boost as each connection increases the number of concurrent file transfers.
For more information, refer to the following parameters in [transmission]:
total_bwlimit_backup
total_bwlimit_restore
concurrency_backup
concurrency_restore
and the following parameters in [CloudStorage]:
cloud_storage_concurrency_backup
cloud_storage_concurrency_restore
You can limit network bandwidth use through the total_bwlimit_backup and total_bwlimit_restore data transmission parameters. For more information, refer to [transmission].