Skip to main content

NAS для офисных бэкапов: рекомендации по архитектуре и настройке

Цель​

Организовать дополнительный слой резервного копирования в офисе:

  • production находится в облаке
  • офисный NAS хранит копии бэкапов, доставляемые через IPsec
  • в облаке уже есть snapshot’ы VM (второй слой)
  • в будущем возможна установка второго NAS

NAS используется только для бэкапов. Высокая производительность не требуется.

Рекомендуемая схема​

Компоненты​

  • NAS в офисе: storage для бэкапов
  • IPsec между офисом и облаком
  • Proxmox Backup Server (PBS) на отдельной машине (в офисе)
  • Proxmox VE (кластер) в облаке или в офисе (в зависимости от инфраструктуры)

Почему PBS отдельно​

PBS не должен жить на том же NAS, куда он пишет данные.

Отдельная машина под PBS устраняет циклические зависимости и повышает надёжность восстановления.

RAID / ZFS: выбор конфигурации​

Рекомендация: RAIDZ2 (эквивалент RAID6)​

Если используется ZFS (TrueNAS или другой ZFS-стек), для массива из 4 дисков рекомендуется:

  • RAIDZ2 (двойная четность)
  • выдерживает отказ 2 дисков

Причины выбора:

  • NAS хранит критичный слой резервных копий
  • в реальности диск может отказать во время ресильвера
  • для бэкапного сценария важнее устойчивость, чем максимальная ёмкость

RAIDZ1 допускается, но не рекомендуется​

RAIDZ1 (аналог RAID5) возможен, если:

  • NAS — не единственный слой бэкапов
  • приоритет — полезная ёмкость

Недостаток:

  • выдерживает только 1 отказ диска
  • выше риск потери массива при деградации и ресильвере

RAID10 не требуется​

RAID10 ориентирован на IOPS и предсказуемую производительность, что не является целью для бэкапного NAS.

Диски​

Требования​

  • использовать CMR-диски (не SMR)
  • желательно NAS/Enterprise линейки
  • одинаковый объём и по возможности одинаковые модели

Рекомендация по запасу​

  • иметь 1 запасной диск на полке
  • это снижает время работы массива в деградированном состоянии

Сеть​

Подключение​

  • NAS гигабитный, 2 порта, поддерживает LACP

Что даёт LACP​

  • не увеличивает скорость одного потока (одной копии)
  • увеличивает суммарную пропускную способность при нескольких параллельных клиентах

Для ежедневных бэкапов 1 GbE обычно достаточно.

Протоколы доступа (NAS как storage)​

Рекомендуемый вариант​

  • NFS (Linux ↔ Linux)
  • либо SMB (если удобнее)

Что не рекомендуется​

  • iSCSI LUN как хранилище для VM-дисков (если нет явной причины)
  • для бэкапов проще и безопаснее использовать файловую шару

Доставка бэкапов из облака в офис​

Так как production в облаке, а NAS в офисе, доставка идёт через IPsec.

Рекомендуемый способ: dump локально → rsync в NAS​

Алгоритм:

  1. на production (в облаке) создаётся дамп в локальную директорию (на диск VM)

  2. после успешного завершения дампа выполняется доставка в NAS:

    • rsync over SSH (предпочтительно)
    • либо копирование в NFS/SMB share

  3. после успешной доставки локальный дамп удаляется

Причины:

  • запись дампа напрямую в сетевую шару через туннель менее надёжна
  • при обрыве туннеля можно получить неполный или повреждённый файл
  • rsync обеспечивает корректное возобновление передачи и проверку

Альтернатива: dump в S3 → офис делает pull​

Если есть объектное хранилище:

  • production пишет дампы в S3
  • офисный сервер/PBS/NAS забирает данные по расписанию (pull)

Преимущество:

  • офис не зависит от стабильности туннеля в момент дампа
  • проще масштабировать и хранить промежуточные копии

Retention policy (рекомендуемая)​

Цель: хранить достаточно точек восстановления без чрезмерного расхода диска.

Базовая политика​

  • daily: 7 дней (каждый день за текущую неделю)
  • weekly: 8 недель (примерно 2 месяца)

Итого ~15 точек восстановления.

Рекомендация (опционально)​

Добавить:

  • monthly: 6–12 месяцев (1 точка в месяц)

Причина:

  • некоторые инциденты обнаруживаются поздно (тихая порча данных, ошибки пользователей, “долго живущие” проблемы)

Мониторинг​

Используется существующий стек:

  • Prometheus + Grafana
  • Vector (или эквивалент)

Что обязательно мониторить​

  • SMART:

    • reallocated sectors
    • pending sectors
    • UDMA CRC errors
    • температура дисков

  • состояние массива/пула

  • заполнение пула/тома

  • ошибки чтения/записи

ZFS maintenance (если используется ZFS)​

Scrub​

  • запуск scrub: 1 раз в месяц (или раз в 2–4 недели)

Свободное место​

  • держать свободными минимум 20% пула
  • рекомендуется 25–30%

Рекомендованная итоговая конфигурация​

  • NAS на 4 диска

  • 4× HDD CMR

  • RAIDZ2 (если ZFS) / RAID6-эквивалент (если встроенный RAID)

  • NAS как файловый storage (NFS/SMB)

  • PBS на отдельной машине

  • доставка дампов из облака: локальный dump → rsync/SSH → NAS

  • retention:

    • daily 7
    • weekly 8
    • optional monthly 6–12

  • мониторинг через существующий Prometheus + Grafana

Если хотите, я могу дополнить документ конкретными командами:

  • пример cron/скрипта для дампа PostgreSQL + rsync
  • пример структуры каталогов на NAS
  • пример retention в PBS и/или в bash-скриптах для дампов