Лучший способ предотвратить заполнение корневой системы при сбое монтирования?

У нас есть внутренний веб-сервер (виртуализированный, на котором размещается ReviewBoard, но не супер релевантный), и у нас есть относительно непротиворечивый режим сбоя с неудачными монтировками NFS, вызывающими / заполняющими Distro - это Ubuntu (не спрашивайте), если решение зависит от другого дистрибутива, его реализация будет медленнее.

Резервное копирование выполняется в / mnt / backup /, который должен быть подключен по NFS к другой системе. К сожалению, когда монтирование завершается неудачно или прекращается, резервное копирование выполняется в корневой файловой системе, что, как вы можете себе представить, не займет много времени, прежде чем / будет заполнено, а затем службы начнут отказывать.

Обсуждается ряд возможных решений.

1. Контролируйте / mnt / резервные копии и убедитесь, что это не root. Возможно, постоянная работа.

2. Используйте / mnt / protected / backups и сначала монтируйте / protected в небольшую файловую систему, возможно, монтируйте цикл в локальный файл, так что вероятность его сбоя значительно ниже.

3. Chmod a-rwx / mnt / backups (точка монтирования корневой файловой системы). Я не уверен, будет ли работать монтирование поверх защищенного директора, я думаю, что это работает.

4. В смонтированном дереве создайте каталог с именем «Резервные копии», а затем программную ссылку «ln - s / mnt / backup / Backups / Backups». Использование / Резервное копирование для резервного копирования завершится неудачей, если не смонтирована / mnt / backup, поскольку локальное дерево не содержит подкаталог.

5. Выполнение проверки правильности подключения каталога в сценарии резервного копирования.

Мне интересны любые отзывы об этих подходах, плюсах и минусах или любых дополнительных методах, которые люди используют в качестве стандартного способа защиты корневой файловой системы от этого вида злобности.

Номер 5 - Поставьте тест в свой скрипт резервного копирования, чтобы убедиться, что каталог подключен, прежде чем продолжить. Сценарий должен завершиться ошибкой, если монтирование недоступно или отсутствует. Или вы можете просто убедиться, что все смонтировано до запуска резервного копирования.

Попробуйте mountpointкоманду, которая проверяет, является ли указанный каталог точкой монтирования:

mountpoint -q /mnt/backups || mount /mnt/backups

Самое надежное решение - сделать точку монтирования недоступной для записи. Это было бы вашим решением № 3. Однако есть еще один шаг, который вы должны выполнить. chattr +i /mnt/backups, Это связано с тем, что даже без каких-либо разрешений root по-прежнему сможет писать в каталог. С chattr +i(устанавливает неизменный флаг) даже root не может писать в него. Когда монтируется монтирование, разрешения не имеют значения, так как разрешения будут иметь удаленный каталог, а не локальный.

Что сказал. Кроме того, дополнительный мониторинг состояния базовой системы не будет плохой идеей.

Что-то вроде Monit может проверить, сколько места осталось . Если вы хотите получить полный контроль над системным мониторингом, вы можете взглянуть на Nagios, но Monit легок и сделает основы.

Поскольку вы используете Ubuntu, Monit уже находится в репозитории, поэтому вы можете выполнить команду «sudo apt-get install monit», а затем начать просматривать файлы конфигурации, чтобы сказать, как отправлять оповещения в нужное место, отслеживать нужные службы и т. Д. Вот краткое руководство .

Вот одна строка, которую вы можете запустить как задание cron, предполагается, что это монтирование в fstab:

if mountpoint -q /mnt ; then : ; else mount /mnt ; fi

Для более долгосрочного решения: не уверен, как это сделать в Ubuntu (я RH-ориентирован) или стоит (если у вас всего одна машина), но методология, которая работала для нас МНОГИЕ годы, заключается в создании отдельной логической тома, файловые системы и даже группы томов на серверах. Поэтому в качестве стандартной практики мы создаем логические тома LVM для /, / tmp. / usr, / usr / local, / opt, / home, / var, пространство подкачки и отдельный раздел для / boot. Такой подход делает файловые системы более сложными для заполнения и отключения системы. На самом деле этот подход сделает практически невозможным заполнение / файловой системы. Вы все еще должны смотреть / TMP, / Var, конечно. Если нам нужно разместить данные, мы создадим для них совершенно другую группу томов. У этого подхода есть и другие преимущества: расширять файловые системы по своему желанию, перемещать их, создавать новые и т. Д.