ACLI 4.0.1 deprecation of api:environments:database-backup-download

[laetus007]

The Acquia CLI command api:environments:database-backup-download is no longer available as of Acquia CLI 4.0.1. Running it returns "Command ... is not defined." This broke our automated database-pull tooling, which relied on it to download database backups for local development.

What we found investigating this

1. Acquia CLI's api:* commands are auto-generated at build time from Acquia's own OpenAPI spec, which ships inside the acquia/cli package (assets/acquia-spec.json).
2. Pulling that spec and searching it, the operation GET/POST /environments/{environmentId}/databases/{databaseName}/backups/{backupId}/actions/download is no longer defined for Cloud Platform environments (/environments/... paths). The equivalent operation still exists in the spec for ACSF/Site Factory (/site-instances/... paths) only.
3. Because the command is spec-generated, this isn't an acli packaging bug or a local-install issue — Acquia removed the operation definition from the Cloud Platform API surface itself, which is why acli stopped generating a command for it.
4. Acquia's own documentation (docs.acquia.com/cloud-platform/manage/back-up/cli) no longer documents any CLI/API-based backup download method. It now instructs users to retrieve backups via SFTP/SCP/rsync directly from the environment's file mount instead.
5. However, on our actual environment (Cloud Platform / Cloud Next infrastructure), there is no backup file present on the SSH-accessible file mount at all — /mnt/files/./ has no backups/ directory and no .sql/.sql.gz files anywhere accessible via SSH. So the SFTP/SCP/rsync approach Acquia now documents does not actually work for this application's hosting type.
6. Separately, we confirmed that the backup resource returned by api:environments:database-backup-find / database-backup-list still includes a _links.download.href entry (e.g. https://cloud.acquia.com/api/environments/{id}/databases/{db}/backups/{id}/actions/download). We tested this endpoint directly with an OAuth-authenticated request (outside of acli, since acli has no generated command for it) and it still returns a valid, working signed S3 download URL with an expiry timestamp. So the underlying capability is functionally still live server-side — it's just undocumented and unsupported by the current acli tooling and current public docs.

The core question for Acquia

The actions/download endpoint referenced by _links.download.href on a database backup resource still functions when called directly, but:

• It's no longer part of the published Cloud Platform API spec.
• It's no longer wrapped by a generated Acquia CLI command.
• The public documentation for backup retrieval was changed to describe a file-mount-based (SFTP/SCP/rsync) method that doesn't apply to this environment's hosting type (no backup files present on the file mount).

We need to know: is this actions/download link/endpoint an intentional, supported, ongoing capability we can build automation against — or is it a deprecated/soon-to-be-removed implementation detail we should not rely on? If it's being retired, what is the supported programmatic replacement for downloading Cloud Platform database backups (not ACSF) going forward?