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>
This commit is contained in:
mrleo1nidandClaude Opus 5.5 committed
commit
1d44d067e9
53 files changed
+7278
No files matched your search
@@ -0,0 +1,133 @@
|
||||
# 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).
|
||||
Reference in new issue
Block a user