Аварійне відновлення валідатора: стратегії та кроки

Операційні вимоги для «Аварійне відновлення валідатора: стратегії та кроки» перевірено 2 серпня 2026 року. Для production використовуйте тільки реліз Agave, рекомендований для конкретного кластера, і звіряйте параметри з agave-validator --help . Офіційні вимоги Anza на цю дату орієнтують операторів на Ubuntu 24.04, щонайменше 12 ядер/24 потоки, 256 ГБ RAM, окремі швидкі NVMe та симетричний канал від 2 Гбіт/с; це рекомендації, а не гарантія достатньої продуктивності.

Аварійне відновлення (disaster recovery) для валідатора Solana — це задокументований і перевірений набір процедур, який дозволяє повернути вузол у консенсус після катастрофічної відмови. Нижче наведено операційний довідник із класифікацією аварій, стратегіями відновлення, вимогами до плану та методами його тестування.

Контекст перевірки: клієнт Agave (колишній solana-labs/solana), mainnet-beta, Ubuntu 24.04 LTS. Читачеві слід перевірити актуальну версію клієнта та сумісність snapshot-форматів у репозиторії Agave перед застосуванням команд.

Що таке disaster recovery для валідатора

Disaster recovery (DR) у контексті валідатора Solana — це не просто бекап даних. Це здатність відновити участь вузла в консенсусі з прийнятною втратою слотів та без компрометації ключів. Валідатор, який пропускає слоти, втрачає винагороду та репутацію, тому DR-план орієнтований на мінімізацію простою, а не лише на збереження даних.

Ключова відмінність DR для валідатора від класичного серверного DR: стан мережі продовжує рухатися вперед. Відновлений вузол повинен не просто завантажити старий стан, а наздогнати поточний висот (slot) кластера. Це визначає вибір стратегії та пріоритети плану.

Типи аварій: апаратні, мережеві, програмні

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

Апаратні відмови охоплюють виходи з ладу компонентів сервера:

• Відмова NVMe-накопичувача — найчастіша критична відмова. Симптом: зупинка запису ledger, помилки вводу-виводу в журналах, зависання процесу validator. Ledger на NVMe зазвичай не підлягає відновленню на місці.
• Відмова оперативної пам'яті — призводить до випадкових крашів процесу або kernel panic. Діагностується через dmesg та ECC-лічильники (якщо підтримуються).
• Відмова материнської плати або блоку живлення — повна втрата вузла. Вимагає фізичної замени або переміщення на резервний сервер.

Мережеві аварії ускладнені тим, що вузол може бути технічно працюючим, але ізольованим від кластера:

• DDoS-атака — перевантаження інтерфейсу або споживання всієї пропускної здатності. Симптом: вузол бачить старі слоти, solana slot зупиняється, але процес активний.
• Відмова провайдера або BGP-проблема — втрата маршрутизації до значної частини кластера. Діагностується через traceroute до відомих публічних вузлів та перевірку BGP-сесій.
• Блокування порту — firewall або хмарний security group заблокували вхідний UDP/TCP для портів валідатора (за замовчуванням 8000–8020, 8800–8899, 9000–9010 — точний перелік треба перевірити в документації поточної версії Agave).

Програмні відмови виникають на рівні ОС або клієнта:

• Пошкодження ledger — може статися через некоректне завершення роботи, помилку файлової системи або баг клієнта. Симптом: валідатор не може десеріалізувати блоки, крашить при старті.
• Заповнення дискового простору — ledger або логи заповнюють розділ. Симптом: помилки No space left on device, зупинка запису.
• Некоректне оновлення — після апгрейду клієнта валідатор не стартує або не може синхронізуватися. Може вимагати відкату до попередньої версії з відновленням snapshot.
• Пошкодження бази даних акаунтів (Accounts Database) — рідкісна, але критична відмова, що може вимагати повного перезавантаження стану.

Стратегії відновлення

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

Відновлення з snapshot

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

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

Очікуваний результат: валідатор завантажується з стану snapshot і починає наздоганяти кластер. Типовий час: 10–30 хвилин залежно від розміру snapshot та швидкості диска.

