Резервное копирование данных

Deckhouse Observability Platform предоставляет возможность выполнить резервное копирование данных путём копирования содержимого S3-бакетов. Помимо метрик и логов, которые сохраняются в S3 во время нормальной работы платформы, модуль также автоматически создаёт резервную копию базы данных PostgreSQL и сохраняет её дамп в S3.

Таким образом, для полного резервного копирования данных необходимо скопировать содержимое трёх S3-бакетов:

  • mimir — для метрик,
  • loki — для логов,
  • backup — для дампов базы данных PostgreSQL.

Настройки резервного копирования базы данных PostgreSQL указываются в ModuleConfig модуля observability-platform. Подробнее см. в описании параметров модуля.

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

Метрики хранятся в S3-бакете в формате TSDB-блоков. Для резервного копирования достаточно скопировать содержимое бакета, например, с использованием утилиты rclone (описана ниже).

⚠️ Обратите внимание: резервное копирование не гарантирует сохранение всех метрик. Метрики за последние два часа могут находиться исключительно в памяти ingester и ещё не быть выгруженными в S3. Это необходимо учитывать при оценке допустимых потерь данных.

Особенности устройства блоков

  • TSDB-блоки иммутабельны (неизменяемы) и имеют уникальные имена. Это позволяет безопасно использовать простые утилиты копирования, без остановки процессов записи.
  • Блок считается завершённым только после появления в нём файла meta.json, который создаётся последним.
  • В резервной копии могут встречаться два типа блоков:
    • Полные блоки (с meta.json) — готовы к восстановлению.
    • Неполные блоки (без meta.json, также называемые partial) — не участвуют в запросах, автоматически удаляются системой через некоторое время и могут присутствовать в бэкапе.
  • Если блок содержит meta.json, но отсутствуют данные (chunks, index), такой блок считается повреждённым. Такие блоки появляются только при сбоях копирования и устраняются при повторном резервном копировании.

Способы резервного копирования S3-бакетов

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

  • Утилиты rclone или minio-client для синхронизации содержимого S3-бакетов с другим хранилищем (локальным или S3-совместимым).
  • Монтирование S3-бакетов в файловую систему сервера с помощью утилит s3fs или geesefs, после чего используются стандартные корпоративные средства резервного копирования.

Использование geesefs

  1. Установите geesefs на сервер, где будет выполняться монтирование:

    curl -L https://github.com/yandex-cloud/geesefs/releases/download/v0.43.0/geesefs-linux-amd64 -o /usr/local/bin/geesefs
chmod +x /usr/local/bin/geesefs

  2. Создайте точки монтирования для соответствующих S3-бакетов:

    mkdir -p /mnt/dop-backup/mimir /mnt/dop-backup/loki /mnt/dop-backup/backup

  3. Получите файл с учетными данными для подключения к S3. На управляющем узле Kubernetes выполните:

    kubectl -n d8-observability-platform get secrets backup-s3 loki-s3 mimir-s3 -o json | jq -r '.items[] | reduce . as $elt ({}; .[$elt.metadata.name|sub("-s3$"; "")] += [($elt.data | map_values(@base64d) | with_entries(.key |= ascii_downcase) | to_entries[] | "\(.key) = \(.value)")]) | to_entries[] | "[\(.key)]\n\(.value|join("\n"))"'

    Сохраните вывод в файл /etc/dop-s3-credentials на сервере.

  4. Сгенерируйте строки для /etc/fstab. На управляющем узле Kubernetes выполните:

    kubectl -n d8-observability-platform get cm backup-s3 loki-s3 mimir-s3 -o json | jq --arg endpoint $(kubectl get mc observability-platform -o json | jq -r '"https://s3." + .spec.settings.general.baseDomain') -r '.items[] | (.metadata.name|sub("-s3$"; "")) as $name | "\(.data.BUCKET_NAME) /mnt/dop-backup/\($name) fuse.geesefs _netdev,allow_other,--file-mode=0644,--dir-mode=0755,--shared-config=/etc/dop-s3-credentials,--profile=\($name),--endpoint=\($endpoint) 0 0"'

    Сохраните вывод в файл /etc/fstab.

  5. Смонтируйте бакеты:

    mount -a

  6. Убедитесь, что S3-бакеты успешно смонтированы:

    ls -l /mnt/dop-backup/backup/postgres-backup

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

