Repository navigation
clickhouse backup: a RestoreJob restores the newest archive, whichever Backup it names #5199
Description
Describe the bug
The Altinity restore strategy ignores which Backup it was asked to restore. For restore the strategy pod calls GET /backup/list/remote on the clickhouse-backup sidecar, keeps archives whose name starts with clickhouse-<app>-, sorts by created and restores the last one (packages/system/backupstrategy-controller/templates/strategy-altinity-default.yaml). The Cozystack Backup carries no archive name, so the driver could not pass the right one even if the template asked for it. examples/backups/clickhouse/92-scenario-user-restore.md describes the pod as restoring "the Backup name".
Environment
Cozystack v1.7.0, clickhouse-backup 2.7.4. Driver and template logic are the same on main (4087218).
To reproduce
- ClickHouse app with
backup.enabled: trueandbackup.useSystemBucket: true, a table with 1000 rows. Run a BackupJob (A). - Insert 1000 more rows, run a second BackupJob (B).
- Drop the table and create a RestoreJob with
backupRef: <A>.
Actual behaviour
The pod log says restore_remote clickhouse-<app>-<timestamp of B> and the table has 2000 rows. In my run A held 1500 rows and B 2000, the RestoreJob from A ended Succeeded with 2000 rows. Same happens when the archive of the referenced Backup was deleted, another archive is restored silently.
Expected behaviour
Restore applies the archive of the Backup named in backupRef, as the example scenario describes, or fails when that archive is gone.
#3549 mentions that the Altinity driver reads no options, it does not cover this.
Activity
dosubot commentedon Nov 4, 2026
There’s an existing pattern for fixing the missing archive identity without adding a new CRD field:
Backup.spec.driverMetadataalready supports snapshot IDs, and the Redis driver records its per-backup object key there and exposes it to the strategy template as.ObjectKey. [1] [2] [3]Altinity currently records only strategy parameters in that map, and its restore template context exposes only the Backup’s name, namespace and application reference. So recording an archive name alone would not suffice: the driver also needs to pass that identity into the rendered template. [4] [5]
I’d follow that pattern here: choose a stable archive name before launching the backup Job, persist it in driver metadata, and restore exactly that name. For older Backups without that metadata, fail explicitly rather than retain the “latest archive” fallback. Also,
spec.takenAtis not a reliable way to reconstruct existing archive names: Altinity sets it when creating the Backup artifact, whereas the shell generates the archive timestamp when startingcreate_remote. [6] [7]To reply, just mention @dosu.
Share context across your team and agents. Try Dosu.
fix(clickhouse): restore the archive a Backup was taken as (cozystack…
fix(clickhouse): restore the archive a Backup was taken as (#5208)