Просмотр и восстановление резервных копий

Обзор резервных копий в ClickHouse Cloud

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

Предварительные требования

• Вы прочитали “Как работают резервные копии в ClickHouse Cloud” (страница обзора возможностей)

​

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

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

​

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

Если не настроено другое расписание, резервное копирование сервисов выполняется каждые 24 часа, а каждая резервная копия хранится 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 в этом примере):

  CREATE USER exporter
  IDENTIFIED WITH SHA256_PASSWORD BY 'password-here'
  SETTINGS readonly = 1;

  GRANT SELECT ON db.table TO exporter;

Скопируйте определение таблицы:

  SELECT create_table_query
  FROM system.tables
  WHERE database = 'db' AND table = 'table'

В целевой системе ClickHouse Cloud (той, где была повреждена таблица):

Создайте целевую базу данных:

  CREATE DATABASE db

Используя оператор CREATE TABLE из источника, создайте объект в пункте назначения:

При выполнении оператора CREATE измените ENGINE на ReplicatedMergeTree без параметров. В ClickHouse Cloud таблицы всегда реплицируются, и нужные параметры подставляются автоматически.

  CREATE TABLE db.table ...
  ENGINE = ReplicatedMergeTree
  ORDER BY ...

Используйте функцию remoteSecure, чтобы перенести данные из недавно восстановленного сервиса ClickHouse Cloud в исходный сервис:

  INSERT INTO db.table
  SELECT *
  FROM remoteSecure('source-hostname', db, table, 'exporter', 'password-here')

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

​

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

Команда UNDROP поддерживается в ClickHouse Cloud через Shared Catalog.

Чтобы пользователи не удаляли таблицы случайно, можно использовать команды GRANT, чтобы отозвать разрешения на выполнение команды DROP TABLE для конкретного пользователя или роли.

Чтобы предотвратить случайное удаление данных, обратите внимание: по умолчанию в ClickHouse Cloud нельзя удалять таблицы размером >1TB. Если вам нужно удалить таблицы, превышающие этот порог, используйте настройку max_table_size_to_drop:

DROP TABLE IF EXISTS table_to_drop
SYNC SETTINGS max_table_size_to_drop=2000000000000 -- увеличивает лимит до 2TB

Legacy Plans: для клиентов на устаревших тарифных планах ежедневные резервные копии по умолчанию с хранением 24 часа включены в стоимость хранения.

​

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

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

В ходе нашего тестирования резервное копирование примерно 1 ТБ занимало от 10 до 15 минут, а 20 ТБ — около часа. Для более крупных датасетов требуется пропорционально больше времени, и резервное копирование нескольких сотен ТБ или более может занимать много часов, хотя при больших объёмах проявляется эффект масштаба.

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

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

Резервное копирование во внешние бакеты может выполняться медленнее, чем резервное копирование в бакеты ClickHouse.

​

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

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

​

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

Если вы хотите экспортировать резервные копии в свой облачный аккаунт, см. эту страницу.