zailon/Docs
0
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
084f1fd41b
Docs/docs/11-backup.md
Administrator 6733688c69 Update 3 files 
- /docs/10-security.md
- /docs/11-backup.md
- /docs/12-troubleshooting.md
2026-03-20 16:29:00 +05:00

11 KiB
Raw Blame History

11. Резервное копирование

Обзор

Резервное копирование критически важно для защиты данных и возможности восстановления после сбоев, ошибок или атак. На момент аудита (март 2026) централизованная система резервного копирования не настроена. В данном разделе описаны требования, предлагаемая стратегия и план внедрения.

Текущее состояние

  • Отсутствие регулярных бэкапов: Нет автоматизированного процесса резервного копирования конфигураций, баз данных и пользовательских данных.
  • Разрозненные данные: Данные хранятся на разных томах (RAID6, SSD) и в разных форматах (файлы, базы данных, Docker-тома).
  • Ручные копии: Возможно, эпизодически создавались копии вручную, но это не систематизировано.
  • Риски: Потеря данных при сбое RAID (хотя RAID6 защищает от отказа двух дисков, но не от случайного удаления, ошибок программ или вирусов), невозможность отката после неудачного обновления.

Цели

  1. Надёжность: Гарантированная возможность восстановления данных после любых инцидентов.
  2. Автоматизация: Регулярные бэкапы по расписанию без участия администратора.
  3. Целостность: Проверка создаваемых копий (тестирование восстановления).
  4. Безопасность: Шифрование бэкапов и хранение вне основной инфраструктуры.
  5. Минимизация потерь: RPO (Recovery Point Objective) – не более 24 часов; RTO (Recovery Time Objective) – не более 4 часов для критических сервисов.

Что нужно бэкапить

1. Конфигурации

  • Ansible: репозиторий с group_vars, ролями, плейбуками (включая зашифрованный vault.yml).
  • Nginx Proxy Manager: база данных SQLite (контейнер npm), сертификаты Let's Encrypt.
  • Системные конфигурации: /etc/ssh, /etc/network, /etc/samba, /etc/fstab, /etc/cron*.
  • Docker: docker-compose.yml всех сервисов, пользовательские тома.

2. Базы данных

  • PostgreSQL: Immich, BookStack, Nextcloud (внутри ВМ), GitLab, Grafana, Loki.
  • MySQL/MariaDB: Ampache, Flibusta, Mealie (SQLite, но можно и файл).
  • SQLite: Bitwarden, Mealie, BookStack (опционально), кастомные приложения.
  • Redis: Nextcloud, GitLab.

