Резервное копирование Proxmox на NAS: пошаговая настройка бэкапов

Почему резервное копирование Proxmox на NAS обязательно, а не опционально

Поднял Proxmox, накатил пяток VM, всё крутится. Бэкапы складываются туда же, на локальный диск ноды, в /var/lib/vz/dump. Диск умирает, и вместе с ним умирают и виртуалки, и их резервные копии. Знакомая ситуация?

Резервное копирование Proxmox на NAS решает именно эту проблему: копии данных живут физически на другом устройстве, с другим контроллером, часто в другой части стойки или даже здания. Если сервер с Proxmox сгорает, NAS остаётся живым, и восстановление занимает часы, а не недели поиска работы с восстановлением данных.

В этой связке ты получишь настроенное NFS хранилище на стороне Proxmox, backup job с расписанием и политикой хранения копий, и рабочую процедуру проверки, что бэкап реально долетел до NAS, а не просто «запустился без ошибок» в интерфейсе. Дальше по тексту разберём причины провалов такой схемы, пошаговый рецепт настройки с командами и таблицами, и раздел проверки, чтобы не гадать, работает оно или нет.

Время на всё, включая настройку NAS со стороны NFS экспорта, уйдёт от 30 минут для домашней лаборатории до пары часов для продакшн кластера с несколькими нодами и настройкой firewall правил под NFS трафик.

Причины, по которым бэкап Proxmox на NAS ломается ещё на этапе настройки

NFS хранилище выглядит простым: указал IP, указал путь, готово. На практике ломается на паре десятков нюансов, и часть из них всплывает только через неделю, когда бэкап job тихо перестаёт писать новые копии.

Большинство этих причин лечится на этапе настройки, если пройти рецепт по порядку и не пропускать шаг проверки после каждого действия. Пропущенный showmount -e с NAS перед добавлением storage в Proxmox экономит десять минут сейчас и убивает час на диагностику потом.

Рецепт: как подключить NAS к Proxmox для бэкапов через NFS

Подготовка: что нужно до начала настройки

Прежде чем лезть в Datacenter → Storage, закрой три вопроса. Первый: NAS уже поднят, NFS сервер на нём включён, шара создана. Второй: у тебя есть root доступ к Proxmox по SSH. Третий: сеть между нодой и NAS не через Wi-Fi мост и не через свитч на 100 Mbit, иначе бэкап 500 GB VM будет идти всю ночь.

Если NAS и Proxmox сидят в одном VLAN без внешнего доступа, портами можно не заниматься вообще. Но если между ними роутер с ACL, открой 2049 в обе стороны и не забудь про 111, если NAS всё ещё держит NFSv3 для совместимости со старыми клиентами.

Шаг 1. Настрой NFS экспорт на стороне NAS

Прежде чем Proxmox сможет что-то монтировать, NAS должен отдавать шару. Логика одинаковая для Synology, TrueNAS и QNAP: создаёшь папку под бэкапы, включаешь NFS сервис, разрешаешь доступ конкретному IP ноды Proxmox, а не всей подсети.

Для TrueNAS SCALE и любого Linux NAS с NFS сервером конфиг экспорта выглядит так:

/mnt/tank/proxmox-backup 192.168.1.50(rw,sync,no_subtree_check,no_root_squash)

Здесь 192.168.1.50 это IP ноды Proxmox. no_root_squash нужен, потому что vzdump пишет файлы от root, и без этой опции NAS подменит root на nobody, а запись упадёт с ошибкой доступа. Для нескольких нод перечисли их через пробел или используй CIDR подсети, если нод больше пяти.

После правки /etc/exports на самодельном NAS применяй изменения:

exportfs -ra
exportfs -v

Результат: вторая команда должна показать строку с путём экспорта и указанным IP или подсетью в скобках. Если строки нет, значит exports не применился, проверь синтаксис файла.

Шаг 2. Проверь доступность NFS экспорта с ноды Proxmox

Не добавляй storage в Proxmox вслепую. Сначала убедись, что NFS экспорт вообще виден с ноды.

showmount -e 192.168.1.100

Результат: команда должна вернуть список экспортов, включая /mnt/tank/proxmox-backup или аналогичный путь. Если получаешь «RPC: Program not registered» или таймаут, проблема на стороне NAS: либо NFS сервис выключен, либо firewall NAS режет порт 111 или 2049.

