Зачем я поднял свой NFS-сервер и как он упростил мне жизнь

Проблема разрозненных данных

У меня три сервера: Proxmox хост, VM 101 с веб-сайтами, VM 200 с OpenWRT. И на каждом свои файлы, свои бекапы, свои скрипты. Когда я захотел перенести бекап базы с VM 101 на Proxmox, пришлось гонять через scp, вводить пароли, проверять, доехало ли. Отвратительно.

Решение: общая файловая папка, доступная всем серверам по сети. Выбрал NFS — потому что это стандарт для Linux, не нужно ставить дополнительный софт.

Настройка

На Proxmox хосте (у него больше всего дискового пространства) я создал папку /nfs/share, расшарил через exports:

echo "/nfs/share 192.168.0.0/24(rw,sync,no_subtree_check)" >> /etc/exports
exportfs -a

На VM 101 смонтировал:

mount -t nfs 192.168.0.196:/nfs/share /mnt/backup

Добавил в fstab, чтобы монтировалось при загрузке. Всё, теперь бекап базы пишу прямиком на общую папку, а Proxmox оттуда забирает.

Где пригодилось

Бекапы баз данных. Каждую ночь cron скрипт делает дамп MySQL на NFS. Утром Proxmox Backup Server забирает эти дампы. Если что-то идёт не так — все данные в одном месте, не надо искать по разным серверам.

Логи. Я настроил rsyslog на всех VM так, чтобы логи писались сразу на NFS. Теперь я могу смотреть логи всех серверов из одной папки. tail -f на хосте — и вижу, что происходит на всех VM.

ISO образы. Храню установочные образы Ubuntu, Alpine, GParted на NFS. Не надо каждый раз качать заново.

Что может пойти не так

Скорость. По гигабитной сети NFS работает достаточно быстро для бекапов, но для баз данных, которые пишут каждую секунду — тормозит. Для продакшн баз такое не годится.

Если NFS сервер лёг — все VM теряют доступ к своим бекапам. Я решил это дублированием критичных бекапов на локальный диск каждой VM.

Права доступа. На NFS пользователи маппятся по UID. Если на хосте uid 1000 это root, а на VM uid 1000 это www-data — будут коллизии. Пришлось унифицировать UID на всех машинах или использовать опцию anonuid в exports.

Итог

NFS — это просто и удобно. Поднять за 10 минут, а пользу даёт колоссальную. Бекапы, логи, общие файлы — всё в одном месте.

Зачем мне вообще понадобился NFS

У меня три сервера дома: один крутит сайты, второй — базы данных, третий — файлопомойка для бекапов. Каждый раз, когда надо было перенести файл с одного на другой, я использовал scp. Это работало, но жутко бесило: надо помнить IP, пути, пароли. А если файлов много — rsync.

Решение — общая файловая система. NFS (Network File System) позволяет примонтировать папку с одного сервера на другой так, будто она локальная. Настроил раз — и забыл.

Как я настраивал

На сервере-хранилище (назовём его NAS) я установил nfs-kernel-server, создал папку /srv/nfs и добавил её в экспорт. В /etc/exports прописал строку: /srv/nfs 192.168.0.0/24(rw,sync,no_subtree_check). Перезапустил сервис и всё.

На клиентах установил nfs-common, создал точку монтирования /mnt/nfs и выполнил mount -t nfs 192.168.0.50:/srv/nfs /mnt/nfs. Теперь на каждом сервере есть общая папка. Кидаю туда бекапы, скрипты, обновления — доступно отовсюду.

Грабли

Первые — права доступа. NFS использует UID/GID. Если на серверах разные пользователи с одинаковыми UID — файлы видны всем. Пришлось синхронизировать пользователей через LDAP. Пока возился, пару раз случайно затирал чужие файлы.

Вторые — скорость. По гигабитной сети NFS работает быстро, но если кто-то качает торрент — задержки растут. Я выделил для NFS отдельную подсеть и настроил QoS на роутере.

Третьи — безопасность. NFS — не шифрованный протокол. Я ограничил доступ по IP (только локальная сеть) и не пробрасываю наружу. Для дополнительной защиты можно использовать Kerberos, но для дома это перебор.

Теперь у меня общая папка для всех серверов. Бекапы складываются автоматически, скрипты синхронизируются, обновления распространяются через NFS. В итоге сэкономил кучу времени и нервов.

Расскажу подробнее, зачем мне понадобился собственный NFS-сервер и как он преобразил мою домашнюю инфраструктуру. Всё началось с проблемы разрозненных данных. У меня три сервера: Proxmox хост, VM 101 с веб-сайтами, VM 200 с OpenWRT. И на каждом свои файлы, свои бекапы, свои скрипты. Когда я захотел перенести бекап базы с VM 101 на Proxmox, пришлось гонять через scp, вводить пароли, проверять, доехало ли. Отвратительно. Каждая передача файла превращалась в маленький квест: вспомнить IP, путь, пароль, дождаться окончания копирования. А если файлов много — вообще боль.

Решение напрашивалось само собой: общая файловая папка, доступная всем серверам по сети. Выбрал NFS — потому что это стандарт для Linux, не нужно ставить дополнительный софт на клиенты. NFS (Network File System) позволяет примонтировать папку с одного сервера на другой так, будто она локальная. Настроил раз — и забыл. Для Linux это нативный протокол, он встроен в ядро, работает быстро и стабильно. Альтернативы вроде Samba тоже хороши, но для сервера-на-сервер — именно Linux — NFS самый естественный выбор.

