Parallel backups

You can run two or more identical Aerospike Backup Service (ABS) containers, each pointed at a different slice of the cluster, to back up and restore the full data set in parallel. You can declare the cluster slice by nodes with node-list, or by partitions with partition-list.

ABS treats every backup routine as an independent job definition.

If you create two routines that share the same source cluster and storage destination, and differ only in the slice they read, you can start both routines at the same time, double the aggregate scan bandwidth, and still end up with a complete and non-overlapping backup set.

node-list and partition-list are mutually exclusive fields.

Prerequisites

• A running Aerospike Database deployment
• Two or more ABS containers
• asbench (for generating test data)
• asadm (for verifying test data restoration)

Configuration file sections

The following example shows the minimum content necessary for the first part of the configuration file, aerospike-backup-service.yml.

The first section, which includes aerospike-clusters and storage sections, is identical between instances in a parallel deployment. Only the slice definition changes between the two routines in the next section,backup-routines.

aerospike-clusters:
  absDefaultCluster:
    seed-nodes:
      - host-name: 10.0.48.7
        port: 4333
        tls-name: asd.aerospike.com
    credentials:
      user: tester
      password: psw
    tls:
      name: asd.aerospike.com
      ca-file: /etc/ssl/certs/ca.aerospike.com.pem

storage:
  local:
    gcp-storage:
      bucket-name: abs-testing-bucket
      path: parallel-backup-test

See ABS configuration file examples and ABS configuration file reference for more example configuration files and information about additional parameters.

Backup routines

In the backup-routines section, the two following examples are identical except for how they slice the cluster. Each example defines two backup routines, and each routine defines different slices of the cluster to back up.

Slice by nodes with `node-list`

First ABS container YAML file

backup-routines:
  fullBackupA:
    source-cluster: absDefaultCluster
    storage: local
    interval-cron: '@daily'
    namespaces: [source-ns1]
    node-list:
      - 10.0.48.7:asd.aerospike.com:4333
      - 10.0.48.8:asd.aerospike.com:4333

Second ABS container YAML file

backup-routines:
  fullBackupB:
    source-cluster: absDefaultCluster
    storage: local
    interval-cron: '@daily'
    namespaces: [source-ns1]
    node-list:
      - 10.0.48.9:asd.aerospike.com:4333
      - 10.0.48.10:asd.aerospike.com:4333
      - 10.0.48.11:asd.aerospike.com:4333

partition-list limits each routine to the partitions owned by the listed hosts at the moment the job starts. This pattern is identical to the --node-list flag in the asbackup CLI tool.

Slice by partitions with `partition-list`

First ABS container YAML file

backup-routines:
  fullBackupA:
    source-cluster: absDefaultCluster
    storage: local
    interval-cron: '@daily'
    namespaces: [source-ns1]
    partition-list: "0-2048"

Second ABS container YAML file

backup-routines:
    source-cluster: absDefaultCluster
    storage: local
    interval-cron: '@daily'
    namespaces: [source-ns1]
    partition-list: "2048-2048"

When you specify a list of partitions with partition-list, use the syntax start-count, where the first number is the partition to start at, and the second number is the number of partitions to include. There are 4096 partitions, so splitting at 0-2048 and 2048-2048 covers the entire space across fullBackupA and fullBackupB.

Example parallel backup and restore workflow

This section outlines a series of steps to write test records to a namespace, set up parallel backups with ABS, run the backups, and restore the database.

Run a test parallel backup

1. Generate test data using asbench.

   The benchmark tool writes one million 1 KiB records into the namespace:

   asbench -U tester -P psw -h 10.0.48.7:asd.aerospike.com:4333 -n source-ns1 -w I -k 1000000 -o B960 --tls-enable --tls-cafile=/etc/ssl/certs/ca.aerospike.com.pem

   See the asbench documentation for more information.

2. Start each backup routine separately through the REST API:

   curl -X POST http://service1:8080/v1/backups/schedule/fullBackupA
   curl -X POST http://service2:8080/v1/backups/schedule/fullBackupB

   A POST request to the /v1/backups/schedule/{routine} endpoint triggers an immediate backup, regardless of how the backup routine is scheduled in its interval-cron parameter. Each routine writes to parallel-backup-test/fullBackupA/<timestamp> or parallel-backup-test/fullBackupB/<timestamp>.

3. Inspect the metadata.yaml file in each namespace’s subdirectory inside the backup output directory. Their record-count values should sum to the expected total of 1000000. ABS writes one metadata file per namespace, per routine.

Restore test data

1. Truncate the target cluster so the restore starts without any data present. Run the three following commands in sequence.

   asadm -h 10.0.48.7:asd.aerospike.com:4333 -U tester -P psw --tls-enable --tls-cafile=/etc/ssl/certs/ca.aerospike.com.pem
   
   Admin> enable
   
   Admin+> manage truncate ns source-ns1

   The manage truncate command removes all records immediately.

2. Create separate request bodies for your restore requests.

   restoreA.json

   {
       "routine": "fullBackupA",
       "time": '"$(($(date +%s)*1000))"',
       "destination": {
         "seed-nodes": [
           {
             "host-name": "10.0.48.7",
             "port": 4333,
             "tls-name": "asd.aerospike.com"
           }
         ],
         "credentials": {
           "user": "tester",
           "password": "psw"
         },
         "tls": {
           "name": "asd.aerospike.com",
           "ca-file": "/etc/ssl/certs/ca.aerospike.com.pem"
         }
       },
       "policy": {
         "parallel": 8,
         "batch-size": 100,
       }
     }

   restoreB.json

   {
       "routine": "fullBackupB",
       "time": '"$(($(date +%s)*1000))"',
       "destination": {
         "seed-nodes": [
           {
             "host-name": "10.0.48.7",
             "port": 4333,
             "tls-name": "asd.aerospike.com"
           }
         ],
         "credentials": {
           "user": "tester",
           "password": "psw"
         },
         "tls": {
           "name": "asd.aerospike.com",
           "ca-file": "/etc/ssl/certs/ca.aerospike.com.pem"
         }
       },
       "policy": {
         "parallel": 8,
         "batch-size": 100,
       }
     }

3. Restore each slice with the JSON requests you defined in the previous step.

   curl -X POST http://service1:8080/v1/restore/2025-04-10T12:34:02Z -H "Content-Type: application/json" -d @restoreA.json
   
   curl -X POST http://service2:8080/v1/restore/2025-04-10T12:34:28Z -H "Content-Type: application/json" -d @restoreB.json

   The JSON body follows the schema in the API examples and includes parallel and batch-size under policy to control writer concurrency.

   Note

   You can also pass the raw JSON content after the -d flag rather than saving it as a file.

4. Verify the object counts:

   asadm -h 10.0.48.7:4333 -U tester -P psw --tls-enable --tls-cafile=/etc/ssl/certs/ca.aerospike.com.pem
   Admin> info

   Each of the five nodes should report about 200,000 objects and zero migrations.

Scaling guidelines

ABS exposes a cluster-wide throttle with the max-parallel-scans parameter. Keep this value below the total vCPU count of the Aerospike nodes. Adjust per-reader threads with parallel in a backup policy and per-writer threads with parallel-write. Adjust writer batch size with batch-size in the restore request.

You can monitor throughput via the built-in /metrics endpoint, and basic health with /health and /ready.