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

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

Коли потрібне повне відновлення

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

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

Коли повне відновлення НЕ потрібне: якщо пошкоджено лише частину accounts, є валідний останній snapshot, або валідатор відставає через тимчасову втрату мережі. У цих випадках достатньо локальних дій — див. розділ діагностики на сайті.

Передумови: клієнт Agave (githash перевірте у своєму репозиторії), кластер mainnet-beta, ОС Ubuntu 24.04 LTS. Дата актуальності перевірки команд — верифікуйте у офіційному репозиторії Solana перед виконанням.

Перевірка наявності ключів

Без ключових пар відновлення неможливе — їх не можна відновити з кластера. Перевірте наявність трьох файлів:

  • identity.json — ключ ідентичності валідатора.
  • vote-account.json — ключ голосуючого акаунта.
  • authorized-voter.json — за наявності (необов’язковий, але рекомендований).

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

solana-keygen pubkey identity.json
solana-keygen pubkey vote-account.json

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

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

Ризик: копіювання ключових файлів через ненадійні канали. Використовуйте лише scp з перевіркою хешу або прямий ввід у пам’ять через solana-keygen grind з відновленням з seed-фрази на ізольованій машині.

Завантаження snapshot з надійного джерела

Solana не підтримує повну синхронізацію з genesis з нуля на mainnet-beta — це зайняло б місяці. Єдиний практичний шлях — завантажити актуальний snapshot.

Вибір джерела snapshot

Перевірені джерела (перевірте актуальність у спільноті операторів перед використанням):

  • Офіційний список snapshot-ів від команди Solana (genesis.genesis.rpcpool.com або аналог — URL змінюється, перевірте у репозиторії).
  • Snapshot-и від відомих RPC-провайдерів, які публікують хеш-суми.
  • Власний резервний сервер, якщо він працює паралельно.

Критерій надійності: джерело публікує хеш SHA-256 snapshot-файлу, а цей хеш збігається з даними незалежних операторів.

Завантаження та верифікація

mkdir -p /mnt/solana/ledger
wget -O /mnt/solana/ledger/snapshot.tar.bz2 <URL-джерела>
sha256sum /mnt/solana/ledger/snapshot.tar.bz2

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

Ризик: завантаження snapshot від компрометованого джерела може призвести до підміни стану accounts. Це не впливає на консенсус (кластер відхилить недійсні блоки), але затримає відновлення на години.

Повторна синхронізація з кластером

Після розпакування snapshot валідатор має завантажити пропущені слоти від моменту snapshot до поточного висоти кластера.

Запуск з snapshot

agave-validator \
  --identity identity.json \
  --vote-account vote-account.json \
  --ledger /mnt/solana/ledger \
  --accounts /mnt/solana/accounts \
  --rpc-port 8899 \
  --no-voting \
  --limit-ledger-size 50000000

Параметр --no-voting навмисно встановлено: валідатор не повинен голосувати, поки не досягне найвищого слота кластера (root). Голосування з відстаючим станом призводить до втрати credits.

Очікуваний результат: у журналах з’являється серія повідомлень про завантаження слотів (slot sync). Швидкість залежить від пропускної здатності мережі та диска.

Коли синхронізація вважається завершеною

Валідатор досяг root slot, коли:

  • Значення solana slot дорівнює або перевищує solana slot --url https://api.mainnet-beta.solana.com мінус 1–2 слоти.
  • У журналах з’являється повідомлення про те, що валідатор досяг найвищого відомого root.

Ризик: нестача місця на диску під час синхронізації. Ledger mainnet-beta займає значний обсяг. Перевірте вільне місце до запуску:

df -h /mnt/solana/ledger

Відкат: якщо щось пішло не так, зупиніть процес (Ctrl+C або systemctl stop agave-validator), видаліть вміст директорій ledger та accounts і повторіть процедуру з нового snapshot.

Перевірка identity та vote account

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

solana validators --url https://api.mainnet-beta.solana.com | grep <ваш-identity-pubkey>

Що перевіряти:

  • Identity pubkey збігається з вашим identity.json.
  • Vote account pubkey збігається з вашим vote-account.json.
  • Статус валідатора — не Delinquent (прострочений).
  • Root slot оновлюється (ознака активності).

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

Типова помилка: використання старого vote-account, який був деактивований. У такому разі необхідна реєстрація нового vote-account — це окрема процедура, яка виходить за межі цього матеріалу.

Моніторинг відновлення

Під час синхронізації та перших епох після відновлення контролюйте такі метрики:

Метрика Як перевірити Нормальне значення
Поточний слот solana slot Збігається з кластером ±2 слоти
Root slot solana slot --root Збільшується кожні ~400 мс
Відстань до root solana catchup 0 (повністю синхронізовано)
Статус голосування Журнали валідатора Vote submitted без помилок
Використання диска df -h /mnt/solana Не перевищує 80% ємності

Увімкніть голосування лише після того, як solana catchup покаже повну синхронізацію. Для цього перезапустіть валідатор без прапорця --no-voting.

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

Запобігання повторній втраті даних

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

  • Роздільне зберігання ключів і даних. Ключові пари мають зберігатися на окремому зашифрованому носії або в HSM. Їхня втрата разом із даними робить відновлення неможливим.
  • Резервне копіювання snapshot на інший сервер. Налаштуйте періодичне копіювання snapshot-файлу на віддалену машину через rsync або аналогічний інструмент. Достатньо одного останнього snapshot.
  • RAID або ZFS для ledger-розділу. Захист від виходу з ладу одного диска. Це не замінює бекап, але усуває найчастішу причину втрати даних.
  • Моніторинг вільного місця на диску. Алерт при досягненні 75% ємності. Заповнений диск призводить до зупинки запису ledger і подальшої корупції.
  • Другий валідатор з тим самим vote-account. У разі втрати даних на основному сервері другий продовжує голосувати без перерви. Це вимагає окремої ліцензії та налаштування, але повністю усуває ризик простою.

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

Джерела