This section describes the essentials of how backups are managed and used in Exasol.
Backups can only be done for an entire database, not for specific schemas or tables. The backup contains the consistent state of the database at the time when the backup was started, and includes only completed transactions that were committed at that time.
Backups are run in the background while the database is running, and usually have a minimal impact on database performance. The duration of a backup depends on several factors, such as the size of the database, and whether the backup is being written to a local or remote volume. Backups can be scheduled or run manually as needed.
Backups are stored on archive volumes in a compressed format.
Exasol provides the following two types of backups:
- Full backup (Level 0): A full backup that contains all database blocks.
- Incremental backup (Level 1 - Level 9): A backup of data that has been added or modified since the last full or incremental backup.
The backup levels work as follows:
- Level 0 is a full backup.
- Level 1 is an incremental backup that contains the changes since the full backup was saved.
- Level 2 is an incremental backup to level 1. It contains the changes since the last level 1 backup was saved.
- Level 3 is an incremental backup to level 2. It contains the changes since the last level 2 backup was saved.
- ...and so on until level 9.
Database backups can be stored on local and remote archive volumes.
Local Archive Volume
You can create a local archive volume for cluster internal data backup after installation.
Some of the benefits of the local archive volume are:
- Local archive volumes support Virtual Access Restore, Non-Blocking Restore, and Blocking Restore types.
- Writing a local backup is fast, as the data stays in the cluster. However, it needs more storage in your cluster than a remote backup.
For more information, see Create Local Archive Volume.
Remote Archive Volume
You can store your backups on a remote location. Exasol supports FTP, SMB, Amazon S3, WebHDFS, Azure Blob Storage, and Google Cloud Storage as remote archives.
The main benefits of using a remote archive volume are:
- Remote archive volumes provide better fail safety. If a whole cluster should crash, you will be able to restore the cluster from the remote backup.
- Remote archive volumes support Blocking Restore.
For more information, see Create Remote Archive Volume.
In case of a database instance failure or error, the database can be restored to a previous state using a backup. When the restore has completed, the database will be in the state it was when the backup was started. Any changes applied to the database after the backup start time are lost. Exasol does not support point-in-time recovery. A database state from the past can only be reached based on the start times of the available backups.
The data distribution inside of an Exasol database depends on the number of cluster nodes. Therefore, a backup can only be restored to a cluster with the same number of nodes as the cluster where the backup was taken before.
The database must be stopped when restoring from a backup.
This is the fastest way to restore a database. However, the database cannot be used during the restore process, and connections to the database are prevented until the restore is finished.
Blocking restore is supported from a local archive volume and from a remote archive volume.
For more information, see Restore Database from Backup