Repository navigation
clickhouse backup: deleting a Backup leaves the archive in the bucket, and the documented delete route does not exist #5198
Description
Describe the bug
Deleting a Backup taken with the Altinity (ClickHouse) strategy removes the object and nothing else. The archive stays in the bucket and in the sidecar remote list, there is no event or condition on the Backup, and the cleanup finalizer is released right away (the Altinity branch of cleanupOnDelete returns nil, internal/backupcontroller/backup_controller.go).
Comments in backup_controller.go, packages/apps/clickhouse/templates/clickhouse.yaml and examples/backups/clickhouse/92-scenario-user-restore.md send tenants to DELETE /backup/<name>/remote on the sidecar. That route does not exist in clickhouse-backup 2.7.4 and answers 404. The route that deletes a remote archive is POST /backup/delete/remote/<name>.
Environment
Cozystack v1.7.0, clickhouse-backup 2.7.4. The driver code is the same on main (4087218).
To reproduce
ClickHouse app with backup.enabled: true and backup.useSystemBucket: true, pod restarted after the first BackupJob so the sidecar has credentials (see #3986).
- Run a BackupJob with
cozy-defaultand wait forSucceeded. - List
<bucket>/<namespace>/<release>/with the AWS CLI and the projectedcozy-backups-creds. One prefixclickhouse-<release>-<timestamp>/withmetadata.json,metadata/...andshadow/.... kubectl delete backups.backups.cozystack.io <name>. It is gone in seconds.- List again and call
GET /backup/list/remoteon port 7171 of the sidecar (basic auth from the<release>-backup-api-authSecret). The archive is still there after several minutes. DELETE /backup/<archive>/remotereturns 404,POST /backup/delete/remote/<archive>returns 200 and removes the objects.
Expected behaviour
The driver deletes the archive when the Backup is deleted, as MongoDB does on the system bucket flow, or the docs say plainly that it does not and give a delete route that works.
Actual behaviour
Nothing is deleted and the documented route is wrong. The Backup does not record its archive name (it is generated inside the strategy pod), so a delete from the controller needs the driver to record it first. System bucket has no retention either, so every ClickHouse backup stays until somebody calls the sidecar by hand.
Activity
dosubot commentedon Nov 4, 2026
Persisting the archive name would also close a related restore gap: the default Altinity restore template currently lists remote backups and selects the newest matching application prefix, rather than the archive belonging to the selected
Backup.createAltinityBackupArtifactsaves strategy parameters but not the generated archive identity. I’d use that persisted identity for both restore and deletion, with a regression test that creates two backups and restores/deletes the older one without touching the newer archive. [1] [2]The core finalizer already supports waiting for cleanup: a nonzero requeue result keeps the finalizer, and a cleanup error also prevents its removal. So an Altinity cleanup implementation can use that existing mechanism rather than releasing the
Backupbefore remote deletion completes. [3]To reply, just mention @dosu.
Docs are dead. Just use Dosu.