Лучшие практики ежедневного резервного копирования и восстановления Elasticsearch

Ежедневные резервные копии защищают ваш кластер Elasticsearch от сбоев, которые не могут исправить реплики: случайное удаление, неправильные маппинги, поврежденные данные, неудачные обновления и полная потеря кластера. Реплики помогают обеспечить доступность, но именно снимки позволяют вернуться к заведомо исправной копии.

Эти лучшие практики ежедневного резервного копирования и восстановления Elasticsearch охватывают настройку репозитория, управление жизненным циклом снимков (SLM), тестирование восстановления и места, где подходит управление жизненным циклом индексов (ILM).

Понимание механизма снимков Elasticsearch

Снимки Elasticsearch — это не просто копии файлов; они инкрементальные и используют внутреннюю структуру индексов Lucene. Это означает, что после первоначального полного снимка последующие снимки сохраняют только те сегменты данных, которые изменились с момента последнего успешного снимка, что делает их очень эффективными с точки зрения времени и хранилища.

Снимки захватывают два основных компонента:

Данные индекса: Фактические сегменты Lucene для выбранных индексов.
Состояние кластера: Метаданные, постоянные настройки, шаблоны индексов, пайплайны и роли.

1. Создание репозитория снимков

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

Типы репозиториев

Тип репозитория	Описание	Лучше всего подходит для	Требования
`fs` (Общая файловая система)	Локальный или сетевой диск, доступный всем мастер- и узлам данных.	Небольшие кластеры, быстрое локальное резервное копирование.	Должен быть зарегистрирован в `elasticsearch.yml` (`path.repo`).
`s3`, `azure`, `gcs`	Облачные сервисы хранения. Некоторые дистрибутивы и версии включают эти типы репозиториев; другие требуют установки соответствующего плагина репозитория на каждом узле.	Продуктивные среды, аварийное восстановление.	Поддержка репозитория, соответствующая версии, и правильные учетные данные IAM/сервисного принципала.

Пример: Регистрация репозитория S3

Для продуктивных сред облачное хранилище обычно является лучшим выбором для долговечности и внеофисного восстановления. Подтвердите поддержку репозитория для вашей версии Elasticsearch, безопасно настройте учетные данные, затем зарегистрируйте репозиторий через API.

PUT /_snapshot/my_s3_daily_repo
{
  "type": "s3",
  "settings": {
    "bucket": "es-backup-bucket-name",
    "region": "us-east-1",
    "base_path": "daily_snapshots/production",
    "compress": true
  }
}

Совет: Убедитесь, что настроенный бакет или путь файловой системы безопасны, неизменяемы (если поддерживается вашим провайдером) и используются исключительно для резервных копий.

2. Внедрение ежедневной автоматизации с помощью SLM

Ручные снимки приемлемы для разовых операций, но рутинные ежедневные резервные копии должны быть автоматизированы с помощью Snapshot Lifecycle Management (SLM). SLM — это встроенный механизм Elasticsearch, предназначенный для определения расписаний, политик хранения и управления снимками.

Определение политики SLM

Типичная ежедневная политика определяет расписание, индексы для включения (или исключения) и срок хранения снимков.

PUT /_slm/policy/daily_archive_policy
{
  "schedule": "0 30 1 * * ?", 
  "name": "<daily-{{now/d}}>",
  "repository": "my_s3_daily_repo",
  "config": {
    "indices": ["logstash-*", "application-metrics-*"],
    "ignore_unavailable": true,
    "include_global_state": false 
  },
  "retention": {
    "expire_after": "30d", 
    "min_count": 5, 
    "max_count": 30 
  }
}

Ключевые моменты конфигурации SLM:

schedule: Использует синтаксис Quartz cron (например, 0 30 1 * * ? выполняется ежедневно в 01:30). Планируйте на часы низкой нагрузки.
include_global_state: false: Для ежедневного резервного копирования данных часто лучше исключить состояние кластера, чтобы предотвратить случайный откат состояния при восстановлении.
retention: Определяет расписание очистки. Пример выше хранит снимки в течение 30 дней, гарантируя, что будет сохранено не менее 5 и не более 30 снимков.

Мониторинг SLM

Регулярно проверяйте статус ваших политик, чтобы убедиться, что они выполняются успешно.

GET /_slm/status
GET /_slm/policy/daily_archive_policy

3. Интеграция с Index Lifecycle Management (ILM)

Для больших временных рядов данных, таких как логи и метрики, Index Lifecycle Management (ILM) управляет индексами от создания до удаления. ILM не заменяет ежедневные снимки SLM, но может помочь скоординировать удаление с завершенной политикой снимков.

ILM и уровни данных

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

Создайте политику SLM, которая делает снимки соответствующего шаблона индекса.
Ссылайтесь на эту политику SLM из фазы удаления ILM с помощью wait_for_snapshot.

