---
title: "Aerospike Backup Service 3.0.0 release notes"
description: "Aerospike Backup Service 3.0.0 release notes: New Azure/GCP cloud storage support and breaking API changes."
---

# Aerospike Backup Service 3.0.0 release notes

> For the complete documentation index see: [llms.txt](https://aerospike.com/docs/llms.txt)
> 
> All documentation pages available in markdown.

January 14, 2025  |  **[Download](https://aerospike.com/download/backupservice/backup_service)**

## New in this version

This version introduces support for GCP and Azure cloud storage, along with a variety of improvements and fixes to enhance performance, usability, and reliability.

## New features

-   Cloud storage support: Added support for Azure Blob Storage and GCP storage. \[APPS-1299\] \[APPS-1279\]
-   Introduced NodeList configuration property for the BackupRoutine. \[APPS-1336\]
-   Added support for configuring Aerospike cluster password in Secret Agent. \[APPS-1321\]
-   Reviewed and updated default configuration values for better out-of-the-box experience. \[APPS-1349\]

## Improvements

-   Optimized “Last Backup Run” field for better performance. \[APPS-1351\]
-   Improved handling of empty backup scenarios to prevent errors. \[APPS-1362\]

### Configuration management changes

-   Any changes you make to the configuration API take effect immediately in version 3.0. Prior to 3.0, API configuration changes required an explicit “apply” step after CRUD operations to update the runtime configuration.
    
-   Each CRUD update now automatically saves the configuration to the file and applies it to the runtime system without needing a separate “apply” operation. The memory config is always in sync with the runtime. Invalid configurations are rejected immediately and neither applied nor saved.
    
-   After an update, the running backup processes will finish as originally started, but:
    
    -   If a routine entry is absent in the updated configuration file, it will not be rescheduled.
    -   If the routine entry is updated, it will be rescheduled with the new parameters.
-   The [`backup-routines`](https://aerospike.com/docs/database/tools/backup-and-restore/backup-service/config/#backup-routines) section has a new optional `node-list` property for you to choose to back up only the selected cluster nodes. The default, if left unspecified, backs up all nodes in the cluster.
    
-   The `credential` object has two new optional properties: a `secret-agent` property that points to a secret agent listed in the `secret-agents` configuration parameter, and a `password-key-secret` property that specifies the secret keyword containing the password.
    

## New API functions (2.0 → 3.0):

-   The `apply` endpoint reads and applies the configuration from the file (after it was modified externally).
-   The restore policy configuration, specified in the body of the restore request, now contains a new field `extra-ttl`. It specifies the amount of extra time-to-live (TTL) to add to records that have expirable void-times.

## Issues fixed

-   Fixed missing primary key issue in restored records. \[APPS-1353\]
-   Client is now closed after `info` command to address a potential memory leak. \[APPS-1214\]

## Breaking changes

Several breaking changes were made to the codebase between 2.0 and 3.0.

### Configuration name changes

All configuration parameters and flags now use `kebab-case` instead of `snake_case`, except for the two parameters `max_async_connections` and `min_part_size`. These parameters were standardized to `kebab-case` in 3.1.

The `secret-agent` configuration field to store the list of secret agents is now named `secret-agents` to reflect that it can contain more than one.

### Restore request

The `restore` request (`/v1/restore/full` and `/v1/restore/incremental`) endpoint was changed to simplify and streamline the process.

-   **2.0:** The `storage` object contained a `path` that was also used as the backup data location.
-   **3.0:** The `path` in the `storage` object now only refers to the root path of the storage. The specific backup data location is now specified using a new required field: `backup-data-path`. This change allows you to reuse the same storage for different restore requests.

### Storage

The `storage` object schema has been updated in 3.0 to improve clarity, modularity, and support for additional storage types.

-   **2.0:** Unified schema with a `type` field to differentiate storage types.
-   **3.0:** Separate schemas for each storage type:
    -   `local-storage`
    -   `s3-storage`
    -   `azure-storage`
    -   `gcp-storage`
-   Validation ensures only one storage type is configured.

S3 Path Construction:

-   **2.0**: S3 paths were constructed in the format `s3://<bucket>/<path>`.
-   **3.0**: `bucket` and `path` are now separate fields in `s3-storage`.

### Storage examples

-   [Local Storage](#tab-panel-3673)
-   [S3 Storage](#tab-panel-3674)
-   [Azure Storage](#tab-panel-3675)
-   [GCP Storage](#tab-panel-3676)

```yaml
storage1:

  local-storage:

    path: /local/backups
```

```yaml
storage2:

  s3-storage:

    bucket: my-backup-bucket

    path: backups

    s3-profile: default

    s3-region: eu-central-1
```

```yaml
storage3:

  azure-storage:

    account-name: my-storage-account

    account-key: my-secret-key

    container-name: my-container

    endpoint: 'https://my-storage-account.blob.core.windows.net'

    path: backups
```

```yaml
storage4:

  gcp-storage:

    bucket-name: my-gcp-bucket

    key-file: /path/to/service-account-key.json

    endpoint: 'https://storage.googleapis.com'

    path: backups
```