Резервное копирование событий средствами ClickHouse

В KOMRAD Enterprise SIEM поддерживается множество вариантов резервного копирования системы.

Репликация обеспечивает защиту от аппаратных сбоев, но не защищает от человеческих ошибок: случайного удаления данных, удаления не той таблицы, которую надо было, или таблицы на не том кластере, а также от программных ошибок, которые приводят к неправильной обработке данных или их повреждению. Во многих случаях подобные ошибки влияют на все реплики. ClickHouse имеет встроенные средства защиты для предотвращения некоторых типов ошибок — например, по умолчанию не получится удалить таблицы *MergeTree, содержащие более 50 Гб данных, одной командой. Однако эти средства защиты не охватывают все возможные случаи и могут быть обойдены.

Для того, чтобы эффективно уменьшить возможные человеческие ошибки, следует тщательно подготовить стратегию резервного копирования и восстановления данных заранее.

Каждая компания имеет различные доступные ресурсы и бизнес-требования, поэтому нет универсального решения для резервного копирования и восстановления ClickHouse, которое будет подходить в каждой ситуации. То, что работает для одного гигабайта данных, скорее всего, не будет работать для десятков петабайт. Существует множество возможных подходов со своими плюсами и минусами, которые будут рассмотрены ниже. Рекомендуется использовать несколько подходов вместо одного, чтобы компенсировать их различные недостатки.

Имейте в виду, что если вы создали резервную копию чего-то и никогда не пытались восстановить её, скорее всего, восстановление не будет работать должным образом, когда вам это действительно понадобится (или, по крайней мере, это займет больше времени, чем будет приемлемо для бизнеса). Поэтому, какой бы подход к резервному копированию вы ни выбрали, обязательно автоматизируйте процесс восстановления и регулярно запускайте его на резервном кластере ClickHouse.

Дублирование данных

Часто данные, которые поступают в ClickHouse, доставляются через некоторую отказоустойчивую очередь, например Apache Kafka. В этом случае можно настроить дополнительный набор подписчиков, которые будут считывать один и тот же поток данных во время записи в ClickHouse и хранить его в холодном хранилище. Большинство компаний уже имеют некоторые рекомендуемые по умолчанию холодные хранилища, которые могут быть хранилищем объектов или распределенной файловой системой, например HDFS.

Снимки файловой системы

Некоторые локальные файловые системы позволяют делать снимки (например, ZFS), но они могут быть не лучшим выбором для обслуживания живых запросов. Возможным решением является создание дополнительных реплик с такой файловой системой и исключение их из Distributed таблиц, используемых для запросов SELECT. Снимки на таких репликах будут недоступны для запросов, изменяющих данные. В качестве бонуса эти реплики могут иметь особые конфигурации оборудования с большим количеством дисков, подключенных к серверу, что будет экономически эффективным.

Манипуляции с партициями

ClickHouse позволяет использовать запрос ALTER TABLE … FREEZE PARTITION … для создания локальной копии партиций таблицы. Это реализуется с помощью жестких ссылок (hardlinks) на каталог /var/lib/clickhouse/shadow/, поэтому такая копия обычно не занимает дополнительное место на диске для старых данных. Созданные копии файлов не обрабатываются сервером ClickHouse, поэтому вы можете просто оставить их там: у вас будет простая резервная копия, которая не требует дополнительной внешней системы, однако при аппаратных проблемах вы можете утратить и актуальные данные и сохраненную копию. По этой причине, лучше удаленно скопировать их в другое место, а затем удалить локальную копию. Распределенные файловые системы и хранилища объектов по-прежнему являются хорошими вариантами для этого, однако можно использовать и обычные присоединенные файловые серверы с достаточно большой ёмкостью (в этом случае передача будет происходить через сетевую файловую систему или, возможно, rsync).

Дополнительные сведения о запросах, связанных с манипуляциями партициями, см. в разделе ALTER.

Для автоматизации этого подхода доступен инструмент от сторонних разработчиков: clickhouse-backup.

Работа с утилитой komrad-backup clickhouse

Для начала работы с утилитой komrad-backup clickhouse необходимо создать каталог clickhouse-backup (если отсутствует):

sudo mkdir /etc/clickhouse-backup/

Далее создать файл конфигурации в директории /etc/clickhouse-backup:

sudo nano /etc/clickhouse-backup/config.yml

Данный файл необходимо заполнить следующим содержимым:

general:
  remote_storage: none
  max_file_size: 0
  disable_progress_bar: true
  backups_to_keep_local: 0
  backups_to_keep_remote: 0
  log_level: info
  allow_empty_backups: false
  download_concurrency: 2
  upload_concurrency: 2
  restore_schema_on_cluster: ""
  upload_by_part: true
  download_by_part: true
  restore_database_mapping: {}
clickhouse:
  username: komrad
  password: "pass"
  host: localhost
  port: 9000
  disk_mapping: {}
  skip_tables:
  - system.*
  - INFORMATION_SCHEMA.*
  - information_schema.*
  - _temporary_and_external_tables.*
  timeout: 5m
  freeze_by_part: false
  freeze_by_part_where: ""
  use_embedded_backup_restore: false
  embedded_backup_disk: ""
  secure: false
  skip_verify: false
  sync_replicated_tables: false
  log_sql_queries: true
  config_dir: /etc/clickhouse-server/
  restart_command: systemctl restart clickhouse-server
  ignore_not_exists_error_during_freeze: true
  check_replicas_before_attach: true
  tls_key: ""
  tls_cert: ""
  tls_ca: ""
  debug: false

Для создания резервной копии событий необходимо перейти в директорию /opt/echelon/komrad/bin:

cd /opt/echelon/komrad/bin

Далее воспользоваться следующей командой:

./komrad-backup clickhouse create "имя резервной копии"

Для восстановления данных используется команда:

./komrad-backup clickhouse restore "имя резервной копии"

Список резервных копий событий можно посмотреть с помощью следующей команды:

./komrad-backup clickhouse list