Update backup and logging documentation for Proxmox and containers. Adjust retention policies for Yandex Object Storage and enhance log rotation settings across various containers. Include detailed instructions for VPS backup processes and configurations for AmneziaVPN.

docs/backup/backup-howto.md

@@ -0,0 +1,231 @@
+# Бэкапы: как устроены и как восстанавливать
+
+Краткая справка: что бэкапится, куда, когда и как восстановить.
+
+---
+
+## Где хранятся бэкапы
+
+Все локальные бэкапы лежат на отдельном диске хоста Proxmox: **/dev/sdb1**, смонтирован в **/mnt/backup**.
+
+```
+/mnt/backup/
+├── proxmox/
+│   ├── dump/           ← vzdump (LXC и VM целиком)
+│   └── etc-pve/        ← конфиги хоста (etc/pve, interfaces, hosts, resolv.conf)
+├── databases/          ← логические дампы БД (pg_dump)
+│   ├── ct101-nextcloud/
+│   ├── ct103-gitea/
+│   ├── ct104-paperless/
+│   └── vm200-immich/
+├── photos/
+│   └── library/        ← копия библиотеки Immich (оригиналы фото) с VM 200
+├── other/
+│   ├── vaultwarden/    ← архив данных Vaultwarden (пароли); для restic → Yandex
+│   └── ct105-vectors/  ← векторы RAG (vectors.npz) из CT 105
+├── restic/             ← (опционально)
+└── vps/
+    └── miran/          ← VPS Миран: БД бота, voice_users, копия S3 (telegram-helper-bot)
+```
+
+---
+
+## Что, откуда, куда, когда
+
+| Что | Откуда | Куда (локально) | Когда | Хранение |
+|-----|--------|------------------|------|----------|
+| **LXC и VM** | Все выбранные контейнеры (100–109) и VM 200 | `/mnt/backup/proxmox/dump/` | **02:00** ежедневно (задание в Proxmox UI) | По настройкам задания (например: 7 daily, 4 weekly, 6 monthly) |
+| **Конфиги хоста** | `/etc/pve`, `/etc/network/interfaces`, `/etc/hosts`, `/etc/resolv.conf` | `/mnt/backup/proxmox/etc-pve/` | **02:15** ежедневно (cron: `backup-etc-pve.sh`) | 30 дней |
+| **БД Nextcloud (PostgreSQL)** | CT 101, контейнер `nextcloud-db-1` в `/opt/nextcloud` | `/mnt/backup/databases/ct101-nextcloud/` | **01:15** ежедневно (cron: `backup-ct101-pgdump.sh`) | 14 дней |
+| **БД Gitea (PostgreSQL)** | CT 103, контейнер `gitea-db-1` в `/opt/gitea` | `/mnt/backup/databases/ct103-gitea/` | **03:00** ежедневно (cron: `backup-ct103-gitea-pgdump.sh`) | 14 дней |
+| **БД Paperless (PostgreSQL)** | CT 104, контейнер `paperless-db-1` в `/opt/paperless` | `/mnt/backup/databases/ct104-paperless/` | **02:30** ежедневно (cron: `backup-ct104-pgdump.sh`) | 14 дней |
+| **Данные Vaultwarden (пароли)** | CT 103, `/opt/docker/vaultwarden/data` | `/mnt/backup/other/vaultwarden/` | **02:45** ежедневно (cron: `backup-vaultwarden-data.sh`); каталог в restic → Yandex | 14 дней |
+| **БД Immich (PostgreSQL)** | VM 200, контейнер `database` в `/opt/immich` | `/mnt/backup/databases/vm200-immich/` | **03:15** ежедневно (cron: `backup-vm200-pgdump.sh`) | 14 дней |
+| **Векторы RAG (CT 105)** | CT 105, `/home/rag-service/data/vectors/` (vectors.npz) | `/mnt/backup/other/ct105-vectors/` | **03:30** ежедневно (cron: `backup-ct105-vectors.sh`) | 14 дней |
+| **Оригиналы фото Immich** | VM 200, `/mnt/data/library/` | `/mnt/backup/photos/library/` | **01:30** ежедневно (cron: `backup-immich-photos.sh`, rsync) | Все копии (без автоудаления) |
+| **VPS Миран (telegram-helper-bot)** | VPS 185.147.80.190: БД `tg-bot-database.db`, каталог `voice_users`, бакет S3 (Miran) | `/mnt/backup/vps/miran/` (db/, voice_users/, s3/) | **01:00** ежедневно (cron: `backup-vps-miran.sh`) | БД: 14 дней; voice_users и S3 — перезапись |
+| **Выгрузка в Yandex (restic)** | `/mnt/backup` целиком | Yandex Object Storage | **04:00** ежедневно (cron: `backup-restic-yandex.sh`) | 3 daily, 2 weekly, 2 monthly |
+
+**Окно бэкапов:** внутренние копии (синк внутри сервера) — **01:00–03:30**; выгрузка в облако — **04:00**. **05:00** зарезервировано под плановую перезагрузку сервера. Задание vzdump — из веб-интерфейса Proxmox (Центр обработки данных → Резервная копия).
+
+---
+
+## Восстановление
+
+### 1. Восстановление контейнера (LXC) или виртуальной машины (VM) из vzdump
+
+**Когда нужно:** потеря или поломка одной/нескольких гостевых систем.
+
+1. В Proxmox: **Центр обработки данных → Резервная копия** (или узел → Резервная копия).
+2. Выбрать хранилище **backup** (или то, куда пишет задание).
+3. Найти нужный бэкап по VMID и дате.
+4. **Восстановить** → указать новый VMID (если восстанавливаем как копию) или тот же (если заменяем сломанный), узел и storage для дисков.
+5. Запустить ВМ/контейнер и проверить доступность.
+
+**С CLI (на хосте):**
+
+- LXC: `pct restore <vmid> /path/to/backup.vma.zst --storage local-lvm` (и т.п., см. `pct restore --help`).
+- VM: `qm restore <vmid> /path/to/backup.vma.zst` (и т.п., см. `qm restore --help`).
+
+Путь к файлу бэкапа на хосте: `/mnt/backup/proxmox/dump/` (имя файла вида `vzdump-lxc-100-...` или `vzdump-qemu-200-...`).
+
+---
+
+### 2. Восстановление конфигов хоста (/etc/pve и сеть)
+
+**Когда нужно:** переустановка Proxmox или потеря конфигов узла (при этом диск с бэкапами доступен).
+
+1. Скопировать нужный архив с хоста, например:  
+   `etc-pve-YYYYMMDD-HHMM.tar.gz` и/или `etc-host-configs-YYYYMMDD-HHMM.tar.gz` из `/mnt/backup/proxmox/etc-pve/`.
+2. **Восстановление /etc/pve** (на переустановленном хосте, от root):
+   ```bash
+   tar -xzf etc-pve-YYYYMMDD-HHMM.tar.gz -C /
+   ```
+   При одномузловой установке обычно достаточно распаковать в `/`. При кластере — аккуратно с нодами и storage.
+3. **Восстановление конфигов сети/хоста** (interfaces, hosts, resolv.conf):
+   ```bash
+   tar -xzf etc-host-configs-YYYYMMDD-HHMM.tar.gz -C /
+   ```
+   При необходимости поправить под текущее железо (интерфейсы, IP) и перезапустить сеть.
+
+После восстановления конфигов — заново добавить storage для бэкапов (если переустанавливали с нуля) и восстанавливать гостей из vzdump по шагу 1.
+
+---
+
+### 3. Восстановление БД Immich (PostgreSQL) на VM 200
+
+**Когда нужно:** повреждение или потеря базы Immich при рабочей ВМ (образ VM можно не трогать, восстанавливаем только БД).
+
+1. Скопировать нужный дамп на VM 200, например:  
+   `immich-db-YYYYMMDD-HHMM.sql.gz` из `/mnt/backup/databases/vm200-immich/`.
+2. На VM 200 (ssh admin@192.168.1.200):
+   ```bash
+   cd /opt/immich
+   gunzip -c /path/to/immich-db-YYYYMMDD-HHMM.sql.gz | docker compose exec -T database psql -U <DB_USERNAME> -d <DB_DATABASE_NAME>
+   ```
+   Или распаковать `.sql.gz`, затем:
+   ```bash
+   docker compose exec -T database psql -U <DB_USERNAME> -d <DB_DATABASE_NAME> < backup.sql
+   ```
+   `<DB_USERNAME>` и `<DB_DATABASE_NAME>` — из `/opt/immich/.env` (обычно `postgres` и `immich`).
+
+Перед восстановлением лучше остановить приложение Immich (или как минимум не писать в БД). При полной пересоздании БД — очистить каталог данных PostgreSQL в контейнере и затем загрузить дамп.
+
+---
+
+### 4. Восстановление библиотеки фото Immich
+
+**Когда нужно:** потеря данных на диске VM 200 (например `/mnt/data/library`).
+
+На VM 200 (или с хоста через rsync в обратную сторону): скопировать содержимое `/mnt/backup/photos/library/` обратно в каталог библиотеки Immich на VM 200 (в .env указан `UPLOAD_LOCATION`, обычно `/mnt/data/library`). Пример с хоста Proxmox:
+
+```bash
+rsync -av /mnt/backup/photos/library/ admin@192.168.1.200:/mnt/data/library/
+```
+
+После копирования на VM 200 выставить владельца/права под контейнер Immich (если нужно) и перезапустить сервисы.
+
+---
+
+### 5. Восстановление БД Paperless (CT 104), Gitea (CT 103)
+
+**Paperless:** дамп из `/mnt/backup/databases/ct104-paperless/paperless-db-*.sql.gz`. На CT 104: остановить приложение, `gunzip -c backup.sql.gz | docker exec -i paperless-db-1 psql -U paperless -d paperless`, запустить стек.
+
+**Gitea:** дамп из `/mnt/backup/databases/ct103-gitea/gitea-db-*.sql.gz`. На CT 103: остановить Gitea, восстановить в контейнер `gitea-db-1` (psql -U gitea -d gitea), запустить стек.
+
+---
+
+### 6. Восстановление данных Vaultwarden (CT 103)
+
+Архив из `/mnt/backup/other/vaultwarden/vaultwarden-data-*.tar.gz`. На CT 103: остановить Vaultwarden, распаковать в `/opt/docker/vaultwarden/` (получится каталог `data/`), выставить владельца/права под контейнер, запустить Vaultwarden.
+
+---
+
+### 7. Восстановление бэкапа VPS Миран (telegram-helper-bot)
+
+**Когда нужно:** потеря данных на VPS или перенос бота на другой хост.
+
+В бэкапе есть:
+- **БД:** `/mnt/backup/vps/miran/db/tg-bot-database-YYYYMMDD.db` — копии SQLite.
+- **Голосовые сообщения:** `/mnt/backup/vps/miran/voice_users/` — каталог .ogg.
+- **S3 (контент бота):** `/mnt/backup/vps/miran/s3/` — полная копия бакета (photos, videos, voice и т.д.).
+
+**Восстановление на VPS:**
+1. Скопировать выбранный файл БД на VPS:  
+   `scp -P 15722 /mnt/backup/vps/miran/db/tg-bot-database-YYYYMMDD.db deploy@185.147.80.190:/home/prod/bots/telegram-helper-bot/database/tg-bot-database.db`
+2. Восстановить `voice_users`:  
+   `rsync -avz -e "ssh -p 15722" /mnt/backup/vps/miran/voice_users/ deploy@185.147.80.190:/home/prod/bots/telegram-helper-bot/voice_users/`
+3. При потере данных в S3 — загрузить из бэкапа в бакет Miran (через aws s3 sync или панель), используя endpoint `https://api.s3.miran.ru` и креды из [VPS Миран](vps-miran-bots.md).
+
+**Требования для бэкапа:** на хосте Proxmox — SSH-ключ root → deploy@185.147.80.190 (порт 15722); для S3 — установленный `aws` cli и файл `/root/.vps-miran-s3.env` с переменными S3_ACCESS_KEY, S3_SECRET_KEY, S3_BUCKET_NAME (см. [VPS Миран](../vps/vps-miran-bots.md)).
+
+---
+
+### 8. Восстановление векторов RAG (CT 105)
+
+Архив из `/mnt/backup/other/ct105-vectors/vectors-*.tar.gz`. Распаковать на хосте и скопировать в контейнер: `tar -xzf vectors-*.tar.gz` → затем `pct push 105 ./vectors /home/rag-service/data/` или распаковать внутри CT 105 в `/home/rag-service/data/` (получится каталог `vectors/` с `vectors.npz`).
+
+---
+
+### 9. Восстановление VM 200 (Immich) с нуля
+
+VM 200 **не входит** в задание vzdump (образ ~380 ГБ, не помещается в политику 7 копий). В бэкапе есть: **конфиг ВМ** (в архивах `/etc/pve`), **БД** (pg_dump), **фото** (rsync в `photos/library`). Восстановление — создание новой ВМ с теми же параметрами и перенос данных.
+
+**Что есть после восстановления хоста:**
+- Из бэкапа `etc-pve`: файл `/etc/pve/qemu-server/200.conf` — полное описание ВМ (CPU, память, диски, **hostpci для GPU**, сеть). Его можно использовать как образец при создании новой ВМ.
+- Дамп БД: `/mnt/backup/databases/vm200-immich/immich-db-*.sql.gz`.
+- Фото: `/mnt/backup/photos/library/`.
+
+**Ключевые параметры VM 200** (если восстанавливать вручную без конфига):
+- **Ресурсы:** 3 ядра, 10 GB RAM.
+- **GPU:** проброс видеокарты (hostpci) — в Proxmox: Hardware → Add → PCI Device → выбрать VGA/NVIDIA, поставить «All Functions» и «ROM-Bar» при необходимости. В конфиге это выглядит как `hostpci0: 0000:xx:00.0` и т.п.
+- **Диски:** первый — системный (~35 GB), второй — данные (~350 GB) под `/mnt/data` (библиотека, PostgreSQL, Docker).
+- **Сеть:** статический IP 192.168.1.200/24, шлюз 192.168.1.1.
+- **ОС:** Debian 13 (trixie), пользователь **admin**, SSH.
+
+**Порядок восстановления:**
+
+1. **Создать ВМ 200** в Proxmox с теми же параметрами (скопировать из восстановленного `200.conf` или задать вручную: CPU, RAM, hostpci для GPU, два диска, сеть с IP 192.168.1.200).
+2. **Установить ОС** (Debian 13), создать пользователя admin, настроить SSH.
+3. **Разметить второй диск** и смонтировать в `/mnt/data` (как в [container-200](../containers/container-200.md)).
+4. **Установить Docker**, склонировать/восстановить каталоги Immich: `/opt/immich/` (docker-compose.yml, .env — из своих заметок или копии; секреты из Vaultwarden).
+5. **Создать каталоги** `/mnt/data/library`, `/mnt/data/postgres` (и др. по .env).
+6. **Скопировать фото** с хоста бэкапов на ВМ:  
+   `rsync -av /mnt/backup/photos/library/ admin@192.168.1.200:/mnt/data/library/`
+7. **Запустить только контейнер БД** (database), восстановить дамп (см. раздел 3 выше), затем поднять весь стек Immich.
+8. Проверить NPM (прокси на 192.168.1.200:2283), при необходимости заново включить ML и настройки в Immich.
+
+Подробное описание сервисов, образов и портов — в [container-200](../containers/container-200.md).
+
+---
+
+## Restic и Yandex
+
+Скрипт **`backup-restic-yandex.sh`** выгружает весь каталог `/mnt/backup` в Yandex Object Storage (S3). Retention: **3 daily, 2 weekly, 2 monthly** (`restic forget --keep-daily 3 --keep-weekly 2 --keep-monthly 2`). Пароли и дампы — чувствительные данные; не выкладывать в открытый доступ.
+
+---
+
+## Скрипты на хосте Proxmox
+
+| Скрипт | Назначение | Cron |
+|--------|------------|------|
+| `/root/scripts/backup-vps-miran.sh` | Бэкап VPS Миран: БД бота, voice_users, S3 (Miran) | 0 1 * * * |
+| `/root/scripts/backup-ct101-pgdump.sh` | Логический дамп БД Nextcloud из CT 101 | 15 1 * * * |
+| `/root/scripts/backup-immich-photos.sh` | Копирование библиотеки фото Immich (rsync с VM 200) | 30 1 * * * |
+| `/root/scripts/backup-etc-pve.sh` | Бэкап /etc/pve и конфигов хоста | 15 2 * * * |
+| `/root/scripts/backup-ct104-pgdump.sh` | Логический дамп БД Paperless из CT 104 | 30 2 * * * |
+| `/root/scripts/backup-vaultwarden-data.sh` | Копирование данных Vaultwarden (пароли) из CT 103 | 45 2 * * * |
+| `/root/scripts/backup-ct103-gitea-pgdump.sh` | Логический дамп БД Gitea из CT 103 | 0 3 * * * |
+| `/root/scripts/backup-vm200-pgdump.sh` | Логический дамп БД Immich с VM 200 | 15 3 * * * |
+| `/root/scripts/backup-ct105-vectors.sh` | Копирование векторов RAG (vectors.npz) из CT 105 | 30 3 * * * |
+| `/root/scripts/backup-restic-yandex.sh` | Выгрузка /mnt/backup в Yandex S3 (restic), retention 3/2/2 | 0 4 * * * |
+
+Задание vzdump (LXC/VM) настраивается в Proxmox UI (расписание 02:00). **05:00** оставлено свободным для плановой перезагрузки сервера.
+
+---
+
+## Связанные документы
+
+- [Стратегия бэкапов (фаза 1)](proxmox-phase1-backup.md) — общий план и принятые решения.
+- [Архитектура](../architecture/architecture.md) — хост, IP, доступ.
+- [VM 200 (Immich)](../containers/container-200.md) — сервисы, пути, .env.

