Introducing absctl: A generational upgrade to Aerospike backup and restore

In large Aerospike deployments, backup operations are part of the production system. They have to be predictable under load.

For years, asbackup and asrestore have powered backups across Aerospike clusters. They have handled the job reliably. But they were designed for a previous era of deployments, when datasets were smaller, deployment patterns were simpler, and clusters were not as widely distributed or deeply integrated with cloud infrastructure.

As clusters grew into multi-terabyte namespaces and began spanning multiple availability zones, running millions of transactions per second with sub-ms latencies for mission-critical applications, the limitations of the legacy backup tool became increasingly apparent. In production environments, teams saw:

• Uneven load distribution across the database cluster, with certain cluster nodes running hotter than others during backups.

• Backup traffic interfering with production workloads, requiring manual cluster tuning to limit impact to production traffic.

• Additional cloud integration overhead, including provisioning extra disks to stage backups before pushing them to object storage.

We repeatedly heard these issues from teams running large production environments. So, instead of layering incremental changes onto the existing tools, we re-architected how backups should behave at scale, with one clear goal: ensure minimal and predictable cluster impact and seamless operation in cloud-native deployments.

The result is absctl, a generational upgrade to asbackup and asrestore. It is built for large, distributed clusters, designed for cloud-native deployments, and fully backward compatible with asbackup and asrestore for straightforward migrations. Built in Go, it provides a modern, flexible foundation for rapid evolution.

One CLI for backup and restore

absctl replaces both asbackup and asrestore with a single command-line interface.

Instead of two separate tools:
asbackup …
asrestore ...

You now use:
absctl backup …
absctl restore ...

Backup and restore now share a consistent structure and configuration model. This simplifies scripting, automation, and documentation.

Balanced load across the cluster

One of the biggest challenges at scale is uneven pressure on cluster nodes during the backup process.

Unlike asbackup, absctl is built for high concurrency. It parallelizes partition scanning across multiple nodes simultaneously, increasing throughput while distributing work more evenly across the cluster.

You control concurrency with the --parallel flag:

absctl backup -h 127.0.0.1:3000 -n my-namespace  -d /backup  --parallel 8

By spreading work across nodes instead of concentrating it on a subset, absctl maintains more stable latency during backup windows and avoids creating hot spots.

You can also cap throughput explicitly, just as you could with asbackup:

absctl backup -h 127.0.0.1:3000 -n my-namespace  -d /backup --records-per-second 50000 --bandwidth 100

Because the underlying engine of absctl is significantly more capable than its predecessor, testing and tuning in staging before updating production workflows is strongly recommended. absctl can achieve higher throughput even with lower parallelization settings. Proper tuning ensures you maximize performance without over-taxing cluster resources.

Reduce cross availability zone data transfer costs

In multi-availability zone deployments, cross-AZ data transfer costs can add up quickly during backups.

absctl reduces those costs by keeping backup traffic local. It improves how work is divided across the cluster, including more efficient partition range handling, while incorporating rack awareness to intelligently select nodes during backup operations. This minimizes unnecessary inter-AZ network traffic and keeps reads closer to where the data resides.

You can explicitly control which racks absctl reads from.

To prefer a rack:
absctl backup --prefer-racks 1  

To strictly limit reads:
absctl backup --rack-list 1  

This allows you to keep backup traffic local to an availability zone, eliminate avoidable cross-AZ egress fees, and minimize cross-zone latency impact during backup windows.

Direct to object storage

Modern deployments expect backup workflows to integrate cleanly with cloud storage. absctl natively supports direct uploads to Amazon S3, Google Cloud Storage, Azure Blob Storage, and S3-compatible systems, such as MinIO. It is no longer required to back up locally and then copy files to object storage.

Example:

absctl backup -h 127.0.0.1:3000  
-n my-namespace  
-d backups/daily  
--s3-bucket-name my-backup-bucket  
--s3-region us-west-2  

You can also specify storage tiers at write time, such as S3 Glacier or GCS Coldline, allowing you to optimize cost based on retention policies. Backups stream directly to the storage tier you choose, eliminating staging disks and additional copy steps.

Restore with absctl

Restore behavior remains consistent with the legacy asrestore tool. Restoring from a backup is straightforward:

absctl restore -h 127.0.0.1:3000 -n my-namespace -d /backup

absctl uses the same .asb file format, so existing backups created with asbackup can be restored without modification.

One CLI for backup and restore

absctl replaces both asbackup and asrestore with a single command-line interface.

Instead of two separate tools:

asbackup … asrestore ...

You now use:
absctl backup …
absctl restore ...

Backup and restore now share a consistent structure and configuration model. This simplifies scripting, automation, and documentation.

The enterprise requirements you expect

absctl continues to support the core capabilities you relied on with asbackup and asrestore. These features remain consistent with the legacy tools.

• Namespace, set, and filter-based backups  

• Partition and time range filtering  

• ZSTD compression  

• AES-128 and AES-256 encryption  

• Incremental backups  

• Backup to local or direct cloud targets (S3, GCS, Azure Blob)  

• Control over backup file limits  

• Structured YAML configuration  

• Structured JSON logging  

• TLS and authentication  

• Aerospike Secret Agent integration  

• Resumable backups

How absctl relates to ABS

absctl is a CLI. You run it, it does the job, and it exits. Aerospike Backup Service (ABS) runs continuously and manages scheduling and retention. Both use the same underlying engine, and backups are compatible in both directions.

Many teams use absctl for manual operations or testing, and ABS for automated production policies or native Kubernetes integration.

Migration from legacy CLI tools

absctl uses the same .asb file format as asbackup. Your existing backups remain usable. Most flags carry over or have direct equivalents. The legacy tools are still supported and can run alongside absctl.

CLI direction and support timeline

For command-line backup and restore workflows, absctl is the path forward.

asbackup and asrestore will remain supported through the end of 2026. During this period, they will continue to receive bug fixes and security updates. No new features will be added to asbackup or asrestore. All new capabilities will be delivered in absctl. We recommend planning your transition to absctl well ahead of the sunset timeline.

Backups are part of your production system. absctl is built for that reality.

For full details on using absctl, see the absctl documentation.