Files
backup-master/README.md
T
mrleo1nidandClaude Opus 5.5 1d44d067e9 backup-master: сервер бэкапов, агент и восстановление VPS
Один бинарник backupctl:
- server: API для агентов и restore, веб-морда (один админ), SQLite,
  ретеншн GFS, heavy-части, уведомления ntfy, раздача agent.sh/restore.sh;
- backup/plan: сбор по каталогу категорий (files/systemd/xui/compose),
  горячие дампы Postgres/Mongo/MySQL, снимок x-ui.db, docker-тома,
  digest образов, проверка crontab, потоковая отправка tar.zst;
- restore: провижининг на основе vps_installer с теми же версиями пакетов,
  recipes 3x-ui/nebula/sing-box нужных версий, восстановление compose
  с заливкой дампов и закреплением образов по digest.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-06 21:52:40 +03:00

134 lines
8.6 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# backup-master
Сервис бэкапов для VPS. Делает три вещи:
- принимает и хранит бэкапы, у него есть простая веб-морда для одного админа;
- агент на каждом сервере раз в сутки собирает бэкап по категориям, корректно дампит базы и записывает, какие версии софта стоят;
- восстанавливает бэкап **на новом сервере**: готовит систему (на основе [vps_installer](https://gitea.hsrv.site/mrleo1nid/vps_installer)), ставит **те же версии** утилит, раскладывает конфиги и данные, запускает сервисы.
Всё это делает один бинарник `backupctl`. Как он устроен внутри — в [docs/DESIGN.md](docs/DESIGN.md).
## Сборка
```bash
make build # dist/backupctl-linux-amd64, dist/backupctl-linux-arm64
make test
```
Без make:
```bash
CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build -trimpath -ldflags "-s -w" -o dist/backupctl-linux-amd64 ./cmd/backupctl
```
## Установка сервера
```bash
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. Выполните на сервере выданную команду:
```bash
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 запускает скрипт, который не попадает ни в одну категорию.
Полезные команды на клиенте:
```bash
sudo backupctl plan # что будет в бэкапе (дампы реально выполняются во временный каталог)
sudo systemctl start backup-agent # бэкап сейчас
journalctl -u backup-agent -f
sudo backupctl backup --heavy # с heavy-частями вне расписания
```
## Восстановление
В карточке клиента нажмите «Команда восстановления». Токен живёт 24 часа и даёт доступ только на чтение бэкапов этого клиента. Если нужен конкретный бэкап, откройте его и нажмите «Восстановить из этого бэкапа». На чистой Ubuntu 24.04:
```bash
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](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):
```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:
```bash
zstd -dc main.tar.zst | tar -tv
```
Ротация:
- обычные бэкапы — по схеме GFS: последний всегда + N дневных, недельных и месячных (по умолчанию 7/4/6);
- heavy-части — только последние `heavy_keep` (по умолчанию 1).