Skip to main content

설명

현재 상태와 기타 속성을 포함한 모든 BACKUP 또는 RESTORE 작업의 목록이 들어 있습니다. 이 테이블은 영구적으로 유지되지 않으며, 마지막 서버 재시작 이후에 실행된 작업만 표시합니다.

컬럼

  • id (String) — 작업 ID입니다. SETTINGS id=...로 전달하거나 무작위로 생성된 UUID일 수 있습니다.
  • name (String) — 작업 이름으로, Disk('backups', 'my_backup')와 같은 문자열입니다.
  • base_backup_name (String) — 기준 백업 작업 이름으로, Disk('backups', 'my_base_backup')와 같은 문자열입니다.
  • query_id (String) — 백업을 시작한 쿼리의 ID입니다.
  • status (Enum8(‘CREATING_BACKUP’ = 0, ‘BACKUP_CREATED’ = 1, ‘BACKUP_FAILED’ = 2, ‘RESTORING’ = 3, ‘RESTORED’ = 4, ‘RESTORE_FAILED’ = 5, ‘BACKUP_CANCELLED’ = 6, ‘RESTORE_CANCELLED’ = 7)) — 백업 또는 복원 작업의 상태입니다.
  • error (String) — 오류가 발생한 경우 해당 오류 메시지입니다.
  • start_time (DateTime64(6)) — 작업이 시작된 시각입니다.
  • end_time (DateTime64(6)) — 작업이 완료된 시각입니다.
  • num_files (UInt64) — 백업에 저장된 파일 수입니다.
  • total_size (UInt64) — 백업에 저장된 파일의 총 크기입니다.
  • num_entries (UInt64) — 백업의 엔트리 수입니다. 즉, 백업이 폴더로 저장된 경우 폴더 안에 있는 파일 수입니다.
  • uncompressed_size (UInt64) — 백업의 압축되지 않은 크기입니다.
  • compressed_size (UInt64) — 백업의 압축된 크기입니다.
  • files_read (UInt64) — 이 백업에서 RESTORE 중 읽은 파일 수를 반환합니다.
  • bytes_read (UInt64) — 이 백업에서 RESTORE 중 읽은 파일의 총 크기를 반환합니다.
  • ProfileEvents (Map(LowCardinality(String), UInt64)) — 이 작업 중 수집된 모든 profile events입니다.
  • settings (Map(LowCardinality(String), String)) — 이 작업에 실제로 적용된 백업/복원 전용 설정입니다(SETTINGS 절의 값이며 기본값 포함). 민감한 설정은 노출되지 않습니다.
  • engine_settings (Map(LowCardinality(String), String)) — 백업 엔진의 reader/writer에 실제로 적용된 설정입니다(예: S3 allow_native_copy). 작업에 평면 맵으로 표현할 수 없는 둘 이상의 엔진이 포함된 경우에는 비어 있습니다. 예를 들어 증분 백업 및 복원, lightweight snapshot 복원, 내부가 아닌 ON CLUSTER 작업이 이에 해당합니다.

복원의 원자성

RESTORE는 트랜잭션을 지원하지 않으며, 실패해도 롤백되지 않습니다. 각 테이블에서는 선택한 모든 파트를 먼저 복사한 다음 ATTACH하지만, ATTACH 단계 자체는 트랜잭션 방식이 아닙니다 — 파트는 한 번에 하나씩 표시됩니다. 테이블은 서로 독립적으로 처리됩니다. 테이블은 서로 독립적입니다. 한 테이블의 복원이 완료되면, 같은 명령에서 나중에 다른 테이블의 복원이 실패하더라도 해당 테이블은 그대로 유지됩니다:
이 명령이 db.t0를 완전히 복원한 뒤 db.t1 복원이 아직 끝나기 전에 실패하더라도, db.t0는 복원된 상태로 유지됩니다. PARTITIONS 절은 commit 경계가 아닙니다. 테이블의 어떤 파트를 복원할지만 선택합니다:
테이블의 선택된 모든 파트는 먼저 복사되며, 모든 파트가 준비된 후에만 한 번에 ATTACH됩니다. 따라서 이 명령이 복사 단계 중에 실패하면 — 예를 들어 파티션 2026-06-01은 완전히 복사되었지만 2026-06-022026-06-03은 아직 완료되지 않은 경우 — 2026-06-01커밋되지 않으며, 이 명령으로 복원된 데이터가 전혀 없는 상태로 테이블이 남습니다. 복사 단계가 완료되고 ATTACH 단계가 시작되면 파트가 한 번에 하나씩 커밋되므로, ATTACH 중에 실패하면 rollback 없이 테이블이 부분적으로만 복원된 상태로 남을 수 있습니다. 파티션을 독립적으로 커밋하려면(즉, 완료된 파티션이 이후 실패가 발생해도 유지되고 개별적으로 재시도할 수 있도록 하려면), 첫 번째 이후에는 SETTINGS allow_non_empty_tables = true를 사용하여 파티션마다 별도의 RESTORE를 실행하십시오.
마지막 수정일 2026년 7월 23일