Skip to main content
В этом руководстве рассказывается, как работают резервные копии в ClickHouse Cloud, какие у вас есть варианты настройки резервного копирования для вашего сервиса и как выполнить восстановление из резервной копии. Предварительные требования

Список состояний резервных копий

Резервные копии вашего сервиса будут создаваться по заданному расписанию — стандартному ежедневному или пользовательскому, которое вы выбрали. Все доступные резервные копии можно посмотреть на вкладке Backups сервиса. Здесь отображаются состояние резервной копии, её продолжительность и размер. Вы также можете восстановить конкретную резервную копию через столбец Actions.

Стоимость резервного копирования

Согласно политике по умолчанию, в ClickHouse Cloud резервное копирование выполняется ежедневно, а срок хранения резервных копий составляет 24 часа. Если выбрать расписание, при котором нужно хранить больше данных или создавать резервные копии чаще, это может привести к дополнительным расходам на их хранение. Чтобы понять стоимость резервного копирования, на экране использования можно посмотреть стоимость резервных копий для каждого сервиса (как показано ниже). Когда резервное копирование по пользовательскому расписанию будет выполняться в течение нескольких дней, вы сможете оценить затраты и экстраполировать их, чтобы получить месячную стоимость резервных копий. Чтобы оценить общую стоимость резервных копий, необходимо задать расписание. До этого можно воспользоваться калькулятором цен, чтобы получить примерную месячную оценку, указав следующие параметры:
  • Размер полных и инкрементных резервных копий
  • Желаемая частота резервного копирования
  • Желаемый срок хранения резервных копий
  • Облачный провайдер и регион
Имейте в виду, что расчетная стоимость резервных копий будет меняться по мере роста объема данных в сервисе.

Восстановление резервной копии

Резервные копии восстанавливаются в новый сервис ClickHouse Cloud, а не в существующий сервис, из которого была создана резервная копия. После нажатия на значок Restore для резервной копии можно указать имя нового сервиса, который будет создан, а затем восстановить в него эту резервную копию: Новый сервис будет отображаться в списке сервисов как Provisioning, пока не станет готов:

Работа с восстановленным сервисом

После восстановления резервной копии у вас будет два похожих сервиса: исходный сервис, который требовалось восстановить, и новый восстановленный сервис, созданный из резервной копии исходного. После завершения восстановления из резервной копии выполните одно из следующих действий:
  • Используйте новый восстановленный сервис и удалите исходный сервис.
  • Перенесите данные из нового восстановленного сервиса обратно в исходный сервис и удалите новый восстановленный сервис.

Используйте новый восстановленный сервис

Чтобы использовать новый сервис, выполните следующие действия:
  1. Убедитесь, что у нового сервиса есть записи в IP Access List, необходимые для вашего сценария использования.
  2. Убедитесь, что новый сервис содержит нужные вам данные.
  3. Удалите исходный сервис.

Перенесите данные из только что восстановленного сервиса обратно в исходный сервис

Предположим, что по какой-то причине вы не можете работать с только что восстановленным сервисом, например если у вас всё ещё есть пользователи или приложения, подключающиеся к существующему сервису. В таком случае вы можете перенести восстановленные данные в исходный сервис. Для этого выполните следующие шаги: Разрешите удалённый доступ к только что восстановленному сервису Новый сервис должен быть восстановлен из резервной копии с тем же IP Access List, что и исходный сервис. Это необходимо, поскольку подключения к другим сервисам ClickHouse Cloud не будут разрешены, если только ранее вы не открыли доступ из Anywhere. Измените список разрешённых и временно разрешите доступ из Anywhere. Подробности см. в документации IP Access List. На только что восстановленном сервисе ClickHouse (в системе, где размещены восстановленные данные)
Чтобы получить доступ к новому сервису, вам потребуется сбросить для него пароль. Это можно сделать на вкладке Settings в списке сервисов.
Добавьте пользователя с доступом только на чтение, который сможет читать исходную таблицу (db.table в этом примере):
Скопируйте определение таблицы:
В целевой системе ClickHouse Cloud (той, где была повреждена таблица): Создайте целевую базу данных:
Используя оператор CREATE TABLE из источника, создайте объект в пункте назначения:
При выполнении оператора CREATE измените ENGINE на ReplicatedMergeTree без параметров. В ClickHouse Cloud таблицы всегда реплицируются, и нужные параметры подставляются автоматически.
Используйте функцию remoteSecure, чтобы перенести данные из недавно восстановленного сервиса ClickHouse Cloud в исходный сервис:
После того как вы успешно вставили данные в исходный сервис, обязательно проверьте их в сервисе. После проверки данных вам также следует удалить новый сервис.

Восстановление или отмена удаления таблиц

Команда UNDROP поддерживается в ClickHouse Cloud через Shared Catalog. Чтобы пользователи не удаляли таблицы случайно, можно использовать команды GRANT, чтобы отозвать разрешения на выполнение команды DROP TABLE для конкретного пользователя или роли.
Чтобы предотвратить случайное удаление данных, обратите внимание: по умолчанию в ClickHouse Cloud нельзя удалять таблицы размером >1TB. Если вам нужно удалить таблицы, превышающие этот порог, используйте настройку max_table_size_to_drop:
Legacy Plans: для клиентов на устаревших тарифных планах ежедневные резервные копии по умолчанию с хранением 24 часа включены в стоимость хранения.

Продолжительность резервного копирования

Продолжительность резервного копирования и восстановления зависит от нескольких факторов, включая размер базы данных, ее схему и количество таблиц. Инкрементные резервные копии обычно создаются значительно быстрее, чем полная резервная копия, поскольку копируется меньший объем данных. Восстановление из инкрементной резервной копии обычно немного медленнее, чем из полной, поскольку, как объяснялось выше, в процессе восстановления используются все инкрементные резервные копии в цепочке и последняя полная резервная копия. По результатам нашего тестирования, резервное копирование сравнительно небольших объемов данных — около 1 ТБ — может занимать примерно 10–15 минут и более. Резервное копирование объемов менее 20 ТБ должно завершаться в течение часа, а резервное копирование 50 ТБ данных должно занимать около 2–3 часов. На больших объемах данных проявляется эффект масштаба, и мы наблюдали, что резервное копирование объемом до 1 ПБ для некоторых внутренних сервисов завершалось примерно за 10 часов.
Резервное копирование во внешние бакеты может выполняться медленнее, чем в бакеты ClickHouse
Продолжительность восстановления примерно такая же, как и продолжительность резервного копирования. Мы рекомендуем протестировать это на собственной базе данных или на выборочных данных, чтобы получить более точные оценки, поскольку фактическая продолжительность зависит от нескольких факторов, перечисленных выше.

Настраиваемые резервные копии

Если вам нужно настроить расписание создания резервных копий, отличающееся от расписания по умолчанию, см. раздел Настраиваемые резервные копии.

Экспорт резервных копий в собственный облачный аккаунт

Если вы хотите экспортировать резервные копии в свой облачный аккаунт, см. эту страницу.
Последнее изменение 24 июля 2026 г.