docs/backup/proxmox-phase1-backup.md

@@ -24,11 +24,9 @@
 | Место | Описание | Что туда |
 |-------|----------|----------|
 | **Локально: /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. |
+| **Офсайт: Yandex Object Storage (S3)** | Арендованный бакет, S3-совместимый API. [Yandex Object Storage](https://yandex.cloud/ru/docs/storage/s3/). | **Restic** с хоста (cron на ноде Proxmox): выгрузка содержимого `/mnt/backup`. Retention: 3 daily, 2 weekly, 2 monthly. |
 
-- **Вариант A (альтернатива):** Отдельный диск/раздел на том же хосте — у тебя это sdb1.
-- **Вариант B:** Сетевое хранилище (NFS/SMB) — не используется в текущей схеме.
-- **Вариант C:** Внешний USB — опционально для 3-2-1 (см. ниже).
+**Принято:** Вариант A — отдельный диск/раздел на хосте (sdb1, 1 ТБ в `/mnt/backup`). Варианты B (NFS/SMB) и C (внешний USB) в текущей схеме не используются; USB опционально для параноидального 3-2-1 (см. выше).
 
 **3-2-1:** Три копии: (1) прод — система и данные на основном диске; (2) локальный бэкап — sdb1; (3) офсайт — Yandex. Два типа носителей: локальный SSD и облачное object storage. Один офсайт — да. **Стратегия удовлетворяет 3-2-1.** Опционально: четвёртая копия на внешнем USB/другом ПК для параноидального сценария (пожар/кража) — по желанию.
 
@@ -64,7 +62,7 @@
 /mnt/backup/
 ├── proxmox/
 │   ├── dump/          ← Proxmox Backup Job (VZDump) — сюда добавляем Storage в PVE
-│   └── etc-pve/       ← архивы tar.gz из cron (backup-etc-pve.sh)
+│   └── etc-pve/       ← архивы tar.gz из cron: etc-pve-*, etc-host-configs-* (backup-etc-pve.sh)
 ├── restic/
 │   ├── local/         ← репозитории restic для локальных снапшотов (опционально)
 │   └── ...            ← или restic только в Yandex, локально только сырые копии
@@ -88,7 +86,7 @@
 ### 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`.
+- **Retention в Yandex:** 3 daily, 2 weekly, 2 monthly — `restic forget --keep-daily 3 --keep-weekly 2 --keep-monthly 2` и затем `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-репозиториев можно не заводить — только каталоги и выгрузка их содержимого в облако.
@@ -97,18 +95,11 @@
 
 ---
 
-### Хранилище паролей (варианты)
+### Хранилище паролей
 
-Чтобы не терять пароли при восстановлении и держать креды в одном месте:
+Чтобы не терять пароли при восстановлении и держать креды в одном месте. Рассматривались варианты: Vaultwarden (self-hosted), Bitwarden Cloud, KeePass/KeePassXC, 1Password и др.
 
-| Вариант | Плюсы | Минусы |
-|--------|--------|--------|
-| **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.
+**Принято и сделано:** **Vaultwarden** развёрнут на **CT 103** LXC. Домен через NPM (HTTPS), клиенты Bitwarden на ПК/телефоне. Бэкап данных Vaultwarden включён в общий план (restic → Yandex).
 
 ---
 
@@ -132,7 +123,7 @@
    - **Mode:**  
      - **Snapshot** — контейнер/ВМ не останавливается, создаётся снимок (рекомендуется для минимизации даунтайма).  
      - **Suspend** — ВМ приостанавливается на время бэкапа (более консистентно для БД, но даунтайм).  
-     Для LXC обычно достаточно **Snapshot**; для VM 200 (Immich с БД) можно оставить Snapshot, при необходимости позже добавить отдельный консистентный бэкап БД изнутри гостя.
+     Для LXC обычно достаточно **Snapshot**. Для **VM 200** (PostgreSQL и др.): Snapshot **не гарантирует консистентность БД** — PostgreSQL может быть в середине транзакции. **Правильная стратегия:** внутри VM делать логический бэкап БД (`pg_dump`), а **vzdump snapshot** использовать для остального (ОС, конфиги, файлы). Итого: VM 200 — vzdump snapshot ок для образа; консистентность БД — отдельно через `pg_dump` внутри гостя.
    - **Compression:** ZSTD (хороший компромисс скорость/размер).
    - **Retention:** например «Keep last 7» или «Keep last 4 weekly» — чтобы не забивать диск.
 
@@ -142,11 +133,11 @@
 
 ---
 
-### Шаг 4. Бэкап /etc/pve
+### Шаг 4. Бэкап /etc/pve и конфигов хоста
 
-Конфиги кластера и виртуалок лежат в `/etc/pve`. Их нужно копировать регулярно и хранить в безопасном месте (желательно не только на том же диске, что и система).
+Конфиги кластера и виртуалок лежат в `/etc/pve`. Плюс для восстановления хоста полезны: `/etc/network/interfaces`, `/etc/hosts`, `/etc/resolv.conf`. Всё это нужно копировать регулярно и хранить в безопасном месте (желательно не только на том же диске, что и система).
 
-**Вариант A: cron на хосте Proxmox**
+**Принято: вариант A — cron на хосте Proxmox.**
 
 1. Создать скрипт, например `/root/scripts/backup-etc-pve.sh`:
 
@@ -156,17 +147,18 @@ 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
+tar -czf "$BACKUP_ROOT/etc-host-configs-$DATE.tar.gz" -C / etc/network/interfaces etc/hosts etc/resolv.conf
 # опционально: удалять бэкапы старше N дней
 # find "$BACKUP_ROOT" -name 'etc-pve-*.tar.gz' -mtime +30 -delete
+# find "$BACKUP_ROOT" -name 'etc-host-configs-*.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`
+3. Добавить в cron: `crontab -e`. Окно внутренних бэкапов 01:00–03:30; пример для etc-pve: `15 2 * * * /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` содержит секреты — не выкладывать в открытый доступ.
+Бэкапы (`etc-pve-*.tar.gz`, `etc-host-configs-*.tar.gz`) хранить **локально** (`/mnt/backup/proxmox/etc-pve`) и **в Yandex** — включить этот каталог в источники restic (мало весит, критично при потере хоста). Файлы с ограниченными правами (chmod 600); `/etc/pve` содержит секреты — не выкладывать в открытый доступ.
 
 ---
 
@@ -174,7 +166,7 @@ tar -czf "$BACKUP_ROOT/etc-pve-$DATE.tar.gz" -C / etc/pve
 
 Чтобы «не вспоминать пароли 3 часа» после восстановления:
 
-Завести **секретное хранилище** — Vaultwarden на CT 107 или 103 (см. выше). Туда: root Proxmox, пользователи PVE, пароли БД и сервисов (Nextcloud, Gitea, Paperless, Immich, NPM, Galene и т.д.), API-ключи (Beget, certbot, Wallos и др.). Полный список кредов по контейнерам — в статьях container-100 … container-200; свести в один список в Vaultwarden и обновлять при смене паролей.
+**Секретное хранилище** — Vaultwarden на **CT 103** (см. выше). Туда: root Proxmox, пользователи PVE, пароли БД и сервисов (Nextcloud, Gitea, Paperless, Immich, NPM, Galene и т.д.), API-ключи (Beget, certbot, Wallos и др.). Полный список кредов по контейнерам — в статьях container-100 … container-200; свести в один список в Vaultwarden и обновлять при смене паролей.
 
 Это не «шаг бэкапа», но обязательная часть восстановления: без паролей восстановленные контейнеры не войдут в сервисы.
 
@@ -218,18 +210,18 @@ tar -czf "$BACKUP_ROOT/etc-pve-$DATE.tar.gz" -C / etc/pve
 
 ## Чек-лист фазы 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`.
+- [x] Разметка: 1 ТБ на sdb1, ФС, монтирование в `/mnt/backup` (без LUKS). *(скрипт `scripts/backup-setup-sdb1-mount.sh`, каталоги созданы.)*
+- [x] В Proxmox добавлен Storage для VZDump → `/mnt/backup/proxmox/dump`.
+- [x] Настроена регулярная задача Backup: LXC (100–108), расписание ночь (02:00), retention задан. *VM 200 исключена из задания (образ ~380 ГБ); восстановление VM 200 — по инструкции «с нуля» в [backup-howto](backup-howto.md).*
+- [ ] Проверен ручной запуск Backup now — файлы появляются в storage. *(рекомендуется проверить разово.)*
+- [x] Настроен бэкап `/etc/pve` (скрипт + cron) → `/mnt/backup/proxmox/etc-pve`. *(backup-etc-pve.sh, 03:00, 30 дней.)*
 - [ ] 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).