Если showmount недоступен на самой ноде, установи пакет с утилитами NFS клиента:

apt update
apt install -y nfs-common

Шаг 3. Добавь NFS хранилище в Proxmox через веб интерфейс

Заходи в Datacenter → Storage → Add → NFS. Заполняешь пять полей: ID (произвольное имя, например backup-nas), Server (IP или hostname NAS), Export (путь, который вернул showmount), Content (обязательно отметь Backup, остальные типы контента для этой задачи не нужны), Nodes (можно оставить «All» для кластера или выбрать конкретную ноду).

После сохранения Proxmox сам смонтирует NFS в /mnt/pve/backup-nas. Руками монтировать ничего не придётся, за это отвечают systemd юниты автоматически.

Тот же результат через CLI, если предпочитаешь командную строку или настраиваешь несколько нод скриптом:

pvesm add nfs backup-nas --server 192.168.1.100 --export /mnt/tank/proxmox-backup --content backup --options vers=4.1

Результат: команда без вывода означает успех. Проверить можно сразу следующей командой из раздела проверки ниже.

Шаг 4. Создай Backup Job с расписанием и retention

Хранилище подключено, но само по себе оно ничего не бэкапит. Нужен job с расписанием. Заходи в Datacenter → Backup → Add.

Выбираешь Node (или All), Storage (тот самый backup-nas), Selection mode (All для всех VM/CT на ноде или конкретные VMID), Schedule (например каждый день в 02:00), Mode (Snapshot для минимального простоя VM, Stop только если приложение внутри не переживает snapshot-режим).

Retention настраивай сразу, иначе NAS через месяц забьётся под завязку старыми копиями:

keep-last=3
keep-daily=7
keep-weekly=4
keep-monthly=6

Это значит: 3 последних бэкапа хранятся всегда, плюс 7 ежедневных, 4 еженедельных и 6 ежемесячных снимков с прореживанием старых. Ротацию Proxmox делает автоматически при каждом запуске job, вручную чистить дамп-папку на NAS не придётся.

Шаг 5. Запусти первый бэкап вручную и не жди утра

Не полагайся на расписание для первой проверки. Запусти vzdump руками прямо сейчас, пока ты у консоли и готов разбирать ошибку по горячим следам.

vzdump 100 --storage backup-nas --mode snapshot --compress zstd

Замени 100 на реальный VMID своей VM или контейнера. Флаг —compress zstd даёт лучший баланс скорости и размера по сравнению с gzip или lzo для большинства задач.

Результат: в консоли пойдёт лог с прогрессом, в конце строка вида «INFO: Finished Backup of VM 100 (00:03:12)». Файл появится в /mnt/pve/backup-nas/dump/ с именем vzdump-qemu-100-дата.vma.zst или аналогичным для LXC.

Безопасность на этапе настройки NFS хранилища

NFS трафик по умолчанию не шифруется, и это осознанный компромисс скорости ради простоты. Для бэкап-сети внутри доверенного периметра это приемлемо, но пару вещей закрыть стоит сразу, а не после инцидента.

• Ограничивай экспорт на NAS конкретным IP ноды Proxmox, а не подсетью /24 целиком, иначе любой хост в сети сможет читать и писать в бэкап-папку.
• Держи NFS трафик в отдельном VLAN, изолированном от пользовательского сегмента сети, особенно если бэкапятся VM с базами данных или персональными данными.
• На самой ноде Proxmox через встроенный firewall (Datacenter → Firewall) разреши исходящий трафик на 2049 порт только к IP NAS, остальное можно резать по умолчанию.
• Не используй no_root_squash шире, чем нужно: применяй его только для конкретного IP ноды в строке экспорта, а не глобально для всех клиентов NFS сервера.

Шифрование на лету для NFS теоретически возможно через Kerberos (sec=krb5p), но для домашней лаборатории и большинства SMB инсталляций это оверинжиниринг. Если данные критичные, проще гонять NFS трафик через отдельный физический сегмент или IPsec туннель между Proxmox и NAS.

Как проверить, что бэкап Proxmox на NAS реально работает

Зелёная галочка в интерфейсе Proxmox не гарантия, что файл физически долетел до диска NAS. Проверяй с обеих сторон.

Со стороны Proxmox смотри статус хранилища:

pvesm status

Результат: строка backup-nas должна показывать Status: active и корректные цифры Total/Used/Available, соответствующие реальному объёму NAS тома, а не нулевые значения.

Проверь, что монтирование реально висит в системе, а не просто числится в конфиге:

mount | grep pve
df -h /mnt/pve/backup-nas

Результат: mount должен вывести строку с типом nfs4 и адресом NAS, df покажет реальное занятое место, растущее после каждого бэкапа.

Список файлов бэкапа прямо в хранилище, без похода в веб интерфейс:

ls -lh /mnt/pve/backup-nas/dump/

Со стороны NAS зайди в файловый менеджер или через SSH проверь тот же путь /mnt/tank/proxmox-backup/dump/. Файл должен быть виден с той же датой изменения и тем же размером, что и на ноде Proxmox. Если на NAS файла нет, а на ноде он есть, значит монтирование NFS работает в кэшированном режиме и данные ещё не сброшены на диск, либо это два разных пути.

Последняя проверка, самая важная: журнал самой задачи бэкапа. В веб интерфейсе Proxmox открой Datacenter → Backup, выбери job, вкладка Log покажет полный вывод последнего запуска, включая точное время начала, окончания и итоговый статус OK или ERROR по каждой VM в задаче.

tail -n 50 /var/log/vzdump/qemu-100.log

Этот лог хранится локально на ноде Proxmox независимо от того, куда улетел сам файл бэкапа, и остаётся даже если NAS временно недоступен. Одна строка «ERROR: Backup of VM 100 failed» в этом файле стоит дороже часа разбора причин на утро после несостоявшегося бэкапа.

Осложнения: типичные ошибки NFS при бэкапе Proxmox на NAS

Настроил по рецепту выше, а vzdump всё равно падает. Ниже разбор ошибок, с которыми реально сталкиваешься в проде, а не в тепличной документации.

ip -4 addr show | grep inet

nc -zv 192.168.1.100 2049

exportfs -ra

pvesm set backup-nas --disable 0
umount -f /mnt/pve/backup-nas
pvesm status

pvesm status
proxmox-backup-client prune --help

umount -l /mnt/pve/backup-nas
mount /mnt/pve/backup-nas

pvesm set backup-nas --content backup

Если NAS древний и упорно не хочет отдавать v4.1, откатись явно на v3 в options хранилища, не жди, что Proxmox сам разберётся с деградацией версии за приемлемое время.

pvesm set backup-nas --options vers=3

После смены версии протокола хранилище нужно перемонтировать, иначе Proxmox продолжит использовать старое соединение до следующей перезагрузки или ручного umount.

Альтернативы NFS: SMB, Proxmox Backup Server и rsync для бэкапа на NAS

NFS не единственный способ подружить Proxmox и NAS. Есть ещё три рабочих варианта, и у каждого своя ниша.

SMB/CIFS вместо NFS для хранилища бэкапов

Proxmox умеет монтировать CIFS напрямую через веб интерфейс, без танцев с /etc/fstab. Для Synology это часто даже проще, чем NFS, потому что SMB там настроен из коробки и права управляются через штатные ACL DSM.

pvesm add cifs backup-smb --server 192.168.1.100 --share proxmox-backup --username backup-user --password 'секрет' --content backup

Минус SMB против NFS: чуть выше overhead протокола на мелких файлах и обязательная аутентификация по логину и паролю, которую нужно хранить в конфиге хранилища. Для бэкапов больших vma файлов разница в скорости на практике почти не заметна на гигабитной сети.

Proxmox Backup Server как замена связке vzdump плюс NFS

Если бэкапы Proxmox на NAS через vzdump уже настроены и работают, но retention и скорость начинают душить, следующий логичный шаг это отдельный Proxmox Backup Server. На момент публикации актуальна версия PBS 4.2, вышедшая как обновление ветки 4.x. Перед установкой проверь свежие релизы на официальной странице загрузок.

PBS даёт дедупликацию на уровне чанков, инкрементальные бэкапы после первого полного, встроенную верификацию контрольных сумм и восстановление отдельных файлов из образа диска без разворачивания всей VM. Разница принципиальная: NFS плюс vzdump просто складывает файлы на диск, PBS хранит данные в собственном datastore с индексацией.

