265 lines
23 KiB
Markdown
265 lines
23 KiB
Markdown
# Фаза 1: Стратегия бэкапов Proxmox
|
||
|
||
Цель: при смерти SSD с системой или потере `/etc/pve` — развернуть Proxmox, восстановить контейнеры/ВМ, поднять сервисы без многочасового восстановления и угадывания паролей.
|
||
|
||
**Приоритет №1.** ИБП уже есть; защищаемся от смерти диска.
|
||
|
||
---
|
||
|
||
## Что бэкапить
|
||
|
||
| Объект | Зачем |
|
||
|--------|--------|
|
||
| **LXC и VM целиком** (vzdump) | Восстановление контейнера/ВМ из одного архива: ОС, конфиги, данные на корневом томе. Не только данные внутри — сам образ для restore. |
|
||
| **/etc/pve** | Конфиги кластера, VM/LXC (ID, сеть, диски, задачи), пользователи Proxmox, права. Без этого после переустановки Proxmox не восстановить привязку дисков и настройки. |
|
||
|
||
---
|
||
|
||
## Пошаговый план
|
||
|
||
### Шаг 1. Определить хранилище для бэкапов
|
||
|
||
**Выбранная схема:**
|
||
|
||
| Место | Описание | Что туда |
|
||
|-------|----------|----------|
|
||
| **Локально: /dev/sdb1 (1 ТБ под бэкапы)** | Отдельный SSD 2 ТБ; под копии выделен 1 ТБ, смонтирован в `/mnt/backup`. Второй ТБ — в запас. | Proxmox vzdump (через UI), затем те же данные (dump, etc-pve, фотки, VPS) в Yandex через restic. Фотки: оригиналы + метаданные + БД Immich; остальное пересчитать можно. VPS: Amnezia — конфиг; Миран — БД бота + контент (контент можно в S3 Мирана; копию на sdb1 — опционально). Конфигурацию серверов не бэкапим — есть Ansible. |
|
||
| **Офсайт: Yandex Object Storage (S3)** | Арендованный бакет, S3-совместимый API. [Yandex Object Storage](https://yandex.cloud/ru/docs/storage/s3/). | **Restic** с хоста (cron на ноде Proxmox): выгрузка содержимого `/mnt/backup` (или выбранных каталогов). Retention: 7 daily, 4 weekly, 6 monthly. |
|
||
|
||
- **Вариант A (альтернатива):** Отдельный диск/раздел на том же хосте — у тебя это sdb1.
|
||
- **Вариант B:** Сетевое хранилище (NFS/SMB) — не используется в текущей схеме.
|
||
- **Вариант C:** Внешний USB — опционально для 3-2-1 (см. ниже).
|
||
|
||
**3-2-1:** Три копии: (1) прод — система и данные на основном диске; (2) локальный бэкап — sdb1; (3) офсайт — Yandex. Два типа носителей: локальный SSD и облачное object storage. Один офсайт — да. **Стратегия удовлетворяет 3-2-1.** Опционально: четвёртая копия на внешнем USB/другом ПК для параноидального сценария (пожар/кража) — по желанию.
|
||
|
||
**Принято:** Точка монтирования — `/mnt/backup`. На диске 2 ТБ выделено 1 ТБ под бэкапы; второй ТБ пока в запас, назначение не определено.
|
||
|
||
**Действие:** Разметить 1 ТБ на /dev/sdb1, создать ФС (ext4/xfs), смонтировать в `/mnt/backup`. Структуру каталогов — см. раздел «Структура локального хранилища» ниже.
|
||
|
||
---
|
||
|
||
### Шаг 2. Добавить Backup Storage в Proxmox
|
||
|
||
1. В веб-интерфейсе: **Datacenter → Storage → Add**.
|
||
2. Тип: **Directory** (если папка на локальном диске) или **NFS/CIFS** (если сетевое).
|
||
3. Указать:
|
||
- **ID** (например `backup-local` или `backup-nfs`),
|
||
- **Directory** — путь, например `/mnt/backup/dump`,
|
||
- Включить опции **Content: VZDump backup file** (и при необходимости **ISO**, **Container template** — по желанию).
|
||
4. Сохранить. Убедиться, что storage виден и доступен для записи.
|
||
|
||
Если используешь NFS: сначала смонтировать NFS в `/mnt/backup` на хосте (fstab или systemd mount), затем добавить Storage с Directory `/mnt/backup/dump`.
|
||
|
||
**Для выбранной схемы:** Directory = `/mnt/backup/proxmox/dump` (см. структуру ниже).
|
||
|
||
---
|
||
|
||
### Структура локального хранилища (1 ТБ на sdb1)
|
||
|
||
«Аналог S3» на одном диске — это просто понятная иерархия каталогов. **MinIO не используем:** лишний сервис; достаточно директорий и restic с бэкендом `local` (если понадобится локальный restic) и `s3` для Yandex. Proxmox пишет в **Directory** — ему достаточно пути.
|
||
|
||
Пример структуры под `/mnt/backup`:
|
||
|
||
```
|
||
/mnt/backup/
|
||
├── proxmox/
|
||
│ ├── dump/ ← Proxmox Backup Job (VZDump) — сюда добавляем Storage в PVE
|
||
│ └── etc-pve/ ← архивы tar.gz из cron (backup-etc-pve.sh)
|
||
├── restic/
|
||
│ ├── local/ ← репозитории restic для локальных снапшотов (опционально)
|
||
│ └── ... ← или restic только в Yandex, локально только сырые копии
|
||
├── photos/ ← Immich: оригиналы фото + метаданные + БД (остальное пересчитать)
|
||
├── vps/ ← Amnezia: конфиг. Миран: БД бота (+ контент при необходимости; основной контент можно в S3 Мирана)
|
||
└── other/ ← прочие важные данные (конфиги, скрипты, что ещё решите)
|
||
```
|
||
|
||
Квоты: при необходимости ограничить размер по каталогам (например `proxmox/dump` — не более 500 ГБ) через отдельные подразделы или скрипты очистки (retention).
|
||
|
||
---
|
||
|
||
### Шифрование диска бэкапов (LUKS)
|
||
|
||
**LUKS** (Linux Unified Key Setup) — стандартное шифрование раздела в Linux. Если диск с бэкапами украдут или вынесут, без пароля/ключа данные не прочитать. Минусы: нужно вводить пароль при загрузке (или хранить ключ на другом носителе), небольшая нагрузка на CPU.
|
||
|
||
**Принято:** LUKS пока не используем. Раздел sdb1 — без шифрования. При необходимости можно добавить позже (потребуется перенос данных).
|
||
|
||
---
|
||
|
||
### Restic и Yandex Object Storage
|
||
|
||
- **Restic** поддерживает бэкенд **S3**. Yandex Object Storage совместим с S3 API — используешь endpoint бакета и ключи (Access Key / Secret).
|
||
- **Retention в Yandex:** 7 daily, 4 weekly, 6 monthly — `restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6` и затем `prune`.
|
||
- **Что гнать в Yandex через restic:** Proxmox dump (каталог `proxmox/dump`), `/etc/pve` (архивы из `proxmox/etc-pve`), фотки (оригиналы + метаданные + БД Immich), бэкапы с VPS — см. «Принятые решения: что куда» ниже.
|
||
|
||
**Локально отдельной политики retention для restic не нужно:** на sdb1 retention задаётся в самом Proxmox Backup Job (например «keep last 7») и в скрипте бэкапа `/etc/pve` (удалять архивы старше N дней). Restic используется только для отправки в Yandex с политикой 7/4/6. Локальных restic-репозиториев можно не заводить — только каталоги и выгрузка их содержимого в облако.
|
||
|
||
Документация Yandex: [Object Storage S3](https://yandex.cloud/ru/docs/storage/s3/). Нужны: bucket name, region, endpoint, Static Key (Access Key ID + Secret Access Key). **Бакет создан; ключи и endpoint зафиксировать при настройке restic.**
|
||
|
||
---
|
||
|
||
### Хранилище паролей (варианты)
|
||
|
||
Чтобы не терять пароли при восстановлении и держать креды в одном месте:
|
||
|
||
| Вариант | Плюсы | Минусы |
|
||
|--------|--------|--------|
|
||
| **Vaultwarden** (self-hosted, Bitwarden-совместимый) | Один сервер в твоём контуре (например CT 100 или отдельный LXC), клиенты Bitwarden на ПК/телефоне, бесплатно | Нужен HTTPS (NPM уже есть), бэкап базы Vaultwarden — в общий план бэкапов |
|
||
| **Bitwarden Cloud** (официальный облачный) | Не нужно поднимать сервер, синхронизация везде | Платно (или ограничения бесплатного), данные у третьей стороны |
|
||
| **KeePass / KeePassXC** (файл .kdbx) | Локально, один зашифрованный файл; можно положить в бэкап (restic/local) и открывать с любого ПК | Нет удобной синхронизации на телефон из коробки (нужен общий файл через Nextcloud/флешку) |
|
||
| **1Password / др. облачные менеджеры** | Удобно, кросс-девайс | Платно, данные у провайдера |
|
||
|
||
**Принято:** Развернуть **Vaultwarden** на контейнере **107 или 103** (не на 100). Домен через NPM, бэкап данных Vaultwarden включить в то, что уходит в restic → Yandex.
|
||
|
||
---
|
||
|
||
### Где запускать бэкапы (централизация)
|
||
|
||
**С хоста Proxmox (cron на ноде):**
|
||
|
||
- **Proxmox Backup Job** уже выполняется на хосте и пишет vzdump всех выбранных LXC/VM в `/mnt/backup/proxmox/dump` — это и есть «бэкапы всех контейнеров и ВМ», централизованно.
|
||
- **Restic** (backup/forget/prune) тоже запускаем с хоста по cron: бэкапит каталоги на хосте (например весь `/mnt/backup` или выбранные подкаталоги) в Yandex S3. Данные для бэкапа — локальные пути (dump, etc-pve, а фотки и данные с VPS нужно либо копировать на хост в `/mnt/backup` скриптами, либо монтировать и тогда restic будет их читать с хоста). Контейнеры и ВМ целиком не бэкапим через restic — ими занимается только Proxmox Backup Job.
|
||
|
||
---
|
||
|
||
### Шаг 3. Настроить расписание бэкапа LXC и VM
|
||
|
||
1. **Datacenter → Backup** (или **Backup** в меню узла).
|
||
2. **Add** — создаётся задача (Job).
|
||
3. Параметры:
|
||
- **Storage** — выбранное хранилище (шаг 2).
|
||
- **Schedule** — например `0 2 * * *` (каждую ночь в 02:00). Подстроить под окно, когда нагрузка минимальна.
|
||
- **Selection mode:** включить нужные узлы (или **All**), затем отметить **галочками** конкретные **LXC (100–108) и VM (200)**. Либо выбрать "Backup all" для всех VMs/containers.
|
||
- **Mode:**
|
||
- **Snapshot** — контейнер/ВМ не останавливается, создаётся снимок (рекомендуется для минимизации даунтайма).
|
||
- **Suspend** — ВМ приостанавливается на время бэкапа (более консистентно для БД, но даунтайм).
|
||
Для LXC обычно достаточно **Snapshot**; для VM 200 (Immich с БД) можно оставить Snapshot, при необходимости позже добавить отдельный консистентный бэкап БД изнутри гостя.
|
||
- **Compression:** ZSTD (хороший компромисс скорость/размер).
|
||
- **Retention:** например «Keep last 7» или «Keep last 4 weekly» — чтобы не забивать диск.
|
||
|
||
4. Сохранить job. Проверить по кнопке **Backup now**, что задача запускается и файлы появляются в Storage.
|
||
|
||
Важно: бэкап должен включать **и LXC, и VM 200**. Не только данные внутри них (те уже описаны в документации контейнеров), а именно полный dump для restore.
|
||
|
||
---
|
||
|
||
### Шаг 4. Бэкап /etc/pve
|
||
|
||
Конфиги кластера и виртуалок лежат в `/etc/pve`. Их нужно копировать регулярно и хранить в безопасном месте (желательно не только на том же диске, что и система).
|
||
|
||
**Вариант A: cron на хосте Proxmox**
|
||
|
||
1. Создать скрипт, например `/root/scripts/backup-etc-pve.sh`:
|
||
|
||
```bash
|
||
#!/bin/bash
|
||
BACKUP_ROOT="/mnt/backup/proxmox/etc-pve" # по структуре выше
|
||
DATE=$(date +%Y%m%d-%H%M)
|
||
mkdir -p "$BACKUP_ROOT"
|
||
tar -czf "$BACKUP_ROOT/etc-pve-$DATE.tar.gz" -C / etc/pve
|
||
# опционально: удалять бэкапы старше N дней
|
||
# find "$BACKUP_ROOT" -name 'etc-pve-*.tar.gz' -mtime +30 -delete
|
||
```
|
||
|
||
2. Сделать исполняемым: `chmod +x /root/scripts/backup-etc-pve.sh`.
|
||
3. Добавить в cron: `crontab -e`, например раз в день после основного backup job:
|
||
`0 3 * * * /root/scripts/backup-etc-pve.sh`
|
||
|
||
**Вариант B:** Тот же скрипт можно вызывать из задачи в Proxmox (Script/Command в задаче типа Hook script), но проще и надёжнее — отдельный cron на хосте.
|
||
|
||
Бэкапы `/etc/pve` хранить **локально** (`/mnt/backup/proxmox/etc-pve`) и **в Yandex** — включить этот каталог в источники restic (мало весит, критично при потере хоста). Файлы с ограниченными правами (chmod 600); `/etc/pve` содержит секреты — не выкладывать в открытый доступ.
|
||
|
||
---
|
||
|
||
### Шаг 5. Хранить секреты отдельно (пароли, ключи)
|
||
|
||
Чтобы «не вспоминать пароли 3 часа» после восстановления:
|
||
|
||
Завести **секретное хранилище** — Vaultwarden на CT 107 или 103 (см. выше). Туда: root Proxmox, пользователи PVE, пароли БД и сервисов (Nextcloud, Gitea, Paperless, Immich, NPM, Galene и т.д.), API-ключи (Beget, certbot, Wallos и др.). Полный список кредов по контейнерам — в статьях container-100 … container-200; свести в один список в Vaultwarden и обновлять при смене паролей.
|
||
|
||
Это не «шаг бэкапа», но обязательная часть восстановления: без паролей восстановленные контейнеры не войдут в сервисы.
|
||
|
||
---
|
||
|
||
### Шаг 6. Тестовое восстановление одного контейнера
|
||
|
||
Без проверки восстановления нельзя считать стратегию рабочей.
|
||
|
||
1. Выбрать **некритичный** контейнер (например 105 — RAG, или 107 — Invidious), для которого краткий даунтайм допустим.
|
||
2. Убедиться, что есть свежий backup этого контейнера в Storage (после шага 3).
|
||
3. **Восстановление:**
|
||
- В Proxmox UI: **Datacenter → Backup** → выбрать storage → найти backup нужного CT → **Restore**. Указать **new VMID** (например 999 для теста) и **Storage** для дисков.
|
||
- Или с CLI:
|
||
`qmrestore` для VM, для LXC — через GUI или `pct restore` (см. справку `pct restore`).
|
||
Для LXC типично: Backup → Restore → задать новый ID (например 999), node, storage.
|
||
4. Запустить восстановленный контейнер (ID 999), проверить:
|
||
- заходит по SSH/консоль;
|
||
- сервисы внутри запускаются (docker/ systemd);
|
||
- с хоста пинг и при необходимости один сервис по порту.
|
||
5. После проверки удалить тестовый контейнер (999), освободить место.
|
||
|
||
Если что-то пошло не так (не находится диск, ошибка прав, сеть) — зафиксировать и поправить стратегию (пути storage, режим backup, права).
|
||
|
||
---
|
||
|
||
### Шаг 7. Документировать процедуру восстановления «с нуля»
|
||
|
||
Кратко зафиксировать в отдельном разделе (здесь или в architecture):
|
||
|
||
1. Установка Proxmox на новое железо (или новый диск).
|
||
2. Восстановление конфигов: распаковать последний `etc-pve-*.tar.gz` в `/etc/pve` (с учётом того, что нужно корректно подставить ноды и storage; при одномузловой установке обычно достаточно скопировать файлы).
|
||
3. Подключение storage с backup (или копирование последних vzdump на новый storage).
|
||
4. Восстановление контейнеров и ВМ из backup по одному (Restore с указанием VMID и storage).
|
||
5. Запуск контейнеров/ВМ, проверка сети и сервисов.
|
||
6. Использование сохранённых паролей/ключей для входа и проверки сервисов.
|
||
|
||
После первого успешного тестового восстановления (шаг 6) эту процедуру можно уточнить и дописать по факту.
|
||
|
||
---
|
||
|
||
## Чек-лист фазы 1
|
||
|
||
- [ ] Разметка: 1 ТБ на sdb1, ФС, монтирование в `/mnt/backup` (без LUKS).
|
||
- [ ] В Proxmox добавлен Storage для VZDump → `/mnt/backup/proxmox/dump`.
|
||
- [ ] Настроена регулярная задача Backup: все LXC (100–108) и VM (200), расписание (например ночь), retention.
|
||
- [ ] Проверен ручной запуск Backup now — файлы появляются в storage.
|
||
- [ ] Настроен бэкап `/etc/pve` (скрипт + cron) → `/mnt/backup/proxmox/etc-pve`.
|
||
- [ ] Restic: cron на хосте, выгрузка нужных каталогов из `/mnt/backup` в Yandex S3, retention 7/4/6.
|
||
- [ ] Yandex: ключи и endpoint зафиксированы, restic успешно пишет в бакет.
|
||
- [x] Vaultwarden развёрнут (CT 103).
|
||
- [ ] Секреты перенесены в Vaultwarden.
|
||
- [ ] Бэкап данных Vaultwarden (`/opt/docker/vaultwarden/data`) включён в restic (Yandex S3).
|
||
- [ ] Выполнено тестовое восстановление одного контейнера (другой VMID), проверена работоспособность.
|
||
- [ ] В документации зафиксирована процедура полного восстановления Proxmox «с нуля».
|
||
|
||
---
|
||
|
||
## Ссылки
|
||
|
||
- [Архитектура и подключение](../architecture/architecture.md) — хосты, IP, домены.
|
||
- [Схема сети и зависимости](../network/network-topology.md) — SPOF, зависимость от Proxmox и бэкапов.
|
||
- Документация контейнеров (100–108, 200) — бэкапы *данных внутри* сервисов (БД, тома); фаза 1 дополняет это бэкапом на уровне PVE.
|
||
|
||
---
|
||
|
||
## Принятые решения (сводка)
|
||
|
||
| Вопрос | Решение |
|
||
|--------|---------|
|
||
| Точка монтирования, второй ТБ | `/mnt/backup`; второй ТБ на sdb1 — в запас, назначение позже. |
|
||
| Шифрование (LUKS) | Пока не делаем; раздел без шифрования. |
|
||
| Proxmox vzdump | Локально в `proxmox/dump` + дублировать в Yandex через restic. |
|
||
| Фотки | Оригиналы + метаданные + БД Immich; остальное пересчитать. |
|
||
| VPS | Amnezia — конфиг. Миран — БД бота + контент (контент можно в S3 Мирана; копия на sdb1 — по желанию). Конфиг серверов не бэкапим — Ansible. |
|
||
| Где запускать бэкапы | Cron на хосте Proxmox: Backup Job (vzdump) + restic в Yandex. |
|
||
| Retention локально | Только в Proxmox Job и в скрипте etc-pve; отдельного restic-репозитория локально не делаем. |
|
||
| /etc/pve | Локально и в Yandex (через restic). |
|
||
| Пароли | Vaultwarden на CT 103. |
|
||
| Yandex | Бакет создан; ключи и endpoint зафиксировать при настройке restic. |
|
||
| MinIO | Не используем; директории + restic (s3 для Yandex). |
|
||
|
||
---
|
||
|
||
## Осталось сделать
|
||
|
||
- **Yandex:** подготовить Static Key (Access Key + Secret), записать endpoint и имя бакета — понадобятся для настройки restic.
|