Skip to content

restore --rbac on a backup without an access/ tree fails with raw lstat error instead of graceful no-op #1521

Description

@ptcar2009

Context

Operator-managed clusters (altinity clickhouse-operator) keep access entities in ClickHouse Keeper, not local_directory user_directories. As a consequence create --rbac --configs produces an empty access tree:

SELECT JSONExtractString(params,'path') AS access_path FROM system.user_directories
WHERE type in ('local_directory','local directory')
done createBackupRBAC, size=0B

... and the empty access/ directory is not archived/uploaded.

Then

INSERT INTO system.backup_actions(command) VALUES('restore_remote --rm --rbac <name>')

fails with:

restoreRBAC: restoreRBACResolveAllConflicts: walk backup access path:
walk backup access path: lstat /var/lib/clickhouse/backup/<name>/access:
no such file or directory

The same happens for --config and --all (any kind touching the missing dirs).

Ask

  1. When the backup has no access/ (or config/) material, --rbac-flavored restores should degrade to a clear no-op result (rbac part missing in backup) instead of a raw lstat error that looks like corruption.
  2. Ideally create --rbac on Keeper-backed access storage either captures the keeper-cased entities or fails loudly at create time, so operators learn the constraint before the first DR restore attempt.

Seen on clickhouse-backup 2.7.2 (and 2.6.x), embedded-Keeper access management.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions