@Phlogi: Вот как работает NFS. По умолчанию стоит опция hard с бесконечным ожиданием. В Proxmox это не проблема. Но да, думаю, было бы здорово добавить что-то, что сделает это за нас. Один из вариантов — использовать такой systemd-скрипт. Другой — задействовать встроенную NFS-опцию. Например:  
Код: cat storage.cfg

nfs: backup  
server backupserver.local  
path /mnt/pve/backup  
export /sicherung/vmbackup  
content backup  
options rw,sec=sys,noatime,vers=3,soft,timeo=10,retrans=5,actimeo=10,retry=5  
maxfiles 4  

Но лучшие результаты я получил с systemd-скриптом. У меня он есть на всех серверах, и работает отлично. Я также тестировал NFS-опцию в storage.cfg. Сначала кажется, что всё работает, но проблемы в том, что NFS-сервер слишком долго занят — из-за высокой нагрузки на диск или если используется Qnap, тогда резервное копирование может не пройти. Кстати, если отключаете NFS-хранилище, его тоже следует размонтировать. Ладно... немного ушёл в сторону...

@fireon: У меня такая же проблема с NFS-шарой на моём QNAP. Использую её для бэкапов VM и LXC. Я попробовал твой скрипт для systemdservice, но, честно говоря, я новичок в скриптах для Linux, поэтому любая помощь будет очень кстати. Я создал файл /etc/rc.local.shutdown, сделал его исполняемым, создал /etc/systemd/system/rc.local.shutdown.service и включил сервис. Может, я что-то упускаю или нужно сделать ещё что-то, чтобы скрипт заработал? Могу выложить точные команды из терминала, если это поможет.

На прошлой неделе я провёл кучу тестов и бенчмарков с NFS/SMB и разными настройками. Факт в том, что NFS в реальных условиях бекапов и хранения с опциями soft и timeout — просто нерабочий вариант. Если вы ставите таймауты, то в лучшем случае один бекап пройдёт нормально, но в реальной жизни с кучей виртуалок и множеством узлов кластера половина бекапов через cron vzdump улетает в пропасть. Я реально много тестировал.

1. Использование NFS. Проверьте ваше устройство для бекапов — оно должно работать безупречно. Если оно всегда доступно, проблем не будет. Не берите дешёвый QNAP, лучше купите маленький сервер, установите на него PVE и сделайте из него хранилище для бекапов. Мы так и делаем.

2. Если очень важно, чтобы PVE-хост ни разу не падал (скажем, раз в год) при запущенных бекапах и при одновременном падении устройства бекапов, то единственный вариант — использовать cifs/samba. Но будьте осторожны с вирусами по сети. Очень важно завести отдельного спецпользователя и ограничить IP. Либо/и настроить vlan ACL по Layer 3.

Разве не должна использоваться команда umount -lf для принудительного отмонтирования NFS-шары? fusermount же предназначена для точек монтирования FUSE, согласно man.

Что-то изменилось в версии 5.1? Скрипт от Fireon больше не работает. Когда пытаюсь вручную выполнить umount -lf /mnt/pve/* — ничего не происходит, так как я всё ещё могу получить доступ к NFS-шарам. Недавно столкнулся с этим, потому что подключил ИБП к серверу и настроил NUT для выключения сервера при низком уровне заряда ИБП, но система зависает, когда пытается отключить NFS-шары, которые уже не в сети (виртуальная машина на хосте или удалённые NFS-шары). У кого-то есть идеи?

Спасибо, fireon, что заглянул. Хочу добавить, что даже если я ввожу полный путь, например, /mnt/pve/Templates через ssh, это тоже не работает. Хотя я всё ещё могу просматривать все свои ISO и LXC Templates на своем NFS-сервере. Есть ли что-то, что блокирует точки монтирования?

Окей, теперь понятно, почему NFS-монтирование не отключается. Попробую это позже после работы. Есть ли способ выключить NFSMount через командную строку? Если да, то я мог бы сделать временное решение для моего скрипта UPS: сначала отключать NFSMount, потом размонтировать NFSshare и в конце выключать сервер.