Налаштування Elasticsearch Snapshot/Restore для резервного копіювання

Elasticsearch snapshot restore: де ламається резервне копіювання

Обов'язкове резервне копіювання Elasticsearch через знімки виглядає прямолінійно, поки кластер невеликий: завдання за розкладом, репозиторій, рідкісні перевірки.

На масштабі ламається не сам механізм, а обв'язка навколо нього — і першим зазвичай здається репозиторій знімків, у який перестають вміщатися нові знімки індексів.

Класичний збій репозиторію знімків — переповнене сховище або відкликані права доступу. Завдання завершується помилкою, але сповіщення не налаштоване, і тижнями копії не створюються взагалі. З'ясовується це в момент відновлення, коли даних за пропущений період уже немає.

Другий клас відмов — накладені завдання, коли розклад запускає новий знімок до завершення попереднього.

Знімки індексів виходять неповними: частина шардів у них відсутня або не сходиться за контрольними сумами, відновлення обривається на середині, а репліки розходяться — один вузол віддає старі дані, інший уже видалені.

Третій — втрачені шарди. Знімок формально успішний, але частина даних не потрапила, бо шард переміщався між вузлами під час зняття. Помилка не видна ні в логах завдання, ні в статусі кластера — тільки під час перевірки відновленням в окремий контур.

Розбираємо, як це закривається: контроль стану репозиторію, серіалізація завдань за розкладом і регулярна перевірка знімків реальним відновленням.

Вимірюваний ефект: час відновлення і втрата даних

Планове резервування переводить відновлення з аварійного сценарію в регламентну операцію: знімки Elasticsearch знімаються за розкладом, а не в момент, коли щось уже зламалося.

Нижче — що саме змінюється у вимірюваних величинах: скільки даних втрачається між знімками, скільки займає підйом кластера і який клас відмов іде зовсім.

Скільки даних втрачається між знімками

Цільову точку відновлення задає частота знімків: інтервал у п'ятнадцять хвилин обмежує втрату операцій цим вікном, а не цілим робочим днем.

Інкрементальні знімки доносять лише змінені сегменти індексів, тому резервувати можна часто — обсяг зберігання зростає повільно, а навантаження на диск залишається в межах штатного.

Додатково налаштовується термін зберігання: старі копії видаляються політикою, реєстр знімків не розростається безконтрольно.

Повне відновлення кластера проти вибіркового

Повне відновлення повертає кластер цілком — це потрібно, коли пошкоджено сам пошуковий шар або налаштування індексів.

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

Час відновлення кластера в цьому разі вимірюється хвилинами, а не годинами очікування переіндексації з первинного джерела.

Вікно резервування не зачіпає пікове навантаження

Знімок знімається без зупинки кластера, але тривалість операції важлива: якщо вона потрапляє в години піку, відгук пошуку просідає.

Ми ставимо розклад на вікно мінімального навантаження і обмежуємо пропускну здатність резервування, тож цільова точка відновлення поліпшується без деградації сервісу для користувачів.

Підсумок перевіряється не на словах: відновлення регулярно програється на тестовому контурі, і за фактом заміряється, скільки даних реально відкотилося і за який час кластер повернувся до роботи.

Варіанти репозиторіїв знімків і коли вони підходять

Репозиторій знімків — це місце, куди кластер пише копії індексів і стану. Тип носія вибирають один раз під час реєстрації: від нього залежить, чи переживе знімок відмову вузла, скільки часу займе відновлення і як розкладаються політики зберігання. Нижче — робочі варіанти та їхні межі.

Локальний диск вузла

Шлях на диску вузла реєструється найшвидше і годиться для стенда й разових перевірок логіки відновлення. Але знімки живуть рівно стільки, скільки живе сам вузол: диск вийшов з ладу — копій немає. Такий репозиторій ще й не розділяється між усіма вузлами, тому в прод його не беруть.

Об'єктне сховище і мережева шара

Об'єктне сховище для резервних копій — основний варіант для продуктивного кластера: знімки лежать поза вузлами, доступні кожному з них і переживають втрату будь-якого. Мережева шара дає схожу відмовостійкість, але чутлива до блокувань і стану мережі.

