메인 콘텐츠로 건너뛰기
이 섹션에서는 ClickHouse의 백업과 복원을 전반적으로 설명합니다. 각 백업 방식에 대한 더 자세한 내용은 사이드바의 해당 방식별 페이지를 참조하십시오.

​
소개

복제는 하드웨어 장애로부터는 보호해 주지만, 사람의 실수까지 막아주지는 못합니다. 예를 들어 데이터를 실수로 삭제하거나, 잘못된 테이블 또는 잘못된 클러스터의 테이블을 삭제하거나, 잘못된 데이터 처리나 데이터 손상을 초래하는 소프트웨어 버그가 발생할 수 있습니다. 이러한 실수는 많은 경우 모든 레플리카에 영향을 미칩니다. ClickHouse에는 일부 유형의 실수를 방지하기 위한 내장 보호 장치가 있습니다. 예를 들어 기본값으로 50 Gb를 초과하는 데이터를 포함하는 MergeTree 계열 엔진의 테이블은 바로 삭제할 수 없습니다. 하지만 이러한 보호 장치가 모든 경우를 포괄하는 것은 아니며, 문제는 여전히 발생할 수 있습니다. 발생 가능한 사람의 실수를 효과적으로 완화하려면, 데이터 백업 및 복원 전략을 미리 신중하게 준비해야 합니다. 회사마다 사용할 수 있는 리소스와 비즈니스 요구사항이 다르므로, 모든 상황에 맞는 ClickHouse 백업 및 복원용 범용 해법은 없습니다. 1기가바이트의 데이터에 적합한 방식이 수십 페타바이트의 데이터에는 맞지 않을 가능성이 큽니다. 적용 가능한 접근 방식은 다양하며 각각 장단점이 있고, 이 문서 섹션에서 이를 소개합니다. 각 방식의 단점을 보완하기 위해 하나의 방식만 사용하는 대신 여러 접근 방식을 함께 사용하는 것이 좋습니다.
무언가를 백업해 두고도 한 번도 복원을 시도해 보지 않았다면, 실제로 필요할 때 복원이 제대로 동작하지 않을 가능성이 높습니다(또는 적어도 비즈니스에서 감당할 수 있는 시간보다 더 오래 걸릴 수 있습니다). 따라서 어떤 백업 방식을 선택하든 복원 프로세스도 반드시 자동화하고, 여분의 ClickHouse 클러스터에서 정기적으로 연습하십시오.
다음 페이지에서는 ClickHouse에서 사용할 수 있는 다양한 백업 및 복원 방법을 자세히 설명합니다: 백업은 다음과 같은 방식으로 수행할 수 있습니다:

​
백업 유형

백업은 전체 백업 또는 증분 백업으로 수행할 수 있습니다. 전체 백업은 데이터 전체의 복사본이며, 증분 백업은 마지막 전체 백업 이후 변경된 데이터만 포함합니다. 전체 백업의 장점은 단순하고 다른 백업에 의존하지 않는 독립적인 방식이며, 복구 신뢰성이 높다는 점입니다. 하지만 완료하는 데 시간이 오래 걸릴 수 있고 많은 저장 공간을 차지할 수 있습니다. 반면 증분 백업은 시간과 공간 측면에서 더 효율적이지만, 데이터를 복원하려면 관련된 모든 백업이 모두 있어야 합니다. 요구 사항에 따라 다음과 같은 방식을 사용할 수 있습니다.
  • 전체 백업: 규모가 작은 데이터베이스나 중요한 데이터에 적합합니다.
  • 증분 백업: 규모가 큰 데이터베이스이거나 백업을 자주, 비용 효율적으로 수행해야 하는 경우에 적합합니다.
  • 둘 다: 예를 들어, 매주 전체 백업을 수행하고 매일 증분 백업을 수행합니다.

​
동기식 백업과 비동기식 백업

BACKUP 및 RESTORE 명령은 ASYNC로 지정할 수도 있습니다. 이 경우 백업 명령은 즉시 반환되고, 백업 프로세스는 백그라운드에서 실행됩니다. 명령에 ASYNC가 지정되지 않으면 백업 프로세스는 동기식으로 실행되며 백업이 완료될 때까지 명령 실행이 차단됩니다.

​
동시 백업과 비동시 백업

