Files

Andrey feaa31f702 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.

2026-02-26 20:14:30 +03:00

24 KiB

Raw Blame History

Фаза 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.	Restic с хоста (cron на ноде Proxmox): выгрузка содержимого `/mnt/backup`. Retention: 3 daily, 2 weekly, 2 monthly.

Принято: Вариант 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/другом ПК для параноидального сценария (пожар/кража) — по желанию.

Принято: Точка монтирования — /mnt/backup. На диске 2 ТБ выделено 1 ТБ под бэкапы; второй ТБ пока в запас, назначение не определено.

Действие: Разметить 1 ТБ на /dev/sdb1, создать ФС (ext4/xfs), смонтировать в /mnt/backup. Структуру каталогов — см. раздел «Структура локального хранилища» ниже.

Шаг 2. Добавить Backup Storage в Proxmox

В веб-интерфейсе: Datacenter → Storage → Add.
Тип: Directory (если папка на локальном диске) или NFS/CIFS (если сетевое).
Указать:
- ID (например backup-local или backup-nfs),
- Directory — путь, например /mnt/backup/dump,
- Включить опции Content: VZDump backup file (и при необходимости ISO, Container template — по желанию).
Сохранить. Убедиться, что 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: etc-pve-*, etc-host-configs-* (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: 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-репозиториев можно не заводить — только каталоги и выгрузка их содержимого в облако.

Документация Yandex: Object Storage S3. Нужны: bucket name, region, endpoint, Static Key (Access Key ID + Secret Access Key). Бакет создан; ключи и endpoint зафиксировать при настройке restic.

Хранилище паролей

Чтобы не терять пароли при восстановлении и держать креды в одном месте. Рассматривались варианты: Vaultwarden (self-hosted), Bitwarden Cloud, KeePass/KeePassXC, 1Password и др.

Принято и сделано: Vaultwarden развёрнут на CT 103 LXC. Домен через NPM (HTTPS), клиенты Bitwarden на ПК/телефоне. Бэкап данных 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

Datacenter → Backup (или Backup в меню узла).
Add — создаётся задача (Job).
Параметры:
- 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 (PostgreSQL и др.): Snapshot не гарантирует консистентность БД — PostgreSQL может быть в середине транзакции. Правильная стратегия: внутри VM делать логический бэкап БД (pg_dump), а vzdump snapshot использовать для остального (ОС, конфиги, файлы). Итого: VM 200 — vzdump snapshot ок для образа; консистентность БД — отдельно через pg_dump внутри гостя.
- Compression: ZSTD (хороший компромисс скорость/размер).
- Retention: например «Keep last 7» или «Keep last 4 weekly» — чтобы не забивать диск.
Сохранить job. Проверить по кнопке Backup now, что задача запускается и файлы появляются в Storage.

Важно: бэкап должен включать и LXC, и VM 200. Не только данные внутри них (те уже описаны в документации контейнеров), а именно полный dump для restore.

Шаг 4. Бэкап /etc/pve и конфигов хоста

Конфиги кластера и виртуалок лежат в /etc/pve. Плюс для восстановления хоста полезны: /etc/network/interfaces, /etc/hosts, /etc/resolv.conf. Всё это нужно копировать регулярно и хранить в безопасном месте (желательно не только на том же диске, что и система).

Принято: вариант A — cron на хосте Proxmox.

Создать скрипт, например /root/scripts/backup-etc-pve.sh:

#!/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
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

Сделать исполняемым: chmod +x /root/scripts/backup-etc-pve.sh.
Добавить в 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-*.tar.gz, etc-host-configs-*.tar.gz) хранить локально (/mnt/backup/proxmox/etc-pve) и в Yandex — включить этот каталог в источники restic (мало весит, критично при потере хоста). Файлы с ограниченными правами (chmod 600); /etc/pve содержит секреты — не выкладывать в открытый доступ.

Шаг 5. Хранить секреты отдельно (пароли, ключи)

Чтобы «не вспоминать пароли 3 часа» после восстановления:

Секретное хранилище — Vaultwarden на CT 103 (см. выше). Туда: root Proxmox, пользователи PVE, пароли БД и сервисов (Nextcloud, Gitea, Paperless, Immich, NPM, Galene и т.д.), API-ключи (Beget, certbot, Wallos и др.). Полный список кредов по контейнерам — в статьях container-100 … container-200; свести в один список в Vaultwarden и обновлять при смене паролей.

Это не «шаг бэкапа», но обязательная часть восстановления: без паролей восстановленные контейнеры не войдут в сервисы.

Шаг 6. Тестовое восстановление одного контейнера

Без проверки восстановления нельзя считать стратегию рабочей.

Выбрать некритичный контейнер (например 105 — RAG, или 107 — Invidious), для которого краткий даунтайм допустим.
Убедиться, что есть свежий backup этого контейнера в Storage (после шага 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.
Запустить восстановленный контейнер (ID 999), проверить:
- заходит по SSH/консоль;
- сервисы внутри запускаются (docker/ systemd);
- с хоста пинг и при необходимости один сервис по порту.
После проверки удалить тестовый контейнер (999), освободить место.

Если что-то пошло не так (не находится диск, ошибка прав, сеть) — зафиксировать и поправить стратегию (пути storage, режим backup, права).

Шаг 7. Документировать процедуру восстановления «с нуля»

Кратко зафиксировать в отдельном разделе (здесь или в architecture):

Установка Proxmox на новое железо (или новый диск).
Восстановление конфигов: распаковать последний etc-pve-*.tar.gz в /etc/pve (с учётом того, что нужно корректно подставить ноды и storage; при одномузловой установке обычно достаточно скопировать файлы).
Подключение storage с backup (или копирование последних vzdump на новый storage).
Восстановление контейнеров и ВМ из backup по одному (Restore с указанием VMID и storage).
Запуск контейнеров/ВМ, проверка сети и сервисов.
Использование сохранённых паролей/ключей для входа и проверки сервисов.

После первого успешного тестового восстановления (шаг 6) эту процедуру можно уточнить и дописать по факту.

Чек-лист фазы 1

Разметка: 1 ТБ на sdb1, ФС, монтирование в /mnt/backup (без LUKS). (скрипт scripts/backup-setup-sdb1-mount.sh, каталоги созданы.)
В Proxmox добавлен Storage для VZDump → /mnt/backup/proxmox/dump.
Настроена регулярная задача Backup: LXC (100–108), расписание ночь (02:00), retention задан. VM 200 исключена из задания (образ ~380 ГБ); восстановление VM 200 — по инструкции «с нуля» в backup-howto.
Проверен ручной запуск Backup now — файлы появляются в storage. (рекомендуется проверить разово.)
Настроен бэкап /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 успешно пишет в бакет.
Vaultwarden развёрнут (CT 103).
Секреты перенесены в Vaultwarden. (на усмотрение: root PVE, пароли БД, API и т.д.)
Бэкап данных Vaultwarden включён в restic (Yandex S3). Локально данные уже копируются в /mnt/backup/other/vaultwarden/ (backup-vaultwarden-data.sh); при настройке restic — включить этот каталог в источники.
Выполнено тестовое восстановление одного контейнера (другой VMID), проверена работоспособность.
В документации зафиксирована процедура полного восстановления Proxmox «с нуля». backup-howto.md: восстановление из vzdump, конфигов, БД, VM 200 с нуля, Vaultwarden, VPS и др.

Ссылки

Архитектура и подключение — хосты, IP, домены.
Схема сети и зависимости — 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 + конфиги хоста (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).

Осталось сделать

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 и обновлять при смене.

24 KiB Raw Blame History Unescape Escape