Регистрация хранилища для снапшотов

Это руководство покажет, как зарегистрировать хранилище для снапшотов. Хранилище для снапшотов — это место хранения снапшотов вне кластера. Необходимо зарегистрировать хранилище, прежде чем можно будет создавать или восстанавливать снапшоты.

В этом руководстве вы узнаете, как:

При регистрации хранилища для снапшотов следует учитывать следующее:

Вы можете зарегистрировать и управлять хранилищами снапшотов двумя способами:

Чтобы управлять хранилищами в Kibana, перейдите в главное меню и нажмите Управление стеком > Снапшоты и восстановление > Хранилища. Чтобы зарегистрировать хранилище для снапшотов, нажмите Зарегистрировать хранилище.

Поддерживаемые типы хранилищ для снапшотов зависят от типа вашей развертывания.

Развертывания Elasticsearch Service автоматически регистрируют хранилище found-snapshots. Elasticsearch Service использует это хранилище и cloud-snapshot-policy для периодического создания снапшотов вашего кластера. Вы также можете использовать хранилище found-snapshots для собственных политик SLM или для хранения снапшотов, которые можно искать.

Хранилище found-snapshots специфично для каждой развертывания. Однако вы можете восстановить снапшоты из хранилища found-snapshots другого развертывания, если развертывания находятся под одной учетной записью и в одной области. Подробнее см. документацию по Снапшотам и восстановлению в Cloud.

Развертывания Elasticsearch Service также поддерживают следующие типы хранилищ:

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

Другие типы хранилищ доступны через официальные плагины:

Вы также можете использовать альтернативные реализации этих типов хранилищ, такие как MinIO, при условии их совместимости. Чтобы проверить совместимость хранилища, см. Проверку хранилища.

Используйте хранилище общей файловой системы для хранения снапшотов в общей файловой системе.

Чтобы зарегистрировать хранилище общей файловой системы, сначала смонтируйте файловую систему в одном и том же расположении на всех узлах-мастерах и узлах данных. Затем добавьте путь к файловой системе или родительский каталог в настройку path.repo в elasticsearch.yml для каждого узла-мастера и узла данных. Для работающих кластеров это требует поэтапной перезагрузки каждого узла.

Поддерживаемые значения path.repo различаются в зависимости от платформы:

path:
  repo:
    - /mount/backups
    - /mount/long_term_backups

PUT _snapshot/my_fs_backup
{
  "type": "fs",
  "settings": {
    "location": "/mount/backups/my_fs_backup_location"
  }
}

PUT _snapshot/my_fs_backup
{
  "type": "fs",
  "settings": {
    "location": "my_fs_backup_location"        
  }
}

PUT _snapshot/my_fs_backup
{
  "type": "fs",
  "settings": {
    "location": "my_fs_backup_location",
    "readonly": true
  }
}

path:
  repo:
    - "E:\\Mount\\Backups"                      
    - "\\\\MY_SERVER\\Mount\\Long_term_backups" 

PUT _snapshot/my_fs_backup
{
  "type": "fs",
  "settings": {
    "location": "E:\\Mount\\Backups\\My_fs_backup_location"
  }
}

PUT _snapshot/my_fs_backup
{
  "type": "fs",
  "settings": {
    "location": "My_fs_backup_location"        
  }
}

PUT _snapshot/my_fs_backup
{
  "type": "fs",
  "settings": {
    "location": "my_fs_backup_location",
    "readonly": true
  }
}

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

Используйте Kibana или API создания репозитория снимков для регистрации репозитория URL.

PUT _snapshot/my_read_only_url_repository
{
  "type": "url",
  "settings": {
    "url": "file:/mount/backups/my_fs_backup_location"
  }
}

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

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

При создании снимка с помощью репозитория только для источников Elasticsearch создает снимок только для источников в делегированном репозитории хранения. Этот снимок содержит только сохраненные поля и метаданные. Он не включает структуры индекса или значений документов и не является сразу же доступным для поиска при восстановлении. Чтобы выполнить поиск восстановленных данных, необходимо сначала переиндексировать их в новый поток данных или индекс.

Перед регистрацией репозитория только для источников используйте Kibana или API создания репозитория снимков для регистрации репозитория снимков другого типа для использования в качестве хранилища. Затем зарегистрируйте репозиторий только для источников и укажите делегированный репозиторий хранения в запросе.

PUT _snapshot/my_src_only_repository
{
  "type": "source",
  "settings": {
    "delegate_type": "fs",
    "location": "my_backup_location"
  }
}

При регистрации репозитория снимков Elasticsearch автоматически проверяет, что репозиторий доступен и функционален на всех узлах мастера и данных.

Чтобы отключить эту проверку, установите параметр запроса verify API создания репозитория снимков в значение false. Отключить проверку репозитория в Kibana нельзя.

PUT _snapshot/my_unverified_backup?verify=false
{
  "type": "fs",
  "settings": {
    "location": "my_unverified_backup_location"
  }
}

При необходимости вы можете вручную выполнить проверку репозитория. Чтобы проверить репозиторий в Kibana, перейдите на страницу списка Репозитории и щелкните имя репозитория. Затем нажмите Проверить репозиторий. Вы также можете использовать API проверки репозитория снимков.

POST _snapshot/my_unverified_backup/_verify

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

Вы можете более тщательно протестировать репозиторий, используя API анализа репозиториев.

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

Чтобы выполнить операцию очистки репозитория в Kibana, перейдите на страницу списка Репозитории и щелкните имя репозитория. Затем нажмите Очистить репозиторий.

Вы также можете использовать API очистки репозитория снимков.

POST _snapshot/my_repository/_cleanup

API возвращает:

{
  "results": {
    "deleted_bytes": 20,
    "deleted_blobs": 5
  }
}

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

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

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

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

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

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