Обсуждение — Разметка и монтирование дополнительного диска

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

Для меня она главная во всём тексте. Мои серверы стоят далеко: до американской машины пинг около 140 мс, для работы это нормально, отсюда до Штатов ближе, чем многие думают. Но обратная сторона — до консоли мне не дойти и не доехать. Если из-за опечатки в fstab сервер уйдёт в аварийный режим, то всё: SSH нет, рук на месте нет, остаётся тикет и ожидание в неудобном часовом поясе. Поэтому «nofail плюс mount -a до перезагрузки» — не ритуал из учебника, а единственная страховка, которая работает на расстоянии. Каждый reboot удалённой машины — маленькая ставка: смотришь, как пинг пропал, и считаешь секунды, пока не вернётся.

И одна заметка по тексту. Сказано, что диски NVMe, но примеры идут с /dev/sdb. На NVMe-системе второй диск будет скорее /dev/nvme1n1, а раздел — /dev/nvme1n1p1, с буквой p перед номером. Тот, кто делает это впервые и ищет sdb в выводе lsblk, может растеряться — стоило упомянуть прямо.

UUID вместо имён поддерживаю: у меня vdb и vdc однажды правда поменялись местами после ребута, с тех пор только UUID.

Меня в nofail волнует обратная сторона. Если система продолжила загрузку без нужного диска, что сделает приложение с каталогом, где оно ждало данные? Для базы я бы отдельно требовал проверку нужного хранилища перед запуском. Самого доступного SSH здесь мало.

То есть «сервер вернулся после ребута» ещё не значит «данные подключились». Это как раз тот итог, по которому я бы успокоился слишком рано. В проверку после запуска тогда надо включать и место хранения, и пару ожидаемых записей приложения.

Проверяйте, какая файловая система смонтирована в нужной точке. Существующий каталог не доказывает наличие диска. И уже после этого — данные приложения. Иначе можно очень успешно проверить пустое место.

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

А аварийный доступ я бы выяснял ещё до правки, не в ожидании пинга. Где открывается консоль, как в неё войти и есть ли нужные доступы. Знание UUID полезно, но в момент, когда удалённая машина не отвечает, хочется иметь уже найденную дверь.

Перед перезапуском можно отдельно проверить описание монтирований: findmnt --verify --verbose проверяет fstab, не монтируя всё подряд. Это ещё не проверка данных на диске, но опечатку помогает отделить от следующего шага. А mount -a уже выполняет монтирование, его не стоит называть сухой проверкой.
Параметр --verify

Ещё поправлю свои слова про nvme1n1: имя зависит от того, как диск представлен гостевой системе. Физический NVMe у хостера не обязывает VPS показать именно такое имя. Перед любыми действиями нужен свой вывод устройств с размерами и разделами; искать только sdb из статьи недостаточно.

Если данные нужны конкретной systemd-службе, можно отдельно потребовать её точку монтирования через RequiresMountsFor. Тогда nofail оставляет машине возможность загрузиться, а зависимая служба не должна начинать работу без нужного диска. Путь подставляется из вашей схемы, не из чужого примера.
Описание RequiresMountsFor