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

Плановое обслуживание обычно сводится к обновлению образов, проверке миграций, логов и резервных копий. Подробная инструкция по автоматическим ZIP-бэкапам и восстановлению вынесена в бэкапы и восстановление.

Режим обслуживания пользователей

Если Remnawave недоступна или запланированы работы, откройте в админке Система → Настройки → Общие, включите Режим обслуживания и сохраните изменения. Настройка применяется без перезапуска. По умолчанию MAINTENANCE_MODE_ENABLED=False; её также можно задать в .env, но сохранённое переопределение из админки имеет приоритет.

Пользователи Telegram-бота получают сообщение о работах с просьбой попробовать позже. Mini App показывает экран обслуживания с кнопкой повторной попытки, а пользовательские API возвращают 503 с кодом maintenance_mode. Администраторы сохраняют доступ к приложению и настройкам. Уведомления платёжных провайдеров и проверка уже созданных платежей продолжают обрабатываться.

Это ручной переключатель: недоступность панели сама по себе не включает режим. После восстановления панели выключите его и сохраните настройки.

Обновление

docker compose pull
docker compose up -d
docker compose logs -f migrate backend worker

Место на диске и системный журнал

В новых Compose-профилях журналы контейнеров ротируются автоматически: три файла по 10 МБ на контейнер. Настройки и область действия описаны в разделе деплоя.

Периодически проверяйте свободное место и размер системного журнала:

df -h /
sudo journalctl --disk-usage

На небольшом сервере с systemd администратор может отдельно ограничить journald. Следующий пример действует на весь сервер, включая другие приложения; установщик Minishop не меняет эту системную настройку:

sudo mkdir -p /etc/systemd/journald.conf.d
sudo tee /etc/systemd/journald.conf.d/50-minishop-limits.conf >/dev/null <<'EOF'
[Journal]
SystemMaxUse=256M
RuntimeMaxUse=64M
SystemKeepFree=1G
EOF
sudo systemctl restart systemd-journald

Лимиты журналов не освобождают место, занятое базой данных, резервными копиями или Docker-образами. Не удаляйте volumes и не обнуляйте управляемые Docker файлы журналов вручную во время работы контейнеров.

Резервная копия PostgreSQL

docker compose exec -T postgres sh -c 'pg_dump -U "$POSTGRES_USER" -d "$POSTGRES_DB"' > backup.sql

Автоматические бэкапы

Worker может собирать ZIP-архивы с дампом PostgreSQL и snapshot compose-папки, отправлять их в Telegram и хранить последние архивы в data/backups. Настройка и восстановление описаны в отдельном разделе.

После изменения backup-настроек в .env перезапустите backend и worker:

docker compose up -d --build backend worker
docker compose logs -f backend worker

Восстановление из архива доступно в админке Система -> Бэкапы. Там же можно загрузить ZIP вручную, выбрать БД и/или compose-папка, а backend проверит архив перед запуском. Подробности: бэкапы и восстановление.

Проверки после работ

docker compose ps
docker compose logs -f backend worker frontend
/healthz на backend-домене
вход в Mini App и админку
тестовый платеж или тестовая активация