Перейти к основному содержанию
В этом разделе в общих чертах рассматриваются резервное копирование и восстановление в ClickHouse. Более подробное описание каждого способа резервного копирования см. на страницах, посвящённых конкретным способам, на боковой панели.

​
Введение

Хотя репликация обеспечивает защиту от аппаратных сбоев, она не защищает от человеческих ошибок: случайного удаления данных, удаления не той таблицы или таблицы не в том кластере, а также ошибок в программном обеспечении, которые приводят к некорректной обработке данных или их повреждению. Во многих случаях такие ошибки затронут все реплики. В ClickHouse есть встроенные механизмы защиты, предотвращающие некоторые типы ошибок; например, по умолчанию нельзя просто удалить таблицы с движком семейства MergeTree, содержащие более 50 ГБ данных. Однако эти механизмы защиты не охватывают все возможные случаи, и проблемы всё равно могут возникнуть. Чтобы эффективно снизить риск человеческих ошибок, следует заранее тщательно подготовить стратегию резервного копирования и восстановления данных. У каждой компании разные ресурсы и бизнес-требования, поэтому универсального решения для резервного копирования и восстановления ClickHouse, которое подошло бы для любой ситуации, не существует. То, что работает для одного гигабайта данных, скорее всего, не подойдёт для десятков PB данных. Существует множество возможных подходов со своими плюсами и минусами, которые представлены в этом разделе документации. Лучше использовать несколько подходов, а не ограничиваться одним, чтобы компенсировать их различные недостатки.
Имейте в виду: если вы создали резервную копию, но ни разу не пытались её восстановить, велика вероятность, что восстановление не сработает должным образом, когда оно действительно понадобится (или, по крайней мере, займёт больше времени, чем может позволить себе бизнес). Поэтому какой бы подход к резервному копированию вы ни выбрали, обязательно автоматизируйте и процесс восстановления, а также регулярно отрабатывайте его на резервном кластере ClickHouse.
На следующих страницах подробно описаны различные методы резервного копирования и восстановления, доступные в ClickHouse: Резервные копии могут:

​
Типы резервного копирования

Резервные копии бывают полными и инкрементными. Полная резервная копия — это полная копия данных, тогда как инкрементная резервная копия содержит изменения, внесенные в данные после последней полной резервной копии. Преимущество полных резервных копий в том, что это простой, независимый (от других резервных копий) и надежный способ восстановления. Однако их создание может занимать много времени и требовать много места. Инкрементные резервные копии, напротив, более эффективны как по времени, так и по занимаемому месту, но для восстановления данных необходимо, чтобы были доступны все резервные копии. В зависимости от ваших потребностей можно использовать:
  • Полные резервные копии для небольших баз данных или критически важных данных.
  • Инкрементные резервные копии для более крупных баз данных или если резервное копирование нужно выполнять часто и с минимальными затратами.
  • Оба типа, например еженедельные полные резервные копии и ежедневные инкрементные резервные копии.

​
Синхронное и асинхронное резервное копирование

Команды BACKUP и RESTORE также можно пометить как ASYNC. В этом случае команда резервного копирования сразу возвращает управление, а сам процесс выполняется в фоновом режиме. Если команды не помечены как ASYNC, процесс резервного копирования выполняется синхронно, и команда не завершится, пока резервное копирование не будет завершено.

​
Параллельные и последовательные резервные копии

По умолчанию ClickHouse позволяет выполнять резервное копирование и восстановление параллельно. Это означает, что вы можете одновременно запускать несколько операций резервного копирования или восстановления. Однако существуют настройки уровня сервера, которые позволяют запретить такое поведение. Если установить для этих настроек значение false, в кластере одновременно будет разрешено выполнять только одну операцию резервного копирования или восстановления. Это помогает избежать конкуренции за ресурсы или возможных конфликтов между операциями. Чтобы запретить параллельное резервное копирование/восстановление, можно использовать следующие настройки соответственно:
Значение по умолчанию для обоих параметров — true, поэтому по умолчанию параллельное резервное копирование и восстановление разрешены. Если в кластере для этих настроек задано значение false, в каждый момент времени в кластере может выполняться только одно резервное копирование или восстановление.

​
Сжатые и несжатые резервные копии

Резервные копии ClickHouse поддерживают сжатие с помощью параметров compression_method и compression_level. При создании резервной копии можно указать:

​
Использование именованных коллекций

Именованные коллекции позволяют хранить пары ключ-значение (например, учетные данные S3, конечные точки и настройки), которые можно повторно использовать при операциях резервного копирования и восстановления. Они помогают:
  • Скрывать учетные данные от пользователей без прав администратора
  • Упрощать команды за счет централизованного хранения сложной конфигурации
  • Поддерживать согласованность между операциями
  • Избегать раскрытия учетных данных в журналах запросов
См. “именованные коллекции” для получения дополнительной информации.

​
Резервное копирование системных таблиц, таблиц логов и таблиц управления доступом

Системные таблицы также можно включать в процессы резервного копирования и восстановления, но необходимость этого зависит от вашего конкретного сценария использования. Системные таблицы, в которых хранятся исторические данные, например таблицы с суффиксом _log (например, query_log, part_log), можно включать в резервные копии и восстанавливать так же, как и любые другие таблицы. Если ваш сценарий использования предполагает анализ исторических данных — например, использование query_log для отслеживания производительности запросов или отладки проблем, — эти таблицы рекомендуется включить в стратегию резервного копирования. Однако, если исторические данные из этих таблиц не нужны, их можно исключить, чтобы сэкономить место в хранилище резервных копий. Системные таблицы, связанные с управлением доступом, такие как users, roles, row_policies, settings_profiles и quotas, особым образом обрабатываются при резервном копировании и восстановлении. Когда эти таблицы включаются в резервную копию, их содержимое экспортируется в специальный файл accessXX.txt, который содержит эквивалентные SQL-операторы для создания и настройки сущностей доступа. При восстановлении процесс восстановления интерпретирует эти файлы и повторно применяет SQL-команды, чтобы воссоздать пользователей, роли и другие конфигурации. Эта возможность гарантирует, что конфигурацию управления доступом кластера ClickHouse можно сохранить в резервной копии и восстановить как часть общей конфигурации кластера. Эта функциональность работает только для конфигураций, управляемых с помощью SQL-команд (обозначаемых как “система управления доступом и учётными записями на основе SQL”). Конфигурации доступа, определённые в файлах конфигурации сервера ClickHouse (например, users.xml), не включаются в резервные копии и не могут быть восстановлены этим методом.

​
Общий синтаксис

См. “сводку команд”, где приведены более подробные сведения о каждой команде.

​
Сводка команд

Подробное описание каждой из перечисленных выше команд приведено ниже:

​
Настройки

Общие настройки резервного копирования и восстановления Настройки для S3 Настройки для Azure

​
Администрирование и устранение неполадок

Команда backup возвращает id и status, и этот id можно использовать, чтобы узнать статус резервной копии. Это особенно полезно для отслеживания хода выполнения длительных резервных копий ASYNC. В примере ниже показана ошибка, возникшая при попытке перезаписать существующий файл резервной копии:
Наряду с таблицей system.backups, все операции резервного копирования и восстановления также отслеживаются в системной таблице журнала system.backup_log:
Последнее изменение 29 июня 2026 г.