Aerospike Backup Service (ABS)
Aerospike Backup Service (ABS) runs on a virtual machine or Docker container and provides a set of REST API endpoints to back up and restore an Aerospike Database cluster. You can perform full and incremental backups and set different backup policies and schedules. There are also several monitoring endpoints to check backup information and the health of the service in general.
Installation options
You can install ABS on Linux, on Kubernetes with or without Aerospike Kubernetes Operator (AKO), or with a Docker Compose file. See Install for installation and setup instructions to get ABS connected to a sample database for testing. See Backup and Restore with AKO for information about using ABS with AKO.
Configure ABS
ABS reads configurations from a YAML file provided when the service is launched. This file arranges the source database clusters, the destination storage, one or more backup policies, and one or more backup routines. See ABS configuration reference and ABS configuration file examples for details about these configuration files.
The ABS REST API can update the configuration and trigger backups on demand. Restore operations are performed with calls to the REST API. See API Usage Examples to learn how to use the REST API to perform common backup and restore tasks.
API specification
Use the OpenAPI generation script included in the GitHub repository to generate an OpenAPI specification for the service that you can host locally. A pre-built OpenAPI specification explaining all configuration and API parameters is also available in Swagger format hosted on GitHub here.
FAQ
How is this tool different from the CLI tools asbackup
and asrestore
?
This tool runs as a separate service constantly listening for REST API requests that trigger backup and restore operations. The CLI tools use the same underlying logic as ABS, but are run as individual commands.
Backups made with ABS are compatible with the asbackup
and asrestore
tools.
Follow the instructions in Direct restore using a specific backup to restore backups done with asbackup
tool that are stored anywhere.
What are full and incremental backups?
Full backups create a copy of all existing data at the time the backup is made. Incremental backups create a copy of all data changed after the most recent full or incremental backup.
For example, if you create a full backup at 2:00 PM, then an incremental backup at 2:30 PM, that incremental backup scans all data changed between 2:00 and 2:30. Another incremental backup at 3:00 would scan all data changed between 2:30 and 3:00. If you restore the database from the 3:00 PM backup, the most recent full backup information, from 2:00 PM, is combined with the changes from all incremental backups made after it.
A backup timestamp refers to the time the backup started, not when it finished.
What happens when a backup doesn’t finish before another starts in the same routine?
-
Full Backups:
- Full backups cannot overlap. If a scheduled full backup is due to start but the previous one is still running, the new backup is skipped entirely. It is not queued but will wait for the next scheduled execution.
- Full backups always take priority over incremental backups. If an incremental backup is running when a full backup is scheduled, the full backup will start as planned, and the incremental backup will continue running without interruption.
-
Incremental Backups:
- By default, incremental backups are skipped if any other backup (full or incremental) is still running. You can change this by setting the
concurrent-incremental
configuration parameter totrue
, which allows incremental backups to run at the same time as other backups. This can happen if the backup process for a large database takes longer than the interval between backups. - Incremental backups do not run until at least one full backup has been successfully completed.
- By default, incremental backups are skipped if any other backup (full or incremental) is still running. You can change this by setting the
Can multiple backup routines be performed simultaneously?
Yes, multiple backup routines can run in parallel. Furthermore, it is possible to back up different namespaces from the same cluster using separate routines with different schedules, all running simultaneously.
To manage resource utilization, you can configure the aerospike-clusters.CLUSTER_NAME.max-parallel-scans
property to limit the number of read threads operating on a single cluster.
Which storage providers are supported?
The backup service supports the following storage providers:
- AWS S3 (or compatible services such as MinIO)
- Microsoft Azure
- Google Cloud Storage
- Local storage (files stored on the same machine where the backup service is running)