Операційні вимоги для «Встановлення й конфігурація» перевірено 2 серпня 2026 року. Для production використовуйте тільки реліз Agave, рекомендований для конкретного кластера, і звіряйте параметри з agave-validator --help . Офіційні вимоги Anza на цю дату орієнтують операторів на Ubuntu 24.04, щонайменше 12 ядер/24 потоки, 256 ГБ RAM, окремі швидкі NVMe та симетричний канал від 2 Гбіт/с; це рекомендації, а не гарантія достатньої продуктивності.
Цей розділ — практичний runbook для розгортання валідатора Solana на базі клієнта Agave від першої команди до повноцінного вузла в мережі mainnet-beta. Кожен крок містить передумови, очікуваний результат, способи перевірки та ризики. Інструкції орієнтовані на Ubuntu 24.04 LTS, Debian 12 та Rocky Linux 9 — перевірте актуальну матрицю сумісності в репозиторії Agave перед початком.
Як підготувати Linux для валідатора Solana
Вибір дистрибутива: Ubuntu, Debian, Rocky
Agave validator компілюється та працює на будь-якому сучасному Linux із підтримкою glibc 2.31+. На практиці оператори найчастіше обирають Ubuntu 24.04 LTS (найширша база документації та спільноти), Debian 12 (мінімальне споживання ресурсів на базовій установці) або Rocky Linux 9 (для команд, що орієнтуються на RHEL-сумісний стек). Вибір дистрибутива не впливає на продуктивність валідатора за умови однакових версій ядра та бібліотек.
Оновлення системи та встановлення залежностей
Перед установкою Agave оновіть всі пакети до останніх стабільних версій та встановіть мінімальний набір залежностей:
- build-essential / Development Tools — компілятори та утиліти збірки (потрібні лише якщо збираєте з вихідного коду)
- libssl-dev / openssl-devel — криптографічні бібліотеки
- pkg-config — для коректного визначення шляхів до бібліотек
- curl, jq — для скриптів моніторингу та взаємодії з API
Очікуваний результат: agave-validator --version відпрацьовує без помилок відсутніх бібліотек.
Налаштування параметрів ядра
Solana генерує значний обсяг мережевого трафіку та файлових операцій. Відредагуйте /etc/sysctl.conf або створіть файл у /etc/sysctl.d/:
- net.core.rmem_max та net.core.wmem_max — збільште до 134217728 (128 МБ) для буферів UDP
- net.core.rmem_default та net.core.wmem_default — 16777216 (16 МБ)
- net.ipv4.udp_rmem_min та net.ipv4.udp_wmem_min — 8388608 (8 МБ)
- vm.swappiness — встановіть 1, щоб мінімізувати використання swap
Застосуйте зміни: sysctl --system. Перевірте: sysctl net.core.rmem_max має повернути встановлене значення. Ризик: некоректні значення можуть призвести до втрати пакетів та відставання вузла.
Створення користувача для валідатора
Ніколи не запускайте валідатор від root. Створіть окремого користувача:
sudo useradd -m -s /bin/bash solana
Надайте доступ до необхідних пристроїв та директорій. Валідатору потрібен доступ до NVMe-розділу для ledger та до мережевих портів. Не додавайте користувача до sudo — це створює зайвий вектор атаки.
Налаштування дискових розділів та монтування
Розділ під ledger має бути на NVMe SSD з файловою системою ext4 або xfs. Рекомендується окремий точка монтування, наприклад /mnt/ledger. У /etc/fstab додайте опції noatime,nodiratime для зменшення записів метаданих. Перевірте: df -h /mnt/ledger має показати очікуваний обсяг. Ризик: використання HDD або мережевого сховища для ledger гарантує відставання вузла.
Перевірка готовності системи
Перед переходом до наступного етапу переконайтеся: система оновлена, залежності встановлені, параметри ядра застосовані, користувач створений, диск змонтований із правильними опціями. Швидка перевірка: від імені користувача solana виконайте uname -a, free -h, df -h та переконайтеся, що результати відповідають очікуваним.
Як безпечно створити identity та vote account
Що таке identity account та vote account
Identity account — це ключова пара, що ідентифікує ваш валідатор у мережі. Вона підписує кожен блок та голосування. Втрата цього ключа означає втрату контролю над вузлом. Vote account — окрема ключова пара, через яку валідатор подає голоси за фіналізацію слотів. Identity авторизує vote account, але вони не є одним і тим же ключем.
Генерація ключових пар
Використовуйте CLI Agave для генерації:
solana-keygen new --outfile ~/identity.json
solana-keygen new --outfile ~/vote-account.json
Під час генерації система запропонує створити мнемонічну фразу (seed phrase). Очікуваний результат: у вказаних файлах з'являються JSON-об'єкти з приватними ключами. Ризик: якщо ви пропустите мнемоніку і видалите файл — ключ буде втрачено безповоротно.
Захист ключів: offline, hardware wallet, vault
Identity ключ — найцінніший актив вашої інфраструктури. Рекомендовані стратегії:
- Offline-генерація — створюйте ключі на машині без мережевого з'єднання, перенесіть файли на сервер через зашифрований носій
- Hardware wallet — Agave підтримує підписання за допомогою Ledger та інших HSM-пристроїв
- Secrets manager / vault — зберігайте ключові файли в зашифрованому сховищі з обмеженим доступом
Ніколи не залишайте приватні ключі у відкритому вигляді в домашній директорії користувача з SSH-доступом.
Створення vote account через CLI
Після генерації ключів створіть vote account в мережі (спочатку на devnet або testnet для перевірки):
solana create-vote-account ~/vote-account.json ~/identity.json 1
Останній аргумент — комісія (у відсотках, з точністю до сотих, помножених на 100). Значення 1 означає 1% комісії, що передається від стейкерів до валідатора. Перевірте: solana vote-account ~/vote-account.json має показати щойно створений акаунт.
Авторизація vote account для identity
Під час створення vote account identity автоматично стає авторизованим голосувальником (authorized voter). Якщо пізніше потрібно змінити авторизованого голосувальника, використовуйте solana vote-authorize-voter. Ризик: неправильна авторизація може призвести до неможливості голосування.
Перевірка прив'язки identity → vote account
Виконайте solana vote-account ~/vote-account.json та переконайтеся, що поле authorized voter містить публічний ключ з ~/identity.json. Також перевірте, що node вказує на правильну identity-адресу.
Резервне копіювання ключів
Створіть мінімум дві незалежні копії кожного ключового файла та мнемонічної фрази. Зберігайте їх у різних фізичних та логічних місцях. Перевірте відновлення: на тестовій машині спробуйте відновити ключ з мнемоніки та порівняйте публічний ключ з оригіналом через solana-keygen pubkey.
Як перевірити identity, vote account та authorized voter перед запуском
Які адреси й ролі потрібно звірити
Перед першим підключенням до mainnet-beta перевірте три сутності: публічний ключ identity (solana-keygen pubkey ~/identity.json), публічний ключ vote account (solana-keygen pubkey ~/vote-account.json) та authorized voter у vote account. Усі три мають бути узгоджені.
Перевірка identity та vote account через CLI
solana vote-account ~/vote-account.json — виведе детальну інформацію про vote account, включно з identity, авторизованими голосувальниками, комісією та поточним кредитним рейтингом. Переконайтеся, що поле node збігається з вашим identity pubkey.
Перевірка authorized voter і withdraw authority
Authorized voter — це акаунт, що має право подавати голоси від імені vote account. Withdraw authority — акаунт, що може вивести SOL з vote account. За замовчуванням обидва встановлені на identity, але ви можете розділити їх для підвищення безпеки. Перевірте обидва поля виводом solana vote-account.
Типові помилки перед першим запуском
- Vote account створено в іншій мережі (testnet замість mainnet-beta) — ключі не будуть працювати
- Authorized voter не збігається з identity — голосування не відбуватиметься
- Ключові файли мають неправильні права доступу — Agave відмовиться їх читати
- Мнемоніка не збігається з ключовим файлом — відновлення неможливе
Контрольний список перед підключенням до mainnet-beta
- Identity pubkey збігається з полем node у vote account
- Authorized voter у vote account збігається з identity pubkey
- Vote account існує в mainnet-beta (перевірте через
solana vote-accountз вказаним entrypoint mainnet-beta) - Ключові файли мають права 600 та належать користувачеві
solana - Резервні копії ключів створені та перевірені
Як встановити Agave validator крок за кроком
Передумови: система, залежності, версія
Переконайтеся, що виконано всі кроки з розділу підготовки Linux. Перевірте актуальну стабільну версію Agave в офіційному репозиторії releases — не використовуйте версію, знайдену на сторонніх сайтах. Середовище: Ubuntu 24.04 LTS / Debian 12 / Rocky Linux 9, користувач solana, NVMe-розділ змонтовано.
Завантаження release Agave
Завантажте попередньо зібраний бінарний release для вашої архітектури (зазвичай x86_64-linux). Використовуйте офіційний репозиторій Agave на GitHub. Не завантажуйте бінарні файли з дзеркал або неперевірених джерел.
Верифікація бінарного файлу
Обов'язково перевірте SHA256-хеш завантаженого архіву з указаним у release-нотатках. Також перевірте GPG-підпис, якщо репозиторій його надає. Очікуваний результат: хеш збігається, підпис валідний. Ризик ігнорування: запуск скомпрометованого бінарного файлу означає повну втрату контролю над ключами та коштами.
Встановлення та перевірка версії
Розпакуйте архів та скопіюйте бінарні файли до директорії, що входить у PATH (наприклад, ~/.local/bin або /usr/local/bin). Перевірте:
agave-validator --version
Очікуваний результат: вивід версії, що збігається з завантаженим release.
Створення робочої директорії
Створіть структуру директорій для валідатора:
~/validator/ledger— для ledger (або використовуйте змонтований NVMe-розділ)~/validator/snapshots— для snapshots (можна розмістити на тому ж або окремому диску)~/validator/config— для конфігураційного файлу
Встановіть правильні права: всі директорії мають належати користувачеві solana.
Перший запуск: що відбувається
При першому запуску валідатор перевіряє конфігурацію, шукає локальний ledger, і якщо його немає — намагається завантажити snapshot із вказаного джерела. Потім починає отримувати блоки через gossip та відновлювати стан. До завершення синхронізації валідатор не голосує і не пропонує блоки.
Типові помилки при встановленні
- Бінарний файл не має права на виконання —
chmod +x agave-validator - Залежності відсутні — помилки типу
libssl.so not found, встановіть відповідні -dev пакети - Невідповідність архітектури — спроба запустити aarch64 бінарний файл на x86_64
- Недостатньо місця на диску для розпакування — release архів може вимагати кілька гігабайтів
Як працюють ledger та snapshots у Solana
Що таке ledger: структура та призначення
Ledger — це послідовний лог усіх записів (entries), що складаються з транзакцій та статусів, отриманих валідатором від мережі. Ledger зберігається у вигляді файлів з розширенням .ledger у вказаній директорії. Це первинне джерело даних для відновлення стану.
Як Solana зберігає стан блокчейну
Solana використовує гібридну модель: повний стан (accounts database) відновлюється з snapshot, а потім програванням ledger-записів від точки snapshot до поточного слота. Accounts database зберігається в оперативній пам'яті та періодично серіалізується на диск у вигляді нових snapshots.
Snapshots: що це та навіщо потрібні
Snapshot — це серіалізований зріз повного стану accounts database на певний слот. Без snapshots новому валідатору довелося б програвати весь ledger з генезису, що зайняло б тижні. Зі snapshot час старту зводиться до годин. Snapshots також потрібні для швидкого відновлення після збоїв.
Повні та інкрементальні snapshots
Повний snapshot містить повний стан усіх акаунтів на певний слот. Інкрементальний snapshot містить лише зміни від попереднього повного snapshot. Валідатор завантажує один повний snapshot та один або кілька інкрементальних, після чого програває залишок ledger. Це значно зменшує обсяг завантажених даних.
Як валідатор завантажує snapshot при старті
При старті валідатор перевіряє локальні snapshots. Якщо знайдено актуальний локальний snapshot, він використовується. Якщо ні — валідатор завантажує snapshot із вказаного джерела (snapshot source). Після завантаження snapshot розпаковується, accounts database завантажується в пам'ять, і починається програвання ledger від точки snapshot.
Розмір ledger та стратегії управління місцем
Ledger безперервно зростає. На mainnet-beta швидкість росту становить десятки ГБ на добу. Стратегії управління: обмеження глибини зберігання ledger через параметр --limit-ledger-size, регулярне видалення старих snapshot-файлів, моніторинг вільного місця з автоматичними алертами. Ризик: заповнення диску призведе до зупинки валідатора та пошкодження ledger.
Налаштування зберігання snapshots
У конфігураційному файлі вкажіть окремі шляхи для ledger та snapshots, якщо вони розташовані на різних дисках. Налаштуйте максимальну кількість snapshots, що зберігаються локально, через параметр --snapshots-per-retention-slot або аналогічний. Перевірте: після кількох годин роботи в директорії snapshots мають з'явитися файли.
Як налаштувати systemd service для валідатора
Чому systemd — стандартний спосіб запуску
systemd забезпечує автоматичний перезапуск після збою, управління логами через journald, контроль ресурсів через cgroups, впорядковане зупинення та старт при перезавантаженні. Альтернативи (screen, tmux, nohup) не дають цих гарантій і непридатні для продакшн-інфраструктури.
Створення unit-файлу: ключові директиви
Створіть файл /etc/systemd/system/agave-validator.service. Ключові директиви:
- Type=simple — процес працює на передньому плані
- User=solana — запуск від непривілейованого користувача
- ExecStart — повна команда запуску з усіма аргументами
- ExecStop=/bin/kill -SIGINT $MAINPID — коректне завершення через SIGINT
- WorkingDirectory — робоча директорія валідатора
RestartPolicy, watchdog, ліміти пам'яті
Налаштуйте політику перезапуску: Restart=on-failure з RestartSec=10 — дасть 10 секунд перед перезапуском. Уникайте Restart=always, оскільки це може призвести до циклу перезапусків при структурних помилках. Для watchdog додайте WatchdogSec=60 та передайте --watchdog аргумент валідатору. Встановіть ліміт пам'яті через MemoryMax — але врахуйте, що Agave потребує значний обсяг RAM для accounts database.
Управління сервісом: start, stop, restart, status
Після створення файлу виконайте sudo systemctl daemon-reload. Далі: sudo systemctl start agave-validator, sudo systemctl stop agave-validator, sudo systemctl restart agave-validator, sudo systemctl status agave-validator. Перевірте: status має показувати active (running).
Логування через journald
Усі stdout/stderr валідатора потрапляють у journald. Перегляд: sudo journalctl -u agave-validator -f (real-time), sudo journalctl -u agave-validator --since "1 hour ago" (за часом). Налаштуйте обмеження розміру журналу в /etc/systemd/journald.conf, щоб уникнути заповнення диску.
Автозапуск після перезавантаження
sudo systemctl enable agave-validator — додає сервіс до автозапуску. Перевірте: sudo systemctl is-enabled agave-validator має повернути enabled. Ризик: якщо конфігурація містить помилку, автозапуск призведе до циклу збоїв після кожного перезавантаження.
Перевірка стабільності сервісу
Через кілька годин роботи перевірте: systemctl status agave-validator — активний час має бути безперервним, без перезапусків. journalctl -u agave-validator | grep -i "error\|panic\|fatal" — не має бути критичних помилок. Моніторинг кількості перезапусків: systemctl show agave-validator -p NRestarts.
Конфігураційний файл валідатора: ключові параметри
Розташування та формат config.yml
Конфігураційний файл у форматі YAML розташовується за замовчуванням у ~/validator/config/config.yml (або вказується через --config). Альтернативно, усі параметри можна передати через аргументи командного рядка, але для продакшн-вузлів конфігураційний файл є кращим варіантом — він версіонується, рев'юється та відтворюється.
Identity та vote account у конфігурації
identity — шлях до файлу identity ключа (наприклад, /home/solana/identity.json). vote-account — шлях до файлу vote account ключа. Обидва параметри обов'язкові. Перевірте: після старту в логах має з'явитися повідомлення з вашою identity-адресою.
Ledger path та snapshot path
ledger — директорія для ledger-файлів (наприклад, /mnt/ledger). snapshots — директорія для snapshots. Якщо не вказано, snapshots зберігаються всередині ledger-директорії. Для оптимальної продуктивності розмістіть їх на різних фізичних дисках.
Вказівка entrypoint та відомих валідаторів
entrypoint — початова точка підключення до мережі у форматі ip:port. Для mainnet-beta використовуйте актуальний entrypoint з офіційної документації — перевірте його перед налаштуванням, оскільки він може змінюватися. known-validatores — список публічних ключів та адрес відомих валідаторів для початкового з'єднання через gossip.
Параметри мережі: порт, gossip
gossip-port — порт для gossip-протоколу (за замовчуванням 8001). gossip-host — зовнішня IP-адреса, яку валідатор оголошує в мережі. Якщо ваш сервер за NAT, обов'язково вкажіть зовнішню IP, інакше інші вузли не зможуть підключитися. rpc-port — порт для RPC (якщо ви його увімкнули).
Обмеження ресурсів: RAM, слоти
accounts-db-skip-shrink — дозволяє пропустити стиснення accounts database (економить CPU, але збільшує споживання RAM). limit-ledger-size — максимальний розмір ledger у шматках (shreds). accounts-db-memory-size — явне обмеження пам'яті під accounts database. Налаштовуйте ці параметри виходячи з доступних ресурсів вашого сервера.
Типові помилки в конфігурації
- Неправильний шлях до ключового файлу — валідатор не стартує з помилкою file not found
- Внутрішня IP замість зовнішньої в
gossip-host— валідатор невидимий у мережі - EntryPoint testnet у конфігурації для mainnet-beta — підключення до неправильної мережі
- Недостатній
accounts-db-memory-sizeдля mainnet-beta — OOM-вбивство процесу
Як запустити валідатор на mainnet-beta
Різниця між mainnet-beta, testnet та devnet
mainnet-beta — основна мережа з реальними коштами та найвищими вимогами до ресурсів. testnet — тестова мережа з умовними токенами, близька до mainnet за навантаженням. devnet — мережа для розробників з нижчими вимогами. Конфігурація для кожної мережі відрізняється entrypoint, генезис-блоком та snapshot-джерелами. Ніколи не використовуйте ключі від mainnet-beta на testnet або devnet.
Підготовка snapshot для mainnet-beta
Для mainnet-beta потрібен актуальний повний snapshot. Вкажіть надійне snapshot-джерело у конфігурації (детальніше — у наступному розділі). Перевірте, що snapshot-джерело доступне з вашого сервера: curl -I <snapshot-url> має повернути 200. Не намагайтеся стартувати mainnet-beta без snapshot — це практично неможливо через обсяг ledger.
Конфігурація для mainnet-beta
У конфігураційному файлі вкажіть: entrypoint mainnet-beta, правильні шляхи до identity та vote account ключів (створених саме в mainnet-beta), ledger та snapshot директорії, зовнішню IP-адресу в gossip-host, snapshot-джерело. Перевірте кожен параметр перед стартом.
Перший запуск та синхронізація
Запустіть сервіс: sudo systemctl start agave-validator. Спостерігайте за логами: journalctl -u agave-validator -f. Ви побачите етапи: завантаження snapshot, розпакування accounts database, програвання ledger, підключення до gossip-мережі, початок отримання блоків. Синхронізація mainnet-beta з snapshot зазвичай займає від кількох годин до доби залежно від швидкості диску та мережі.
Перевірка: чи валідатор синхронізовано
solana slot — повертає поточний слот вашого валідатора. solana block-height — поточна висота блоку. Порівняйте з solana slot --url https://api.mainnet-beta.solana.com — різниця має бути в межах кількох слотів. Також перевірте solana validator-info — якщо валідатор синхронізовано, він почне голосувати.
Моніторинг перших годин роботи
Спостерігайте за: використанням RAM (accounts database зростає), завантаженням CPU (програвання ledger інтенсивно навантажує процесор), швидкістю росту слота (має бути стабільною), наявністю помилок у логах. Типова проблема перших годин — OOM-вбивство, якщо accounts-db-memory-size встановлено занадто низько.
Що робити, якщо синхронізація зупинилася
Перевірте логи на наявність помилок. Типові причини: втрата мережевого з'єднання (перевірте gossip-host та фаєрвол), нестача місця на диску (df -h), OOM-вбивство (dmesg | grep -i oom). Якщо проблема в мережі — перевірте, що порти 8000-8010 відкриті для UDP та TCP. Не перезапускайте валідатор без діагностики — це може погіршити ситуацію.
Як налаштувати snapshot-джерело та генератор
Що таке snapshot-джерело (snapshot source)
Snapshot-джерело — це URL або локальний шлях, звідки валідатор завантажує snapshot при старті. Типові джерела: офіційні snapshot-сервери мережі, сторонні провайдери (Genesis, Stakeconomy, інші) або ваш власний сервер. Вибір джерела впливає на швидкість старту та надійність.
Як вказати зовнішній snapshot у конфігурації
У конфігураційному файлі використовуйте параметр snapshot-from або аргумент --snapshot-from <url>. URL має вказувати на конкретний файл повного snapshot. Деякі провайдери надають генератор URL за шаблоном — перевірте документацію провайдера. Перевірте: при старті валідатор має логувати завантаження snapshot з вказаного URL.
Налаштування генерації власних snapshots
Agave автоматично генерує snapshots під час роботи. Щоб інші валідатори могли завантажувати ваші snapshots, налаштуйте HTTP-сервер (nginx, caddy) на директорію snapshots та відкрийте відповідний порт. У конфігурації валідатора вкажіть snapshot-interval-slots — частоту генерації snapshots у слотах.
Частота генерації та зберігання
Типова частота — кожні 100-200 слотів. Зберігайте кілька останніх snapshots для надійності. Налаштуйте автоматичне видалення старих snapshots через cron або systemd-timer, щоб уникнути переповнення диску. Ризик: занадто висока частота генерації збільшує навантаження на диск та CPU.
Як інші валідатори завантажують ваші snapshots
Інші валідатори можуть вказати ваш HTTP-сервер як snapshot-джерело. Для цього ваш сервер має бути доступний за публічною IP-адресою на порту 80 або 443, а директорія snapshots має містити актуальні повні та інкрементальні snapshots. Перевірте доступність: curl -I http://your-server/snapshots/ ззовні.
Моніторинг snapshot-процесу
Спостерігайте за: розміром директорії snapshots, часом генерації кожного snapshot (в логах валідатора), кількістю завантажень з вашого HTTP-сервера (логи nginx). Якщо генерація snapshot займає занадто багато часу — це сигнал про проблеми з диском або недостатній обсяг RAM.
Як перенести валідатор на новий сервер без втрати даних
Коли потрібне перенесення
Типові причини: апгрейд апаратного забезпечення, зміна хостинг-провайдера, міграція на інший регіон для зменшення латентності, заміна пошкодженого сервера. Перенесення не потрібне для оновлення версії Agave — це виконується на місці (детальніше у розділі оновлень).
Підготовка нового сервера
Виконайте повний цикл підготовки Linux, як описано в першому розділі цієї сторінки. Встановіть Agave тієї ж версії, що працює на старому сервері. Створіть користувача, налаштуйте диски, параметри ядра, systemd service. Не створюйте нові ключі — ви будете використовувати існуючі.
Перенесення identity та vote ключів
Попередження: identity ключ — найчутливіший актив. Переносьте його через зашифрований канал. Рекомендований порядок: розшифруйте ключ на офлайн-машині, запишіть на зашифрований USB-накопичувач, перенесіть на новий сервер, перевірте pubkey, видаліть з носія. Альтернатива — використання hardware wallet, який фізично переноситься між серверами. Перевірте: solana-keygen pubkey ~/identity.json на новому сервері має повернути ту саму адресу.
Перенесення ledger або завантаження snapshot
Є два підходи. Перший — перенести весь ledger на новий сервер (підходить для невеликих ledger, займає значний час на копіювання). Другий — завантажити актуальний snapshot на новий сервер (швидше, але потребує часу на синхронізацію з останнього snapshot до поточного слота). Для mainnet-beta другий підхід практичніший. Якщо обираєте перший — зупиніть валідатор на старому сервері перед копіюванням, щоб уникнути пошкодження ledger.
Переключення трафіку на новий вузол
Не запускайте два валідатори з однаковою identity одночасно — це призведе до дублювання голосувань та можливого еджекту. Порядок: зупиніть валідатор на старому сервері (systemctl stop agave-validator), переконайтеся, що процес зупинено, запустіть валідатор на новому сервері. Перевірте: в експлорері Solana ваша identity має показати активність з нової IP-адреси.
Перевірка працездатності після перенесення
Через 15-30 хвилин після старту на новому сервері перевірте: solana slot зростає, solana validator-info показує активне голосування, логи не містять критичних помилок, використання ресурсів в межах норми. Порівняйте швидкість синхронізації з очікуваною.
Декомісія старого сервера
Не поспішайте видаляти дані зі старого сервера. Залиште його працювати в режимі очікування щонайменше 24-48 годин, поки ви не переконаєтеся в стабільності нового вузла. Після підтвердження: зупиніть сервіс, видаліть ключові файли (безпечно — перезапишіть диски), скасуйте підписку на хостинг. Перед видаленням ключів переконайтеся, що у вас є щонайменше дві перевірені резервні копії.