Для домашней лаборатории и небольшой инфраструктуры до пяти VM связка NFS плюс vzdump закрывает задачу без лишней инфраструктуры. PBS оправдан, когда счёт VM идёт на десятки, а место на NAS начинает поджимать из за отсутствия дедупликации.

rsync и rclone как ручная альтернатива для сложных случаев

Если NAS не отдаёт нормально ни NFS, ни SMB, только объектное хранилище или облачный сервис, файлы дампов можно гонять скриптом через rsync или rclone по cron, без storage интеграции Proxmox. Это менее прозрачно с точки зрения статуса в интерфейсе Proxmox, зато работает почти с любым транспортом.

rsync -avz --delete /var/lib/vz/dump/ backup-user@nas:/volume1/proxmox-backup/dump/

Минус подхода: Proxmox не видит, что копия физически долетела до NAS, и не покажет это в своём статусе storage. Мониторить успешность такой синхронизации нужно отдельным скриптом или системой алертинга.

Профилактика: как не потерять бэкапы Proxmox после того как всё настроено

Что бэкапить, как часто и где хранить копии

Бэкапить нужно не только диски VM, но и конфиг самого Proxmox: /etc/pve, /etc/network/interfaces, список storage.cfg. Без этого восстановление кластера после полной потери ноды превращается в реконструкцию по памяти.

Правило 3 2 1 тут работает буквально: минимум три копии данных, на двух разных носителях, одна копия физически в другом месте. NAS в соседней стойке закрывает только два пункта из трёх. Третий требует облака или второй площадки.

Как восстановить VM из бэкапа на NAS

Восстановление проверяется не реже раза в квартал, иначе узнаёшь о битом архиве в момент реального инцидента, а не на спокойном тесте.

qmrestore /mnt/pve/backup-nas/dump/vzdump-qemu-100-2026_09_15-02_00_01.vma.zst 999 --storage local-lvm

Результат: команда развернёт бэкап в новую VM с VMID 999, чтобы не затирать оригинал 100. Проверь, что VM с новым ID стартует и грузится, потом удали тестовую VM.

Мониторинг статуса бэкапов и свободного места на NAS

Отдельная задача бэкапа без мониторинга это лотерея: работает, пока кто-то не забудет проверить логи. Настрой уведомления по e-mail в самом Backup Job (поле Notification), а для продакшна добавь внешний контроль через Zabbix или Grafana с алертом на свободное место NAS ниже 15%.

df -h /mnt/pve/backup-nas | awk 'NR==2{print $5}'

Заведи cron проверку раз в час, которая шлёт алерт, если процент занятого места превышает пороговое значение или если storage вдруг показывает Status: unknown в pvesm status.

Автозапуск монтирования после перезагрузки ноды

NFS хранилище, добавленное через Datacenter → Storage, монтируется автоматически при старте pve-cluster и pvestatd, отдельный fstab не нужен и даже вреден: два механизма монтирования начинают конфликтовать друг с другом. Проверь после перезагрузки ноды, что монтирование поднялось сразу, без ручного вмешательства.

systemctl status pvestatd
mount | grep backup-nas

Безопасное обновление Proxmox без потери доступа к NAS хранилищу

Перед обновлением Proxmox VE или NAS проверь совместимость версии протокола NFS: иногда обновление ядра меняет поведение клиента, и storage, который годами висел на vers=3, вдруг начинает мигать offline. Сделай снимок конфига storage.cfg перед обновлением.

cp /etc/pve/storage.cfg /root/storage.cfg.backup-$(date +%F)
apt update && apt list --upgradable

После обновления сразу проверь pvesm status и запусти тестовый vzdump на минимальную VM, прежде чем доверять расписанию всю ночь без присмотра. Если storage не поднялся, откати конфиг из сохранённой копии и перезапусти pvestatd.

cp /root/storage.cfg.backup-2026-09-19 /etc/pve/storage.cfg
systemctl restart pvestatd

Безопасность бэкап-инфраструктуры на постоянной основе