Іноді розумно тримати кілька репозиторіїв: окремо під часті знімки гарячих індексів і окремо під архів.

Етапи налаштування: аудит, схема, перевірка, передача

Аудит починається не з налаштування, а з розбору того, що вже є: які індекси живуть в Elasticsearch, як швидко зростають, де лежать знімки і хто відповідає за їхній стан. Без цього політика знімків або перекриває потрібне, або залишає без захисту найнавантаженіші дані.

Аудит поточної схеми резервування

1. Інвентаризація: перелічуємо індекси та шаблони, відокремлюємо робочі дані від службових, фіксуємо приріст і реально потрібний термін зберігання.
2. Перевірка сховища знімків: доступи, вільне місце, поведінка при паралельному записі, знімки, які створюються, але жодного разу не відновлювалися.
3. Політика знімків: періодичність, глибина зберігання, прив'язка до індексів, вікно запуску поза піковим навантаженням, правила ротації старих копій.

Перевірка відновленням

• Розгортаємо копію кластера на ізольованому контурі й відновлюємо знімок цілком — у тому обсязі, в якому його доведеться підіймати при аварії.
• Звіряємо результат: кількість документів та індексів, відображення і налаштування, роботу пошукових запитів та агрегацій на відновлених даних.
• Заміряємо час відновлення і точку, до якої дані втрачаються при збої; якщо не вкладаємося в допустиме — змінюємо періодичність і глибину зберігання.

Регламент відновлення передаємо разом з конфігураціями: покрокова інструкція, ролі та доступи, критерії приймання, порядок ескалації. Критерій закритої роботи — команда замовника підіймає кластер без нас.

Політики знімків, терміни зберігання і схеми відновлення

Робоча політика знімків відрізняється від налаштованої тим, що її може виконати черговий, який цю конфігурацію не писав.

Тому замовнику передаємо не лише репозиторій з копіями, а й регламент: що знімається, скільки живе, хто має право записувати, хто — відновлювати і як це перевірити до аварії, а не під час неї.

Регламент чергування і порядок відновлення

• Опис політик знімків — за кожним індексом і потоком даних: періодичність, момент запуску, вікно допустимої затримки, поведінка при недоступності репозиторію.
• Життєвий цикл знімків — скільки зберігається кожен рівень (годинний, щоденний, тижневий), що видаляється автоматично, що захищене від видалення до закриття звітного періоду.
• Схема розміщення репозиторіїв — де фізично лежать копії, як це співвідноситься з вузлами кластера, чому репозиторій не може ділити відмову з продакшеном.
• Ролі доступу до репозиторію — окремі облікові записи на запис, читання і відновлення; спільний обліковий запис чергового виключено, усі операції потрапляють до журналу аудиту.
• Схема відновлення — окремі гілки для втрати одного індексу, відкату всього кластера і перенесення на резервний майданчик, із зазначенням, що саме потрібно від замовника на кожному кроці.
• Чек-ліст перевірки — регулярне тестове відновлення в ізольований контур, звірка кількості документів, мапінгів і налаштувань аналізу, звіт з результатом.
• Документація з резервного копіювання — де лежить, хто власник, що і в який термін оновлюється при додаванні нового індексу або зміні топології.

Після передачі видно, що відновлення не залежить від однієї людини: черговий діє за схемою, а зміни в політиці проходять через того самого власника, що й зміни в кластері.

Кейс: відновлення кластера після відмови майданчика

Аварія почалася з відмови майданчика: вийшли вузли з первинними шардами, а репліки виявилися розміщені в тій самій зоні доступності. Знімки Elasticsearch робилися за розкладом, але лежали в тому самому контурі, і відновлення з них жодного разу не перевіряли.

У момент відмови підіймати кластер було нічим: останній придатний знімок — тижневої давності, репозиторій недоступний разом із майданчиком.

Що було до і що стало після

Спочатку винесли репозиторій знімків у незалежне об'єктне сховище і перебудували розміщення шардів так, щоб репліки не перетиналися з первинними за зоною. Потім налаштували політики знімків: щоденний інкрементальний, тижневий повний, зберігання за кількістю копій на тег.

Окремо зібрали копію кластера на ізольованому контурі — без цього кроку знімок залишається надією, а не планом відновлення.

