Velero Kubernetes резервне копіювання: де рветься відновлення
Резервні копії знімаються за розкладом, звіти зелені, копії лежать в об'єктному сховищі. А в момент аварії відновлення проходить без жодної помилки — і кластер піднімається «порожнім»: поди падають на старті, застосунки не знаходять своїх даних, частина об'єктів просто відсутня.
Причина в тому, що Velero за замовчуванням копіює не все, що потрібно для робочого стану, а порядок відновлення не повторює порядок залежностей.
Першими втрачаються ресурси, яких немає в маніфестах застосунку: описи власних типів та їхні контролери, секрети й параметри конфігурації, прив'язки прав доступу, вебхуки, обв'язка томів.
За кількістю об'єктів копія виглядає повною, але відновлення кластера після збою не дає жодного робочого зв'язку між ними — і це неповне резервне копіювання, яке виявляється лише на живому контурі.
Друга точка розриву — узгодженість резервних копій.
Знімок тому знімається на рівні сховища, тоді як частина стану застосунку живе в пам'яті та в журналі транзакцій: без попередньої зупинки запису знімок і дані розходяться, і після відкату ми отримуємо узгоджену файлову систему з неузгодженим вмістом. Застосунок стартує, база відкривається — і йде в помилки цілісності.
Третя — порядок. Об'єкти застосовуються хвилями, і якщо власні типи, секрети або оператори опиняються пізніше залежних від них застосунків, контролери створюють ресурси в порожнечу.
Розбираємо, як це закривається: що включати в копію, у якій послідовності відновлювати і як перевіряти, що копія справді піднімає робочий кластер, а не лише формально завершується успіхом.
Що дає кероване резервне копіювання кластера
Резервне копіювання перестає бути страховкою «на всяк випадок» і стає керованим процесом з вимірюваним цільовим часом відновлення.
Розклади знімають стан ресурсів і томів в об'єктне сховище, а відновлення виконується з конкретної точки: окремим простором імен або кластером цілком. Цільовий час відновлення задається заздалегідь — десятки хвилин на типовий сценарій замість годин ручного складання.
Закривається цілий клас відмов, який раніше означав втрату стану: пошкодження сховища стану кластера, помилкове видалення простору імен разом із томами, невдале оновлення описів ресурсів, збій вузла з локальними даними.
У кожному з цих випадків відновлення йде з останньої перевіреної копії, а не зі спроб зібрати конфігурацію з пам'яті.
З чергової зміни знімається ручна робота: Velero за розкладом створює копії, застосовує політику зберігання і за таким самим розкладом перевіряє відновлення в окремому просторі імен.
Черговий не шукає свіжу копію і не збирає ресурси вручну — він запускає відпрацьований сценарій і бачить результат у звіті.
Передбачуваність дає регулярна перевірка: видно, скільки зайняло відновлення, які ресурси не піднялися, що живе поза кластером — сертифікати, секрети, стан зовнішніх систем.
Простій сервісу стає планованим вікном, а не аварією, а частка успішних тренувальних відновлень — метрикою, за якою видно, що захист справді працює.
Velero, снапшоти і реплікація: коли що підходить
Захист стану кластера розпадається на дві різні задачі: швидко повернути робоче навантаження після збою і перенести його на інший майданчик. Снапшот тому закриває першу, але нічого не знає про об'єкти API — маніфести, секрети, прив'язки ролей і конфігурації.
Velero працює саме з ресурсами кластера і вміє доповнювати їх копіюванням даних томів, але за швидкістю відкату поступається снапшоту.
Нижче — варіанти резервного копіювання, між якими реально вибирають, та їхні обмеження, про які зазвичай згадують на етапі відновлення.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Снапшоти томів (засоби CSI або хмари) | Кластер в одній зоні, диски підтримують снапшоти, потрібен відкат за хвилини | Не переносить стан об'єктів API, прив'язаний до провайдера й зони |
| Копії Velero з файловим збором даних томів | Різні майданчики та хмари, потрібне перенесення робочого навантаження | Повільніше на великих томах, агент на нодах, бази потребують узгодженої зупинки |
| Реплікація між кластерами | Потрібні низький час відновлення і безперервність сервісу | Не рятує від логічних помилок: видалення даних реплікується так само |
| Інкрементальні копії | Великі обсяги, вікно копіювання обмежене | Ланцюжок залежностей: для відновлення потрібні всі сегменти |
На практиці підходи комбінують: снапшот дає швидкий відкат, Velero — перенесення і довге зберігання, реплікація прикриває відмову майданчика. Що брати за основу, визначається тим, який час відновлення ви обіцяєте бізнесу.
Етапи впровадження: від аудиту сховищ до передачі
Впровадження починається не зі встановлення, а з інвентаризації: які простори імен критичні, які томи потрібно знімати узгоджено, а які відновлюються із зовнішніх систем. Без цієї картини розклади роблять «на все підряд», сховище зростає, а відкат ніхто не перевіряв.
- Аудит навантажень і цілей відновлення. Розмічаємо ресурси за критичністю і фіксуємо для кожної групи два числа: допустиму втрату даних і допустимий час простою. Вони задають глибину розкладів і вирішують, що потрапляє в копії.
- Схема резервування. Вибираємо цільове об'єктне сховище, розкладку за контейнерами і правила зберігання: скільки копій тримати і коли чистити старе. Окремо визначаємо, як знімати постійні томи — знімками дисків чи файловим способом.
- Налаштування розкладів. Розклади Velero описуємо декларативно, розносимо за критичністю і доповнюємо сценаріями узгодженого зняття стану баз. Конфігурація зберігається в системі контролю версій і проходить рев'ю як код.
- Ізоляція доступу і контроль. Облікові записи з мінімально достатніми правами, шифрування копій і оповіщення про неуспішні завдання — пропущене копіювання видно того ж дня, а не під час аварії.
- Перевірка відновленням. Розгортаємо копії в окремому тестовому контурі, заміряємо час відкату і звіряємо цілісність даних. Розбіжності повертаємо в схему: правимо розклад, порядок зняття томів або набір ресурсів.
- Передача документації. Віддаємо схеми, файли конфігурації, порядок відкату та інструкцію для чергового, розбираємо процес з командою замовника. Далі регламент живе як звичайна експлуатаційна процедура.
Що залишається у вашої команди після впровадження
Робота вважається зданою не тоді, коли розклад копіювання запущено, а коли чергова зміна здатна відновити кластер без автора налаштування. Тому разом з робочою конфігурацією команда отримує пакет доступів, схем і регламентів, за якими відновлення йде по кроках.
- Конфігурації копіювання — розклади Velero, шаблони, списки включених і виключених ресурсів, терміни зберігання точок відновлення.
- Схема резервування — карта: які простори імен, диски та об'єкти потрапляють у копію, у які сховища йдуть дані, чим відрізняються повна та інкрементальна копії.
- Політики доступу і ролі для сховища — роздільні облікові записи на запис копій і на відновлення, мінімально необхідні права, порядок ротації ключів.
- Регламент відновлення — покроковий сценарій з точками розгалуження: вибір точки, підйом окремого простору імен або всього кластера, перевірка результату.
- Інструкції для чергової зміни — що робити при збої, як перевірити свіжість останньої копії, коли ескалувати і кого підключати.
- Регламент регулярних перевірок — як часто виконується тестове відновлення на окремому контурі, що вважається успішним результатом і де зберігається звіт.
- Моніторинг і оповіщення — журнал запусків, алерти на неуспішні копії та на перевищення часу відновлення.
Кожен артефакт перевіряємо на навчальному відновленні: якщо за інструкцією копія не піднімається на тестовому контурі, документ доопрацьовується.
Кейс: відновлення за хвилини замість доби
До впровадження відновлення кластера було ручною операцією: знімки etcd знімалися за розкладом, а томи й об'єкти всередині кластера в копію не потрапляли взагалі.
Коли після невдалого оновлення контролерів потрібно було підняти робочий контур заново, інженери збирали його частинами зі старих описів — простій розтягнувся майже на добу.
Жодної перевірки копій до цього не робили, тому ніхто не міг сказати, чи лежить в архіві щось придатне для відновлення.
Що змінили
Копіювання та відновлення перевели на Velero: розклади рознесли за просторами імен з різними інтервалами — для критичних сервісів частіше, для тестових рідше. Додатковий агент знімає копії томів на рівні файлів, тож в архів потрапляють не лише описи об'єктів, а й самі дані.
Раз на тиждень копія автоматично розгортається в окремому просторі імен: перевірка більше не залежить від того, чи згадає про неї черговий.
Що змінилося в цифрах
Час відновлення типового сервісу скоротився з доби до 15-20 хвилин, вікно допустимої втрати даних — з кількох годин до 15 хвилин на критичних контурах. Частка успішних автоматичних перевірок вийшла за 90%, і кожна займає хвилини без участі людини.
Відкат перестав бути подією: інженер піднімає потрібний зріз даних однією командою і отримує звіт про те, що саме відновлено, а інтервали розкладів підібрані так, щоб обсяг архіву зростав передбачувано.
Що робити, якщо кластер уже розгорнуто і розділено
Кластер уже працює — і це не привід зупиняти його заради резервування. Velero ставиться всередину кластера як контролер і спілкується з ним лише через програмний інтерфейс, а копії складає у сховище об'єктів за межами кластера.
Застосунки, оператори, правила доступу і конвеєри складання залишаються недоторканими — додаються лише описи розкладів і політик зберігання.
Сумісність з поточною схемою забезпечується на рівні відбору об'єктів: копіювати можна за просторами імен, за мітками або за окремими типами ресурсів. Для застосунків зі станом додаються пре- та пост-команди, які призупиняють запис і знімають узгоджений знімок.
Якщо в платформі вже є механізм знімків дисків, він підключається як є; якщо немає — працює файловий збір, і перебудовувати сховище не потрібно.
Кілька контурів розводяться за областями зберігання: у кожного свій набір облікових даних і своя область, щоб політики короткого зберігання на тестових середовищах не витісняли копії бойового контуру.
Керівний екземпляр може бути спільним для всіх контурів, а може стояти в кожному окремо: спільний простіше супроводжувати, роздільний ізолює відмови та права доступу.
Поетапний перехід починається з пілота на одному контурі, потім відновлення перевіряється в окремому просторі імен — там видно, чи піднімаються дані та зв'язки ресурсів цілком.
Після цього розклади включаються на інших контурах по одному, з контролем розміру копій і часу їх створення. Простою немає: запис іде паралельно з робочим трафіком, а перевірочне відновлення не зачіпає бойові сервіси.
Технічні сумніви та обмеження підходу
Копії роблять не для галочки, а під перевірку відновленням. Нижче — заперечення, які найчастіше звучать перед впровадженням Velero: наскільки повна копія, як процес впливає на продуктивний контур і де закінчуються межі застосовності.
Копія буде консистентною, якщо знімок збігся із записом у базу?
Знімок тому фіксує стан диска, але не порядок операцій у застосунку. Для баз і черг стан на момент знімка буває неузгодженим — у конфігурацію додають хуки, які скидають буфери або на час зупиняють запис.
Повнота копій залежить не від інструменту, а від того, чи описані правила для кожного компонента зі станом.
Чи не просяде продуктивний контур під час копіювання?
Основний видаток — читання тому і вивантаження в об'єктне сховище. Знімок робить саме сховище, тому застосунок процесу не помічає, а передача йде фоном з обмеженням за кількістю потоків і смугою.
Частота копіювання задається розкладом: інкрементальні знімки раз на добу, повні — рідше і поза піковими вікнами.
Хто відповідає, якщо відновлення не спрацює?
Інструмент повертає те, що в нього поклали: об'єкти кластера і томи. Секрети в сторонніх сховищах, DNS-записи, балансувальники і стан за межами кластера в копію не потрапляють — це зона замовника.
Ми описуємо політики, хуки і розклади та перевіряємо відновлення на окремому контурі, замовник підтверджує перелік систем і порядок їх підйому.
Де підхід перестає працювати?
На кластерах із тисячами томів і високою швидкістю змін повний обхід стає дорогим за часом. Там, де неприпустима втрата останніх транзакцій, копії не замінюють потокову реплікацію.
Відновлення можливе на рівні namespace, кластера або окремого тому, а цільовий час вимірюється годинами.
Обговоримо вашу задачу і повернемося з планом
Щоб повернутися зі складом робіт і строками, а не із загальними словами, потрібні ваші вихідні дані.
Надішліть конфігурацію кластерів і список просторів імен, позначте сервіси, які зберігають стан, і вкажіть, де зараз лежать копії — в об'єктному сховищі чи на дисках поруч із кластером.
Окремо потрібні цільові показники: допустимий час простою і допустима втрата даних за кожною групою сервісів. Від них залежить і обсяг робіт, і порядок етапів — що закриваємо першим, а що можна відкласти.
Далі ми збираємо план впровадження:
- розбір того, як копії влаштовані зараз — штатними засобами кластера чи через Velero, і на яких кроках вони перестають спрацьовувати
- інвентаризація ресурсів: що копіюється цілком, що відновлюється частинами, що потребує окремого правила
- схема зберігання: розклад, терміни життя версій, захист самих копій від видалення
- перевірка відновлення на тестовому контурі — мінімум по одному сервісу з кожної групи
- регламент для чергової зміни: як запустити відновлення і за якими ознаками зрозуміти, що воно пройшло
- критерії приймання, за якими ви перевірите результат без нашої участі
На виході — оцінка строків за етапами, склад робіт команди і список того, що знадобиться з вашого боку: доступи, вікно на тестові прогони, відповідальний за інфраструктуру. Частини даних може не вистачати — приходьте з тим, що є, решту уточнимо в розмові. Опишіть задачу, і ми повернемося з оцінкою та планом впровадження.
