lt_probackup
is a utility to manage backup and recovery of LightDB database clusters.
It is designed to perform periodic backups of the LightDB instance that enable you to
restore the server in case of a failure.
As compared to other backup solutions, lt_probackup
offers the following benefits
that can help you implement different backup strategies and deal with large amounts of data:
Incremental backup: page-level incremental backup allows you to save disk space, speed up backup and restore. With three different incremental modes, you can plan the backup strategy in accordance with your data flow.
Incremental restore: page-level incremental restore allows you dramatically speed up restore by reusing valid unchanged pages in destination directory.
Merge: using this feature allows you to implement "incrementally updated backups" strategy, eliminating the need to do periodical full backups.
Validation: automatic data consistency checks and on-demand backup validation without actual data recovery
Verification: on-demand verification of LightDB instance with the checkdb
command.
Retention: managing WAL archive and backups in accordance with retention policy. You can configure retention policy based on recovery time or the number of backups to keep, as well as specify time to live (TTL) for a particular backup. Expired backups can be merged or deleted.
Parallelization: running backup, restore, merge, delete, verificaton and validation processes on multiple parallel threads
Compression: storing backup data in a compressed state to save disk space
Deduplication: saving disk space by not copying unchanged non-data files, such
as _vm
or _fsm
Remote operations: backing up LightDB instance located on a remote system or restoring a backup remotely
Backup from standby: avoid extra load on master by taking backups from a standby server
External directories: backing up files and directories located outside of the LightDB
data directory
(PGDATA), such as scripts, configuration files, logs, or SQL dump files.
Backup Catalog: get list of backups and corresponding meta information in plain text or JSON formats
Archive catalog: getting the list of all WAL timelines and the corresponding meta information in plain text or JSON formats
Partial Restore: restore only the specified databases or exclude the specified databases from restore.
To manage backup data, lt_probackup
creates a backup catalog. This directory stores
all backup files with additional meta information, as well as WAL archives required for point-in-time
recovery. You can store backups for different instances in separate subdirectories of a single backup catalog.
Using lt_probackup
, you can take full or incremental backups:
Full
backups contain all the data files required to restore the database cluster from scratch.
Incremental
backups only store the data that has changed since the previous backup. It allows
to decrease the backup size and speed up backup operations. lt_probackup
supports the
following modes of incremental backups:
PAGE
backup. In this mode, lt_probackup
scans all
WAL files in the archive from the moment the previous full or incremental backup was
taken. Newly created backups contain only the pages that were mentioned in WAL records.
This requires all the WAL files since the previous backup to be present in the WAL
archive. If the size of these files is comparable to the total size of the database
cluster files, speedup is smaller, but the backup still takes less space.
DELTA
backup. In this mode, lt_probackup
read all
data files in PGDATA directory and only those pages, that where changed since previous
backup, are copied. Continuous archiving is not necessary for it to operate. Also this
mode could impose read-only I/O pressure equal to Full
backup.
PTRACK
backup. In this mode, LightDB tracks page changes on the fly.
Continuous archiving is not necessary for it to operate. Each time a relation page is
updated, this page is marked in a special PTRACK
bitmap for this
relation. As one page requires just one bit in the PTRACK
fork, such
bitmaps are quite small. Tracking implies some minor overhead on the database server
operation, but speeds up incremental backups significantly.
Regardless of the chosen backup type, all backups taken with lt_probackup
support the following strategies of WAL delivery:
Autonomous backups
streams via replication protocol all the WAL files required
to restore the cluster to a consistent state at the time the backup was taken. Even if continuous
archiving is not set up, the required WAL segments are included into the backup.
Archive
backups rely on continuous archiving.
lt_probackup
currently has the following limitations:
The server from which the backup was taken and the restored server must be compatible by
the block_size
(Reports the size of a disk block. It is determined by the
value of BLCKSZ
when building the server. The default value is 8192 bytes.) and
wal_block_size
(Reports the size of a WAL disk block. It is determined by
the value of XLOG_BLCKSZ
when building the server. The default value
is 8192 bytes.) parameters and have the same major release number.
When running remote operations via ssh, remote and local lt_probackup versions must be the same.