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

docs/containers/container-100.md

@@ -210,10 +210,10 @@ docker logs vpn-route-check
 ## Логи и ротация
 
 - **NPM:** логи в `/opt/docker/nginx-proxy/data/logs/`.  
-  - Для файлов **proxy-host-*_access.log** настроен logrotate: `/etc/logrotate.d/npm-access` — ротация при 100 MB, 4 копии, copytruncate, compress.  
-  - Файлы **fallback_http_access.log**, **fallback_http_error.log** и другие **fallback_*** в правиле не указаны** — ротация по размеру/времени для них не настроена, каталог уже ~67 MB. Риск разрастания (см. TODO).
+  - Logrotate: `/etc/logrotate.d/npm-nginx.conf` — все `*.log` в каталоге; ротация **daily**, `size 100M`, `rotate 5`, `compress`, `copytruncate` (≈30 дней / ~512 MB). Старый конфиг `npm-access` переименован в `npm-access.disabled`.
+- **AdGuard:** данные и логи в `data/work/` и `data/conf/` (~85 MB). Хранение логов запросов и статистики ограничено **14 днями**: в `AdGuardHome.yaml` заданы `querylog.interval = 336h` и `statistics.interval = 336h`.
+- **Базовая политика LXC:** системные логи контейнера ротируются по `/etc/logrotate.d/homelab-lxc.conf` — 14 дней, 50 MB, 5 архивов. Подробнее: [Logrotate — базовая политика homelab](../maintenance/logrotate/README.md).
 - **Certbot:** `/etc/logrotate.d/certbot` — ротация логов letsencrypt (weekly, 12 копий).
-- **AdGuard:** данные и логи в `data/work/` и `data/conf/` (~85 MB). Стоит проверить настройки хранения логов запросов в веб-интерфейсе AdGuard (ограничение по времени/размеру).
 
 ---
 
@@ -241,8 +241,8 @@ docker logs vpn-route-check
 
 ## TODO по контейнеру 100
 
-- [ ] **Логи NPM:** Добавить в logrotate ротацию для `fallback_http_access.log`, `fallback_http_error.log` (и при необходимости других fallback_*) по размеру или по дням, чтобы не забивать диск.
-- [ ] **Логи AdGuard:** Проверить в веб-интерфейсе AdGuard настройки хранения логов запросов (срок/размер) и при необходимости ограничить.
+- [x] **Логи NPM:** Добавить в logrotate ротацию для `fallback_http_access.log`, `fallback_http_error.log` (и при необходимости других fallback_*) по размеру или по дням — настроено в `npm-nginx.conf` (30 дней / ~512 MB).
+- [x] **Логи AdGuard:** Ограничить хранение логов запросов/статистики — настроено в `AdGuardHome.yaml` (`querylog.interval = 336h`, `statistics.interval = 336h` ≈ 14 дней).
 - [ ] **VPN Route Check:** Вынести `ROUTER_TELNET_*` в `.env`, подключать в compose через `env_file`, не коммитить .env в репозиторий.
 - [ ] **Log-dashboard:** Зафиксировать способ запуска контейнера (отдельный compose или скрипт) и добавить его в документацию/автозапуск при перезагрузке CT.
 - [ ] **Мониторинг диска:** Настроить оповещение (например, из Prometheus/Alertmanager или скрипт по крону) при заполнении корня или `/opt/docker` выше порога (например 80%).

docs/containers/container-101.md

@@ -107,6 +107,7 @@ PostgreSQL и Redis не проброшены на хост — доступ т
 
 ## Логи и ротация
 
+- **Базовая политика LXC:** в контейнере настроен logrotate `/etc/logrotate.d/homelab-lxc.conf` — 14 дней, 50 MB, 5 архивов (системные логи в `/var/log`). Подробнее: [Logrotate — базовая политика homelab](../maintenance/logrotate/README.md).
 - **Nextcloud:** основной лог приложения — `/var/www/html/data/nextcloud.log` (в контейнере; на хосте — `/mnt/nextcloud-data/html/data/nextcloud.log`). На момент проверки файл уже порядка **сотен MB**. Встроенной ротации по размеру/времени в Nextcloud нет; в контейнере и на хосте **logrotate для этого файла не настроен** — риск разрастания и заполнения раздела (см. TODO).
 - **PostgreSQL:** логи по умолчанию в stdout (видны через `docker logs nextcloud-db-1`). Отдельного файлового лога и logrotate не проверялось.
 - **Docker:** вывод контейнеров — `docker logs`. Ротация логов Docker (json-file) зависит от настроек демона; при необходимости задать max-size/max-file в `/etc/docker/daemon.json`.
