Files

Andrey b0d2746490 Remove deprecated files related to homelab architecture, container context, and various scripts. This cleanup includes the removal of configuration files for Nextcloud, Gitea, and VPN setups, as well as documentation files that are no longer relevant. This helps streamline the project and eliminate outdated references.

2026-02-25 17:03:10 +03:00

23 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: 7 daily, 4 weekly, 6 monthly.

Вариант A (альтернатива): Отдельный диск/раздел на том же хосте — у тебя это sdb1.
Вариант B: Сетевое хранилище (NFS/SMB) — не используется в текущей схеме.
Вариант C: Внешний USB — опционально для 3-2-1 (см. ниже).

3-2-1: Три копии: (1) прод — система и данные на основном диске; (2) локальный бэкап — sdb1; (3) офсайт — Yandex. Два типа носителей: локальный SSD и облачное object storage. Один офсайт — да. Стратегия удовлетворяет 3-2-1. Опционально: четвёртая копия на внешнем USB/другом ПК для параноидального сценария (пожар/кража) — по желанию.

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

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

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

В веб-интерфейсе: 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 (backup-etc-pve.sh)
├── restic/
│   ├── local/         ← репозитории restic для локальных снапшотов (опционально)
│   └── ...            ← или restic только в Yandex, локально только сырые копии
├── photos/            ← Immich: оригиналы фото + метаданные + БД (остальное пересчитать)
├── vps/               ← Amnezia: конфиг. Миран: БД бота (+ контент при необходимости; основной контент можно в S3 Мирана)
└── other/             ← прочие важные данные (конфиги, скрипты, что ещё решите)

Квоты: при необходимости ограничить размер по каталогам (например proxmox/dump — не более 500 ГБ) через отдельные подразделы или скрипты очистки (retention).

Шифрование диска бэкапов (LUKS)

LUKS (Linux Unified Key Setup) — стандартное шифрование раздела в Linux. Если диск с бэкапами украдут или вынесут, без пароля/ключа данные не прочитать. Минусы: нужно вводить пароль при загрузке (или хранить ключ на другом носителе), небольшая нагрузка на CPU.

Принято: LUKS пока не используем. Раздел sdb1 — без шифрования. При необходимости можно добавить позже (потребуется перенос данных).

Restic и Yandex Object Storage

Restic поддерживает бэкенд S3. Yandex Object Storage совместим с S3 API — используешь endpoint бакета и ключи (Access Key / Secret).
Retention в Yandex: 7 daily, 4 weekly, 6 monthly — restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 и затем prune.
Что гнать в Yandex через restic: Proxmox dump (каталог proxmox/dump), /etc/pve (архивы из proxmox/etc-pve), фотки (оригиналы + метаданные + БД Immich), бэкапы с VPS — см. «Принятые решения: что куда» ниже.

Локально отдельной политики retention для restic не нужно: на sdb1 retention задаётся в самом Proxmox Backup Job (например «keep last 7») и в скрипте бэкапа /etc/pve (удалять архивы старше N дней). Restic используется только для отправки в Yandex с политикой 7/4/6. Локальных restic-репозиториев можно не заводить — только каталоги и выгрузка их содержимого в облако.

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

Хранилище паролей (варианты)

Чтобы не терять пароли при восстановлении и держать креды в одном месте:

Вариант	Плюсы	Минусы
Vaultwarden (self-hosted, Bitwarden-совместимый)	Один сервер в твоём контуре (например CT 100 или отдельный LXC), клиенты Bitwarden на ПК/телефоне, бесплатно	Нужен HTTPS (NPM уже есть), бэкап базы Vaultwarden — в общий план бэкапов
Bitwarden Cloud (официальный облачный)	Не нужно поднимать сервер, синхронизация везде	Платно (или ограничения бесплатного), данные у третьей стороны
KeePass / KeePassXC (файл .kdbx)	Локально, один зашифрованный файл; можно положить в бэкап (restic/local) и открывать с любого ПК	Нет удобной синхронизации на телефон из коробки (нужен общий файл через Nextcloud/флешку)
1Password / др. облачные менеджеры	Удобно, кросс-девайс	Платно, данные у провайдера

