Snapshots и Restore
Тема дорожной карты · Elasticsearch
Снапшоты в Elasticsearch — это инкрементные резервные копии одного или нескольких индексов (или всего состояния кластера), создаваемые в определённый момент времени и хранящиеся в репозитории снапшотов, которым может служить общая файловая система, Amazon S3, Google Cloud Storage или Azure Blob Storage. Репозиторий снапшотов регистрируется через PUT /_snapshot/<repo_name>, а снапшот создаётся командой PUT /_snapshot/<repo_name>/<snapshot_name>, которую Elasticsearch выполняет в фоновом режиме, не прерывая текущий трафик поиска. Поскольку снапшоты Elasticsearch инкрементны, каждый последующий снапшот сохраняет только файлы сегментов Lucene, изменившиеся с момента предыдущего, что делает регулярные расписания снапшотов экономичными по месту даже для больших индексов. Восстановление из снапшота выполняется через POST /_snapshot/<repo_name>/<snapshot_name>/_restore и может быть направлено на конкретные индексы с опциональным их переименованием во время восстановления во избежание конфликтов с существующими данными. Политики Snapshot Lifecycle Management (SLM) автоматизируют создание, хранение и удаление снапшотов Elasticsearch по расписанию cron, что является рекомендованным продуктивным подходом к управлению резервными копиями в Elastic Stack.
Как это работает
Snapshots и Restore: cluster health (/_cluster/health — green/yellow/red), shard allocation (rebalancing, awareness, exclusion), Snapshot + Restore (на S3, GCS, MinIO, NFS) для бэкапов, Cross-cluster Search (query нескольких кластеров), Hot-Warm-Cold tiered архитектура (свежие данные на fast SSD, старые на cheap HDD/object store). На масштабе ES Frozen tier + searchable snapshots позволяют держать месяцы логов по cloud-storage ценам.
Когда применять
Snapshots с первого дня — backup ваш единственный выход из data corruption. Rack/zone awareness для HA — shards на multiple failure domains. Мониторьте pending_tasks — растущая очередь = master перегружен. Для long-retention logs — tiered storage (hot/warm/cold), цена — доля от all-SSD.
Типичные ошибки
Ловушки Snapshots и Restore: нет snapshot стратегии (один плохой диск = данных нет); cluster split-brain (избегайте: 3+ master ноды, quorum-based); игнор yellow health (один rolling restart делает red); вручную двигают shards (кластер rebalance обратно, если не excluded).