Резервное копирование

Резервное копирование и восстановление KUMA
Резервная копия (локальная) событий из хранилища
Архивировние и восстановление БД через ClickHouse BACKUP/RESTORE

Резервное копирование и восстановление KUMA

Информация, приведенная на данной странице, является разработкой команды pre-sales и/или community KUMA и НЕ является официальной рекомендацией вендора.

Официальная документация по данному разделу приведена в Онлайн-справке на продукт: https://support.kaspersky.com/help/KUMA/2.1/ru-RU/222208.htm

Резервное копирование и восстановление KUMA версии 2.1+

В связи с появлением возможности организации отказоустойчивого ядра в кластере kubernetes добавился новый механиз создания резервных копий ядра. Данный механизм использует API системы и в дальнейшем будет основным механизмом резервного копирования и восстановления.

Создание резервной копии Ядра KUMA по API

Для создания резервной копии ресурсов и сертификатов необходимо отправить следующий API-запрос:

GET /api/v1/system/backup

В ответ на запрос возвращается архив tar.gz, содержащий резервную копию Ядра KUMA. На хосте, где установлено Ядро, резервная копия не сохраняется. Сертификаты включаются в состав резервной копии.

Если операция выполнена успешно, создается событие аудита со следующими параметрами:
DeviceAction = "Core backup created"
SourceUserID = "<user-login>"

Пример команды для бэкапа через curl:

curl -k --header 'Authorization: Bearer <token>' 'https://<ip_kuma>:7223/api/v1/system/backup' -o backup.tar.gz

У токена пользователя должны быть соответствующие права для выполнения бекапа

Восстановление Ядра KUMA из резервной копии по API

Восстановление данных из резервной копии доступно только при сохранении версии KUMA.

Необходим работающий сервис MongoDB.

Если сервис MongoDB в нерабочем состоянии

Останавливаете службы MongoDB и Core:

systemctl stop kuma-mongodb.service
systemctl stop kuma-core*.service

Удаляете данные из папки data:

