In Exasol, backups are always done while the database is running. The backup created contains the consistent state of the database from 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.
Exasol allows you to store your database backups 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. Here are some of the benefits of the local archive volume:
- It supports 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.
To know more about it, see Create Local Archive Volume.
Remote Archive Volume
You can store your backups on a remote location. You need to create remote archive volumes
- The remote archive volume is beneficial when it comes to fail-safety. If your complete cluster crashes because of any reason, the remote backup is still safe and you can use it to restore your cluster from the remote backup. The remote archive volume's performance is slower than the local volume.
- It supports Blocking Restore.
To know more about it, see Create Remote Archive Volume with Google Cloud Storage .
Exasol provides you with the following two types of backups:
- Full backup: A full backup, also known as level 0 backup contains all database blocks.
- Incremental backup: A backup of data that has been added or modified since the last full or incremental backup. Level 1 to level 9 backups are incremental backups.
The backup levels work as follows:
- Level 0 is a full backup.
- Level 1 is an incremental backup and only changes since the full backup are saved.
- Level 2 is an incremental backup to level 1 and only changes since the last level 1 backup are saved.
- Level 3 is an incremental backup to level 2 and only changes since the last level 2 backup are 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 (and not for specific schemas or tables). The backup includes only completed transactions that were committed at the time the backup started.
The backups process has the following three phases:
- Perform local integrity check.
- Write backup files.
- 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).
Make sure to not do any of the following when a backup is in progress:
- Stop a database.
- Add or remove nodes on an archive volume.
- 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