Использование rclone

  1. Установите rclone:

    curl -L https://github.com/rclone/rclone/releases/download/v1.69.1/rclone-v1.69.1-linux-amd64.zip -o rclone.zip
unzip -p rclone.zip rclone-*-linux-amd64/rclone | sudo tee /usr/local/bin/rclone > /dev/null
sudo chmod +x /usr/local/bin/rclone
rm rclone.zip

  2. Сформируйте файл rclone.conf. На управляющем узле Kubernetes выполните:

kubectl -n d8-observability-platform get secrets backup-s3 loki-s3 mimir-s3 -o json | jq -r \
  --arg endpoint $(kubectl get mc observability-platform -o json | jq -r '"https://s3." + .spec.settings.general.baseDomain') \
  --argjson buckets $(kubectl -n d8-observability-platform get cm backup-s3 loki-s3 mimir-s3 -o json | jq -cM 'reduce .items[] as $elt ({}; .[$elt.metadata.name] = $elt.data.BUCKET_NAME)') \
  '.items[] | reduce . as $elt ({}; .[$elt.metadata.name] += [($elt.data | map_values(@base64d) | with_entries(.key |= ascii_downcase) | with_entries(.key |= sub("^aws_"; "")) | . += {type: "s3", provider: "Ceph", endpoint: $endpoint} | to_entries[] | "\(.key) = \(.value)")] | .[($elt.metadata.name|sub("-s3$"; ""))] = ["type = alias", "remote = " + ($elt.metadata.name + ":" + $buckets[$elt.metadata.name])]) | to_entries[] | "[\(.key)]\n\(.value|join("\n"))\n"'

  1. Сохраните вывод команды в файл rclone.conf на сервере.

  2. Проверьте доступ к бакету:

    rclone --config rclone.conf ls backup:

  3. Используйте команды rclone sync / copy для создания резервных копий.

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

rclone --config rclone.conf sync -v --delete-before --exclude-if-present deletion-mark.json --exclude '*/markers/*' --exclude '*/bucket-index.json.gz' dop-mimir: /backup/prod/mimir/

Команда синхронизирует содержимое бакета с локальным хранилищем, исключая маркеры, bucket-index и блоки, помеченные на удаление. Исключённые файлы будут удалены из локальной копии, если отсутствуют в источнике.

Восстановление данных

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

Сначала загружаются все блоки без meta.json, затем отдельно загружаются meta.json. Это позволяет обрабатывать только полные, завершённые блоки.

Пример:

rclone --config rclone.conf sync /backup/prod/mimir/ dop-flant-mimir: --exclude '*/meta.json'
rclone --config rclone.conf sync /backup/prod/mimir/ dop-flant-mimir: --include '*/meta.json'

Восстановление базы данных PostgreSQL

Инструкция применима для случаев, когда модуль observability-platform использует встроенный PostgreSQL. Если используется внешняя база данных (.spec.settings.ui.postgres.mode: External), следуйте документации вашего провайдера СУБД.

  1. Остановите backend и компоненты alertgate. Удалите cronjobs, использующие базу данных:

    kubectl -n d8-observability-platform scale deploy backend alertgate-receiver alertgate-sender alertgate-api --replicas=0
kubectl -n d8-observability-platform delete cronjob backend-clean-silences host-load postgres-backup

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

  3. Удалите текущую базу данных PostgreSQL:

    kubectl -n d8-observability-platform exec -it $(kubectl -n d8-observability-platform get po -l spilo-role=master -o name) -- psql -U dop -c "DROP DATABASE dop;" postgres

  4. Создайте базу данных заново:

    kubectl -n d8-observability-platform exec -it $(kubectl -n d8-observability-platform get po -l spilo-role=master -o name) -- psql -U dop -c "CREATE DATABASE dop;" postgres

  5. Восстановите базу данных из дампа:

    zcat dop-202504211200.dump.gz | kubectl -n d8-observability-platform exec -it $(kubectl -n d8-observability-platform get po -l spilo-role=master -o name) -- psql -U dop dop

  6. Запустите backend и компоненты alertgate:

    kubectl -n d8-observability-platform scale deploy backend alertgate-receiver alertgate-sender alertgate-api --replicas=2

  7. Убедитесь, что все компоненты работают:

    kubectl -n d8-observability-platform get po -l 'app in (backend,alertgate-receiver,alertgate-sender,alertgate-api)'

  8. Проверьте доступность веб-интерфейса системы.