メインコンテンツへスキップ
このセクションでは、ClickHouse におけるバックアップと復元の概要を説明します。各バックアップ方法のより 詳細な説明については、サイドバーにある各方法のページを参照してください。

​
はじめに

レプリケーション はハードウェア障害に対する保護を提供しますが、人的ミスまでは防げません。たとえば、データの誤削除、誤った テーブルの削除、誤ったクラスター上のテーブルの削除、さらに不正な データ処理やデータ破損を引き起こすソフトウェアバグなどです。 多くの場合、このようなミスはすべてのレプリカに影響します。ClickHouse には一部の種類のミスを防ぐための 組み込みの安全策があります。たとえば、デフォルト では、50 Gb を超えるデータを含む MergeTree ファミリーのエンジンを使用するテーブルを そのまま削除することはできません。とはいえ、こうした安全策ですべてのケースを カバーできるわけではなく、問題が発生する可能性は残ります。 想定される人的ミスを効果的に軽減するには、 データのバックアップと復元のための戦略をあらかじめ慎重に準備しておく必要があります。 利用できるリソースや業務要件は会社ごとに異なるため、 あらゆる状況に適した ClickHouse のバックアップと復元の万能な解決策は 存在しません。1 ギガバイトのデータに有効な方法が、数十 PB のデータには通用しない可能性があります。考えられるアプローチにはそれぞれ長所と短所が あり、このドキュメントのこのセクションで紹介しています。さまざまな 欠点を補うために、1 つだけでなく複数のアプローチを併用することをお勧めします。
何かをバックアップしても、一度も復元を試したことがない場合、 実際に必要になったときに復元が正しく動作しない可能性があります (少なくとも、 業務で許容できるよりも長い時間がかかるでしょう) 。したがって、どのバックアップ アプローチを選ぶ場合でも、復元プロセスも自動化し、定期的に予備の ClickHouse クラスターで復元手順を検証してください。
以下のページでは、ClickHouse で利用可能なさまざまなバックアップおよび 復元方法について詳しく説明しています。 バックアップは次のように分類できます。

​
バックアップの種類

バックアップには、フルバックアップと増分バックアップがあります。フルバックアップはデータの完全なコピーであり、増分バックアップは直近のフルバックアップ以降に変更されたデータの差分です。 フルバックアップには、単純で独立性が高く (ほかのバックアップに依存せず) 、信頼性の高い復旧方法であるという利点があります。ただし、完了までに時間がかかる場合があり、多くの容量を消費することもあります。一方、増分バックアップは時間と容量の両面でより効率的ですが、データを復元するには、関連するバックアップがすべて利用可能である必要があります。 要件に応じて、次の方法を検討できます。
  • フルバックアップ: 小規模なデータベースや重要なデータ向け。
  • 増分バックアップ: 大規模なデータベース向け、またはバックアップを高頻度かつコスト効率よく実行する必要がある場合。
  • 両方: たとえば、毎週フルバックアップを実行し、毎日増分バックアップを実行します。

​
同期バックアップと非同期バックアップ

BACKUP コマンドと RESTORE コマンドには、ASYNC を指定することもできます。この場合、 バックアップコマンドはすぐに制御を返し、バックアップ処理はバックグラウンドで実行されます。 コマンドに ASYNC を指定しない場合、バックアップ処理は同期的に実行され、 バックアップが完了するまでコマンドは待機します。

​
同時実行バックアップと非同時実行バックアップ

デフォルトでは、ClickHouse はバックアップと復元の同時実行を許可しています。つまり、 複数のバックアップまたは復元操作を同時に開始できます。ただし、この動作を 無効にできるサーバーレベルの設定もあります。これらの設定を false にすると、 クラスター上で同時に実行できるバックアップまたは復元操作は 1 つだけになります。 これにより、リソースの競合や、操作間で発生しうる競合を回避しやすくなります。 バックアップ/復元の同時実行を無効にするには、それぞれ次の設定を使用できます:
両方のデフォルト値は true であるため、デフォルトではバックアップ/復元の同時実行が 許可されています。クラスターでこれらの設定が false の場合、そのクラスターでは一度に 実行できるバックアップ/復元は 1 つだけです。

​
圧縮バックアップと非圧縮バックアップ

ClickHouse のバックアップでは、compression_method および compression_level 設定により圧縮を利用できます。 バックアップの作成時には、以下を指定できます。

​
named collections の使用

named collections を使用すると、バックアップ/復元操作で再利用できるキー・バリューの組 (S3 の認証情報、エンドポイント、設定など) を保存できます。 これにより、次のことが可能になります。
  • 管理者アクセス権のないユーザーに認証情報を見せない
  • 複雑な構成を一元管理して、コマンドを簡素化する
  • 操作間の一貫性を保つ
  • クエリログに認証情報が露出するのを防ぐ
詳細については、“named collections” を参照してください。

​
システム、ログ、またはアクセス管理テーブルのバックアップ

システムテーブルもバックアップおよび復元のワークフローに含めることができますが、 含めるかどうかは、具体的なユースケースによって異なります。 _log 接尾辞を持つもの (たとえば query_log、part_log) など、履歴データを格納するシステムテーブルは、 他のテーブルと同様にバックアップおよび復元できます。 ユースケース上、履歴データの分析が必要な場合、たとえば query_log を使って クエリのパフォーマンスを追跡したり問題をデバッグしたりする場合は、これらの テーブルをバックアップ戦略に含めることを推奨します。ただし、これらのテーブルの履歴データが 不要であれば、バックアップの保存容量を節約するために除外できます。 users、ロール、row_policies、 settings_profiles、quotas などのアクセス管理に関連するシステムテーブルは、バックアップおよび復元操作時に 特別な扱いを受けます。 これらのテーブルがバックアップに含まれると、その内容は特別な accessXX.txt ファイルにエクスポートされ、このファイルにはアクセスエンティティの作成と 設定に対応する SQL ステートメントがまとめられます。復元時には、復元処理が これらのファイルを解釈し、SQL コマンドを再適用して users、 ロール、その他の設定を再作成します。この機能により、 ClickHouse クラスターのアクセス制御設定を、 クラスター全体の構成の一部としてバックアップおよび復元できます。 この機能は、SQL コマンドで管理される構成に対してのみ動作します (“SQL-driven Access Control and Account Management” と呼ばれます) 。 ClickHouse server の設定ファイル (例: users.xml) で定義されたアクセス設定は バックアップに含まれず、この方法では復元できません。

​
基本構文

各コマンドの詳細については、“コマンド概要”を参照してください。

​
コマンド概要

上記の各コマンドの詳細は以下のとおりです。

​
設定

共通のバックアップ／復元設定 S3固有の設定 Azure固有の設定

​
管理とトラブルシューティング

backup コマンドは id と status を返し、その id を使って バックアップのステータスを取得できます。これは、長時間かかる ASYNC バックアップの進行状況を確認する際に非常に便利です。以下の例は、 既存のバックアップファイルを上書きしようとしたときに発生したエラーを示しています。
system.backups テーブルに加え、すべてのバックアップおよび復元操作は、システムログテーブル system.backup_log にも記録されます:
最終更新日 2026年6月19日