@@ -145,6 +146,7 @@ docker compose logs -f nextcloud
 
 ## TODO по контейнеру 101
 
+- [x] **Базовая политика logrotate:** для системных логов настроена (homelab-lxc.conf — 14 дней, 50 MB, 5 архивов). См. [Logrotate — базовая политика homelab](../maintenance/logrotate/README.md).
 - [ ] **Ротация nextcloud.log:** Настроить logrotate для `/mnt/nextcloud-data/html/data/nextcloud.log` (или пути на хосте CT 101): ротация по размеру (например 100–200 MB) или по дням, сжатие, ограничение числа копий. Либо включить в Nextcloud логирование в syslog и ротировать его.
 - [ ] **Уровень логирования:** В Nextcloud при необходимости снизить уровень лога (loglevel) в config.php или через `occ config:system:set loglevel --value 1` (1 = только ошибки), чтобы уменьшить рост лога.
 - [ ] **Резервное копирование:** Регулярный бэкап:  

docs/containers/container-103.md

@@ -205,6 +205,7 @@ curl -s http://127.0.0.1:8280/ | head -c 200
 
 ## Логи и ротация
 
+- **Базовая политика LXC:** в контейнере настроен logrotate `/etc/logrotate.d/homelab-lxc.conf` — 14 дней, 50 MB, 5 архивов (системные логи в `/var/log`). Подробнее: [Logrotate — базовая политика homelab](../maintenance/logrotate/README.md).
 - **Gitea:** в app.ini задано `MODE = console`, `ROOT_PATH = /data/gitea/log`. Логи идут в stdout и попадают в драйвер Docker **json-file** без ограничения размера и количества файлов — со временем каталог `/var/lib/docker/containers/<id>/*.log` может разрастаться (см. TODO).
 - **PostgreSQL:** логи в stdout контейнера, то же хранилище Docker.
 - **act_runner:** логи в stdout.
@@ -249,6 +250,7 @@ curl -s http://127.0.0.1:8280/ | head -c 200
 
 ## TODO по контейнеру 103
 
+- [x] **Базовая политика logrotate:** для системных логов настроена (homelab-lxc.conf — 14 дней, 50 MB, 5 архивов). См. [Logrotate — базовая политика homelab](../maintenance/logrotate/README.md).
 - [ ] **Логи Docker:** Включить ограничение размера логов для контейнеров: в `docker-compose.yml` (Gitea) добавить для сервисов `logging: driver: json-file options: max-size: "50m" max-file: "3"` или задать default в `/etc/docker/daemon.json` и перезапустить Docker. После этого перезапустить контейнеры.
 - [ ] **CouchDB compose:** Создать `/opt/docker/couchdb/docker-compose.yml` с текущими томами и портами, перейти на `docker compose up -d` вместо ручного `docker run`, зафиксировать в документации.
 - [ ] **Домены и NPM:** При необходимости настроить в NPM proxy для git.katykhin.ru → 192.168.1.103:3000 и obsidian.katykhin.ru → 192.168.1.103:5984, выпустить SSL (certbot + deploy в NPM). В Gitea при использовании домена обновить ROOT_URL и DOMAIN в compose/app.ini.

docs/containers/container-104.md

@@ -103,6 +103,7 @@ docker logs paperless-broker-1
 
 ## Логи и ротация
 
