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

План відкату (rollback) — це задокументована послідовність дій, яка повертає валідатор Solana до попереднього стабільного стану після невдалого оновлення, пошкодження конфігурації або критичної аномалії. Без такого плану будь-яке оновлення — це необґрунтований ризик простою та втрати делегованих стейків. Нижче — операційний підхід до створення, перевірки та використання плану відкату.

Що таке rollback та коли він потрібен

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

Відкат потрібен у таких ситуаціях:

  • Після оновлення клієнта валідатор не синхронізується з кластером або постійно форкується (forks).
  • Нова версія бінарного файлу містить регресію, що призводить до крашу (panic) у певних умовах навантаження.
  • Зміна конфігурації (порти, пути до ledger, параметри RAM) зробила сервіс недоступним.
  • Локальна база ledger пошкодилася під час або після оновлення.
  • Оновлення залежностей ОС або системних бібліотек порушило роботу клієнта.

Відкат не допоможе, якщо проблема пов'язана з консенсусом кластера загалом, а не з вашим вузлом. У такому разі рішення приймається на рівні протоколу.

Компоненти плану відкату

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

Резервна версія бінарного файлу

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

Приклад створення резервної копії бінарного файлу Agave (перевірте актуальну назву бінарного файлу у вашому середовищі):

cp /usr/local/bin/agave-validator /usr/local/bin/agave-validator.backup-$(date +%Y%m%d)

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

Резервний конфігураційний файл

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

cp /home/solana/validator-keypair.json /home/solana/validator-keypair.json.backup-$(date +%Y%m%d)
cp /home/solana/testnet-validator.yml /home/solana/testnet-validator.yml.backup-$(date +%Y%m%d)

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

Точка відновлення ledger

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

  • Збереження попередніх snapshot-ів. Перед оновленням скопіюйте поточний snapshot у окрему директорію. Якщо після оновлення ledger пошкодиться, валідатор зможе відновитися з цього snapshot-у замість завантаження з нуля.
  • Збереження інформації про останній стабільний slot. Зафіксуйте номер останнього обробленого слота до оновлення. Це дозволить визначити, чи потрібне повне відновлення ledger, чи достатньо відкотити лише бінарний файл.

solana slot

Зафіксуйте вивід у свій операційний журнал перед початком оновлення.

Документування кроків відкату

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

Мінімальна структура документації кроків відкату:

  1. Ідентифікатор події. Дата, версія клієнта до оновлення, версія після оновлення, кластер (mainnet-beta, testnet, devnet).
  2. Опис проблеми. Що саме пішло не так (краш, форк, помилка синхронізації).
  3. Крок 1: Зупинка сервісу. Точна команда зупинки вашого валідатора (systemctl, pm2, прямий kill).
  4. Крок 2: Заміна бінарного файлу. Команда копіювання резервного бінарного файлу на місце поточного.
  5. Крок 3: Відновлення конфігурації. Команда копіювання резервного конфігураційного файлу.
  6. Крок 4: Перевірка ledger. Команда перевірки цілісності snapshot-у або команда для визначення, чи потрібне відновлення з бекапу.
  7. Крок 5: Запуск сервісу. Точна команда запуску.
  8. Крок 6: Верифікація. Команди для перевірки, що валідатор працює: статус делегування, поточний слот, відсутність помилок у журналі.

Зберігайте цей документ у місці, доступному навіть якщо сам валідатор недоступний (окремий сервер, офлайн-копія).

Тестування плану відкату

План відкату, який ніколи не тестувався — це не план, а ілюзія безпеки. Перевірте його на testnet або devnet перед тим, як застосовувати на mainnet-beta.

Процедура тестування:

  1. Розгорніть валідатор на testnet із тією версією клієнта, з якої плануєте оновлюватися на mainnet.
  2. Дочекайтеся повної синхронізації та стабільної роботи.
  3. Створіть резервні копії бінарного файлу, конфігурації та зафіксуйте стан ledger згідно з вашим планом.
  4. Виконайте оновлення до нової версії.
  5. Навмисно імітуйте проблему (наприклад, замініть бінарний файл на пошкоджений або використайте конфігурацію з помилкою).
  6. Виконайте план відкату крок за кроком.
  7. Зафіксуйте результат: чи повернувся валідатор до роботи, скільки часу зайняв відкат, чи виникли несподівані проблеми.

Якщо під час тестування хоча б один крок не спрацював як задокументовано — виправте документ і повторіть тест.

Критерії прийняття рішення про відкат

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

Відкат виконується негайно, якщо:

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

Відкат не потрібен, якщо:

  • Проблема пов'язана з мережею або DNS, а не з версією клієнта.
  • Валідатор працює стабільно, але ви помітили нові попередження в журналі, які не впливають на голосування.
  • Проблема відома і має офіційне виправлення (hotfix), яке можна застосувати замість відкату.

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

Чеклист відкату

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

До оновлення (підготовка):

  • Резервну копію бінарного файлу створено та хеш зафіксовано.
  • Резервну копію конфігураційного файлу створено.
  • Номер останнього стабільного слота зафіксовано.
  • Snapshot-и скопійовано в окрему директорію (якщо застосовно до вашої стратегії).
  • План відкату задокументовано та доступний офлайн.
  • План відкату протестовано на testnet або devnet.

Під час відкату (виконання):

  • Сервіс валідатора повністю зупинено (перевірено через systemctl status або аналогічну команду).
  • Бінарний файл замінено на резервну копію.
  • Хеш відновленого бінарного файлу збігається з зафіксованим.
  • Конфігураційний файл відновлено з резервної копії.
  • Права доступу до файлів ключів та конфігурації перевірено.
  • Ledger перевірено на цілісність (або відновлено з бекапу snapshot-у).
  • Сервіс запущено.

Після відкату (верифікація):

  • Валідатор приєднався до кластера (перевірено через solana catchup або аналогічну команду).
  • Валідатор голосує (перевірено в журналі або через моніторинг).
  • Жодних нових помилок або panic у журналі.
  • Делегації на місці (перевірено через solana validators або зовнішній дашборд).
  • Подія задокументована: причина відкату, час, виконані кроки, результат.

Після успішного відкату проаналізуйте причину невдачі перед тим, як повторювати спробу оновлення. Якщо проблема у новій версії клієнта — дочекайтеся виправлення. Якщо проблема у вашій конфігурації — виправте її та повторіть тестування на testnet. Додаткові деталі про безпечне оновлення дивіться у розділі Як оновити валідатор без зайвого простою, а про попередню перевірку нових версій — у матеріалі Як перевірити нову версію Agave перед оновленням.

Джерела