backup-master

Сервис бэкапов для VPS. Делает три вещи:

• принимает и хранит бэкапы, у него есть простая веб-морда для одного админа;
• агент на каждом сервере раз в сутки собирает бэкап по категориям, корректно дампит базы и записывает, какие версии софта стоят;
• восстанавливает бэкап на новом сервере: готовит систему (на основе vps_installer), ставит те же версии утилит, раскладывает конфиги и данные, запускает сервисы.

Всё это делает один бинарник backupctl. Как он устроен внутри — в docs/DESIGN.md.

Сборка

make build      # dist/backupctl-linux-amd64, dist/backupctl-linux-arm64
make test

Готовые бинарники собирает Gitea Actions. .gitea/workflows/ci.yml на каждый push и PR проверяет форматирование, запускает vet и тесты и собирает бинарники. release.yml на тег v* публикует релиз с backupctl-linux-{amd64,arm64}, checksums.txt и файлами из deploy/:

git tag v0.1.0 && git push origin v0.1.0

Без make:

CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build -trimpath -ldflags "-s -w" -o dist/backupctl-linux-amd64 ./cmd/backupctl

Установка сервера

sudo useradd -r -s /usr/sbin/nologin -d /var/lib/backup-master backup-master
sudo install -d -o backup-master -g backup-master -m 700 /var/lib/backup-master
sudo install -d /opt/backup-master/dist
sudo cp dist/backupctl-linux-* /opt/backup-master/dist/
sudo cp dist/backupctl-linux-amd64 /usr/local/bin/backupctl
sudo -u backup-master BM_DATA=/var/lib/backup-master backupctl admin-passwd admin
sudo cp deploy/backup-master.service /etc/systemd/system/   # поправьте BM_PUBLIC_URL
sudo systemctl enable --now backup-master

Сервер слушает 127.0.0.1:8080, TLS даёт Caddy (пример — deploy/Caddyfile.example). Агентам сервер раздаёт бинарники из BM_DIST. Для своей архитектуры сервер раздаёт сам себя.

В «Настройках» укажите топик ntfy. Уведомления приходят:

• об ошибках бэкапа;
• когда от клиента нет бэкапа дольше заданного срока (по умолчанию 26 ч);
• если включено — и об успешных бэкапах.

Добавление клиента

1. В веб-морде нажмите «Добавить клиента» и укажите домен сервера.
2. Выполните на сервере выданную команду:

   curl -fsSL https://backup.example.com/agent.sh | sudo bash -s -- --token bm_... --now
   

   Команда ставит backupctl, конфиг /etc/backup-agent/agent.yaml и таймер backup-agent.timer (03:00 ± 30 мин), показывает план (backupctl plan) и запускает первый бэкап.
3. В карточке клиента видно, что попадает в бэкап, версии софта и предупреждения. Например, cron запускает скрипт, который не попадает ни в одну категорию.

Полезные команды на клиенте:

sudo backupctl plan                  # что будет в бэкапе (дампы реально выполняются во временный каталог)
sudo systemctl start backup-agent    # бэкап сейчас
journalctl -u backup-agent -f
sudo backupctl backup --heavy        # с heavy-частями вне расписания

Восстановление

В карточке клиента нажмите «Команда восстановления». Токен живёт 24 часа и даёт доступ только на чтение бэкапов этого клиента. Если нужен конкретный бэкап, откройте его и нажмите «Восстановить из этого бэкапа». На чистой Ubuntu 24.04:

curl -fsSL https://backup.example.com/restore.sh | sudo bash -s -- --token bm_...

Что происходит:

1. Показывается сводка бэкапа и запрашивается подтверждение.
2. Базовая подготовка системы (internal/restore/provision.sh): пользователь с sudo, hostname, fail2ban, UFW, blocklist, SSH hardening. Docker, Caddy и Telegraf ставятся тех же версий apt-пакетов, если такие версии ещё есть в репозитории. Спрашиваются только логин и пароль пользователя.
3. Распаковка: файлы ложатся на свои места, docker-тома — прямо в тома.
4. Категории восстанавливаются по порядку:
   • 3x-ui, Nebula и sing-box ставятся той версии, что была на старом сервере. Если скачать не получилось, используется копия бинарника из бэкапа;
   • база x-ui кладётся на место;
   • compose-проекты: образы закрепляются по digest (compose.restore.yml), базы поднимаются, в них заливаются дампы, затем запускается весь проект;
   • systemd-сервисы включаются и запускаются так, как было на старом сервере.
5. В конце выводятся итог и список того, что осталось сделать: DNS, lighthouse, перезагрузка.

Флаги:

• --backup ID — конкретный бэкап;
• --skip-heavy — без MinIO Stoat;
• --skip-provision — повторный прогон без базовой подготовки;
• --user NAME, --yes, --keep-staging.

Что бэкапится

Встроенный каталог — internal/catalog/default.yaml:

Категория	Что входит
system	правила UFW, все crontab (/var/spool/cron/crontabs), ban-blacklist, /etc/sysctl.d
xui	/etc/x-ui (снимок базы через VACUUM INTO, без логина в панель), /root/cert, версия 3x-ui
nebula	/etc/nebula, юнит, версия
caddy	/etc/caddy, /var/www, сертификаты
telegraf	/etc/telegraf, sudoers
sing-box-warp	/opt/sing-box-warp, /etc/sing-box-warp, юнит, sysctl, версия sing-box-extended
scripts	/var/scripts, update-geosite.sh
pnvpanel	/opt/PnvPanel целиком, кроме pgdata; pg_dump; том ticket_uploads
stoat	/opt/stoat, кроме data/db и data/rabbit; mongodump; data/minio идёт отдельной heavy-частью раз в неделю
stoat-mbot	/opt/stoat-mbot целиком, восстанавливается после stoat
psiphon	отключён

Compose-проекты, которых нет в каталоге, находятся автоматически (docker compose ls). Они бэкапятся с настройками по умолчанию и помечаются в морде как «авто». Базы распознаются по образу (postgres, mongo, mysql, mariadb) и дампятся без остановки.

Каталог для конкретного клиента можно переопределить в его карточке (YAML):

categories:
  - {name: scripts, disabled: true}     # отключить встроенную
  - name: hostdb                        # своя категория с дампом
    type: files
    paths: [/etc/mysql]
    dumps:
      - name: full_dump.sql
        cmd: mysqldump --all-databases --single-transaction
        restore_cmd: mysql < "$DUMP_FILE"

Хранение

Бэкапы лежат в /var/lib/backup-master/backups/<домен>/<дата>-<id>/: main.tar.zst, heavy-части и manifest.json. Архив — обычный tar+zstd, его можно разобрать и без backupctl:

zstd -dc main.tar.zst | tar -tv

Ротация:

• обычные бэкапы — по схеме GFS: последний всегда + N дневных, недельных и месячных (по умолчанию 7/4/6);
• heavy-части — только последние heavy_keep (по умолчанию 1).