+- **Базовая политика LXC:** в контейнере настроен logrotate `/etc/logrotate.d/homelab-lxc.conf` — 14 дней, 50 MB, 5 архивов (системные логи в `/var/log`). Подробнее: [Logrotate — базовая политика homelab](../maintenance/logrotate/README.md).
 - **Paperless:** логи приложения в **/mnt/paperless-data/data/log/**:
   - `celery.log` — фоновые задачи (OCR, индекс и т.д.); приложение может делать собственную ротацию (celery.log.1, .2, .3). На момент проверки каталог ~568 KB.
   - `paperless.log` — основной лог приложения.
@@ -136,6 +137,7 @@ docker logs paperless-broker-1
 
 ## TODO по контейнеру 104
 
+- [x] **Базовая политика logrotate:** для системных логов настроена (homelab-lxc.conf — 14 дней, 50 MB, 5 архивов). См. [Logrotate — базовая политика homelab](../maintenance/logrotate/README.md).
 - [ ] **Логи Paperless:** Настроить logrotate для `/mnt/paperless-data/data/log/*.log`: например еженедельная ротация или по размеру (max 50–100 MB), хранить 3–4 копии, сжатие. Создать `/etc/logrotate.d/paperless` и проверить работу.
 - [ ] **Логи Docker:** Включить ограничение размера логов контейнеров: в `docker-compose.yml` добавить для сервисов `logging: driver: json-file options: max-size: "50m" max-file: "3"` или задать default в `/etc/docker/daemon.json` и перезапустить Docker, затем контейнеры.
 - [ ] **Домен и NPM:** При необходимости настроить в NPM proxy для docs.katykhin.ru → 192.168.1.104:8000, выпустить SSL. В Paperless в `docker-compose.env` задать PAPERLESS_URL=https://docs.katykhin.ru (если ещё не задан).

docs/containers/container-105.md

@@ -79,6 +79,7 @@ curl -s -H "X-API-Key: <key>" http://192.168.1.105:8000/api/v1/health
 
 ## Логи и ротация
 
+- **Базовая политика LXC:** в контейнере настроен logrotate `/etc/logrotate.d/homelab-lxc.conf` — 14 дней, 50 MB, 5 архивов (системные логи в `/var/log`). Подробнее: [Logrotate — базовая политика homelab](../maintenance/logrotate/README.md).
 - **RAG-service:** логи приложения идут в **stdout** контейнера (LOG_LEVEL из .env) и попадают в драйвер Docker **json-file** без ограничения размера и количества файлов.
 - **Системный logrotate** в CT — только стандартные правила (apt, dpkg, btmp, wtmp). Отдельных правил для RAG или Docker нет.
 
@@ -108,6 +109,7 @@ curl -s -H "X-API-Key: <key>" http://192.168.1.105:8000/api/v1/health
 
 ## TODO по контейнеру 105
 
+- [x] **Базовая политика logrotate:** для системных логов настроена (homelab-lxc.conf — 14 дней, 50 MB, 5 архивов). См. [Logrotate — базовая политика homelab](../maintenance/logrotate/README.md).
 - [ ] **Логи Docker:** Включить ограничение размера логов: в `docker-compose.yml` добавить для сервиса `logging: driver: json-file options: max-size: "50m" max-file: "3"` или задать default в `/etc/docker/daemon.json`, перезапустить Docker и контейнер.
 - [ ] **Мониторинг диска:** Следить за местом (df -h). Уже 74% — при достижении 85%+ выполнить `docker builder prune` и/или оценить увеличение диска. При желании — оповещение при заполнении выше порога.
 - [ ] **Домен и NPM:** При необходимости настроить в NPM proxy для mini-lm.katykhin.ru → 192.168.1.105:8000, выпустить SSL. В клиентах использовать https и передавать X-API-Key.

docs/containers/container-107.md

@@ -111,6 +111,7 @@ Companion и PostgreSQL доступны только внутри docker-сет
 
 ## Логи и ротация
 
+- **Базовая политика LXC:** в контейнере настроен logrotate `/etc/logrotate.d/homelab-lxc.conf` — 14 дней, 50 MB, 5 архивов (системные логи в `/var/log`). Подробнее: [Logrotate — базовая политика homelab](../maintenance/logrotate/README.md).
 - **Invidious и Companion:** логи идут в stdout контейнеров и сохраняются драйвером Docker **json-file**. В compose для `invidious` и `companion` заданы опции:
   - `max-size: "1G"`, `max-file: "4"` — максимум ~4 GB логов на контейнер. На момент проверки общий размер `/var/lib/docker` ~774 MB, запас по логам большой.
 - **PostgreSQL:** контейнер `invidious-db` использует json-file **без ограничений** (`Config:{}`) — логи БД могут разрастаться (см. TODO).
@@ -158,6 +159,7 @@ Companion и PostgreSQL доступны только внутри docker-сет
 
 ## TODO по контейнеру 107
 
+- [x] **Базовая политика logrotate:** для системных логов настроена (homelab-lxc.conf — 14 дней, 50 MB, 5 архивов). См. [Logrotate — базовая политика homelab](../maintenance/logrotate/README.md).
 - [ ] **Логи PostgreSQL:** Добавить ограничение логов для контейнера `invidious-invidious-db-1`:  
       либо через `logging` в `docker-compose.yml` (аналогично `invidious`/`companion`, но с меньшим лимитом, например `max-size: "200m"`, `max-file: "5"`), либо через глобальный `/etc/docker/daemon.json`. После изменения — перезапустить контейнер.
 - [ ] **Права на конфиги:** Ограничить доступ к `docker-compose.yml` и, при необходимости, к другим файлам с секретами (chmod 600, владелец root), убедиться, что эти файлы не попадают в публичные репозитории.

docs/containers/container-108.md

@@ -88,6 +88,7 @@ curl -s -k https://192.168.1.108:8443/  # или через NPM: https://call.ka
 
 ## Логи и ротация
 
+- **Базовая политика LXC:** в контейнере настроен logrotate `/etc/logrotate.d/homelab-lxc.conf` — 14 дней, 50 MB, 5 архивов (системные логи в `/var/log`). Подробнее: [Logrotate — базовая политика homelab](../maintenance/logrotate/README.md).
 - **Galene:** логи пишутся в **stdout/stderr** и попадают в **systemd journal** (journalctl -u galene.service). Отдельных файловых логов в `/opt/galene-data/` нет. На момент проверки журнал занимает ~8 MB.
 - **Ротация journal:** управляется настройками journald (например `/etc/systemd/journald.conf`: SystemMaxUse, MaxFileSec). Отдельного правила logrotate для Galene нет — ротация только за счёт journald. При долгой работе и активном трафике журнал может расти (см. TODO).
 - **Системный logrotate** в CT — стандартные правила (apt, dpkg, btmp, wtmp). Для Galene отдельного файла логов нет.
@@ -117,6 +118,7 @@ curl -s -k https://192.168.1.108:8443/  # или через NPM: https://call.ka
 
 ## TODO по контейнеру 108
 
+- [x] **Базовая политика logrotate:** для системных логов настроена (homelab-lxc.conf — 14 дней, 50 MB, 5 архивов). См. [Logrotate — базовая политика homelab](../maintenance/logrotate/README.md).
 - [ ] **Ротация journal:** Проверить/задать в `/etc/systemd/journald.conf` параметры `SystemMaxUse=`, `MaxFileSec=` (или аналог), чтобы журнал не разрастался бесконечно. После изменений — `systemctl restart systemd-journald` (учёт потери текущего лога при рестарте).
 - [ ] **Права на конфиги:** Ограничить доступ к файлам с паролями и кредами: `chmod 600` на `ice-servers.json`, на файлы в `groups/`. Владелец root.
 - [ ] **Мониторинг диска:** Следить за местом (df -h) и размером журнала. При желании — оповещение при заполнении выше порога (например 80%).

docs/containers/container-109.md

@@ -105,6 +105,8 @@ ip a show wg0
 
 Ожидаемый адрес: `10.10.99.1/24`.
 
+**Логи и ротация:** для auth/syslog настроен logrotate `/etc/logrotate.d/homelab-vpn-ssh.conf` — 90 дней, небольшой лимит размера (10 MB, 4 архива). Базовая политика LXC: `/etc/logrotate.d/homelab-lxc.conf`. См. [Logrotate — базовая политика homelab](../maintenance/logrotate/README.md).
+
 ---
 
 ## Конфиги клиентов (split-tunnel + DNS через AdGuard)

docs/containers/container-200.md

@@ -183,8 +183,9 @@ sudo resize2fs /dev/sdb1
 
 ## Логи и ротация
 
+- **Базовая политика (как в LXC):** на ВМ настроен logrotate `/etc/logrotate.d/homelab-lxc.conf` — 14 дней, 50 MB, 5 архивов, сжатие (системные логи в `/var/log`). На ВМ 200 пакет `logrotate` был установлен вручную (в образе по умолчанию не было); после установки активен таймер `logrotate.timer`. Подробнее: [Logrotate — базовая политика homelab](../maintenance/logrotate/README.md).
 - **Docker:** данные Docker (образы, контейнеры, overlay) хранятся в **/mnt/data/docker** (Docker Root Dir). Логи контейнеров — драйвер **json-file** без ограничения размера и количества файлов (Config:{} у immich_server и immich_postgres). При активной работе логи могут разрастаться и занимать место на **корневом** разделе (если логи пишутся на корень) или в overlay на /mnt/data — уточнить расположение логов контейнеров (часто в /mnt/data/docker/containers). В любом случае ограничение логов не задано (см. TODO).
