Change backup storage destination

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/full/ROUTINE_NAME, then calling GET /v1/backups/full to verify that a new full backup appears in the returned list. The legacy POST /v1/backups/schedule/ROUTINE_NAME endpoint is deprecated, but still supported.

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.

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.