Создание снимка

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

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

Руководство также содержит рекомендации по созданию отдельных снимков состояния кластера и созданию снимков в разные промежутки времени.

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

Следующие разрешения кластера управляют доступом к действиям SLM при включенных функциях безопасности Elasticsearch:

Вы можете создавать и управлять ролями для назначения этих разрешений через Kibana Management.

Чтобы предоставить необходимые разрешения для создания и управления политиками SLM и снимками, можно настроить роль с разрешениями кластера manage_slm и cluster:admin/snapshot/* и полным доступом к индексам истории SLM.

Например, следующий запрос создает роль slm-admin:

POST _security/role/slm-admin
{
  "cluster": [ "manage_slm", "cluster:admin/snapshot/*" ],
  "indices": [
    {
      "names": [ ".slm-history-*" ],
      "privileges": [ "all" ]
    }
  ]
}

Чтобы предоставить доступ только для чтения к политикам SLM и истории снимков, можно настроить роль с разрешением кластера read_slm и чтением индексов истории управления жизненным циклом снимков.

Например, следующий запрос создаёт роль slm-read-only:

POST _security/role/slm-read-only
{
  "cluster": [ "read_slm" ],
  "indices": [
    {
      "names": [ ".slm-history-*" ],
      "privileges": [ "read" ]
    }
  ]
}

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

Вы также можете управлять SLM с помощью API SLM. Для создания политики используйте API создания политики SLM.

Следующий запрос создает политику, которая ежедневно в 1:30 по UTC создаёт резервную копию состояния кластера, всех потоков данных и всех открытых индексов.

PUT _slm/policy/nightly-snapshots
{
  "schedule": "0 30 1 * * ?",       
  "name": "<nightly-snap-{now/d}>", 
  "repository": "my_repository",    
  "config": {
    "indices": "*",                 
    "include_global_state": true    
  },
  "retention": {                    
    "expire_after": "30d",
    "min_count": 5,
    "max_count": 50
  }
}

Вы можете вручную выполнить политику SLM, чтобы немедленно создать снимок. Это полезно для тестирования новой политики или создания снимка перед обновлением. Ручное выполнение политики не влияет на её расписание.

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

POST _slm/policy/nightly-snapshots/_execute

Процесс создания снимка выполняется в фоновом режиме. Для отслеживания его хода см. Отслеживание снимка.

Удержание снимков SLM — это задача на уровне кластера, которая выполняется отдельно от расписания создания снимков политикой. Для управления запуском задачи удержания SLM настройте настройку кластера slm.retention_schedule.

PUT _cluster/settings
{
  "persistent" : {
    "slm.retention_schedule" : "0 30 1 * * ?"
  }
}

Чтобы немедленно выполнить задачу удержания, используйте API выполнения политики удержания SLM.

POST _slm/_execute_retention

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

Мы рекомендуем включать правила удержания в вашу политику SLM для удаления снимков, которые вам больше не нужны.

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

Чтобы сделать снимок без политики SLM, используйте API создания снимка. Имя снимка поддерживает математику дат.

# PUT _snapshot/my_repository/<my_snapshot_{now/d}>
PUT _snapshot/my_repository/%3Cmy_snapshot_%7Bnow%2Fd%7D%3E

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

PUT _snapshot/my_repository/my_snapshot?wait_for_completion=true

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

Для отслеживания всех выполняющихся снимков используйте API получения снимка с параметром пути запроса _current.

GET _snapshot/my_repository/_current

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

GET _snapshot/_status

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

GET _slm/stats

Чтобы получить информацию об истории выполнения определенной политики SLM, используйте API получения политики SLM. Ответ включает:

GET _slm/policy/nightly-snapshots

Чтобы удалить снимок в Kibana, перейдите на страницу Снимки и нажмите значок корзины в столбце Действия. Вы также можете использовать API удаления снимка.

DELETE _snapshot/my_repository/my_snapshot_2099.05.06

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

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

По умолчанию снимок, включающий состояние кластера, также включает все состояния компонентов. Аналогично, снимок, исключающий состояние кластера, по умолчанию исключает все состояния компонентов.

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

Чтобы получить список доступных компонентов, используйте API получения компонентов.

GET _features

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

{
  "features": [
    {
      "name": "tasks",
      "description": "Manages task results"
    },
    {
      "name": "kibana",
      "description": "Manages Kibana configuration and reports"
    },
    {
      "name": "security",
      "description": "Manages configuration for Security features, such as users and roles"
    },
    ...
  ]
}

Чтобы включить определенное состояние компонента в снимке, укажите компонент name в массиве feature_states.

Например, следующая политика SLM включает в свои снимки только состояния компонентов для компонентов безопасности Kibana и Elasticsearch.

PUT _slm/policy/nightly-snapshots
{
  "schedule": "0 30 2 * * ?",
  "name": "<nightly-snap-{now/d}>",
  "repository": "my_repository",
  "config": {
    "indices": "*",
    "include_global_state": true,
    "feature_states": [
      "kibana",
      "security"
    ]
  },
  "retention": {
    "expire_after": "30d",
    "min_count": 5,
    "max_count": 50
  }
}

Любой индекс или поток данных, являющийся частью состояния компонента, будет отображаться в содержимом снимка. Например, если вы создаёте резервную копию состояния компонента security, системные индексы security-* отображаются в ответе API получения снимка как в indices, так и в feature_states.

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

Для лучшей защиты этих данных следует создать выделенный репозиторий и политику SLM для снимков состояния кластера. Это позволяет строго ограничивать и аудировать доступ к репозиторию.

Например, следующая политика SLM делает резервную копию только состояния кластера. Эта политика хранит эти снимки в выделенном репозитории.

PUT _slm/policy/nightly-cluster-state-snapshots
{
  "schedule": "0 30 2 * * ?",
  "name": "<nightly-cluster-state-snap-{now/d}>",
  "repository": "my_secure_repository",
  "config": {
    "include_global_state": true,                 
    "indices": "-*"                               
  },
  "retention": {
    "expire_after": "30d",
    "min_count": 5,
    "max_count": 50
  }
}

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

PUT _slm/policy/nightly-snapshots
{
  "schedule": "0 30 2 * * ?",
  "name": "<nightly-snap-{now/d}>",
  "repository": "my_repository",
  "config": {
    "include_global_state": false,    
    "indices": "*,-.*"                
  },
  "retention": {
    "expire_after": "30d",
    "min_count": 5,
    "max_count": 50
  }
}

Если вы используете только одну политику SLM, сложно создавать частые снимки и удерживать снимки с более длительными интервалами.

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

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

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

PUT _slm/policy/hourly-snapshots
{
  "name": "<hourly-snapshot-{now/d}>",
  "schedule": "0 0 * * * ?",
  "repository": "my_repository",
  "config": {
    "indices": "*",
    "include_global_state": true
  },
  "retention": {
    "expire_after": "1d",
    "min_count": 1,
    "max_count": 24
  }
}

Следующая политика делает ночные снимки в том же репозитории снимков. Политика хранит свои снимки в течение одного месяца.

PUT _slm/policy/daily-snapshots
{
  "name": "<daily-snapshot-{now/d}>",
  "schedule": "0 45 23 * * ?",          
  "repository": "my_repository",
  "config": {
    "indices": "*",
    "include_global_state": true
  },
  "retention": {
    "expire_after": "30d",
    "min_count": 1,
    "max_count": 31
  }
}

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

PUT _slm/policy/monthly-snapshots
{
  "name": "<monthly-snapshot-{now/d}>",
  "schedule": "0 56 23 1 * ?",            
  "repository": "my_repository",
  "config": {
    "indices": "*",
    "include_global_state": true
  },
  "retention": {
    "expire_after": "366d",
    "min_count": 1,
    "max_count": 12
  }
}