Примеры Snapshot
Готовое расследование
Выбрать и выполнить правильный сценарий восстановления mainnet
Используйте это расследование, когда оператор говорит «мне нужно вернуть этот узел в онлайн» и нужно понять, правильный ли путь — optimized fast-rpc, обычный RPC или архивное восстановление с hot/cold-данными.
Сначала выберите класс восстановления, а затем выполните минимальную последовательность команд именно для него.
01Сначала решите, нужен ли вам optimized fast-rpc, обычный RPC или архивный режим.
02Если нужен архив, сначала зафиксируйте одну точную высоту snapshot-блока и дальше переиспользуйте только её.
03Выполняйте только команды выбранного пути и не смешивайте optimized, standard и archival шаги в одном сценарии.
Цель
- Превратить расплывчатый запрос на восстановление в правильный сценарий снапшота mainnet и минимальную последовательность команд, с которой уже можно безопасно стартовать.
| Путь или команда | Как используем | Зачем используем |
|---|---|---|
Mainnet optimized fast-rpc | Выбираем его первым, когда цель — максимально быстрое восстановление высокопроизводительного RPC, а узел подходит для optimized profile | Это предпочтительный путь быстрого восстановления, если архивное хранение не требуется |
| Стандартный RPC в mainnet | Используем его, когда нужен более простой сценарий восстановления RPC без optimized profile | Даёт прямой стандартный путь восстановления в обычный каталог данных nearcore |
| Получение последней высоты архивного снапшота | Получаем последнюю высоту архивного снапшота перед архивным восстановлением | Даёт конкретный блок снапшота как опору для загрузки hot/cold-данных |
| Команда загрузки hot-данных | Запускаем её первой и размещаем результат на NVMe | Горячие архивные данные должны лежать на быстром уровне хранения, чтобы узел работал корректно |
| Команда загрузки cold-данных | Запускаем её после hot-данных и размещаем на холодном уровне хранения | Завершает архивное восстановление без необходимости держать весь архив на дорогом hot-уровне |
Что должен включать полезный ответ
- какой сценарий восстановления выбран и почему
- какие ключевые env vars важны для выбранного пути
- куда на диске должны попасть данные
- должен ли оператор оставаться в FastNear snapshot docs или переходить к общим гайдам nearcore по bootstrap
Shell-сценарий архивного восстановления mainnet
Используйте этот сценарий, когда вы уже решили, что нужен именно архивный путь для mainnet, и теперь нужна точная последовательность команд с одной общей опорной высотой блока.
Что вы делаете
- Один раз получаете последнюю высоту архивного снапшота mainnet.
- Сохраняете её в
LATEST. - Переиспользуете ровно эту же высоту блока и для hot-data, и для cold-data.
HOT_DATA_PATH=~/.near/data
COLD_DATA_PATH=/mnt/hdds/cold-data
LATEST="$(curl -s "https://snapshot.neardata.xyz/mainnet/archival/latest.txt")"
echo "Latest archival mainnet snapshot block: $LATEST"
curl --proto '=https' --tlsv1.2 -sSf https://raw.githubusercontent.com/fastnear/static/refs/heads/main/down_rclone_archival.sh \
| DATA_TYPE=hot-data DATA_PATH="$HOT_DATA_PATH" CHAIN_ID=mainnet BLOCK="$LATEST" bash
curl --proto '=https' --tlsv1.2 -sSf https://raw.githubusercontent.com/fastnear/static/refs/heads/main/down_rclone_archival.sh \
| DATA_TYPE=cold-data DATA_PATH="$COLD_DATA_PATH" CHAIN_ID=mainnet BLOCK="$LATEST" bashЗачем нужен следующий шаг?
Архивные hot- и cold-данные должны происходить из одного и того же среза снапшота. Повторное использование одного сохранённого значения LATEST в обеих командах сохраняет внутреннюю согласованность архива и делает последующую настройку nearcore заметно менее неожиданной.
Частые задачи
Поднять optimized fast-rpc-узел в mainnet
Начните здесь
- Снапшоты mainnet, конкретно путь для optimized
fast-rpc.
Следующая страница при необходимости
- Вернитесь к обычному сценарию mainnet RPC, если узел не подходит для optimized profile.
Остановитесь, когда
- Уже есть правильная команда
fast-rpcи нужные переменные окружения для целевой машины.
Переходите дальше, когда
- На самом деле требуется архивное хранение, а не просто быстрый запуск.
Восстановить обычный RPC-узел в стандартный каталог nearcore
Начните здесь
- Снапшоты mainnet или Снапшоты testnet в зависимости от сети и выберите обычный RPC-сценарий для нужного окружения.
Следующая страница при необходимости
- Настраивайте
DATA_PATH,THREADSили ограничения по пропускной способности только после того, как понятен стандартный сценарий.
Остановитесь, когда
- Уже можно запускать правильную команду восстановления RPC с ожидаемым путём данных.
Переходите дальше, когда
- Оператору на самом деле нужна архивная история или разнесение hot/cold-данных по разным хранилищам.
Правильно поднять архивные hot- и cold-данные mainnet
Начните здесь
- Снапшоты mainnet, раздел архивного режима.
Следующая страница при необходимости
- Сначала получите последнюю высоту архивного снапшота, затем запускайте отдельные загрузки hot- и cold-данных с правильными путями.
Остановитесь, когда
- План по hot-data и cold-data уже ясен, и порядок шагов выбран правильно.
Переходите дальше, когда
- Оператору нужны уже общие гайды nearcore по bootstrap, а не только FastNear snapshots.
Поднять архивные hot-данные в testnet
Начните здесь
- Снапшоты testnet, раздел архивного режима.
Следующая страница при необходимости
- Получите последнюю высоту архивного снапшота testnet перед шагом загрузки.
Остановитесь, когда
- Уже есть правильная команда для архивных hot-данных testnet и опорная высота блока снапшота.
Переходите дальше, когда
- Пользователь на самом деле не поднимает инфраструктуру и должен быть возвращён к документации API или RPC.
Частые ошибки
- Использовать документацию по снапшотам, когда задача на самом деле про чтение данных цепочки.
- Выбирать архивное восстановление, когда достаточно обычного или optimized RPC.
- Забывать про разделение hot/cold-данных для архивного режима.
- Переходить к командам до выбора сети и цели узла.