Щотижня знімок відновлюється на копії: звіряються кількість документів і контрольні суми ключових індексів, розходження дає сповіщення черговому.

Відновлення кластера перестало бути аварійним сценарієм — відкат на попередній реліз і переїзд між майданчиками тепер вкладаються в чергову зміну.

Чим відрізняється snapshot від репліки індексу?

Репліка — це копія шарда в межах того самого кластера: вона тримає читання, коли вузол випадає, але ділить з основним шардом простір відмови. Знімок — вивантаження сегментів індексу в сховище поза кластером: він переживає повну втрату кластера і відновлюється на порожньому місці.

Механізми закривають різні класи відмов і тому доповнюють один одного. Репліка дає безперервність: вузол випав — кластер працює далі.

Знімок дає оборотність: помилковий мапінг або масова правка відкочуються до стану на момент зняття — те, що репліки рознесуть по всіх копіях за секунди.

Вибіркове відновлення індексу — причина тримати знімки не лише «на чорний день»: зі знятого стану підіймають один індекс, за потреби під іншим іменем, порівнюють з робочим і переносять потрібне.

Перенесення даних між кластерами працює так само — спільний репозиторій доступний обом сторонам, проміжні вивантаження не потрібні.

Часті технічні сумніви щодо знімків і відновлення

Знімок в Elasticsearch знімається на рівні сегментів: движок фіксує стан на момент запуску і продовжує приймати запис.

Блоки копіюються у фоні з обмеженням пропускної здатності, тому кластер не перестає обслуговувати запити, хоча на час вивантаження зростає навантаження на диск і мережу.

Як розмітити репозиторій знімків?

Окремий шлях на середовище і призначення: продуктові знімки, передрелізні, архівні. Репозиторій для відновлення підключаємо в режимі лише для читання — так випадковий перезапис бойового знімка виключено на рівні прав доступу.

Як переконатися, що знімок робочий?

Відновленням в ізольований контур, а не перевіркою розміру файлу. Звіряємо кількість документів і ключові індекси, результат фіксуємо в журналі перевірок — інакше відкат перетворюється на лотерею.

Скільки місця знімки займають у сховищі?

Менше, ніж здається: повторювані сегменти не копіюються двічі, кожен наступний знімок додає лише змінені дані. Старі версії прибираємо за правилом зберігання, тому обсяг репозиторію з часом виходить на плато.

Чи можна відновити окремий індекс?

Так, знімок відновлюється вибірково — за списком індексів і з перейменуванням у цільове ім'я. Це прискорює точковий відкат: повертаємо один індекс, не зачіпаючи решту даних і не переписуючи весь кластер.

Обговоримо задачу: що уточнити щодо вашого кластера

Щоб оцінка робіт була точною, а план впровадження — реалізованим без сюрпризів, потрібен короткий набір вступних щодо вашого кластера Elasticsearch. Вивантаження, доступи і тестовий контур на цьому етапі не потрібні: достатньо опису у вільній формі.

За ним уже видно, чи вкладеться повний знімок у вікно обслуговування або потрібні інкрементальні, чи знадобиться окремий репозиторій під архів і правки в розкладі.

• склад кластера: кількість вузлів та їхні ролі, чи виділені окремі вузли під приймання даних;
• поточний репозиторій знімків: файлова система, об'єктне сховище чи інший варіант — і що ще ним користується;
• обсяг даних і добовий приріст: від цього залежить частота знімків і глибина зберігання;
• термін зберігання: скільки поколінь і за який період потрібно тримати доступними для відновлення;
• допустиме вікно втрати даних: скільки хвилин роботи можна втратити при відмові — це задає інтервал між знімками;
• обмеження оточення: пропускна здатність каналу до сховища, години пікового навантаження, вікна обслуговування;
• що вже налаштовано: чи робилися спроби відновлення і куди розгортали дані.

З цими вступними ми повертаємося з оцінкою і планом робіт: порядок кроків, розміщення репозиторію, розклад знімків, окремі перевірки читабельності й пробне відновлення на ізольованому контурі. Опишіть задачу — уточнимо деталі та запропонуємо варіанти щодо термінів і обсягу.