+- [ ] Секреты перенесены в Vaultwarden. *(на усмотрение: root PVE, пароли БД, API и т.д.)*
+- [ ] Бэкап данных Vaultwarden включён в restic (Yandex S3). *Локально данные уже копируются в `/mnt/backup/other/vaultwarden/` (backup-vaultwarden-data.sh); при настройке restic — включить этот каталог в источники.*
 - [ ] Выполнено тестовое восстановление одного контейнера (другой VMID), проверена работоспособность.
-- [ ] В документации зафиксирована процедура полного восстановления Proxmox «с нуля».
+- [x] В документации зафиксирована процедура полного восстановления Proxmox «с нуля». *[backup-howto.md](backup-howto.md): восстановление из vzdump, конфигов, БД, VM 200 с нуля, Vaultwarden, VPS и др.*
 
 ---
 
@@ -252,8 +244,9 @@ tar -czf "$BACKUP_ROOT/etc-pve-$DATE.tar.gz" -C / etc/pve
 | VPS | Amnezia — конфиг. Миран — БД бота + контент (контент можно в S3 Мирана; копия на sdb1 — по желанию). Конфиг серверов не бэкапим — Ansible. |
 | Где запускать бэкапы | Cron на хосте Proxmox: Backup Job (vzdump) + restic в Yandex. |
 | Retention локально | Только в Proxmox Job и в скрипте etc-pve; отдельного restic-репозитория локально не делаем. |
