8000 Backup: sidecar or per-shard Pod transport, multi-period schedules, orchestrator script as operator config by Slach · Pull Request #2148 · Altinity/clickhouse-operator · GitHub
[go: up one dir, main page]

Skip to content

Backup: sidecar or per-shard Pod transport, multi-period schedules, orchestrator script as operator config - #2148

Open
Slach wants to merge 1 commit into
0.28.0from
backup-config-file
Open

Slach wants to merge 1 commit into
0.28.0from
backup-config-file

Conversation

@Slach
@Slach Slach commented Nov 12, 2026 •
Copy link
Copy Markdown
Collaborator

fix #2146

What changes

  • Transport per cluster — spec.backup.mode / clusters[].backup.mode:

    • sidecar (default): a clickhouse-backup server sidecar in every ClickHouse Pod;
    • pod: while a backup, verify or restore Job of the cluster is active, one Pod per shard chi-<chi>-<cluster>-<shard>-bk runs on the node of a ready replica and mounts that replica's volumes. A headless Service <chi>-<cluster>-backup gives each Pod a DNS name. ClickHouse Pods are never restarted.

    Both modes use the REST API on 7171 with operator-generated credentials; a user config.yml cannot turn the auth off.

  • Orchestrator — backup-orchestrator.sh (bash + curl) replaces job.sh and the exec runner (workflow.sh, pods/exec RBAC removed):

    • shipped as an operator config file in config/backup/: operator config backup.path, ConfigMap etc-clickhouse-operator-backup-files, Helm configs.backupFiles;
    • the operator copies it to <chi>-<cluster>-backup-orchestrator;
    • spec.orchestratorConfigMapRef on ClickHouseBackup / ClickHouseBackupSchedule / ClickHouseRestore (and spec.backup.recovery.orchestratorConfigMapRef) swaps the script for one operation;
    • Jobs run altinity/clickhouse-backup:stable (imagePullPolicy: Always) under the operator's ServiceAccount. In other namespaces the operator creates that SA with a minimal Role.
  • Schedules — ClickHouseBackupSchedule.spec.schedules[] (minute, hour, 6hours, daily, weekly, monthly, with time, day, keep, incremental):

    • one CronJob per cluster on the finest entry; the slot time comes from the Job name;
    • the heaviest matching entry decides full vs incremental.
  • Retention follows the Altinity usual backup workflow:

    • each entry keeps its own keep newest backups (GFS);
    • the newest backup is always kept;
    • run-now backups live within the window of the scheduled ones;
    • incomplete or empty backups are neither counted nor deleted;
    • nothing is deleted during a restore;
    • incremental bases are rebased by clickhouse-backup; the operator forces backups_to_keep_remote: 0 and rebase_*: true.
  • Validation — the CHI reconcile stops with status Aborted, reason BackupConfigInvalid and a Warning event BackupStorageConfigInvalid when:

    • backup is enabled without configSecretRef;
    • the storage Secret is missing or invalid;
    • the backup block is invalid;
    • a pod-mode cluster has no backup user.
  • Status and events:

    • ClickHouseBackup / ClickHouseRestore get the Aborted phase (the operat 8000 or stopped them), separate from Failed (the Job failed);
    • schedule status: phase (Active / Suspended / Aborted), entries[], nextScheduleTime;
    • the operator emits an event on every phase change and every observed scheduled run;
    • the orchestrator posts per-step Orchestrator* events on the same CR.
  • Docs: docs/backup.md, docs/custom_resource_explained.md, docs/chb-examples/.

Tests

  • go build ./... && go test ./pkg/... ./cmd/...: the orchestrator's functions are unit-tested by sourcing the script, including retention simulations and a cross-check of slot matching against the Go helpers.
  • Native e2e on orbstack:
    • test_010087: sidecar, Jobs, restore, schedule;
    • test_010088: recovery of a new CHI from another one's backup;
    • test_010089: pod mode round trip and aborted configurations.

deploy/operatorhub is not regenerated (done at release).

…rchestrator script as operator config

- spec.backup.mode / clusters[].backup.mode: sidecar (default) or pod. Pod mode runs a clickhouse-backup
  server Pod per shard on the node of a ready replica only while a backup, verify or restore Job is active,
  behind a headless Service <chi>-<cluster>-backup. Both modes use the REST API with operator-generated auth.
- backup-orchestrator.sh (bash + curl) replaces job.sh and the exec runner; shipped as operator config in
  config/backup (backup.path, ConfigMap etc-clickhouse-operator-backup-files, Helm configs.backupFiles),
  copied to <chi>-<cluster>-backup-orchestrator; spec.orchestratorConfigMapRef on ClickHouseBackup,
  ClickHouseBackupSchedule, ClickHouseRestore and spec.backup.recovery overrides it per operation.
  Jobs run altinity/clickhouse-backup:stable under the operator ServiceAccount (SA + Role in other namespaces).
- ClickHouseBackupSchedule.spec.schedules[]: minute/hour/6hours/daily/weekly/monthly entries with keep and
  incremental; one CronJob per cluster on the finest entry; per-entry GFS retention as in the Altinity usual
  backup workflow, forced backups_to_keep_remote: 0 and rebase options.
- CHI reconcile is Aborted (BackupConfigInvalid) on backup without configSecretRef, a missing or invalid
  storage Secret, an invalid backup block, or a pod-mode cluster without backup user.
- Aborted phase for backups and restores, schedule status phase/entries/nextScheduleTime, events on every
  phase change and per orchestrator step.
- Docs, unit tests sourcing the script, e2e test_010087, test_010088, test_010089.

Refs #2146

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@Slach
Slach force-pushed the backup-config-file branch from d0d0ec5 to d81d518 Compare November 12, 2026 10:51

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant

0