Как зарезервировать Docker-контейнер Elasticsearch (2026)
Elasticsearch требует согласованного дампа до того, как в дело вступит restic. Dockstash выполняет `PUT _snapshot/<repo>/<snap> via the snapshot API (register a repository first)` внутри контейнера, забирает вывод и хранит его зашифрованным вовне — он никогда не копирует /usr/share/elasticsearch/data вживую, потому что aPI снапшотов захватывает согласованный, инкрементальный point-in-time-вид каждого индекса, пока сегменты Lucene продолжают мержиться внизу.
Что находит Dockstash
| Найденные переменные окружения | ELASTIC_PASSWORD, ELASTICSEARCH_USERNAME, discovery.type |
|---|---|
| Порт по умолчанию | 9200 |
| Живые пути данных (никогда не копируются вживую) | /usr/share/elasticsearch/data |
| Примеры образов | elasticsearch:8.13.0, elasticsearch:8, docker.elastic.co/elasticsearch/elasticsearch |
Резервируем Elasticsearch с Dockstash, шаг за шагом
Создайте аккаунт Dockstash и откройте панель
Зарегистрируйтесь бесплатно на app.dockstash.com/register. Одноразовый мастер настройки спросит ваш VPS для хранения (машину, где будут лежать зашифрованные резервные копии) и сгенерирует пароль шифрования — сразу сохраните его в менеджере паролей: он показывается ровно один раз.
Добавьте Docker-проект, в котором работает Elasticsearch
На экране Projects Dockstash автоматически находит каждую папку Compose-проекта на сервере (по умолчанию под /var/www). Выберите проект с вашим сервисом Elasticsearch. Пока ничего не резервируется — вы лишь указываете Dockstash, где живёт проект.
Проверьте, что Elasticsearch распознан
Откройте проект и вкладку Plan. Dockstash читает docker-compose.yml, распознаёт образ elasticsearch и добавляет слой на основе API снапшотов — плюс имя контейнера и найденные переменные (ELASTIC_PASSWORD, ELASTICSEARCH_USERNAME, discovery.type). Файлы, базы и конфиги прокси можно переключать перед сохранением.
Опционально: проверьте кластер вручную
Если хотите доказательство до автоматизации, опросите curl-ом эндпоинт _cluster/health в контейнере. Статус green или yellow — кластер готов к снапшоту (yellow нормален для одного узла: реплики некуда класть). Red — минимум один первичный шард недоступен; сперва почините его.
docker exec <es-container> curl -s http://localhost:9200/_cluster/health?prettyПодтвердите место хранения
Копии хранятся как зашифрованные снимки restic на вашем VPS, по SSH. После мастера всё настроено; менять — в Settings → Storage. Самому Elasticsearch дополнительно нужен зарегистрированный репозиторий снапшотов — путь в файловой системе (проще всего bind-смонтированный каталог) или object store, куда пишет API снапшотов и который Dockstash передаёт restic.
Настройте расписание резервного копирования
Во вкладке Schedule выберите ежедневно, еженедельно или собственный cron (валидируется при вводе). Ежедневно — верное умолчание для поисковых кластеров: снапшоты в репозитории инкрементальны, каждый запуск хранит только новые сегменты. Добавьте еженедельный prune с политикой хранения.
Запустите первую копию сейчас
Нажмите Backup Now. Dockstash запустит снапшот через API (PUT _snapshot/<repo>/<snap>): Elasticsearch запишет согласованный point-in-time-вид каждого индекса в репозиторий, который Dockstash передаст restic на ваш VPS — живой вывод смотрите в панели логов.
Убедитесь, что снимок существует
По завершении запуска карточка проекта показывает новое время последней копии, число снимков и размер репозитория. Откройте экран Snapshots: точка восстановления появится на таймлайне — это ваше доказательство, что копия дошла до внешнего хранилища.
Команда дампа
PUT _snapshot/<repo>/<snap> via the snapshot API (register a repository first)Команда восстановления
POST _snapshot/<repo>/<snap>/_restore via the snapshot APIAPI снапшотов захватывает согласованный, инкрементальный point-in-time-вид каждого индекса, пока сегменты Lucene продолжают мержиться внизу.
Восстановите копию Elasticsearch и докажите, что она работает
Резервная копия Elasticsearch становится настоящей только после восстановления. Восстановления Dockstash по умолчанию не перезаписывают живой кластер — сначала в новое место, проверка индексов, затем осознанное продвижение.
Выберите точку восстановления
Откройте Snapshots, выберите проект и просмотрите таймлайн. Каждая строка содержит репозиторий снапшотов с согласованным видом каждого индекса плюс файлы проекта того же запуска.
Восстановите в новое место
Нажмите Restore и оставьте режим по умолчанию «Restore to new location». Введите имя проекта для подтверждения — осознанное действие с набором текста. Дамп и файлы попадут в выбранный целевой путь, не трогая живой проект.
Проверьте восстановленные данные
Опросите _cat/indices?v на тестовом узле и прочитайте таблицу: каждый ожидаемый индекс должен быть со здоровьем green или yellow, статусом open и docs.count как в продакшене. Выборочно проверьте документы поисковым запросом.
docker exec <es-container> curl -s "http://localhost:9200/_cat/indices?v"Продвигайте, когда всё проверено
Когда восстановленные данные проверены, переключите на них приложение (или повторите восстановление в режиме «Overwrite existing» — явный опт-ин). Ещё лучше: пусть еженедельная тренировка восстановления делает это доказательство автоматически, чтобы восстановление никогда не было вашей первой репетицией.
Каких ловушек избегать
- Никогда не запускайте restic по живому каталогу данных — сегменты Lucene пишутся и мержатся непрерывно, копия файлов несогласована.
- До первого снапшота нужно зарегистрировать репозиторий (общий fs-путь или object store); bind-смонтированный путь, разделяемый с контейнером, — простейший fs-репозиторий.
- Восстановление уже существующего индекса требует сперва его закрыть или удалить, иначе restore отклоняется.
Типичные проблемы резервирования Elasticsearch
- Симптом
- Вызовы снапшота падают с repository_missing_exception или ошибкой верификации репозитория.
- Причина
- Репозиторий снапшотов не зарегистрирован, либо путь не указан в path.repo / недоступен на запись из контейнера.
- Решение
- Bind-смонтируйте каталог в контейнер, добавьте его в path.repo в elasticsearch.yml, перезапустите и зарегистрируйте через PUT _snapshot/<repo> как fs-репозиторий. Снапшоты работают только с зарегистрированным, проверенным репозиторием.
- Симптом
- Восстановление отклонено: «cannot restore index ... because an open index with same name already exists».
- Причина
- API снапшотов отказывается восстанавливать в открытый индекс — он никогда молча не мержит и не перезаписывает живые данные.
- Решение
- Сначала закройте или удалите индекс, либо восстановите под другим именем через rename_pattern/rename_replacement. Восстановление в тестовый узел полностью снимает коллизию.
- Симптом
- Здоровье кластера red, снапшоты выходят partial или падают.
- Причина
- Минимум один первичный шард не назначен; снапшот не может захватить недоступные шарды.
- Решение
- Диагностируйте через _cluster/allocation/explain и верните первичные шарды (watermark диска, упавший узел, битый шард) до резервирования. Жёлтый одноузловой кластер — норм; red — нет.
Сделайте это в один клик с Dockstash
Dockstash выполняет ровно тот дамп, что выше, передаёт его restic вовне и автоматически проверяет восстановление тренировкой — без скриптов на поддержке.
Последнее обновление: July 2026
Часто задаваемые вопросы
Почему API снапшотов, а не копирование каталога данных?
Elasticsearch постоянно пишет и мержит сегменты Lucene: копия живого каталога несогласована и может не открыться. API снапшотов захватывает согласованный, инкрементальный point-in-time-вид каждого индекса.
Как зарегистрировать репозиторий снапшотов?
Настройте файловый репозиторий на путь, читаемый Elasticsearch и Dockstash (или object store), и зарегистрируйте его вызовом PUT _snapshot. Dockstash передаёт этот каталог restic.
Инкрементальны ли снапшоты Elasticsearch?
Да. Внутри репозитория каждый снапшот хранит лишь отсутствующие сегменты — повторные снапшоты дёшевы. Дедупликация restic усиливает эффект.
Работает ли это и для OpenSearch?
Да — OpenSearch форкнулся от Elasticsearch и сохранил ту же модель API снапшотов. Регистрируете репозиторий и снимаете так же.
Как часто резервировать Elasticsearch?
Ежедневно — практичный вариант: снапшоты инкрементальны, ежедневные запуски дёшевы даже на больших индексах. На Free копии вручную (Backup Now); Pro — до ежечасных, Business — любой cron.
Где на самом деле живут резервные копии?
На вашем собственном VPS для хранения, как зашифрованные снимки restic, отправляемые по SSH. Dockstash никогда не держит ваши данные в чужом облаке — вы указываете машину под вашим контролем, а репозиторий зашифрован паролем, который есть только у вас.
Как узнать, что копия восстановима, без ручного восстановления?
Запланируйте тренировку восстановления. Dockstash восстанавливает последний снимок в изолированную рабочую область, сверяет каждый файл по байтам с источником и проверяет восстановленный дамп — затем ставит на проект значок «прошло/провалено». Еженедельная тренировка означает всегда свежее доказательство.