• Держи бэкап-сеть в отдельном VLAN и не открывай порт 2049 наружу дальше периметра доверенной сети.
• Ограничивай доступ к веб интерфейсу Proxmox через firewall или VPN, а не голым паролем в интернет.
• Ротацию SSH ключей для доступа к ноде делай регулярно, особенно если к серверу имеет доступ несколько инженеров.
• Шифруй критичные бэкапы отдельно, если NAS физически доступен посторонним, например стоит в удалённом офисе без охраны.
• Проверяй права на папку экспорта на NAS: 750 с владельцем backup-user достаточно, 777 это дырка, которую найдут не только твои сервисы.
• Веди журнал изменений в /etc/exports и storage.cfg через git или простой changelog файл, чтобы через полгода понимать, кто и почему поменял правило доступа.

Капля никотина убивает лошадь. Забытая строчка no_root_squash для всей подсети вместо одного IP убивает изоляцию всей бэкап-инфраструктуры сразу.

FAQ: частые вопросы про резервное копирование Proxmox на NAS

Почему резервное копирование Proxmox на NAS не работает после настройки?

Чаще всего причина в том, что storage смонтировался в момент настройки, но отвалился после перезагрузки NAS или ноды из-за stale file handle. Вторая частая причина: в Content для хранилища не отмечен тип Backup, и vzdump просто не видит storage в списке доступных при создании job. Проверяй pvesm status и содержимое /etc/pve/storage.cfg перед тем, как копать глубже.

Как проверить, что бэкап на NAS работает правильно?

Сверяй три источника одновременно: статус в pvesm status на ноде Proxmox, реальный файл в папке dump на самом NAS через файловый менеджер или SSH, и лог задачи в Datacenter → Backup → Log. Если все три источника показывают одинаковый файл с одинаковой датой и размером, бэкап реально долетел.

Что делать, если вылезает ошибка permission denied при бэкапе на NAS?

В девяти случаях из десяти это root_squash на стороне NAS, который подменяет root Proxmox на nobody без прав записи. Добавь no_root_squash в строку экспорта конкретно для IP ноды Proxmox, а не для всей подсети, и перечитай exports командой exportfs -ra.

Чем бэкап на NAS через NFS отличается от Proxmox Backup Server?

NFS плюс vzdump просто складывает полные файлы дампов на диск NAS без дедупликации и без инкрементальности. Proxmox Backup Server хранит данные в собственном datastore с дедупликацией на уровне чанков, поддержкой инкрементальных бэкапов и восстановлением отдельных файлов без разворачивания всего образа.

Как настроить NFS хранилище в Proxmox, если NAS не поддерживает NFSv4.1?

Явно укажи vers=3 в опциях хранилища через pvesm set или в веб интерфейсе. NFSv3 требует дополнительно открытого порта 111 для portmapper, не забудь про него на firewall NAS и на промежуточных роутерах.

Как сделать бэкап VM на Synology через Proxmox?

На Synology включи NFS сервис в Control Panel, создай Shared Folder под бэкапы, в её настройках NFS Permissions добавь правило с IP ноды Proxmox и опцией без Squash root as everyone для отдельного пользователя. Дальше действуй по тому же рецепту: showmount с ноды, добавление storage через Datacenter → Storage → Add → NFS, тестовый vzdump.

vzdump не видит NFS storage, что делать?

Проверь, что у хранилища в настройках Content отмечен тип Backup, а не только Images или ISO. Без этой галки Proxmox монтирует NFS, но полностью игнорирует его при выборе места назначения для job резервного копирования.

Прогноз: что теперь работает после настройки бэкапа Proxmox на NAS

После прохождения этого рецепта у тебя настроено NFS хранилище с проверенной доступностью, backup job с расписанием и retention, который сам чистит старые копии без ручного вмешательства, и рабочая процедура проверки, что файл бэкапа реально лежит на NAS, а не просто отметился зелёной галочкой в интерфейсе.

Дальше это процесс, а не разовая настройка на сегодня: раз в квартал тестовое восстановление, раз в месяц проверка свободного места на NAS, при каждом обновлении Proxmox сверка, что storage поднялся после перезапуска pvestatd. Именно эти три привычки отделяют инфраструктуру, где бэкап реально спасает при отказе диска, от инфраструктуры, где бэкап существует только в виде записи в конфиге.