Vertica uses vbr.py tools that is written in python.
This utility lets you create full and incremental database snapshots, as well as snapshots of specific
schema's or tables for use with a multitenant database.
You can run the Vertica vbr.py from a crontab job or other task scheduler.
Location where you can save the backups:
A local directory on the nodes in the cluster
One or more hosts outside of the cluster
A different Vertica cluster (effectively cloning your database)
Snapshots create with the vbr.py tool requires the same to tool to be restored.
As well as snapshots made with backup.sh tools are only to be restored with backup.sh tool.
Snapshot Configuration Parameters.
Parameter:
RemoveSnapshotInterval
s the number of seconds that Vertica checks for snapshots that can be automatically removed.
Default value -3600
To alter this parameter :
SnapshotRetentionTime
-How long a snapshot can exist before it can be automatically removed.
Default value -3600
To alter this parameter :
VBR Terminology
Snapshots
A consistent image of all objects and data in the database at the time the snapshot is taken.
-Object-level snapshots consist of a subset of database objects, selected by the user. They include other
objects in the dependency graph, and associated data in the database at the time the object-level snapshot is taken.
-We can name our snapshot as we like (blablasnap,1snap,fullsnap,etc)
Archive
A number of same-name snapshots, past and psent. Each archive can have a different retention policy.
Example :
If TSnap names a snapshot of table T, and you take the snapshot daily, keeping 7 snapshots in the archive would
let you revert back to any of the last week's snapshots of table T.
Backup location
The directory location on a backup host where snapshots are saved. This location can comprise multiple snapshots,
including associated archives. All snapshots in the same backup location share data files (through hard links). The
snapshots are also compatible, meaning that after restoring a full database snapshot, any object snapshot from the same
backup location is eligible to be restored.
Object-level snapshot
One or more schemas or tables, or group of such objects, saved on a backup host. The conglomerate parts of the object-level snapshot do not contain the entire database.
In earlier Vertica versions, object-level snapshots could not exist because a snapshot always contained the entire database.
Incremental backups
A successive backup consisting only of new or changed data.
Selected objects
The objects chosen to be part of an object-level snapshot. For example, if tables T1 and T2 are backed up in a snapshot, these objects comprise the selected objects.
Dependent objects
Objects that should be part of an object-level snapshot due to their dependency. For example, a table with a foreign key can exist on its own, but must be backed up with the primary key table, due to table constraints. Projections anchored on a table in the selected objects are also dependent objects.
Principal objects
The objects on which both selected and dependent objects depend. For instance, each table and projection has an owner. The owner is a principal object.
When to Back-up the Database
Whenever you choose to, depending on your needs
Before you upgrade Vertica to another release.
Before you drop a partition.
After you load a large volume of data.
If the epoch in the latest snapshot is earlier than the current ancient history mark .
Before and after you add, remove, or replace nodes in your database cluster.
After recovering a cluster from a crash.
Note: When you restore a database snapshot, you must restore to a cluster that is identical to the one on which you created the snapshot. For this reason, always create a new snapshot after adding, removing, or replacing nodes.
Configuring Backup Hosts
You can backup you database in one or more location, being use full in creating offsite data backups.
The backup hosts you use must:
Have sufficient backup disk space.
Be accessible from your database cluster.
Have password less SSH access for the database administrator account.
Have a copy of the same versions of Python and rsync that were installed by the Vertica installer.
Configuring Single-Node Database Hosts for Backup
Installing Vertica on a single-node database host automatically sets up the node with passwordless SSH access.
The vbr.py utility requires that all database hosts (including single-node hosts) and backup location hosts have passwordless SSH access.
Estimating Backup Host Disk Requirements
Wherever you plan to save data backups, consider the disk requirements for incremental backups at your site.
To see the total used space on your cluster:
To see space used on your cluster separated for each node
Generating the vbr.py Configuration File
The vbr.py utility uses a configuration file for the information it requires to back up and restore a full- or object level snapshot.
You cannot run vbr.py without a configuration file, and no default file exists.
Creating a vbr Configuration File
You can alter the generated file manually as well.
Now to back-up the database follow the syntax :
The command to restore the database is :
Follow a full example of backup-destroy-restore(full/all objects) of a cluster using vbr.py tool:
1 -see cluster state.
2 -see cluster objects
3 -backup the cluster with the full_backup.ini script
4 -drop all objects in the cluster
5 -stop the cluster database
6 -restore the cluster database
7 -start cluster database
8- Verify cluster database content
And there you go we have restored our cluster database successfully.
Generating Different types of vbr.py Configuration File
To create a configuration file:
1. From a command terminal, enter vbr.py command:
Sample Session Configuring Required Parameters:
We are going to describe each parameter of the vbr.py backup configuration file:
Note you can have as many backup configuration file as you need (full/incremental, objects/schema specific, location specific).
We saved the vbr.py configuration to exampleBackup.ini in the actual work directory, or if
you specify the full path when setting config file name
Example:
Note:
Directory ackupConfdoes not exists by default you can create one for the purpose of a better organization.
Configuring Advanced VBR Parameter
To use advanced settings in configuring the backup file choose when:
Examples of backup config files:
(All examples are made on a 3 node cluster called luster)
Before all we must choose our backup host and create specific directories that can be written by the user who running the backup/restore duties.
We will chose our monitoring host for the backup storage (Vertica_Master1)
And we will create the directories needed.
All directories are created now let us create the backup config files:
1-Full database backup config file with 1 level of retention (will be overwritten every time a backup occurs).
See content of the full_backup.ini file
2-Full/Incremental database backup config file with more than one level of retention (values 1-99).
See content of the backup_incremental_7.ini file
3- Object specific database backup config file (as well can have more levels of retention).
Chose some object/objects in the database to backup only
We will backup table public.one
See content of the backup_table_one.ini file
Testing our backup configuration files
To run backup on Vertica using the configuration file created use the following sintax:
To run restore a Vertica backup using the configuration file created use the following sintax:
NOTE:
-to restore/recover a full database you need to have the database shutdown.
Example of test backups
Full backup
The backup files were generated in the specified location
Incremental backup
The backup files were generated in the specified location
Single object backup
The backup files were generated in the specified location
Verify backup location
So backup were created and placed in the supplied directories during backup configuration file.
Restoring the backup of a database from an actual backup
Syntax:
Let's drop all the objects in our database and restore it with our recently made backup
Great, now stop the database so we can restore it. Other-wise you will get an error telling you :
So the database is down.
Now restore the database:
Startup the database and check that your objects are available :
Now let simulate the loss of a table and in this case we will restore the single backup option:
Note:For this restore database must be up and running
Now check that the object is in the database:
Great out table is back and ready to use.
Automating Regular Backups
The vbr.py utility helps to automate backing up you database, because you can configure vbr with the required run-time parameters. The ability to configure runtime parameters facilitates adding the utility to a cron or other task scheduler to fully automate regular backing up your database.
Example of crontab syntax:
How i put it inside my crontab.
So our crontab job will do a full back-up every day at 1 am and will write the output into a log file that resides into