asbackup Snapshot Consistency in Aerospike 7.x Rolling Upgrades

Direct Answer

No. asbackup does not acquire a cluster-wide read lock, freeze writes, or provide multi-record snapshot isolation. It is a logical record scanner that reads partitions sequentially over time. During a rolling upgrade, continued writes and node restarts mean the backup can capture a mix of pre- and post-upgrade records.

Why the Backup Is Not Atomic

Aerospike guarantees consistency per record or transaction, not across the many partitions a full-namespace backup reads. If a node restarts or migrates mid-run, or if the application writes between partition scans, the output file contains records from different logical points in time. There is no supported configuration flag in asbackup that changes this behavior.

Capturing a Stable Backup

To approximate a single stable state, stability must come from operational quiescence rather than a backup flag:

1. Pause the upgrade. Stop advancing nodes to new versions so the cluster topology and binary versions remain fixed.
2. Wait for migrations. Confirm migration and rebalance counters are zero and stable across all nodes before starting the scan.
3. Quiesce writes. Route application traffic away or pause writes. Wait for in-flight transactions to settle.
4. Run one full-namespace backup. Execute a single asbackup run to a new output location. Do not append to or reuse an existing backup directory.
5. Record the exact state. Capture the cluster build versions and the time writes were paused so the restore target can be validated.

Schema and Restore Considerations

The backup format is record-oriented and schemaless. It stores the bins present on each record at read time; it does not capture or enforce a namespace schema. If the upgrade introduces bin additions, removals, or type changes, the backup may contain heterogeneous records. On restore, asrestore writes records back as captured. Secondary indexes and UDFs are not part of the record backup and must be recreated separately on the target cluster. Validate that every bin type and feature is supported by the rollback target; otherwise the restore may fail, skip records, or produce data the older application cannot read.

Rollback Path

For rollback, restore the pre-upgrade backup into a clean cluster running the target version rather than attempting an in-place reverse upgrade. A backup taken after the upgrade began is unsafe as a reverse-upgrade point if any node already accepted writes using new-version-only data features.

Missing Diagnostic

What are the exact source and target 7.x versions in your upgrade path? Mixed-version support and downgrade behavior are version-sensitive, and the answer determines whether a clean restore is mandatory or whether an in-place rollback is even possible.

Verification Commands

Before relying on any backup, confirm the utility and server versions:

asbackup --version
asrestore --version
asinfo -h <host> -p 3000 -v build

Inspect asbackup --help on the exact binary for any lock, freeze, or snapshot options; their absence confirms the no-guarantee behavior described above.