Проверка диска данных перед запуском служб

Если диск данных не смонтировался, приложение не обязательно сразу сообщит об ошибке. Каталог /srv/data, предназначенный для монтирования, остаётся обычным каталогом на системном диске, и служба может продолжать записывать в него данные, пока на системном диске не закончится место. Когда монтирование будет восстановлено, эти файлы окажутся скрыты под смонтированной файловой системой. В результате появятся два набора данных, которые будет трудно различить. Поэтому перед вводом в эксплуатацию нужно проверять файловую систему, стоящую за путём, а не только наличие каталога.

1. Сначала определите диск данных и границы допустимых действий

В примерах используется Ubuntu Server 24.04 LTS и раздел данных с уже созданной файловой системой ext4. Создание разделов и форматирование не выполняются. Команды запускаются на сервере через SSH; реквизиты подключения CloudSFP доступны в панели управления после оплаты. Если указано несколько адресов, используйте первый.

В стандартную комплектацию входят два накопителя NVMe по 1 ТБ с прямым подключением каждого, без аппаратного RAID. Номер устройства не определяет, является ли диск системным или предназначенным для данных, и не позволяет судить о наличии избыточности. Если уже используется программный RAID или другой слой хранения, монтировать нужно файловую систему верхнего уровня, а не отдельный диск массива в обход этого слоя.

lsblk -o NAME,PATH,SIZE,TYPE,FSTYPE,UUID,MOUNTPOINTS
sudo blkid
findmnt -T /
findmnt -T /srv

Определите нужный раздел по совокупности признаков: ёмкости, типу файловой системы, текущим точкам монтирования и записям об установке. Зафиксируйте его UUID. UUID стабильнее имени, назначаемого устройству при обнаружении, но не гарантированно уникален: при клонировании файловой системы UUID тоже может быть скопирован. Если обнаружены дубликаты, сначала устраните конфликт идентификаторов и только затем вносите настройки запуска.

Описанные ниже изменения следует выполнить до начала использования диска данных в рабочих задачах. На сервере с уже работающими приложениями необходимо сначала остановить запись, проверить резервные копии и порядок восстановления. Нельзя размонтировать используемую файловую систему только ради проверки.

2. Выполните пробное монтирование, затем внесите запись в fstab

Создайте пустую точку монтирования и проверьте, нет ли в ней файлов, включая скрытые. Если каталог не пуст, сначала выясните происхождение его содержимого. Ничего не удаляйте и не перезаписывайте.

sudo mkdir -p /srv/data
sudo find /srv/data -mindepth 1 -maxdepth 1 -print
read -r -p 'Filesystem UUID: ' DATA_UUID
sudo blkid -U "$DATA_UUID"
sudo mount -t ext4 -o ro "UUID=$DATA_UUID" /srv/data
findmnt -M /srv/data -o TARGET,SOURCE,FSTYPE,OPTIONS,UUID

Продолжайте монтирование только после того, как вывод blkid совпадёт с зафиксированными сведениями о диске. Первое монтирование в режиме только для чтения предназначено для проверки содержимого, а не для восстановления повреждённой файловой системы. Здесь findmnt -M проверяет точную точку монтирования. В отличие от него, findmnt -T находит файловую систему, содержащую указанный путь: если диск данных не смонтирован, команда может вернуть корневую файловую систему. Поэтому один лишь успешный код завершения этой команды не подтверждает правильность монтирования.

Проверив источник и содержимое, размонтируйте файловую систему, подключённую только для чтения. Создайте резервную копию /etc/fstab, затем отредактируйте файл. Не добавляйте повторные записи для одной и той же точки монтирования. UUID в примере необходимо заменить фактическим значением, проверенным на предыдущем шаге:

UUID=<已核对的文件系统UUID> /srv/data ext4 defaults,nofail,x-systemd.device-timeout=15s 0 2

Эта запись позволяет системе продолжить загрузку при отсутствии диска. Предельное время ожидания устройства в этом примере — 15 секунд; это не обещание срока предоставления сервера или восстановления. Если при отсутствии диска требуется блокировать загрузку системы, нужно отдельно разработать соответствующую стратегию, а не копировать настройку nofail.

sudo umount /srv/data
sudo cp -a /etc/fstab /etc/fstab.before-data-mount
sudoedit /etc/fstab
sudo findmnt --verify --verbose
sudo systemctl daemon-reload
sudo mount /srv/data
findmnt -M /srv/data -o TARGET,SOURCE,FSTYPE,OPTIONS,UUID