-| /etc/pve | Локально и в Yandex (через restic). |
+| /etc/pve + конфиги хоста (interfaces, hosts, resolv.conf) | Вариант A: cron на хосте → `etc-pve` и `etc-host-configs` в `/mnt/backup/proxmox/etc-pve`; локально и в Yandex (restic). |
 | Пароли | Vaultwarden на CT 103. |
+| VM 200 (БД PostgreSQL) | vzdump snapshot — для образа ВМ; консистентность БД — отдельно: внутри VM логический бэкап (`pg_dump`). |
 | Yandex | Бакет создан; ключи и endpoint зафиксировать при настройке restic. |
 | MinIO | Не используем; директории + restic (s3 для Yandex). |
 
@@ -261,4 +254,7 @@ tar -czf "$BACKUP_ROOT/etc-pve-$DATE.tar.gz" -C / etc/pve
 
 ## Осталось сделать
 
-- **Yandex:** подготовить Static Key (Access Key + Secret), записать endpoint и имя бакета — понадобятся для настройки restic.
+- **Yandex + Restic:** подготовить Static Key (Access Key + Secret), записать endpoint и имя бакета; настроить restic на хосте (cron): выгрузка `/mnt/backup` в Yandex S3, retention 3 daily / 2 weekly / 2 monthly. Скрипт: `scripts/backup-restic-yandex.sh`.
+- **Проверка:** один раз запустить Backup now в Proxmox UI и убедиться, что файлы появляются в storage.
+- **Тестовое восстановление:** восстановить один контейнер (например 105 или 107) под другим VMID, проверить доступ и сервисы, затем удалить тестовый.
+- **Секреты:** при необходимости перенести пароли/ключи (root PVE, БД, API) в Vaultwarden и обновлять при смене.

docs/backup/restic-yandex-env.example

@@ -0,0 +1,12 @@
+# Пример конфига для restic + Yandex Object Storage.
+# Скопировать на хост Proxmox: cp restic-yandex-env.example /root/.restic-yandex.env
+# Подставить свои Access Key ID и Secret Key, chmod 600 /root/.restic-yandex.env
+# Не коммитить файл с реальными ключами.
+# Сервисному аккаунту в Yandex нужна роль storage.editor (не только uploader) — restic требует List объектов в бакете.
+
+RESTIC_REPOSITORY=s3:storage.yandexcloud.net/backup-local
+AWS_ACCESS_KEY_ID=ваш_идентификатор_ключа
+AWS_SECRET_ACCESS_KEY=ваш_секретный_ключ
+RESTIC_PASSWORD_FILE=/root/.restic-password
+# Регион Yandex (по умолчанию ru-central1)
+AWS_DEFAULT_REGION=ru-central1