Как выполнять backup/restore и disaster recovery в ClickHouse Cloud и self-hosted кластере?

Self-Hosted: SQL BACKUP / RESTORE

Начиная с версии 22.4 ClickHouse поддерживает нативный синтаксис резервного копирования.

-- Бэкап базы данных на S3
BACKUP DATABASE analytics
TO S3('https://s3.us-east-1.amazonaws.com/my-bucket/backups/2025-05-20/', 'ACCESS_KEY', 'SECRET_KEY')
SETTINGS
    compression_method = 'lz4',
    base_backup = S3('https://s3.us-east-1.amazonaws.com/my-bucket/backups/2025-05-19/', 'ACCESS_KEY', 'SECRET_KEY');  -- инкрементальный

-- Бэкап конкретной таблицы на локальный диск
BACKUP TABLE analytics.events
TO Disk('backups', 'events_2025-05-20.zip');

-- Восстановление
RESTORE DATABASE analytics
FROM S3('https://s3.us-east-1.amazonaws.com/my-bucket/backups/2025-05-20/', 'ACCESS_KEY', 'SECRET_KEY')
SETTINGS allow_non_empty_tables = 1;

Настройка диска для бэкапов в storage_configuration.xml:

<storage_configuration>
  <disks>
    <backups>
      <type>local</type>
      <path>/var/lib/clickhouse/backups/</path>
    </backups>
  </disks>
</storage_configuration>
<backups>
  <allowed_disk>backups</allowed_disk>
  <allowed_path>/var/lib/clickhouse/backups/</allowed_path>
</backups>

clickhouse-backup (Altinity)

Утилита с расширенными возможностями: инкрементальные бэкапы, поддержка S3/GCS/Azure, расписание через cron.

# Установка
curl -fL https://github.com/Altinity/clickhouse-backup/releases/latest/download/clickhouse-backup-linux-amd64.tar.gz | tar xz

# Создать бэкап
clickhouse-backup create my_backup_2025-05-20

# Загрузить на S3
clickhouse-backup upload my_backup_2025-05-20

# Восстановить с S3
clickhouse-backup download my_backup_2025-05-20
clickhouse-backup restore my_backup_2025-05-20

# Список удалённых бэкапов
clickhouse-backup list remote

Конфигурация /etc/clickhouse-backup/config.yml:

general:
  remote_storage: s3
s3:
  bucket: my-ch-backups
  region: us-east-1
  access_key: AKIAIOSFODNN7EXAMPLE
  secret_key: wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
  path: clickhouse/
clickhouse:
  host: localhost
  port: 9000
  username: backup_user
  password: secret

ClickHouse Cloud

В Cloud бэкапы выполняются автоматически каждые 24 часа и хранятся 30 дней. Восстановление через консоль или API:

# CLI (clickhouse-cloud)
clickhouse-cloud service backup list --service-id SERVICE_ID
clickhouse-cloud service backup restore \
  --service-id TARGET_SERVICE_ID \
  --backup-id BACKUP_ID

Disaster Recovery: стратегия

• RPO 0 (нет потерь) — ReplicatedMergeTree с репликами в разных зонах доступности; при падении одной зоны реплика берёт на себя трафик автоматически.
• RPO > 0 (допустима потеря) — регулярный бэкап на S3 + тест восстановления на отдельном кластере каждую неделю.
• Cross-region DR — настройте Distributed Table поверх двух кластеров в разных регионах или используйте ClickPipes/ClickHouse Cloud replica.

Мониторинг бэкапов

SELECT
    id,
    name,
    status,
    error,
    start_time,
    end_time,
    uncompressed_size,
    compressed_size
FROM system.backups
ORDER BY start_time DESC
LIMIT 10;

Подводные камни

• BACKUP не включает метаданные ZooKeeper/Keeper — пути репликации, ACL и задачи DDL-queue не бэкапируются; после восстановления нужно вручную воссоздать таблицы на кластере.
• Инкрементальный бэкап требует сохранения базового — если базовый бэкап удалён, инкрементальный нельзя восстановить; храните базовые бэкапы отдельно с увеличенным TTL.
• Бэкап на тот же диск что данные — при использовании Disk('backups', ...) убедитесь, что backups смонтирован на отдельный раздел; заполнение диска данными убьёт бэкап.
• Восстановление с allow_non_empty_tables — без этого флага RESTORE отказывает при наличии существующих таблиц; с флагом данные могут дублироваться — сначала TRUNCATE.
• Проверяйте восстановление регулярно — бэкап без тестового восстановления не является бэкапом; автоматизируйте еженедельный restore на staging.
• clickhouse-backup версия должна совпадать с версией ClickHouse — использование несовместимой версии утилиты приводит к ошибкам формата при восстановлении.

• Отвечать определением без production-сценария.
• Не называть runtime boundary, security boundary или failure mode.
• Игнорировать версию API, observability и тестовую проверку.

• Объясняет механизм своими словами и без выдуманных API.
• Называет реальные риски, диагностику и критерий корректности.
• Связывает ответ с текущей документацией и миграционными ограничениями.