Если проверка не пройдена, сначала исправьте конфигурацию и не переходите к монтированию. Монтируйте только целевой путь: попытка смонтировать всё сразу может скрыть проблемы в других настройках. Успешная проверка синтаксиса также не гарантирует доступность устройства — результат фактического монтирования всё равно нужно проверить.

3. Свяжите запуск службы с монтированием

nofail определяет поведение системы при загрузке, но не обеспечивает безопасность приложения. Для службы, использующей каталог данных, необходимо явно задать зависимость от монтирования. В примере app.service обозначает существующий юнит рабочего приложения: замените его реальным именем и убедитесь, что именно этот юнит запускает процесс, выполняющий запись.

Выполните sudo systemctl edit app.service и добавьте:

[Unit]
RequiresMountsFor=/srv/data
AssertPathIsMountPoint=/srv/data

RequiresMountsFor инициирует монтирование файловых систем, необходимых для доступа к этому пути, и задаёт порядок запуска. Проверка утверждения не допускает запуска в состоянии «каталог существует, но не является точкой монтирования». Ни одна из этих настроек не выявляет ошибочно выбранный диск и не заменяет проверку целостности данных самим приложением. Поэтому проверка источника по UUID остаётся отдельным обязательным шагом.

sudo systemctl daemon-reload
sudo systemctl cat app.service
sudo systemctl show app.service -p Requires -p After

Проверьте, что дополнительные настройки юнита применились и что фактический каталог данных приложения находится внутри /srv/data. Если скрипт запуска перенаправляет запись в другой путь, даже правильная зависимость не предотвратит запись не туда. Задания по расписанию, скрипты, запускаемые вручную, и другие службы не наследуют эти ограничения автоматически — их нужно проверить отдельно.

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

4. Проверьте отсутствие диска и восстановление до начала рабочей записи

Проверку следует проводить, пока на диске нет рабочих данных и активной записи. Сначала остановите приложение, затем юнит монтирования диска данных. Имя юнита для /srv/data можно проверить командой systemd-escape --path --suffix=mount /srv/data; для сложных путей не следует определять его вручную наугад.

sudo systemctl stop app.service
sudo systemctl stop srv-data.mount
sudo systemctl mask --runtime srv-data.mount
sudo systemctl start app.service
sudo systemctl status app.service srv-data.mount --no-pager

Временная блокировка юнита монтирования имитирует недоступность монтирования и не даёт системе автоматически смонтировать диск при запуске приложения. Ожидаемый результат: запуск завершается неудачей, процесс приложения не работает. Если при размонтировании появляется сообщение, что файловая система занята, выясните, кто её использует. Не обходите эту проверку принудительным или отложенным размонтированием.

На этом этапе проверьте, не появились ли новые файлы в лежащем под точкой монтирования каталоге /srv/data. После завершения проверки сначала снимите блокировку, затем восстановите монтирование:

sudo systemctl unmask --runtime srv-data.mount
sudo systemctl start srv-data.mount
findmnt -M /srv/data -o TARGET,SOURCE,FSTYPE,OPTIONS,UUID
sudo systemctl reset-failed app.service
sudo systemctl start app.service

Восстановление считается завершённым только после подтверждения правильного источника и успешной проверки работоспособности приложения. По окончании приёмки обязательно убедитесь, что временная блокировка снята. Зависимости запуска защищают прежде всего на этапе старта и не служат средством обнаружения отказов диска во время работы. Для дальнейшей эксплуатации также нужны обработка ошибок в приложении и мониторинг.

5. Сохраните проверяемый протокол ввода в эксплуатацию

В протоколе должны быть указаны идентификационные сведения о диске, UUID, точка монтирования, тип файловой системы, изменения в fstab, дополнительные настройки юнита службы и результаты проверки отсутствия диска. Проверку после перезагрузки следует запланировать до начала рабочей эксплуатации: необходимо убедиться, что монтирование завершается раньше запуска службы. Одно успешное ручное монтирование не заменяет проверку поведения при загрузке.

Если после монтирования обнаружено необъяснимое использование места на системном диске, сначала проверьте, нет ли старых файлов, скрытых под смонтированной файловой системой. Нужно остановить соответствующую запись и организовать проверку. Нельзя размонтировать файловую систему на работающем сервере и сразу удалять файлы; тем более нельзя вслепую объединять содержимое нижележащего каталога и каталога на диске данных.

Итоговые критерии приёмки: источник выбран правильно, путь действительно является точкой монтирования, зависимости службы действуют, при отсутствии диска запись не попадает в неверное место, а после восстановления приложение успешно проходит проверку работоспособности. Настройка монтирования не обеспечивает ни избыточности, ни резервного копирования — эти задачи необходимо проектировать и проверять отдельно.

Часто задаваемые вопросы