...
"delete": {
  "min_age": "90d",
  "actions": {
    "wait_for_snapshot": {
      "policy": "daily_archive_policy"
    },
    "delete": {}
  }
}
...

Это ожидает успешного снимка от указанной политики SLM, прежде чем ILM удалит индекс. Если вы используете потоки данных, протестируйте жизненный цикл в стейджинге, чтобы знать, какие базовые индексы покрываются политикой снимков.

Если ваша цель — хранить старые доступные для поиска данные на более дешевом хранилище вместо их удаления, обратите внимание на действие searchable snapshot в холодной или замороженной фазе. Это другой шаблон, чем обычный снимок для аварийного восстановления:

...
"cold": {
  "min_age": "30d",
  "actions": {
    "searchable_snapshot": {
      "snapshot_repository": "my_s3_daily_repo"
    }
  }
}
...

Используйте один шаблон жизненного цикла на цель: SLM для восстанавливаемых резервных копий, wait_for_snapshot перед удалением и searchable snapshots, когда вам нужен доступ к поиску с меньшими затратами.

4. Лучшие практики тестирования восстановления

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

Среда тестирования восстановления

Не тестируйте восстановление непосредственно на живом продуктивном кластере. Используйте выделенную стейджинговую или тестовую среду, которая работает на совместимой версии Elasticsearch и имеет достаточно дискового пространства для восстановленных шардов.
Частота: Тестируйте восстановление не реже одного раза в квартал или после крупных обновлений/изменений конфигурации.

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

Восстановление может быть нацелено на конкретные индексы или все состояние кластера.

Шаг 1: Получите детали снимка

Определите имя снимка, который нужно восстановить.

GET /_snapshot/my_s3_daily_repo/_all

Шаг 2: Выполните операцию восстановления

Чтобы восстановить конкретные индексы, используйте параметр indices. Часто необходимо переименовывать индексы во время восстановления, чтобы избежать конфликта с активными индексами (особенно в тестовой среде).

POST /_snapshot/my_s3_daily_repo/snapshot_20240501/_restore
{
  "indices": ["logstash-2024-05-01"],
  "rename_pattern": "(.+)",
  "rename_replacement": "restored-$1",
  "include_aliases": false
}

Проверка успешности восстановления

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

GET /_cluster/health/restored-logstash-2024-05-01?wait_for_status=green&timeout=60s
GET /restored-logstash-2024-05-01/_count

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

Безопасность

Доступ к репозиторию: Убедитесь, что учетные данные, используемые Elasticsearch для доступа к репозиторию, следуют принципу наименьших привилегий для пути репозитория. На практике управление снимками требует прав на чтение, запись, список и удаление для объектов, которыми он владеет, особенно когда хранение удаляет старые снимки.
Шифрование: Используйте безопасные репозитории (например, S3) с включенным шифрованием на стороне сервера (SSE-S3 или SSE-KMS).

Регулирование производительности

Снимки могут быть интенсивными по вводу-выводу. Если вы замечаете ухудшение производительности во время окна создания снимков, ограничьте трафик снимков на уровне репозитория. Для многих типов репозиториев соответствующими настройками являются max_snapshot_bytes_per_sec и max_restore_bytes_per_sec при регистрации или обновлении репозитория.

PUT /_snapshot/my_s3_daily_repo
{
  "type": "s3",
  "settings": {
    "bucket": "es-backup-bucket-name",
    "region": "us-east-1",
    "base_path": "daily_snapshots/production",
    "max_snapshot_bytes_per_sec": "100mb",
    "max_restore_bytes_per_sec": "100mb"
  }
}

indices.recovery.max_bytes_per_sec управляет трафиком восстановления пиров и снимков, поэтому настраивайте его только тогда, когда понимаете влияние на восстановление шардов. По возможности планируйте расписания снимков вне пиковых окон индексации и поиска.

Ежедневный рабочий процесс резервного копирования

Настройте долговечный репозиторий: Используйте облачное хранилище (S3/Azure/GCS) для продуктивных сред.
Определите политику SLM: Запланируйте снимки (например, ежедневно в 1:30 утра) с помощью SLM, установив соответствующие правила хранения.
Скоординируйте ILM (если применимо): Используйте wait_for_snapshot перед удалением или searchable snapshots для более дешевой доступной для поиска истории.
Мониторинг статуса: Регулярно проверяйте выполнение политики SLM через API _slm/policy и _slm/status.
Тестируйте восстановление: Ежеквартально или раз в полгода выполняйте полное восстановление в изолированную среду для проверки готовности RTO.

Полезная резервная копия — это та, которую вы можете восстановить. Держите ежедневную политику SLM простой, отслеживайте сбои и проводите тренировки по восстановлению достаточно часто, чтобы ваша команда знала точные шаги до инцидента.