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) — バックアップを開始したクエリの Query 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)) — バックアップ engine の reader/writer が実際に使用した設定です (例: S3 allow_native_copy) 。フラットな map では表現できない複数の engine が関与する場合、この値は空になります。これには、incremental backups と restores、lightweight snapshot restores、非 internal の ON CLUSTER 操作が含まれます。

復元のアトミック性

RESTORE はトランザクション処理ではないため、失敗してもロールバックされません。各テーブルでは、選択したすべてのパーツが、どのパーツもアタッチされる前にコピーされますが、アタッチのフェーズ自体にはトランザクション性がありません。つまり、パーツは 1 つずつ順に可視状態になります。テーブルはそれぞれ独立して処理されます。 テーブルは独立しています。 あるテーブルの復元が完了した場合、同じコマンド内の別のテーブルがその後失敗しても、そのテーブルはそのまま残ります。
このコマンドが、db.t0 の復元が完全に完了したあとで、db.t1 の復元が完了する前に失敗した場合、db.t0 は復元されたまま残ります。 PARTITIONS 句はコミット境界ではありません。 これは、テーブルのどのパーツを復元するかを選択するだけです。
選択したテーブル内のパーツは、まずすべてコピーされ、すべての準備が整ってからまとめて一度だけアタッチされます。したがって、このコマンドがコピーのフェーズ中に失敗した場合、たとえばパーティション 2026-06-01 のコピーは完了していても、2026-06-022026-06-03 がまだ完了していなければ、2026-06-01コミットされず、このコマンドで復元されたデータはテーブルに一切反映されません。コピーのフェーズが完了してアタッチの手順が始まると、パーツは 1 つずつコミットされるため、アタッチ中に失敗すると、ロールバックされないままテーブルが部分的に復元された状態になる可能性があります。 パーティションごとに独立してコミットしたい場合 (つまり、完了したパーティションが後続の失敗後も保持され、個別に再試行できるようにしたい場合) は、パーティションごとに RESTORE を個別に実行し、最初の実行以降は SETTINGS allow_non_empty_tables = true を使用してください。
最終更新日 2026年7月23日