Я планирую использовать облачный плагин ElasticSearch S3 для создания снимков нашего кластера ES. Все это выглядит довольно прямолинейно, но мне интересно, можно ли интегрировать это в нашу существующую стратегию резервного копирования.
Для других наших хранилищ данных мы делаем полную резервную копию каждый час. Мы храним последние 24 часа, по 1 для каждого из последних 7 дней, по 1 для каждой из последних 4 недель и по 1 для каждого из последних 2 месяцев ...
Можно ли создавать снимки таким образом, или мне лучше использовать репозиторий снимков FS, а затем заархивировать содержимое и подключиться к той же процедуре загрузки?
Меня беспокоит только то, что похоже, что функция моментальных снимков по существу создает инкрементные резервные копии, что означает, что это не сработает. Было бы хорошо узнать, как другие делают резервную копию своих кластеров ES.
Большое спасибо
Цитировать документация:
Процесс создания снимка индекса является инкрементным. В процессе создания моментального снимка индекса Elasticsearch анализирует список индексных файлов, которые уже хранятся в репозитории, и копирует только те файлы, которые были созданы или изменены с момента последнего снимка. Это позволяет сохранять в репозитории несколько снимков в компактном виде.
Проработав карьеру в планировании резервного копирования и аварийного восстановления, я понимаю вашу озабоченность. Как и все резервные копии, работа с этой стратегией требует небольшого анализа. Что следует учитывать:
Процедура моментального снимка - это непрерывно-инкрементная стратегия. Для таблицы-накопителя (без оборота) достаточно взять одну полную и хранить приращения навсегда. Кроме...
Во время инициализации моментального снимка информация обо всех предыдущих снимках загружается в память, что означает, что в больших репозиториях для возврата этой команды может потребоваться несколько секунд (или даже минут), даже если
wait_for_completionпараметр установлен наfalse.
Это ваш стимул не хранить все на самом деле. Ежечасная история снимков за два года займет много кучи. К счастью, у них есть DELETE функциональность для удаления этой истории.
Если у вас высокая текучесть кадров, обязательно планируйте выпуск DELETE к более старым снимкам с течением времени. Согласно документации, процесс моментального снимка ES достаточно умен, чтобы правильно обрабатывать процесс очистки данных. Ваша политика моментальных снимков GFS определенно может быть реализована даже с помощью системы «непрерывно-инкрементного» резервного копирования. Думайте об этом как о системе резервного копирования на диск с дедупликацией; вы не очищаете кластер дедупликации каждые 2 месяца, вы позволяете системе резервного копирования извлекать блоки / файлы, которые больше не нужны.
Если вам нужно переместить этот материал, вы можете скопировать само репозиторий моментальных снимков и выполнить на нем обычную ротацию мультимедиа. Es-repo для моментальных снимков предназначен для горячего резервного копирования / восстановления. Если вам по какой-то причине необходимо загрузить более старую версию, вы сможете восстановить автономную копию поверх горячей копии и вызвать восстановление из ES API, и оно загрузится из данных, которые вы поместили в репозиторий моментальных снимков.