Backup Essentials

This section describes the essentials of how backups are managed in Exasol.

  • Backups must be done while the database is running.
  • The backup contains the consistent state of the database at the time when the backup was started.
  • The scope of any backup is the whole database, it cannot be limited to only certain objects or schemas.
  • Backups are stored on archive volumes.

Archive Volumes

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

Local Archive Volume

You can create the local archive volume for cluster internal data backup at the time of installation or later from EXAoperation. Some of the benefits of the local archive volume are:

For more information, see Create Local Archive Volume.

Remote Archive Volume

You can store your backups on a remote location. You need to create remote archive volumes from EXAoperation. 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 Blocking Restore.

For more information, see Create Remote Archive Volume with Amazon S3 .

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.

Backup processes run in the background and usually have a minimal impact on database performance. The duration of a backup depends on various factors, such as the size of the database and whether the backup is being written to a local or remote volume.

Backups can only be done for an entire database, not for specific schemas or tables. The backup includes only completed transactions that were committed at the time the backup started.

Backup Process

The backup process has the following three phases:

  1. Perform local integrity check
  2. Write backup files
  3. Validate backup files

During the write process, the backup data is compressed. If more disk space is required, the backup process automatically deletes expired backups (this is not applicable to remote archive volumes).


To prevent risk of data loss, make sure to not do any of the following when a backup is in progress:

  • Do not stop the database.
  • Do not add or remove nodes on the archive volume.
  • Do not add or remove nodes on the data volume of the database being backed up.


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

  • Backup start
  • Backup finished
  • Backup failed