Change backup storage destination

This page describes how to dynamically change the local or remote storage destination for Aerospike Backup Service (ABS).

Change the storage destination for a routine

To change the storage destination, edit the provider destination in the configuration file and restart ABS. Note, however, that ABS does not copy data between providers. After the change, ABS only sees 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.
   • 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.
5. Resume scheduling by re-enabling the cron expressions or uncommenting the configuration file.
6. Restart ABS, or call POST /v1/config/apply to trigger a restart.

After the restart, all new backups are stored in the new destination. You can check that the new destination is working correctly by calling POST /v1/backup/full/<routine> to trigger a new backup, then calling GET /v1/backups/full to see the new full backup in the returned list.

ABS configuration reload

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

• If it finds one or more metadata.yaml files, ABS treats the most recent file as the most recent full backup baseline, no matter the age of the backup. An incremental backup starts, immediately saving all data changed since the timestamp inside that file.

  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 Skipping incremental backup: initial full backup not yet completed. The incremental backup is skipped until you complete a new full backup.

Listing backups

The API endpoint GET /v1/backups/full lists only the backups that exist in the storage currently 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.