-- **Системный logrotate:** стандартные правила (apt, dpkg, cloud-init, unattended-upgrades, wtmp). Отдельных правил для Immich или Docker нет.
+- **Системный logrotate:** стандартные правила (apt, dpkg, cloud-init, unattended-upgrades, wtmp) плюс homelab-lxc.conf. Отдельных правил для Immich или Docker нет.
 
 **Риск:** корневой диск заполнен на 87%. Рост логов, обновления и кэш могут привести к нехватке места. Необходимо ограничить логи Docker и следить за местом на корне (см. TODO).
 
@@ -216,6 +217,7 @@ sudo resize2fs /dev/sdb1
 
 ## TODO по ВМ 200
 
+- [x] **Базовая политика logrotate:** для системных логов настроена (homelab-lxc.conf — 14 дней, 50 MB, 5 архивов, как в LXC). См. [Logrotate — базовая политика homelab](../maintenance/logrotate/README.md).
 - [ ] **Корневой диск:** Снизить использование корня (87%). Варианты: перенести логи Docker на /mnt/data (если сейчас пишутся на корень), очистить старые образы/кэш (`docker system prune` с осторожностью), увеличить размер корневого диска ВМ в Proxmox. Настроить мониторинг и оповещение при заполнении >90%.
 - [ ] **Логи Docker:** Включить ограничение размера логов для всех контейнеров Immich и deduper: в `docker-compose.yml` добавить для каждого сервиса `logging: driver: json-file options: max-size: "100m" max-file: "3"` или задать default в `/etc/docker/daemon.json`. Убедиться, что Docker Root Dir остаётся на /mnt/data и логи не пишутся на корень. После изменений перезапустить контейнеры.
 - [ ] **Права на конфиги:** Ограничить доступ к .env (chmod 600), не коммитить в публичные репозитории.