Настройка. На Proxmox хосте (у него больше всего дискового пространства) я создал папку /nfs/share, расшарил через exports: echo «/nfs/share 192.168.0.0/24(rw,sync,no_subtree_check)» >> /etc/exports, затем exportfs -a. Эти опции важны: rw — чтение и запись, sync — синхронная запись (без потери данных при сбое), no_subtree_check — ускорение выдачи прав. На VM 101 смонтировал: mount -t nfs 192.168.0.196:/nfs/share /mnt/backup. Добавил в fstab, чтобы монтировалось при загрузке. Всё, теперь бекап базы пишу прямиком на общую папку, а Proxmox оттуда забирает. Настройка заняла от силы десять минут, а пользу приносит постоянно.

Где пригодилось — бекапы баз данных. Каждую ночь cron скрипт делает дамп MySQL на NFS. Утром Proxmox Backup Server забирает эти дампы. Если что-то идёт не так — все данные в одном месте, не надо искать по разным серверам. Это ключевое преимущество: централизованное хранение бекапов. Раньше каждый бекап лежал на своей VM, и при сбое я должен был помнить, где что. Теперь всё в одном месте, на самом мощном дисковом массиве хоста. Резервные копии под защитой рейда и регулярных внешних дампов.

Логи. Я настроил rsyslog на всех VM так, чтобы логи писались сразу на NFS. Теперь я могу смотреть логи всех серверов из одной папки. tail -f на хосте — и вижу, что происходит на всех VM. Это невероятно удобно для диагностики: вместо того чтобы заходить на каждую машину по SSH и смотреть её логи отдельно, я открываю одну папку. Если что-то странное происходит в 3 часа ночи на какой-то из VM — я вижу это из единой точки. Централизация логов на порядок ускоряет поиск причин проблем.

ISO образы. Храню установочные образы Ubuntu, Alpine, GParted на NFS. Не надо каждый раз качать заново. Это мелочь, но экономит трафик и время: образ Linux весит гигабайты, а переустановка VM — рутинная операция. Скачал раз — используешь для любых новых машин. Плюс скрипты и обновления я тоже распространяю через NFS: положил файл в общую папку — он доступен всем серверам. Такая мелочь экономит кучу времени в повседневной работе.

Что может пойти не так — скорость. По гигабитной сети NFS работает достаточно быстро для бекапов, но для баз данных, которые пишут каждую секунду — тормозит. Для продакшн баз такое не годится. Это важное ограничение: NFS отлично подходит для бекапов, логов и файлов, но не для горячих данных с высоким IOPS. Решение для продакшн баз — быстрые локальные диски. NFS — это про удобство хранения и доступности, а не про максимальную производительность. Держите это в голове при проектировании.

Отказоустойчивость. Если NFS сервер лёг — все VM теряют доступ к своим бекапам. Это одиночная точка отказа. Я решил это дублированием критичных бекапов на локальный диск каждой VM. То есть половина бекапов пишется на NFS, половина остаётся локально. Если NFS лежит — локальные копии спасают. Для особо критичных данных я делаю двойную запись. Мониторинг NFS тоже важен: я настроил проверку доступности общей папки и уведомление в Telegram, если монтирование слетело. Проактивность вместо паники.

Права доступа. На NFS пользователи маппятся по UID. Если на хосте uid 1000 это root, а на VM uid 1000 это www-data — будут коллизии. Пришлось унифицировать UID на всех машинах или использовать опцию anonuid в exports. Это классика NFS-граблей: несовпадение UID приводит к тому, что файлы «принадлежат» не тому пользователю. Пока возился, пару раз случайно затирал чужие файлы. Обидно терять данные из-за несостыковки номеров UID. Унификация пользователей через LDAP решила проблему навсегда. Ну, почти.

Безопасность. NFS — не шифрованный протокол. Я ограничил доступ по IP (только локальная сеть) и не пробрасываю наружу. Дома эта мера достаточна: злоумышленник всё равно должен попасть в локальную сеть. Для дополнительной защиты можно использовать Kerberos, но для дома это перебор. Если бы я поднимал NFS в облаке или для компании — Kerberos обязателен. А дома главное правило: NFS должен смотреть только внутрь доверенной сети. Я разделил сети: общая, где всё кушает интернет, и серверная подсеть с NFS. QoS на роутере выделил приоритет NFS-трафику.

Грабли с задержками. По гигабитной сети NFS работает быстро, но если кто-то качает торрент — задержки растут. Сетевой трафик без приоритизации жрёт доступную полосу, и NFS-записи начинают тормозить. Я выделил для NFS отдельную подсеть и настроил QoS на роутере. Задержки исчезли. Если вы планируете NFS — сразу предусмотрите изоляцию трафика или приоритизацию. Гигабит — это предел одновременной работы нескольких интенсивных потребителей. Не полагайтесь на удачу, настройте QoS.

Итог. Теперь у меня общая папка для всех серверов. Бекапы складываются автоматически, скрипты синхронизируются, обновления распространяются через NFS. В итоге сэкономил кучу времени и нервов. NFS — это просто и удобно. Поднять за 10 минут, а пользу даёт колоссальную. Бекапы, логи, общие файлы — всё в одном месте. Если у вас несколько серверов, между которыми регулярно мигрируют файлы — это первый инструмент, который стоит поднять. Он окупается в первый же день. А память о scp-марафонах, которые я гонял раньше, осталась лишь в моих заметках — как страшный сон.