Перед обновлением
- Проверьте источник обновлений и выбранную версию в панели. Стабильный и предварительный каналы могут содержать разные возможности.
- Убедитесь, что доступны хранилище резервных копий, место на диске и средства работы с PostgreSQL.
- Создайте свежую резервную копию, проверьте её целостность и сохраните доступ к серверу на время обновления.
- Просмотрите ограничения и миграции выбранного релиза, затем запустите обновление в панели.
Что проверяется
Современный официальный установщик проверяет не только SHA-256 архива, но и подпись файла контрольной суммы. Отсутствующая или неверная подпись останавливает установку. Отключение проверки через флаг или переменную окружения не является поддерживаемым обходом. Старый уже установленный upgrader может не иметь этой проверки. При переходе со старой установки используйте актуальный официальный установщик из доверенного источника; наличие подписанного архива само по себе не обновляет проверяющий скрипт.Порядок обновления
Для архива БД установщик сначала пробуетpsql, pg_dump и pg_restore
на хосте. Версия pg_dump должна быть не ниже основной версии PostgreSQL.
Для внешней БД нужны рабочие клиентские инструменты и доступ по настроенному
AXOTTLE_DB_URL. Соседний старый Docker-контейнер не выбирается только по имени:
резервный путь через Docker сверяет опубликованный loopback-порт и имя базы
с подключением панели.
Проверенный дамп обновления хранится отдельно от обычных резервных копий:
по умолчанию в /opt/axottle/data/backups/upgrades. Путь можно задать через
--backup-dir или AXOTTLE_UPGRADE_BACKUP_DIR. Сохраните дамп вместе с .meta;
точный путь выводится в отчёте обновления.
- До остановки и замены панели создаётся и проверяется архив БД. Если подготовка архива не удалась, установленная панель не заменяется.
- Сохраняется комплект предыдущего релиза: бинарник, миграции, файлы установки и связанные служебные файлы релиза.
- Служба останавливается, новый комплект устанавливается и запускается.
- Проверяется здоровье запущенной панели. При неудаче запускается согласованный откат.
journalctl -u axottle.service помогут отличить сбой новой версии от сбоя восстановления.
Проверка
Сверьте запрошенную и фактически запущенную версию, завершение операции и доступность панели. Проверьте БД, агентов и ключевые страницы. Доступность/ping подтверждает запуск процесса, но не заменяет проверку нужных рабочих сценариев.
Откат
При неудаче обновления текущий upgrader сначала останавливает неуспешный процесс, затем восстанавливает проверенный архив БД и полный сохранённый комплект прежнего релиза. После этого запускает прежнюю панель и проверяет здоровье и версию. Если откат БД или файлов не удался, панель оставляется остановленной, а отчёт указывает причину и путь к сохранённому архиву. Не запускайте произвольную версию поверх частично восстановленной БД: завершите восстановление данных и соответствующего комплекта файлов. Для более позднего ручного отката используйте пути и инструкции конкретной операции. Возврат только бинарника и каталога миграций недостаточен после того, как новая версия могла изменить БД. Если нужно вернуться к архиву до обновления, учитывайте потерю изменений, появившихся после его создания.Совместимость компонентов
Для возможностей старого агента может понадобиться подготовительный переход обновлятора. Для нового служебного API и оформления Statuspage проверяйте версию приложения страницы. Версия панели сама по себе не подтверждает версии остальных компонентов.Отдельные обновления
Агенты, Remnawave и развёрнутые страницы имеют собственные операции. Успешное обновление панели не означает, что все они обновились одновременно.Сверено с текущим кодом и историей веток Axottle 2026-09-06. Возможности зависят от установленной сборки; запись не объявляет выпуск релиза.
Дополнение по изменениям кода Axottle: 2026-09-08. Новые сценарии сверены с реализацией; установка на реальные ноды в рамках этой сверки не выполнялась.
Выбор PostgreSQL-инструментов и хранение дампа обновления сверены с кодом Axottle 2026-09-22.