Кроки:

1. Зупиніть службу валідатора:
   sudo systemctl stop agave-validator
2. Створіть резервну копію поточного ledger (якщо дані ще доступні та можуть знадобитися для діагностики):
   sudo mv /mnt/ledger /mnt/ledger.corrupted.$(date +%Y%m%d%H%M)
3. Створіть чисту директорію ledger:
   sudo mkdir -p /mnt/ledger
sudo chown solana:solana /mnt/ledger
4. Завантажте snapshot з довіреного джерела. Перевірте актуальну команду та формат у документації Agave — синтаксис може змінюватися між версіями. Типова команда:
   solana-ledger-tool create-snapshot --snapshot-archive-path /tmp/snapshot.tar.bz2 /mnt/ledger
   Або завантаження з публічного джерела через curl або wget з подальшою розпаківкою.
5. Перевірте цілісність snapshot (якщо джерело надає контрольні суми):
   sha256sum /tmp/snapshot.tar.bz2
6. Розпакуйте snapshot у директорію ledger.
7. Запустіть валідатор:
   sudo systemctl start agave-validator
8. Перевірте, що валідатор наздоганяє кластер:
   solana slot
solana catchup

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

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

Відновлення з резервного вузла

Стратегія, що передбачає наявність попередньо налаштованого резервного вузла (warm або hot standby), готового прийняти навантаження. Це найнадійніший варіант для виробничих валідаторів із суворими вимогами до доступності.

Передумови: резервний сервер із встановленим Agave тієї ж версії, налаштованим сервісом, скопійованими ключами та актуальним snapshot. Резервний вузол може бути запущений у режимі архівного вузла (archive node) або просто періодично оновлювати snapshot.

Очікуваний результат: резервний вузол починає валідувати замість основного. Час переключення: 1–5 хвилин (якщо використовується плавна IP-міграція) або час пропаганда DNS (якщо переключення через DNS).

Кроки:

1. Переконайтеся, що резервний вузол має актуальний стан (наздогнав кластер або має свіжий snapshot).
2. Перемкніть IP-адресу на резервний вузол (через BGP announce, floating IP у хмарі або оновлення DNS A-запису).
3. Перевірте, що резервний вузол отримує транзакції та голосує:
   solana validators | grep <your-identity-pubkey>
4. На основному вузлі: зупиніть службу, щоб уникнути конфлікту ідентичності:
   sudo systemctl stop agave-validator

Ризики: одночасна робота двох вузлів з однаковою ідентичністю може призвести до дублювання голосів і штрафів (duplicate vote penalty). Обов'язково зупиняйте основний вузол перед стартом резервного, або використовуйте механізми, що гарантують єдиність активного інстансу.

Відкат: поверніть IP на основний вузол після його відновлення, переконайтеся, що резервний зупинено, і запустіть основний.

Повне відновлення з нуля

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

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

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

Кроки:

1. Підготуйте чисту директорію ledger (див. попередження вище щодо руйнівних операцій).
2. Запустіть валідатор без snapshot, вказавши entrypoint кластера:
   agave-validator --identity /path/to/identity.json --ledger /mnt/ledger --entrypoint entrypoint.mainnet.solana.com:8001
3. Моніторьте прогрес синхронізації:
   solana slot
solana catchup --our-localhost
4. Після досягнення поточного слота перевірте статус голосування.

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

План аварійного відновлення: компоненти

Ефективний DR-план — це не набір команд, а структурований документ, який можна виконати під тиском. Обов'язкові компоненти:

• Інвентаризація інфраструктури. Повний перелік серверів, їхніх ролей (основний, резервний, архівний), специфікації (CPU, RAM, NVMe модель, ємність), хостинг-провайдери, IP-адреси, ASN (якщо є власна). Указати, де фізично знаходиться кожен вузол та які залежності між ними.
• Керування ключами. Точне місцезнаходження keypair валідатора (identity.json), авторизованих withdrawer-адрес. Механізм відновлення ключів: шифрований бекап на окремому фізичному носії, HSM, або multisig-схема. Критично: ключі ніколи не повинні зберігатися на тому ж сервері, що й ledger, без додаткового шифрування.
• Каталог snapshot-джерел. Перелік власних та зовнішніх джерел snapshot із пріоритетами, URL, методами перевірки цілісності та контактами відповідальних осіб.
• Процедури для кожного типу відмови. Покрокові інструкції з чіткими умовами застосування (коли використовувати яку стратегію). Кожна процедура містить: діагностику, дії, перевірку результату, критерії переходу до наступної стратегії, якщо поточна не спрацювала.
• Матриця контактів. Хто відповідає за кожен компонент: системний адміністратор, мережевий інженер, власник ключів, контакт хостинг-провайдера (з номером контракту для пріоритетної підтримки).
• Журнал змін. Кожна модифікація DR-плану фіксується з датою та автором. План, який не оновлювався після зміни інфраструктури, є непридатним.

Час відновлення (RTO) та точність (RPO)

RTO (Recovery Time Objective) — максимальний допустимий час від моменту відмови до відновлення участі вузла в консенсусі. RPO (Recovery Point Objective) — максимальна допустима втрата даних (у контексті валідатора — кількість слотів, стан яких буде втрачено при відновленні).

Для валідатора Solana ці метрики мають специфіку:

Практичне значення: якщо ваш RTO — 30 хвилин, а стратегія відновлення з нуля займає 8 годин, ця стратегія не відповідає вашим вимогам. Вам потрібен резервний вузол або власний свіжий snapshot. RTO та RPO треба визначити до вибору стратегії, а не після.

Важливо: RPO для валідатора не означає втрату транзакцій (вони зафіксовані в кластері незалежно від вашого вузла). Він означає лише точку стану, з якої ваш вузол відновлює роботу.

Тестування плану аварійного відновлення

Неперевірений DR-план — це не план, а документ із хибною впевненістю. Тестування має бути регулярним, задокументованим та реалістичним.

Рівні тестування:

1. Табличне тестування (tabletop exercise). Команда обговорює сценарій аварії на папері, крок за кроком проходить процедури, виявляє розриви в плані. Частота: щокварталу. Мінімальні витрати ресурсів, максимальна цінність для виявлення логічних прогалин.
2. Функціональне тестування на testnet/devnet. Реальне виконання процедур відновлення на тестовому кластері. Імітація відмови диска (відключення розділу), мережевої ізоляції (iptables rules), пошкодження ledger. Частота: раз на півріччя. Дозволяє перевірити актуальність команд та сумісність версій.
3. Повне тестування на mainnet (з обережністю). Переведення основного вузла в плановий простій із виконанням DR-процедури на резервному. Це єдиний спосіб перевірити реальний RTO, але вимагає прийняття ризику простою. Частота: щорічно або після значних змін інфраструктури.

Що фіксувати під час тестування:

• Фактичний час від початку відмови до відновлення голосування (реальний RTO).
• Розбіжності між планом та реальністю (забуті кроки, неточні команди, відсутні доступи).
• Проблеми з snapshot-джерелами (недоступні, повільні, несумісні).
• Час, витрачений на діагностику (часто найбільша складова RTO).

Типові помилки при тестуванні:

• Тестування лише за ідеальних умов (всі доступи відкриті, документ під рукою, мережа стабільна). Реальна аварія супроводжується стресом та обмеженим доступом.
• Виконання тестування тією ж людиною, яка писала план — вона знає процедури напам'ять і не помічає пропущені кроки в документі.
• Відсутність фіксації результатів — без записів неможливо відстежити прогрес і виправити виявлені проблеми.
• Ігнорування оновлень клієнта — після оновлення Agave синтаксис команд або формат snapshot можуть змінитися, роблячи старий план непридатним.

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

Джерела

• Anza: Agave Validator Requirements
• Anza: Setup an Agave Validator
• Anza: Validator Security Best Practices
• Anza Agave: Releases
• Anza: Install the Solana CLI
• Solana Documentation: Staking
• Solana Documentation: Stake Accounts