3. Пользовательские данные

  • Медиафайлы: /mnt/video/*, /mnt/audio/*, /mnt/books/* на хосте media.
  • Игры: /mnt/games/ на хосте games.
  • Фотографии: Immich (папка загрузок, библиотека) на photo.
  • Документы: BookStack, Nextcloud.
  • Торренты: qBittorrent (метаданные, настройки).

4. Виртуальные машины и LXC

  • Proxmox: конфигурации ВМ (файлы .conf), диски LVM-thin, шаблоны.

Стратегия резервного копирования

Рекомендуемый инструмент: Proxmox Backup Server (PBS)

  • Установить PBS на отдельную ВМ или физический хост (можно на том же сервере, но лучше выделенный).
  • Настроить хранилище (желательно на отдельном диске или NAS).
  • Использовать дедупликацию, сжатие, шифрование.
  • Настроить расписания бэкапов для каждой ВМ/LXC через Proxmox VE (интеграция с PBS).

Альтернатива (если PBS не используется)

  • Для LXC и ВМ: встроенные средства Proxmox (VZDump) с сохранением на NFS или SMB.
  • Для Docker-контейнеров: скрипты с docker exec дампов БД, архивация томов.
  • Для файлов: rsync или restic в cron.

План внедрения

Этап 1: Подготовка (1–2 дня)

  • Определить список всех ресурсов, подлежащих бэкапу (таблица выше).
  • Оценить объём данных: примерно (медиа ~8 ТБ, игры ~4 ТБ, фото ~200 ГБ, базы ~10 ГБ, конфиги ~1 ГБ).
  • Выбрать место для хранения бэкапов: внешний HDD (USB) + дополнительно облако (например, Backblaze B2) для критических данных.
  • Установить и настроить Proxmox Backup Server (можно в LXC на olimp или на отдельной машине).

Этап 2: Настройка бэкапов ВМ и LXC (2–3 дня)

  • В Proxmox VE добавить PBS как хранилище.
  • Создать расписания для каждой ВМ/LXC:
    • Критические (базы, GitLab, Nextcloud): ежедневно, хранить 7 дней, еженедельно 4 недели, ежемесячно 3 месяца.
    • Некритические (медиа, игры): еженедельно, хранить 4 недели.
  • Настроить уведомления об ошибках.

Этап 3: Бэкап данных вне Proxmox (2–3 дня)

  • Написать скрипты (на базе Ansible или shell) для:
    • Дампов баз данных PostgreSQL, MySQL, SQLite.
    • Копирования Docker-томов.
    • Синхронизации файловых данных (медиа, игры) с бэкап-хранилищем (можно через restic).
  • Запускать скрипты по расписанию (cron или systemd timer) до или после бэкапов ВМ.
  • Проверить, что бэкапы не дублируют данные (например, диски ВМ уже содержат часть файлов – можно исключить их из файлового бэкапа, если они уже входят в VZDump).

Этап 4: Тестирование восстановления (1 день)

  • Выполнить тестовое восстановление ВМ на изолированной среде (или с переименованием).
  • Проверить восстановление базы данных из дампа.
  • Восстановить несколько файлов из бэкапа.

Этап 5: Автоматизация и мониторинг (1 день)

  • Настроить алерты в Grafana на статус бэкапов (через API Proxmox или логи).
  • Добавить проверку успешности бэкапов в мониторинг.

Примеры команд

Бэкап базы данных PostgreSQL (например, Immich)

pg_dump -U immich -h localhost immich > /backup/immich_$(date +%Y%m%d).sql

Бэкап SQLite (Bitwarden)

sqlite3 /path/to/vaultwarden.db ".backup /backup/vaultwarden_$(date +%Y%m%d).db"

Бэкап Docker-томов (например, Jellyfin)

tar -czf /backup/jellyfin_config_$(date +%Y%m%d).tar.gz /opt/service/jellyfin/config

Синхронизация файлов с внешним хранилищем (restic)

restic -r /mnt/backup_drive/restic_repo backup /mnt/video /mnt/audio /mnt/books

Восстановление ВМ из бэкапа через PBS

  • В интерфейсе Proxmox: Datacenter → Storage → PBS → Backups → выбрать backup → Restore.

Проблемы и рекомендации

🔴 Отсутствие резервных копий

Проблема: Критическая уязвимость – потеря всех данных при сбое или ошибке. Решение: Немедленно начать внедрение системы бэкапов по плану выше. Минимально: запустить ручной бэкап критических данных (базы, конфиги) на внешний диск.

🟡 Большой объём медиа

Проблема: Медиафайлы (~8 ТБ) сложно бэкапить часто и хранить в нескольких местах. Решение:

  • Для медиа достаточно еженедельного бэкапа.
  • Использовать дедупликацию (PBS или restic).
  • Рассмотреть бэкап только метаданных (библиотеки Jellyfin, настройки), а сами файлы можно перекачать заново (но если они уникальны, то бэкапить полностью).

🟢 Шифрование бэкапов

Рекомендация: Все бэкапы, хранящиеся вне сервера (на внешних дисках, в облаке), шифровать. PBS поддерживает шифрование на стороне клиента.

🟢 Хранение копий вне сети

Рекомендация: Хранить как минимум одну копию бэкапов вне основной сети (например, внешний USB-диск, отключаемый после бэкапа, или облачное хранилище).

Связанные разделы: