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 local or remote archive volumes in a compressed format.

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 locally in the cluster. The volume can be created at the time of installation or later from EXAoperation.

  • 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. You create the remote archive volumes using EXAoperation. Exasol supports FTP, 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 with Amazon S3.

Monitoring backups

You can monitor backup processes using logservice messages. This can be done in EXAoperation (Services > Monitoring), or by using XML-RPC functions. The logservice shows alerts for the following:

  • Backup start
  • Backup finished
  • Backup failed

Backup expiration

A backup can have an optional expiration time, which determines how the backup is treated by the system when a new backup is created in the same archive volume.

  • If there is enough space for a new backup, expired backups 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 backups will be automatically deleted.

  • Expired backups in remote archive volumes are by default not automatically removed. If the option cleanvolume is set for the remote volume, expired backups are removed after a successful backup.

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 with the exact same number of nodes as the cluster where the backup was taken. This is because the data distribution in an Exasol database depends on the number of cluster nodes.

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.

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 restored databases do not count toward the license limit.

For more information, see Restore from Backup