У нас есть внутренний веб-сервер (виртуализированный, с размещением ReviewBoard, но не очень актуальный), и у нас есть относительно постоянный режим сбоя с неудачным монтированием NFS, вызывающим заполнение /. Дистрибутив - это Ubuntu (не спрашивайте), если решение зависит от другого дистрибутива, его реализация будет медленнее.
Резервное копирование выполняется в / mnt / backup /, который предполагается монтировать по NFS в другую систему. К сожалению, когда монтирование не выполняется или прерывается, резервное копирование выполняется в корневой файловой системе, что, как вы понимаете, не занимает много времени, прежде чем / будет заполнено, а затем службы начинают отказывать.
Обсужден ряд возможных решений.
Следите за / mnt / backups и убедитесь, что это не root. Возможно, работа cron.
Используйте / mnt / protected / backups и сначала смонтируйте / protected в небольшой файловой системе, возможно, при помощи цикла монтирования в локальный файл, так что вероятность сбоя гораздо меньше.
Chmod a-rwx / mnt / backups (точка монтирования корневой файловой системы). Я не уверен, что установка поверх защищенного директора сработает, думаю, работает.
В смонтированном дереве создайте каталог с именем «Резервные копии», затем выберите программную ссылку «ln - s / mnt / backup / Backups / Backups». Использование / Backups для резервного копирования приведет к сбою, если / mnt / backup не смонтирован, поскольку локальное дерево не содержит подкаталог.
Выполнение проверки правильности подключения каталога в сценарии резервного копирования.
Мне интересны любые отзывы об этих подходах, плюсах и минусах или любых дополнительных методах, которые люди используют в качестве стандартного способа защиты корневой файловой системы от такого рода неприятностей.
Наиболее надежное решение - сделать точку монтирования недоступной для записи. Это будет ваше решение №3. Однако вам следует выполнить еще один дополнительный шаг. chattr +i /mnt/backups. Это связано с тем, что даже без разрешений root все равно сможет писать в каталог. С участием chattr +i (устанавливает неизменяемый флаг) даже root не может писать в него. После монтирования разрешения не имеют значения, поскольку разрешения будут относиться к удаленному каталогу, а не к локальному.
Номер 5 - Перед продолжением проверьте сценарий резервного копирования, чтобы убедиться, что каталог смонтирован. Сценарий должен завершиться ошибкой, если монтирование недоступно или отсутствует. Или вы можете просто убедиться, что все подключено, перед запуском резервного копирования.
Попробуйте mountpoint команда, которая проверяет, является ли указанный каталог точкой монтирования:
mountpoint -q /mnt/backups || mount /mnt/backups
Что сказал еуууай. Также неплохо было бы провести дополнительный мониторинг работоспособности базовой системы.
Что-то вроде Монита может проверьте, сколько места осталось. Если вы хотите полностью посвятить себя мониторингу системы, вы можете взглянуть на 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, конечно. Если нам нужно разместить данные, мы создаем для них совершенно другую группу томов. У этого подхода есть и другие преимущества: расширение файловых систем по желанию, их перемещение, создание новых и т. Д. И в качестве исторической заметки мы перенесли этот метод в Linux из ОС AIX еще в 1990-х годах!