Backup Essentials

This article describes the essentials of how backups are managed and used in Exasol.

You can only create a backup of the entire database, not of individual schemas or tables. The backup contains the consistent state of the database at the time when the backup was started, and it includes only completed transactions that were committed at that time.

Backups are run in the background while the database is running, and the process normally has a minimal impact on database performance. How long the backup process takes depends on several factors, such as the size of the database and the location of the archive volume.

Backups can be scheduled or created manually.

Backups are stored on archive volumes. With on-premises installations of Exasol you can create archive volumes either locally in the cluster, or on a remote location. For cloud deployments, only remote archive volumes are supported. Backups are by default stored in a compressed format. On remote archive volumes you can disable compression to allow backups to be stored as raw data.

Backup types

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.

Archive volumes

Database backups can be stored on local and remote archive volumes.

Local archive volume

You can create a local archive volume for storing backups in the cluster. Local archive volumes must be created after you have installed Exasol.

  • Writing to a local backup is fast, since the data stays in the cluster. However, it needs more storage in your cluster than a remote backup.
  • Local archive volumes support the non-blocking, blocking, and virtual access restore types. For more information, see Restore types.

For more information about how to create a local archive volume, see Create Local Archive Volume.

Remote archive volume

You can store your backups on remote archive volumes, which are volumes located on resources outside of the Exasol cluster. Exasol supports FTP/FTPS, SMB, Amazon S3, WebHDFS, Azure Blob Storage, and Google Cloud Storage as remote archives.

  • 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 only support the blocking restore type. For more information, see Restore types.

For more information about how to create a remote archive volume, see Create Remote Archive Volume.

Backup expiration

A backup file can have an optional expiration time, which determines how it is treated by the file system when new files are added to the archive volume.

  • If there is enough space for a new backup, expired backup files in local archive volumes are removed after a new successful backup.

  • If a local archive volume runs out of free space during a backup, expired backup files are automatically removed.

  • If a remote archive volume runs out of free space during a backup, expired backup files are automatically removed if the option cleanvolume is set for the volume. If this option is not set and the remote archive volume runs out of space, the backup will fail.

Restore essentials

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.

A backup can only be restored to a cluster that has the same number of active nodes as the cluster where the backup was taken. This is because the data distribution in an Exasol database depends on the number of active nodes in the cluster.

The database must be stopped when restoring from a backup.

Restore types

Blocking restore

Blocking restore 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 both local and remote archive volumes.

Non-blocking restore

Non-blocking restore allows connections to the database while the restore is ongoing in the background. If sessions request blocks that have not yet been restored, these blocks are restored with priority.

Non-blocking restore is only supported from a local archive volume.

Non-blocking restore is not supported in cloud deployments of Exasol 8.

Virtual access restore

Virtual access restore is limited to blocks that are requested by connected sessions. The database is opened in a special state: changes are allowed, but these changes are not persisted on the data volumes.

Virtual access restore is only supported from a local archive volume.

Virtual access restore is not supported in cloud deployments of Exasol 8.

Virtual restored databases do not count toward the license limit.

For more information, see Restore Database from Backup