기본적으로 ClickHouse는 백업과 복원 작업의 동시 실행을 허용합니다. 즉, 여러 개의 백업 또는 복원 작업을 동시에 시작할 수 있습니다. 하지만 이러한 동작을 허용하지 않도록 제어하는 서버 수준 설정도 있습니다. 이 설정을 false로 지정하면, 클러스터에서는 한 번에 하나의 백업 또는 복원 작업만 실행할 수 있습니다. 이렇게 하면 리소스 경합이나 작업 간 잠재적 충돌을 방지하는 데 도움이 될 수 있습니다. 백업/복원의 동시 실행을 허용하지 않으려면, 각각 다음 설정을 사용할 수 있습니다:
두 설정의 기본값은 모두 true이므로, 기본적으로 동시 백업/복원이 허용됩니다. 클러스터에서 이 설정들이 false이면, 한 번에 클러스터당 하나의 백업/복원만 실행할 수 있습니다.

​
압축 백업과 비압축 백업

ClickHouse 백업은 compression_method 및 compression_level 설정을 통해 압축을 지원합니다. 백업을 생성할 때 다음 항목을 지정할 수 있습니다:

​
이름이 지정된 컬렉션 사용하기

이름이 지정된 컬렉션을 사용하면 백업/복원 작업 전반에 걸쳐 재사용할 수 있는 key-value 쌍(S3 자격 증명, endpoint, 설정 등)을 저장할 수 있습니다. 다음과 같은 이점이 있습니다:
  • 관리자 권한이 없는 사용자가 자격 증명을 볼 수 없도록 할 수 있습니다
  • 복잡한 구성을 중앙에서 저장해 명령을 단순화할 수 있습니다
  • 여러 작업 간 일관성을 유지할 수 있습니다
  • 쿼리 로그에 자격 증명이 노출되는 것을 방지할 수 있습니다
자세한 내용은 “이름이 지정된 컬렉션”을 참조하십시오.

​
시스템, 로그 또는 액세스 관리 테이블 백업

시스템 테이블도 백업 및 복원 워크플로에 포함할 수 있지만, 포함할지 여부는 사용 사례에 따라 달라집니다. _log 접미사가 있는 테이블(예: query_log, part_log)처럼 이력 데이터를 저장하는 시스템 테이블은 다른 테이블과 마찬가지로 백업하고 복원할 수 있습니다. 예를 들어 query_log를 사용해 쿼리 성능을 추적하거나 문제를 디버깅하는 등, 사용 사례에서 이력 데이터 분석이 필요하다면 이러한 테이블을 백업 전략에 포함하는 것이 좋습니다. 반면 이러한 테이블의 이력 데이터가 필요하지 않다면 백업 저장 공간을 절약하기 위해 제외할 수 있습니다. users, 역할, row_policies, settings_profiles, 쿼터와 같이 액세스 관리와 관련된 시스템 테이블은 백업 및 복원 작업 중 특별히 처리됩니다. 이러한 테이블이 백업에 포함되면, 해당 내용은 특수한 accessXX.txt 파일로 내보내지며, 이 파일에는 해당 액세스 엔터티를 생성하고 구성하는 데 필요한 SQL 문이 담깁니다. 복원 시에는 복원 프로세스가 이 파일을 해석하고 SQL 명령을 다시 적용하여 users, 역할 및 기타 구성을 다시 생성합니다. 이 기능을 통해 ClickHouse 클러스터의 액세스 제어 구성을 클러스터 전체 구성의 일부로 백업하고 복원할 수 있습니다. 이 기능은 SQL 명령으로 관리되는 구성에 대해서만 작동합니다 (“SQL 기반 액세스 제어 및 계정 관리”라고 부름). ClickHouse 서버 설정 파일(예: users.xml)에 정의된 액세스 구성은 백업에 포함되지 않으며 이 방법으로는 복원할 수 없습니다.

​
일반 구문

각 명령에 대한 자세한 내용은 “명령 요약”을 확인하십시오.

​
명령 요약

위의 각 명령은 아래에서 자세히 설명합니다.

​
설정

일반 백업/복원 설정 S3 관련 설정 Azure 관련 설정

​
관리 및 문제 해결

백업 명령은 id와 status를 반환하며, 이 id를 사용해 백업의 상태를 확인할 수 있습니다. 이는 시간이 오래 걸리는 ASYNC 백업의 진행 상황을 확인할 때 매우 유용합니다. 아래 예시는 기존 백업 파일을 덮어쓰려고 할 때 발생한 오류를 보여줍니다:
system.backups 테이블과 마찬가지로, 모든 백업 및 복원 작업은 시스템 로그 테이블 system.backup_log에도 기록됩니다:
마지막 수정일 2026년 6월 29일