Обслуживание

Parano1d транзакционно хранит Live State. Для обычного обслуживания не нужно воспроизводить или сохранять исторические тела блоков.

Наблюдение

Используйте локальный CLI:

parano1d-cli status
parano1d-cli peers
parano1d-cli state
parano1d-cli mempool
parano1d-cli mining

С systemd:

systemctl status parano1d
journalctl -u parano1d --since today

Следите за свободным местом для Live State в MDBX и кеша доказательств, а не за условной фиксированной квотой. Объём State следует за текущим числом UTXO.

Остановка перед файловыми операциями

Всегда останавливайте процесс перед копированием базы или заменой бинарников:

sudo systemctl stop parano1d

Дождитесь неактивного состояния службы. Обычное копирование работающего каталога MDBX не гарантирует согласованную резервную копию.

Резервная копия полномочий кошелька

Критически важный файл:

DATA_DIR/wallet.key

Он содержит незашифрованный 256-битный мастер-секрет. Скопируйте файл в офлайн-хранилище с контролем доступа и сохраните права только для владельца.

Для платёжных свидетельств также сохраните:

DATA_DIR/wallet.receipts

Файл идентификатора P2P-пира сохраняет постоянный peer ID ноды, но не даёт права расходовать средства.

Обновление

скачайте новый архив и соответствующий SHA256SUMS;
проверьте хеш;
остановите службу;
одновременно замените parano1d, parano1d-cli и parano1d-miner;
запустите службу;
проверьте запуск и синхронизацию.

При обычном обновлении каталог данных не удаляется.

Пересоздание базы цепи

Если вы подозреваете повреждение State и доступны здоровые пиры:

parano1d --purge-state

Команда очищает всю базу цепи: заголовки, индексы, сохранённые полные блоки, данные отката и Live State. Файлы кошелька, чеки и идентификатор пира находятся вне этой базы и сохраняются. После очистки нода заново синхронизирует цепь и Live State. Предварительно всё равно сохраните ключ кошелька и чеки. Это средство восстановления, а не регулярной очистки.

Подготовка снимков

Входящие снимки хранятся как временные данные. После прерванной передачи незавершённая копия удаляется при следующем запуске до начала новой сессии. Не переносите файлы из snapshot-staging в каноническую базу вручную.

База и финальность

Данные отката хранятся 36 блоков, полные тела — 18. Эти окна обслуживаются автоматически. Увеличение локального дискового хранения не меняет консенсусное правило финальности в 18 блоков.