Принято: Развернуть Vaultwarden на контейнере 107 или 103 (не на 100). Домен через NPM, бэкап данных Vaultwarden включить в то, что уходит в restic → Yandex.

Где запускать бэкапы (централизация)

С хоста Proxmox (cron на ноде):

Proxmox Backup Job уже выполняется на хосте и пишет vzdump всех выбранных LXC/VM в /mnt/backup/proxmox/dump — это и есть «бэкапы всех контейнеров и ВМ», централизованно.
Restic (backup/forget/prune) тоже запускаем с хоста по cron: бэкапит каталоги на хосте (например весь /mnt/backup или выбранные подкаталоги) в Yandex S3. Данные для бэкапа — локальные пути (dump, etc-pve, а фотки и данные с VPS нужно либо копировать на хост в /mnt/backup скриптами, либо монтировать и тогда restic будет их читать с хоста). Контейнеры и ВМ целиком не бэкапим через restic — ими занимается только Proxmox Backup Job.

Шаг 3. Настроить расписание бэкапа LXC и VM

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 (Immich с БД) можно оставить Snapshot, при необходимости позже добавить отдельный консистентный бэкап БД изнутри гостя.
- Compression: ZSTD (хороший компромисс скорость/размер).
- Retention: например «Keep last 7» или «Keep last 4 weekly» — чтобы не забивать диск.
Сохранить job. Проверить по кнопке Backup now, что задача запускается и файлы появляются в Storage.

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

Шаг 4. Бэкап /etc/pve

Конфиги кластера и виртуалок лежат в /etc/pve. Их нужно копировать регулярно и хранить в безопасном месте (желательно не только на том же диске, что и система).

Вариант 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
# опционально: удалять бэкапы старше N дней
# find "$BACKUP_ROOT" -name 'etc-pve-*.tar.gz' -mtime +30 -delete

Сделать исполняемым: chmod +x /root/scripts/backup-etc-pve.sh.
Добавить в cron: crontab -e, например раз в день после основного backup job: 0 3 * * * /root/scripts/backup-etc-pve.sh

Вариант B: Тот же скрипт можно вызывать из задачи в Proxmox (Script/Command в задаче типа Hook script), но проще и надёжнее — отдельный cron на хосте.

Бэкапы /etc/pve хранить локально (/mnt/backup/proxmox/etc-pve) и в Yandex — включить этот каталог в источники restic (мало весит, критично при потере хоста). Файлы с ограниченными правами (chmod 600); /etc/pve содержит секреты — не выкладывать в открытый доступ.

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

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

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

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

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

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

Выбрать некритичный контейнер (например 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).
В Proxmox добавлен Storage для VZDump → /mnt/backup/proxmox/dump.
Настроена регулярная задача Backup: все LXC (100–108) и VM (200), расписание (например ночь), retention.
Проверен ручной запуск Backup now — файлы появляются в storage.
Настроен бэкап /etc/pve (скрипт + cron) → /mnt/backup/proxmox/etc-pve.
Restic: cron на хосте, выгрузка нужных каталогов из /mnt/backup в Yandex S3, retention 7/4/6.
Yandex: ключи и endpoint зафиксированы, restic успешно пишет в бакет.
Vaultwarden развёрнут (CT 107 или 103), секреты перенесены, бэкап данных Vaultwarden входит в restic.
Выполнено тестовое восстановление одного контейнера (другой VMID), проверена работоспособность.
В документации зафиксирована процедура полного восстановления Proxmox «с нуля».

Ссылки

Архитектура и подключение — хосты, 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	Локально и в Yandex (через restic).
Пароли	Vaultwarden на CT 107 или 103.
Yandex	Бакет создан; ключи и endpoint зафиксировать при настройке restic.
MinIO	Не используем; директории + restic (s3 для Yandex).

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

Yandex: подготовить Static Key (Access Key + Secret), записать endpoint и имя бакета — понадобятся для настройки restic.

23 KiB Raw Blame History Unescape Escape