Бэкап и обновление панели без даунтайма

Сервис чаще умирает тихо: нода легла ночью, серт протух, база не бэкапилась — а ты узнаёшь из потока негатива. Ниже — как закрыть это заранее: бэкап базы, авто-выгрузка наружу, проверенное восстановление и мониторинг с алертами. Свои данные впиши в конструктор сверху.

Почему это не опционально

Нет бэкапа базы = угон, сбой или изъятие сервера = потеря всех клиентов. В базе Remnawave всё: пользователи, сроки, ноды, сквады. Восстановить это руками невозможно. Поэтому бэкап — не «когда-нибудь настрою», а первое, что делаешь после появления клиентов.

Второй тихий убийца — отсутствие мониторинга. Нода упала в три ночи, клиенты без интернета, а ты спишь и узнаёшь утром из вала жалоб. Разберём оба фронта.

Дамп базы одной командой

PostgreSQL в контейнере панели дампится одной командой. Заодно упаковываем конфиги:

cd /opt/remnawave
docker compose exec -T remnawave-db pg_dump -U postgres postgres > backup-$(date +%F).sql
tar czf conf-$(date +%F).tgz .env docker-compose.yml

Это делается до любых экспериментов с панелью — перед правкой инбаундов, перед обновлением, перед любым «а что если». Дамп снимается на живой панели без остановки — клиенты ничего не замечают.

Авто-бэкап по cron с выгрузкой наружу

Руками бэкапить забудешь через неделю. Ставим ежедневный дамп по cron и выгрузку вне сервера (бэкап на том же сервере, который изъяли, — бесполезен):

cat >/etc/cron.d/rw-backup <<'EOF'
0 4 * * * root cd /opt/remnawave && docker compose exec -T remnawave-db pg_dump -U postgres postgres | gzip > /root/backups/db-$(date +\%F).sql.gz
EOF

Дальше выгрузка в облако (настрой rclone заранее на другого провайдера):

# после cron-дампа — копируем наружу
rclone copy /root/backups remote:vpn-backups

Правила хранения:

• В другом месте — другой провайдер/облако, не тот же сервер.
• 7–14 копий — чтобы откатиться не на «вчера», а на любой из последних дней (если поломку заметили не сразу).

Восстановление, которое ты проверял

Бэкап, который не восстанавливается, — это не бэкап. Порядок восстановления: поднимаешь только базу, льёшь дамп, поднимаешь панель:

cd /opt/remnawave
docker compose up -d remnawave-db                 # поднять только БД
gunzip < /root/backups/db-2026-06-05.sql.gz | \
  docker compose exec -T remnawave-db psql -U postgres postgres   # залить дамп
docker compose up -d                              # поднять панель целиком

После восстановления проверь: пользователи, ноды, сквады на месте, ноды поднялись online. И самое важное — регулярно тестируй восстановление на запасном сервере. «Бэкап, который никто не восстанавливал» имеет свойство не восстанавливаться в момент, когда он нужен.

Обновление без даунтайма

Обновление панели — это перезагрузка образов. Правильный порядок: снял бэкап, вытянул новые образы, пересоздал стек:

cd /opt/remnawave
docker compose exec -T remnawave-db pg_dump -U postgres postgres > backup-before-update.sql
docker compose pull
docker compose up -d
docker compose logs -f

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

Важно про .env: если менял переменные окружения — обычный restart их не перечитает, нужен полный пересоздать (down + up). Обновление образов через pull + up контейнеры пересоздаёт, так что тут env подхватится.

Мониторинг, который будит раньше клиентов

Чтобы не узнавать о падении из жалоб — лёгкий монитор с алертами в Telegram. Uptime Kuma поднимается за пару минут:

docker run -d --restart=always -p 127.0.0.1:3001:3001 \
  -v uptime-kuma:/app/data --name uptime-kuma louislam/uptime-kuma:1

Выводишь за reverse-proxy, добавляешь мониторы:

• TCP на ноды (IP:443) — ловит упавшую ноду.
• HTTP на страницу подписки — если она не отвечает, клиенты остаются без конфигов.
• В Notifications → Telegram: бот-токен и chat_id → падение прилетает в бот.

Интервал 60 секунд и 2–3 ретрая, чтобы не дёргало на моргании канала.

Что ещё мониторить

Помимо доступности — тихие убийцы маржи и работоспособности:

• Баланс хостинга — ушёл в ноль, сервер выключат. Настрой напоминания у провайдера.
• Сертификаты — протухший серт кладёт всё. certbot ставит таймер сам, проверь: systemctl list-timers | grep certbot.
• Диск и RAM ноды — переполнение роняет Xray.
• Лишние выключенные VPS — тикают по счёту, главный убийца маржи. Удаляй.

Бэкап настроен, восстановление проверено, мониторинг будит раньше клиентов — сервис перестал умирать тихо. Дальше по разделу — админ панели (роли, доступы, сброс пароля) и управление лимитами клиентов. А почему мёртвые серверы съедают прибыль, разбирали в экономике из раздела «Основы».