---
title: "Change backup storage destination"
description: "Change the backup storage destination for Aerospike Backup Service (ABS) routines and manage data migration."
---

# Change backup storage destination

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

Change the storage destination for Aerospike Backup Service (ABS) routines.

## Change the storage destination for a routine

To change the storage destination, edit the provider destination in the configuration file and reload the configuration. ABS does not copy data between providers. After the change, ABS sees only the backups that already exist in the new destination.

1.  Perform a full backup before you change storage destinations.
2.  Pause the routine by disabling its cron schedules with the REST API, or commenting them out in the configuration file.
3.  Choose one of the following:
    -   Migrate existing data: Manually copy the routine’s `backup/` directory, including `metadata.yaml`, to the new storage location. If the routine also has incremental backups, copy the `incremental/` directory too, so ABS finds the full incremental history.
    -   New backup: Plan a full backup in the new storage location.
4.  Modify the routine’s `storage` value in the configuration file. Verify that the destination does not contain an older `metadata.yaml` file under `backup/` or `incremental/`.
5.  Resume scheduling by re-enabling the cron expressions or uncommenting the configuration file.
6.  Restart ABS, or call `POST /v1/config/apply` to reload the configuration.

After ABS reloads the configuration, all new backups are stored in the new destination. You can check that the new destination works by triggering a backup with `POST /v1/backups/schedule/ROUTINE_NAME`, then calling `GET /v1/backups/full` to verify that a new full backup appears in the returned list.

### ABS configuration reload

When ABS restarts or reloads the configuration, it performs a one-time scan of the configured storage for each routine. It searches `ROUTINE_NAME/backup/` and `ROUTINE_NAME/incremental/` for the most recent `metadata.yaml` files.

If it finds a full backup’s `metadata.yaml`, ABS treats it as the full backup baseline, regardless of the age of the backup. If a later incremental backup’s `metadata.yaml` also exists, ABS uses that later timestamp instead. The next incremental backup saves all data changed since that timestamp.

::: note
The first incremental backup may be unusually large if `metadata.yaml` is outdated, for example if switching back to a previously-used older storage bucket. To avoid unexpectedly large incremental backups, trigger a full backup or copy the latest `metadata.yaml` from your old storage to the new bucket.
:::

If it does not find `metadata.yaml`, ABS does not run incremental jobs and logs `incremental backup skipped` with an `error` value such as `backup skipped: initial full backup not yet completed`. Incremental backups are skipped until you complete a new full backup. See [Backup skip outcomes](https://aerospike.com/docs/database/tools/backup-and-restore/backup-service/3.1.0/monitoring#backup-skip-outcomes).

### List backups

The API endpoint `GET /v1/backups/full` lists only the backups that exist in the storage configured for the routine. After a storage change, this list reflects the new destination until you perform a new backup or copy a full backup there. This endpoint does not show any of the existing backups in the old destination after switching storage destinations.