Using HardFile Link Local Backups
You can use the vbr
utility hardLinkLocal
option to create a full- or object-level backups with hard file links on a local database host.
Creating hard-link local backups can provide the following advantages over a remote host backup:
- Speed — Hard link local backups are significantly faster than a remote host backup. When backing up,
vbr
does not copy files if the backup directory exists on the same file system as the database catalog and data directories. - Reduced network activities — The hard-link local backup minimizes network load because it does not require rsync to copy files to a remote backup host.
- Less disk space — The backup includes a copy of the catalog and hard file links. Therefore, the local backup uses significantly less disk space than a backup with copies of database data files. However, a hard-link local backup saves a full copy of the catalog each time you run
vbr
. Thus, the disk size increases with the catalog size over time.
Hard-link local backups can help you during experimental designs and development cycles. Database designers and developers can create hard-link local object backups of schemas and tables on a regular schedule during design and development phases. If any new developments are unsuccessful, developers can restore one or more objects from the backup.
Note: Running vbr
does not affect active database applications. The vbr
utility supports creating backups while concurrently running applications that execute DML statements, including COPY, INSERT, UPDATE, DELETE, and SELECT.
Planning Hard-Link Local Backups
If you plan to use hard-link local backups as a standard site procedure, design your database and hardware configuration appropriately. Consider storing all of the data files on one file system per node. Such a configuration has the advantage of being automatically set up for hard-link local backups. However, be aware that using one file system per node to support hard-link local backups does preclude the use of external storage locations on separate file systems.
Specifying Backup Directory Locations
The backupDir
parameter of the configuration file specifies the location of the top-level backup directory. Hard-link local backups require that the backup directory be located on the same Linux file system as the database data and catalog files. The Linux operating system cannot create hard file links to another file system.
Do not create the hard-link local backup directory in a database data storage location. For example, as a best practice, the database data directory should not be at the top level of the file system, as it is in the following example:
/home/dbadmin/data/VMart/v_vmart_node0001
Instead,OpenText recommends adding another subdirectory for data above the database level, such as in this example:
/home/dbadmin/data/dbdata/VMart/v_vmart_node0001
You can then create the hard-link local backups subdirectory as a peer of the data directory you just created, such as in this example:
/home/dbadmin/data/backups /home/dbadmin/data/dbdata
Hard-Link Local Backups in Disaster Recovery
Hard-link local backups are only as reliable as the disk on which they are stored. If the local disk becomes corrupt, so does the hard link local backup. In this case, you are unable to restore the database from the hard-link local backup because it is also corrupt.
All sites should maintain full backups externally for disaster recovery because hard-link local backups do not actually copy any database files.