docs/maintenance/logrotate/README.md

@@ -0,0 +1,23 @@
+# Logrotate: базовая политика homelab
+
+Конфигурации logrotate для Proxmox, LXC-контейнеров, Nginx Proxy Manager и VPN/SSH.
+
+## Политики
+
+| Цель | Срок | Размер/архивы | Сжатие |
+|-----|------|----------------|--------|
+| **Proxmox host** | 14 дней | max 100 MB на файл, 5–7 архивов | да |
+| **LXC контейнеры** | 14 дней | 50 MB ротация, 5 архивов | да |
+| **ВМ 200 (Immich)** | 14 дней | 50 MB ротация, 5 архивов (то же, что LXC) | да |
+| **nginx reverse proxy (CT 100)** | 30 дней или 512 MB суммарно | rotate 5 × ~100 MB | да |
+| **VPN / SSH (CT 109 и auth)** | 90 дней | небольшой лимит размера | да |
+
+## Размещение на хостах
+
+- **Proxmox:** правки в `/etc/logrotate.conf` (секция default) + при необходимости `/etc/logrotate.d/`.
+- **LXC:** `/etc/logrotate.d/homelab-lxc.conf` (и при необходимости специфичные файлы).
+- **ВМ 200:** `/etc/logrotate.d/homelab-lxc.conf` (тот же конфиг, что и в LXC). На ВМ 200 пакет `logrotate` при необходимости установить: `sudo apt-get install logrotate` (после установки активен `logrotate.timer`).
+- **CT 100 (nginx):** `/etc/logrotate.d/npm-nginx.conf` (логи NPM в `/opt/docker/nginx-proxy/data/logs/`).
+- **CT 109 (VPN) и везде auth/SSH:** `/etc/logrotate.d/homelab-vpn-ssh.conf`.
+
+Конфиги из этой папки можно копировать на соответствующие хосты и проверять: `logrotate -d /path/to/config`.

docs/maintenance/logrotate/lxc-default.conf