rm -rf /opt/kaspersky/kuma/mongodb/data/*

Запускаете службу MongoDB:

systemctl start kuma-mongodb.service

Инициализируете MongoDB:

/opt/kaspersky/kuma/mongodb/bin/mongo --eval 'rs.initiate()'

Запускаете службу Core:

systemctl start kuma-core*.service

Далее восстанавливаете ядро по пунктам ниже этой главы.

Для восстановления из резервной копии необходимо отправить следующий API-запрос:

POST /api/v1/system/restore

curl -k --request POST 'https://<ip_kuma>:7223/api/v1/system/restore' --header 'Authorization: Bearer <token>'  --data-binary '@/backup/backup.tar.gz'

Тело запроса должно содержать архив с резервной копией Ядра KUMA, полученный в результате выполнения API-запроса создания резервной копии.

После получения архива с резервной копией KUMA выполняет следующие действия:

1. Распаковывает архив с резервной копией Ядра KUMA во временную директорию.

2. Сравнивает версию текущей KUMA и с версией резервной копии KUMA.

3. Если версии соответствуют друг другу, создается событие аудита со следующими параметрами:

DeviceAction = "Core restore scheduled"
SourceUserID = "<имя пользователя инициировавшего восстановление KUMA из резервной копии"

4. Если версии не различаются, выполняет восстановление данных из резервной копии Ядра KUMA.

5. Удаляет временную директорию и стартует в штатном режиме.
В журнале Ядра KUMA появится запись "WARN: restored from backup".

Резервное копирование и восстановление KUMA до версии 2.1 (включительно)

Для создания резервной копии баз ресурсов и сертификатов можно использовать команду:

sudo /opt/kaspersky/kuma/kuma tools backup --dst <путь к директории для резервной копии> --certificates

Для создания резервной копии баз можно использовать команду:

sudo /opt/kaspersky/kuma/kuma tools backup --dst <путь к директории для резервной копии>

(Best Practice) Для автоматизации создания еженедельной (каждое воскресенье в 00:00) резервной копии (в защищенном виде, файлы будут находиться в папке /root/backup/ его можно заменить по желанию) создайте задачу в планировщике CRON следующей командой (выполняется от суперпользователя и в одну строку):

mkdir /root/backup ; echo  PATH=$PATH >> /var/spool/cron/root ; echo  SHELL=$SHELL >> /var/spool/cron/root ; echo "# m h dom mon dow user   command" >> /var/spool/cron/root ; echo "# m h dom mon dow user   command"  >>  /var/spool/cron/root  ;  echo  "0 0 * * 0  /opt/kaspersky/kuma/kuma tools backup --dst /root/backup/ --certificates"  >> /var/spool/cron/root ;  echo  "#0 0 * * 0  /opt/kaspersky/kuma/kuma tools backup --dst /root/backup/"  >> /var/spool/cron/root

Чтобы восстановить данные из резервной копии, войдите в ОС сервера, на котором установлено Ядро KUMA. Остановите Ядро KUMA, выполнив следующую команду:

sudo systemctl stop kuma-core

Выполните следующую команду:

sudo /opt/kaspersky/kuma/kuma tools restore --src <путь к директории с резервной копией> --certificates

Флаг --certificates не является обязательным и используется для восстановления сертификатов.

Запустите KUMA, выполнив следую команду:

sudo systemctl start kuma-core

(опционально) Для создания незащищенной резервной копии конфигураций ресурсов KUMA можно использовать команду, файл сохраните на отдельном носителе (файл будет находиться в папке /home):

/opt/kaspersky/kuma/mongodb/bin/mongodump --db=kuma --archive=/home/kuma_dump_$(date +"%d%m%Y")

Для восстановления:

/opt/kaspersky/kuma/mongodb/bin/mongorestore --drop --archive=<путь к архиву>

Полезные ссылки

Резервное копирование KUMA (онлайн-справка): https://support.kaspersky.com/help/KUMA/2.1/ru-RU/222208.htm
Создание резервной копии Ядра KUMA (Postman): https://www.postman.com/kl-ru-presales/workspace/kaspersky-products-apis-ru/request/23340929-bd766c26-c34b-467e-a28a-4ff65ac05328
Восстановление Ядра KUMA из резервной копии (Postman): https://www.postman.com/kl-ru-presales/workspace/kaspersky-products-apis-ru/request/23340929-974b96b4-0876-449c-9001-9912783f6acc

Резервная копия (локальная) событий из хранилища

С помощью встроенного клиента clickhouse в KUMA

Сохранение данных

Сохранение данных за определенную дату в файл CSV:

/opt/kaspersky/kuma/clickhouse/bin/client.sh -d kuma --multiline --query "SELECT * FROM events_local_v2 WHERE toDate(fromUnixTimestamp64Milli(Timestamp)) = toDate('2024-07-16') FORMAT CSVWithNames;" > click_events.csv

Сохранение данных за определенную дату в файл CSV с максимальным сжатием (cырой файл CSV 1.4 Гб (строк 5630119) - сжатый 72 Мб):

/opt/kaspersky/kuma/clickhouse/bin/client.sh -d kuma --multiline --query "SELECT * FROM events_local_v2 WHERE toDate(fromUnixTimestamp64Milli(Timestamp)) = toDate('2024-07-16') FORMAT CSVWithNames;" | gzip -9 -c > click_events.csv.gz

Сохранение данных за определенную дату по определенному промежутку в часах (время в UTC) в файл CSV с максимальным сжатием (с 10:00:00 до 11:00:00):

/opt/kaspersky/kuma/clickhouse/bin/client.sh -d kuma --multiline --query "SELECT * FROM events_local_v2 WHERE toDateTime(fromUnixTimestamp64Milli(Timestamp)) > toDateTime('2024-07-16 10:00:00') AND toDateTime(fromUnixTimestamp64Milli(Timestamp)) < toDateTime('2024-07-16 11:00:00') FORMAT CSVWithNames;" | gzip -9 -c > click_events.csv.gz

Загрузка данных в хранилище

Распаковать данные с сохранением архива: gzip -dk click_events.csv.gz
Распаковать данные без сохранения архива: gzip -d click_events.csv.gz

Если необходима замена TenantID для видимости событий в определенном тенанте, нужно в распакованном файле CSV заменить третье значение после запятой (столбцы CSV "ID","Timestamp","TenantID","ServiceID","ServiceName"...), пример команды (старый TenantID 746c6045-b929-4edd-8e1e-84ebe4a11880, новый TenantID 911c6045-b929-4edd-8e1e-84ebe4a11911):

sed -i 's/746c6045-b929-4edd-8e1e-84ebe4a11880/911c6045-b929-4edd-8e1e-84ebe4a11911/g' click_events.csv

Загрузка событий из файла CSV в хранилище ClickHouse:

/opt/kaspersky/kuma/clickhouse/bin/client.sh -d kuma --multiline --query "INSERT INTO events_local_v2 FORMAT CSV" < /root/click_events.csv

В CSV файле не должно быть пустых строк, иначе будет ошибка: Code: 27. DB::ParsingException: Cannot parse input: expected ',' before: '\n\n':

С утилитой clickhouse-backup

Для создания резервной копией можно воспользоваться утилитой clickhouse-backup. Исполняемый файл (clickhouse-backup-linux-amd64.tar.gz) для ОС Linux можно загрузить отсюда. Подробнее про утилиту https://github.com/Altinity/clickhouse-backup

Подготовка

Разархивируем загруженный файл:

tar -xvf clickhouse-backup-linux-amd64.tar.gz

Добавляем возможность исполнения файла:

chmod +x clickhouse-backup

Добавляем следующую строку <access_management>1</access_management> в файл:

nano /opt/kaspersky/kuma/clickhouse/cfg/config.xml

В этот раздел конфига:

Создадим файл конфигурации:

nano click_backup_config.yml

Соследующим содержимым:

general:  
  log_level: error
  #remote_storage: sftp
clickhouse:
  host: kuma-aio.sales.lab
  port: 9000
  username: default
  password: ""
  secure: true
  tls_key: "/opt/kaspersky/kuma/clickhouse/certificates/key.pem"
  tls_cert: "/opt/kaspersky/kuma/clickhouse/certificates/cert.pem"
  tls_ca: "/opt/kaspersky/kuma/clickhouse/certificates/ca-cert.pem"
  
  skip_tables:
    - system.*
    - INFORMATION_SCHEMA.*
    - information_schema.*
    - _temporary_and_external_tables.*
#sftp:
#  address: "172.30.56.216"
#  port: 22
#  username: "sftpuser"
#  password: "password"
#  key: ""
#  path: "clickhouse-backup"
#  compression_format: gzip
#  compression_level: 1
#  concurrency: 1
#  debug: false

Для логирования действий утилиты используйте значение log_level: info в конфигурации click_backup_config.yml

В нашем случае восстанавливается Хранилище в инсталляции All-In-One.

Для создания копии данных (ВСЕХ событий) используйте команду:

./clickhouse-backup create -t kuma.events_local_v2 -c click_backup_config.yml

Резервная копия создастся по пути /opt/kaspersky/kuma/clickhouse/data/backup/

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

./clickhouse-backup list -c click_backup_config.yml

Для восстановления из бекапа:

./clickhouse-backup restore 2024-04-08T11-07-24 -t kuma.events_local_v2 -c click_backup_config.yml

После восстановления при поиске может возникать следующая ошибка:

Для исправления ошибки перезапустите хранилище из активных сервисов.

Для удаления бекапа:

./clickhouse-backup delete local 2024-04-08T11-07-24 -c click_backup_config.yml

Удалить служебные данные утилиты:

./clickhouse-backup clean -c click_backup_config.yml

Архивировние и восстановление БД через ClickHouse BACKUP/RESTORE

Данная инструкция проверена и актуальна только для версии KUMA 3.0.3.19

Описание

Данный метод позволяет выполнять локальное архивирование и восстановление партиций ClickHouse через встроенные механизмы BACKUP и RESTORE.

В статье описан пример ручного резервного копирования и восстановления на сервере в конфигурации All-in-One. При помощи скриптов данный подход может быть автоматизирован и распространен на распределенную конфигурацию.

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

Настройка хранилища

1. Создать на сервере хранилища директорию для сохранения резервных копий, например, /tmp/test_backup

2. Сделать владельцем директории пользователя kuma с помощью команды:

chown kuma:kuma /tmp/test_backup/

3. Убедиться, что у пользователя kuma также есть права x и r на всех родительских директориях

4. Перейти в Web-интерфейс KUMA на вкладку "активные сервисы".

5. Открыть на редактирование требуемый сервис хранилища.

6. В поле "Переопределение параметров ClickHouse" задать разрешенный путь для сохранения резервных копий

<backups>
        <allowed_path>/tmp/test_backup/</allowed_path>
</backups>

7. Сохранить сервис хранилища

8. На вкладке "Активные сервисы" выбрать галочкой соответствующий сервис и нажать перезапустить в верхнем меню для применения настроек

Как проверить, что изменения применились

1. Перейдите в консоль соответствующего сервиса Хранилища

2. Выполните команду

cat /opt/kaspersky/kuma/clickhouse/cfg/config.d/override.xml

3. В выводе должны быть параметры, переопределенные в настройках севриса

Выполнение архивирования

1. Запустить клиента clickhouse командой

/opt/kaspersky/kuma/clickhouse/bin/client.sh

2. Выполнить запрос для просмотра партиций, например, такой

SELECT partition, name, partition_id 
FROM system.parts 
WHERE table='events_local_v2' 
AND NOT positionCaseInsensitive(partition,'audit')>0
ORDER BY partition DESC

3. В результате будут выведены названия и id партиций

Для фильтрации по дате можно воспользоваться следующим запросом

SELECT partition, name, partition_id 
FROM system.parts 
WHERE substring(partition,2,8) = '20240406'
AND table='events_local_v2'
AND NOT positionCaseInsensitive(partition,'audit')>0

В результате будут выведены все партиции, кроме партиций событий аудита за 6 апреля 2024 года

4. Для архивации потребуется значение из первой колонки (partition) или последней (partition_id)

5. Для архивации партиции по id необходимо выполнить команду

BACKUP TABLE kuma.events_local_v2 
PARTITION ID '04fb255c7659adfd1d43ed2dd0646b10' 
TO File('/tmp/test_backup/20240406_04fb255c7659adfd1d43ed2dd0646b10.tar.gz') 
SETTINGS compression_method='gzip'

Описание параметров

04fb255c7659adfd1d43ed2dd0646b10 - id партиции из предыдущего запроса

/tmp/test_backup/ - директория для бэкапов

20240406_04fb255c7659adfd1d43ed2dd0646b10.tar.gz - имя файла бэкапа (может быть произвольным)

compression_method='gzip' - выбранный метод сжатия

В случае, если все прошло успешно будет получено сообщение о создании бэкапа:

Также посмотреть состояние бэкапа можно через запрос к таблице system.backups

SELECT * FROM system.backups ORDER BY start_time \G

Либо сразу с фильтрацией по соответствующему id, который был получен в результате выполнения резервного копирования

SELECT * FROM system.backups WHERE id = '66bc2331-9d66-445f-87e7-56e42e2c2b58' \G

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

Пример удаления партиции из интерфейса

1. Перейти на вкладку "Активные сервисы"

2. Выбрать нужное хранилище, нажать по его имени правой кнопкой мыши и выбрать пункт "Смотреть разделы"

3. В разделах выбрать нужный и нажать удалить

Выполнение восстановления

1. Запустить клиента clickhouse командой

/opt/kaspersky/kuma/clickhouse/bin/client.sh

2. Выполнить запрос для восстановления

RESTORE TABLE kuma.events_local_v2 
PARTITION ID '04fb255c7659adfd1d43ed2dd0646b10' 
FROM File('/tmp/test_backup/20240406_04fb255c7659adfd1d43ed2dd0646b10.tar.gz') 
SETTINGS allow_non_empty_tables=true

3. В результате будет восстановлена выбранная партиция из бэкапа и получено соответствующее сообщение:

Если бэкап содержит несколько партиций

В таком случае можно перечислить сразу несколько ID или названий партиций, например:

RESTORE TABLE kuma.events_local_v2 
PARTITIONS (20240405,'a1fbde7a-76d3-4bbc-a769-82126b41b56f',''),
(20240406,'faeede7a-76d3-4bbc-a769-82126b41e453','')
FROM File('/tmp/test_backup/20240406_04fb255c7659adfd1d43ed2dd0646b10.tar.gz')
SETTINGS allow_non_empty_tables=true

Либо выполнить восстановления всех партиций из бэкапа (также полезно в случае, если не известно id или имя партиции)

RESTORE ALL 
FROM File('/tmp/test_backup/20240406_04fb255c7659adfd1d43ed2dd0646b10.tar.gz')
SETTINGS allow_non_empty_tables=true

По аналогии с резервным копированием в таблице system.backups можно посмотреть состояние

SELECT * FROM system.backups ORDER BY start_time \G

Либо сразу с фильтрацией по соответствующему id, который был получен в результате выполнения восстановления:

SELECT * FROM system.backups WHERE id = 'd7758d2f-59c1-4650-afba-c1c288402bf5' \G

При восстановлении партиция ВСЕГДА восстанавливается на диск горячего хранения. Перенос данных на холодное хранение выполняется раз в 1 час. Для форсирования операции необходимо перезапустить сервис Ядра KUMA

Полезные ссылки

ClickHouse Backup and Restore: https://clickhouse.com/docs/en/operations/backup