@@ -0,0 +1,22 @@
+# LXC контейнеры: базовая политика
+# 14 дней, 50 MB ротация, 5 архивов, сжатие
+# Размещение: /etc/logrotate.d/homelab-lxc.conf
+
+/var/log/*.log
+/var/log/mail.log
+/var/log/syslog
+/var/log/daemon.log
+/var/log/kern.log
+/var/log/auth.log
+/var/log/user.log
+{
+    daily
+    maxage 14
+    size 50M
+    rotate 5
+    compress
+    delaycompress
+    missingok
+    notifempty
+    sharedscripts
+}

docs/maintenance/logrotate/npm-nginx.conf

@@ -0,0 +1,17 @@
+# Nginx Proxy Manager (контейнер 100): логи в /opt/docker/nginx-proxy/data/logs/
+# 30 дней или ~512 MB суммарно (5 архивов × ~100 MB), сжатие
+# Размещение на CT 100: /etc/logrotate.d/npm-nginx.conf
+
+/opt/docker/nginx-proxy/data/logs/*.log
+{
+    daily
+    maxage 30
+    size 100M
+    rotate 5
+    compress
+    delaycompress
+    missingok
+    notifempty
+    copytruncate
+    sharedscripts
+}

docs/maintenance/logrotate/proxmox-host.conf

@@ -0,0 +1,35 @@
+# Базовые настройки для Proxmox host (192.168.1.150)
+# 14 дней, max 100 MB на файл, 5–7 архивов, сжатие
+#
+# Вариант 1: встроить в /etc/logrotate.conf в секцию default:
+#   daily
+#   maxage 14
+#   size 100M
+#   rotate 6
+#   compress
+#   delaycompress
+#   missingok
+#   notifempty
+#
+# Вариант 2: положить этот файл как /etc/logrotate.d/99-proxmox.conf
+# (применяется к перечисленным путям; пакетные конфиги имеют приоритет по имени)
+
+/var/log/syslog
+/var/log/messages
+/var/log/daemon.log
+/var/log/kern.log
+/var/log/auth.log
+/var/log/user.log
+/var/log/pve/tasks/active
+/var/log/pve/tasks/index
+{
+    daily
+    maxage 14
+    size 100M
+    rotate 6
+    compress
+    delaycompress
+    missingok
+    notifempty
+    sharedscripts
+}

docs/maintenance/logrotate/vpn-ssh.conf

@@ -0,0 +1,19 @@
+# VPN / SSH: длительное хранение (90 дней), небольшой лимит размера
+# Контейнер 109 (WireGuard) и общие auth/SSH логи
+# Размещение: CT 109 — /etc/logrotate.d/homelab-vpn-ssh.conf
+# На других хостах (опционально) — то же для auth.log / secure
+
+/var/log/auth.log
+/var/log/secure
+/var/log/syslog
+{
+    daily
+    maxage 90
+    size 10M
+    rotate 4
+    compress
+    delaycompress
+    missingok
+    notifempty
+    sharedscripts
+}

docs/vps/amnezia-awg/Dockerfile

@@ -0,0 +1,50 @@
+# Образ для AmneziaWG на VPS. Используется на 185.103.253.99 (Germany) и 147.45.124.117 (USA).
+# Сборка: docker build -t amnezia-awg .
+# Конфиг WireGuard/обфускация задаётся через приложение AmneziaVPN при установке протокола на сервер.
+
+FROM amneziavpn/amnezia-wg:latest
+
+LABEL maintainer="AmneziaVPN"
+
+#Install required packages
+RUN apk add --no-cache bash curl dumb-init
+RUN apk --update upgrade --no-cache
+
+RUN mkdir -p /opt/amnezia
+RUN echo -e "#!/bin/bash\ntail -f /dev/null" > /opt/amnezia/start.sh
+RUN chmod a+x /opt/amnezia/start.sh
+
+# Tune network
+RUN echo -e " \n\
+  fs.file-max = 51200 \n\
+  \n\
+  net.core.rmem_max = 67108864 \n\
+  net.core.wmem_max = 67108864 \n\
+  net.core.netdev_max_backlog = 250000 \n\
+  net.core.somaxconn = 4096 \n\
+  \n\
+  net.ipv4.tcp_syncookies = 1 \n\
+  net.ipv4.tcp_tw_reuse = 1 \n\
+  net.ipv4.tcp_tw_recycle = 0 \n\
+  net.ipv4.tcp_fin_timeout = 30 \n\
+  net.ipv4.tcp_keepalive_time = 1200 \n\
+  net.ipv4.ip_local_port_range = 10000 65000 \n\
+  net.ipv4.tcp_max_syn_backlog = 8192 \n\
+  net.ipv4.tcp_max_tw_buckets = 5000 \n\
+  net.ipv4.tcp_fastopen = 3 \n\
+  net.ipv4.tcp_mem = 25600 51200 102400 \n\
+  net.ipv4.tcp_rmem = 4096 87380 67108864 \n\
+  net.ipv4.tcp_wmem = 4096 65536 67108864 \n\
+  net.ipv4.tcp_mtu_probing = 1 \n\
+  net.ipv4.tcp_congestion_control = hybla \n\
+  # for low-latency network, use cubic instead \n\
+  # net.ipv4.tcp_congestion_control = cubic \n\
+  " | sed -e 's/^\s\+//g' | tee -a /etc/sysctl.conf && \
+  mkdir -p /etc/security && \
+  echo -e " \n\
+  * soft nofile 51200 \n\
+  * hard nofile 51200 \n\
+  " | sed -e 's/^\s\+//g' | tee -a /etc/security/limits.conf
+
+ENTRYPOINT [ "dumb-init", "/opt/amnezia/start.sh" ]
+CMD [ "" ]

docs/vps/vpn-migrate-config.md

@@ -58,3 +58,82 @@
 - Переключение: выбираешь активное подключение — либо одно, либо другое (или отключено). Маршруты/политики при необходимости те же для обоих (например, весь трафик в туннель или только часть по правилам).
 
 Так можно в любой момент перейти с USA на новый VPS: добавляешь новый профиль с конфигом нового сервера и переключаешься на него.
+
+---
+
+## Конфиги для полного восстановления сервера
+
+Все файлы, чтобы поднять новый VPS с нуля (тот же образ и параметры контейнера). Ключи и пиры WireGuard создаются приложением AmneziaVPN при установке протокола — их не копируем.
+
+### Файлы в репозитории
+
+| Назначение | Путь в репо |
+|------------|-------------|
+| Dockerfile AmneziaWG | `docs/vps/amnezia-awg/Dockerfile` |
+| Метрики для Homepage | `scripts/vps-metrics-api.py` |
+| Systemd-юнит метрик | `docs/vps/vps-metrics.service` |
+
+### 1. Подготовка VPS
+
+- ОС: Ubuntu (или [поддерживаемая Amnezia](https://docs.amnezia.org/ru/documentation/supported-linux-os-for-vps)).
+- Установить Docker, настроить SSH-доступ с твоего ключа (для AmneziaVPN).
+- На хосте: скопировать `docs/vps/amnezia-awg/Dockerfile` в каталог на VPS (например `/opt/amnezia/amnezia-awg/`), собрать образ:
+  ```bash
+  cd /opt/amnezia/amnezia-awg
+  docker build -t amnezia-awg .
+  ```
+
+### 2. Запуск контейнера AmneziaWG
+
+**Германия (или новый сервер с портом 33118):**
+
+```bash
+docker run -d --name amnezia-awg --restart=always \
+  -p 33118:33118/udp \
+  -v /lib/modules:/lib/modules \
+  --cap-add=NET_ADMIN --cap-add=SYS_MODULE \
+  --privileged \
+  --sysctl net.ipv4.conf.all.src_valid_mark=1 \
+  --security-opt label=disable \
+  amnezia-awg
+```
+
+**США (или второй сервер с портом 37135):**
+
+```bash
+docker run -d --name amnezia-awg2 --restart=always \
+  -p 37135:37135/udp \
+  -v /lib/modules:/lib/modules \
+  --cap-add=NET_ADMIN --cap-add=SYS_MODULE \
+  --privileged \
+  --sysctl net.ipv4.conf.all.src_valid_mark=1 \
+  --security-opt label=disable \
+  amnezia-awg
+```
+
+Важно: внутри контейнера AmneziaWG слушает тот порт, который задаётся при установке протокола через приложение (на Germany — 33118, на USA — 37135). Если поднимаешь новый сервер с другим портом, в команде меняй оба: `-p ПОРТ:ПОРТ/udp` и при установке AmneziaWG в приложении укажи тот же порт.
+
+### 3. Установка протокола через AmneziaVPN
+
+1. В приложении AmneziaVPN добавь сервер по IP нового VPS (SSH по ключу).
+2. Установи протокол **AmneziaWG** на этот сервер (приложение подключится по SSH и настроит контейнер).
+3. В настройках протокола на сервере задай параметры обфускации из таблицы выше: **jc, jmin, jmax, s1, s2, h1–h4**.
+4. Сгенерируй гостевые конфиги / конфиг с полным доступом — в них будет Endpoint = IP:порт нового VPS.
+
+### 4. Метрики для Homepage (опционально)
+
+Чтобы виджет метрик на Homepage показывал данные с этого VPS:
+
+```bash
+# Скопировать скрипт и юнит на VPS
+cp scripts/vps-metrics-api.py /usr/local/bin/
+chmod +x /usr/local/bin/vps-metrics-api.py
+cp docs/vps/vps-metrics.service /etc/systemd/system/
+systemctl daemon-reload && systemctl enable --now vps-metrics
+```
+
+Порт **3497/tcp** должен быть доступен с хоста, где крутится Homepage (или открыт в файрволе VPS).
+
+### 5. Файрвол
+
+На текущем сервере в Германии UFW не включён, политика iptables по умолчанию ACCEPT. Достаточно убедиться, что хостинг не режет входящий **UDP на порт AmneziaWG** (33118 или 37135) и при необходимости SSH (22) и 3497 для метрик.

docs/vps/vpn-vps-amneziawg.md

@@ -24,7 +24,7 @@
 - Контейнер запущен с `--restart=always`, примонтирован `/lib/modules` (для ядерного модуля WireGuard). Сеть — bridge, проброс порта 33118/udp на хост.
 - Дополнительно: **vps-metrics** (systemd-сервис) — API метрик для виджета Homepage.
 
-Каталог образа/скриптов на хосте: `/opt/amnezia/amnezia-awg/` (там лежит Dockerfile; сам сервер AmneziaWG настраивается через приложение AmneziaVPN при установке протокола на этот VPS).
+Каталог образа/скриптов на хосте: `/opt/amnezia/amnezia-awg/` (там лежит Dockerfile; сам сервер AmneziaWG настраивается через приложение AmneziaVPN при установке протокола на этот VPS). Копия Dockerfile и команды для полного развёртывания на новом VPS — в [перенос конфигурации](vpn-migrate-config.md#конфиги-для-полного-восстановления-сервера).
 
 ---
 

docs/vps/vps-metrics.service

@@ -0,0 +1,16 @@
+# Копировать на VPS: /etc/systemd/system/vps-metrics.service
+# Затем: systemctl daemon-reload && systemctl enable --now vps-metrics
+# Скрипт: scripts/vps-metrics-api.py → /usr/local/bin/vps-metrics-api.py
+
+[Unit]
+Description=VPS metrics API for Homepage
+After=network.target
+
+[Service]
+Type=simple
+ExecStart=/usr/bin/python3 /usr/local/bin/vps-metrics-api.py
+Restart=always
+RestartSec=5
+
+[Install]
+WantedBy=multi-user.target

docs/vps/vps-miran-bots.md

@@ -55,6 +55,8 @@ VPS в ЦОД Миран (Санкт-Петербург). Развёрнуты
 
 В ботаx (переменные окружения prod) заданы `S3_ENDPOINT_URL=https://api.s3.miran.ru`, регион и креды для загрузки/выдачи контента. Для локальной разработки или других клиентов использовать те же endpoint и ключи.
 
+**Бакет контента бота:** в S3 Miran используется бакет с именем `9829-telegram-helper-bot` (переменная `S3_BUCKET_NAME` в .env бота).
+
 ### 4. Остальное на хосте
 
 - **nginx** — порты 80 и 443; по умолчанию отдаёт статику из `/var/www/html`.  
@@ -103,3 +105,26 @@ docker compose logs -f telegram-bot
 - **Homepage** (контейнер 100): виджет метрик может показывать данные с vps-metrics (185.147.80.190:3497).
 
 Остальные узлы homelab (Proxmox, NPM и т.д.) описаны в [архитектуре](../architecture/architecture.md).
+
+---
+
+## Бэкап VPS (telegram-helper-bot)
+
+Бэкап выполняется **с хоста Proxmox** скриптом `backup-vps-miran.sh` (cron 01:00). Копируются:
+
+1. **БД:** `/home/prod/bots/telegram-helper-bot/database/tg-bot-database.db` → `/mnt/backup/vps/miran/db/` (с датой в имени, хранение 14 дней).
+2. **Голосовые сообщения:** `/home/prod/bots/telegram-helper-bot/voice_users/` → `/mnt/backup/vps/miran/voice_users/` (rsync).
+3. **S3 (Miran):** полная выгрузка бакета `9829-telegram-helper-bot` → `/mnt/backup/vps/miran/s3/` (через `aws s3 sync`).
+
+**Что нужно на Proxmox:**
+
+- **SSH:** с хоста (root) должен работать вход без пароля на `deploy@185.147.80.190 -p 15722` (добавить публичный ключ хоста в `~/.ssh/authorized_keys` пользователя deploy на VPS).
+- **S3:** установить `awscli` (`apt install awscli`) и создать файл `/root/.vps-miran-s3.env` с содержимым (подставить свои креды):
+  ```bash
+  S3_ACCESS_KEY=j3tears100@gmail.com
+  S3_SECRET_KEY=...
+  S3_BUCKET_NAME=9829-telegram-helper-bot
+  ```
+  Файл читается только root; в репозиторий не коммитить.
+
+Подробности и восстановление — в [Бэкапы: как устроены и как восстанавливать](../backup/backup-howto.md).