ИБП и удалёнка: порядок выключения NAS/ПК, чтобы не словить порчу ФС

Типичная заявка звучит так: «свет моргнул, я был в отъезде, утром NAS не монтирует том, Windows просит chkdsk, а в логах SMB куча обрывов». Вариант похуже: том поднялся, фото на месте, зато база 1С или iSCSI-лун после ночи «как будто обрезали посередине записи». Ещё чаще люди ставят ИБП «на всякий случай», вешают на него NAS, ПК и чайник, а сценарий выключения не прописывают вообще. Батарея держит минуты, потом ИБП сам щёлкает нагрузку — и это уже не «мягкое выключение», а обычный hard power-off, только с задержкой.

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

Хосты в примерах вымышленные: nas.home.lan, pc-office, nut-master. Свои имена, VLAN и модель ИБП подставляйте.

Почему «ИБП стоит» ≠ «файловая система целая»

Журнал ext4, NTFS dirty bit, ZFS intent log — это подушки. Они уменьшают шанс полной смерти тома, но не отменяют простой факт: если в момент отключения шёл сброс кэша, дописывался RAID-страйп или клиент держал открытый файл по SMB, вы ловите как минимум долгий fsck и «тихую» порчу одного файла. На NAS это особенно обидно: локальный диск ПК ещё можно пережить, а общий том — уже заявка «откати бэкап, но не вчерашний».

ИБП даёт время. Не бесконечное. Бытовой line-interactive на NAS + роутер + коммутатор часто держит от нескольких минут до четверти часа под реальной нагрузкой. Если за это время никто не начал shutdown, батарея просто кончится. Тогда ИБП либо уйдёт в bypass и потухнет, либо сам отрубит розетки. Для дисков разницы почти нет: питание пропало на работающей ФС.

Отдельная ловушка — «умные» розетки и сценарии вроде «через 60 секунд после пропадания 220 отключить NAS, чтобы экономить батарею». Это не shutdown. Это тот же hard power-off, только реле сработало красиво. Резать питание можно только после того, как ОС сама погасла.

Порядок, который я держу в голове

Клиенты с сетевыми дисками выключаются раньше хранилища. Хранилище — раньше, чем сеть, по которой ему пришла команда. Монитор ИБП (тот, у кого USB в ИБП) гаснет последним из компьютеров. Коммутатор и роутер живут до последнего: без них команда shutdown до NAS не доедет.

На пальцах для типичной квартиры/небольшого офиса:

• Короткий моргающий свет (секунды) — ничего не выключаю. Только пишу в лог ONBATT и, если настроено, шлю уведомление.
• Питание так и не вернулось, батарея ушла в «мало» или осталось несколько минут рантайма — начинаю сценарий.
• Сначала ПК, тонкие клиенты, виртуалки, которые держат SMB/NFS/iSCSI на NAS. Им нужно сбросить кэш и отпустить файлы.
• Потом сам NAS: unmount, flush, штатный poweroff. DSM/TrueNAS на это могут занять пару минут, не секунды.
• Потом хост, который видит ИБП по USB (NUT master). Он же в конце может дать ИБП команду снять нагрузку.
• Роутер и коммутатор не трогаю сценарием. Они умрут сами, когда ИБП снимет розетки — к этому моменту компьютеры уже должны быть off.

Перепутать два места легко. Первое: NAS выключился, а pc-office ещё дописывает проект на \\nas\share. Клиент получит обрыв, локальный кэш SMB может соврать, а на томе останется недописанный файл. Второе: выключили коммутатор «чтобы экономить батарею», и NAS, который должен был принять команду по сети, её уже не услышит. Дальше NAS живёт до нуля батареи и падает как есть.

Кто вообще имеет право нажимать shutdown

USB от ИБП физически торчит в один хост. Не в два сразу: hid-драйвер не шарится. Этот хост становится источником правды: он читает OL/OB/LB, считает рантайм и рассылает остальным «пора гаснуть».

Три рабочие схемы, которые я встречаю:

• USB в NAS (Synology/TrueNAS). NAS сам гаснет по своему «UPS». Остальные машины либо клиенты NUT/Synology UPS Server, либо их вообще нет в сценарии. Минус: если ПК с примонтированными шарами не клиент, он переживёт NAS и умрёт позже на пустой батарее.
• USB в отдельный Linux («nut-master»). Классика Network UPS Tools: master видит ИБП, slaves слушаются. Порядок я тогда рисую скриптом на master, а не надеюсь, что все slaves погаснут «примерно одновременно».
• Вендорский агент на Windows (PowerChute и аналоги). Работает, пока в контуре один ПК. Как только появляется NAS с шарами, Windows-агент про NAS не думает. Либо добавляю NUT/SSH со стороны Linux, либо сознательно оставляю NAS единственным, кто умеет гаснуть.

Правило, которое я записываю заказчику в одну строку: кто держит диски с чужими сессиями — тот не имеет права умереть первым. NAS с открытыми SMB — не первый. Хост с USB — не первый, если он должен ещё раздать команду.

NUT: master, slave и почему «все slave» — плохой порядок

На nut-master минимум такой каркас. Имена и пароли вымышленные, в прод так не копировать.

# /etc/nut/ups.conf
[officeups]
    driver = usbhid-ups
    port = auto
    desc = "office line-interactive"

# /etc/nut/upsd.conf
LISTEN 127.0.0.1 3493
LISTEN 192.168.10.10 3493

# /etc/nut/upsd.users
[upsmon]
    password = "replace-me"
    upsmon master

# /etc/nut/upsmon.conf
MONITOR officeups@localhost 1 upsmon replace-me master
MINSUPPLIES 1
SHUTDOWNCMD "/sbin/shutdown -h now"
POWERDOWNFLAG /etc/killpower
FINALDELAY 5

LISTEN только во внутреннюю сеть, не на белый IP. upsd — не веб-морда.

На NAS или втором Linux slave выглядит так:

MONITOR officeups@192.168.10.10 1 upsmon replace-me slave
SHUTDOWNCMD "/sbin/shutdown -h now"

Если и pc-office, и nas.home.lan оба slave, NUT при FSD скажет им гаснуть почти вместе. Для меня этого мало. Клиенту нужно 20–40 секунд на unmount, NAS — минуты на сброс томов. Поэтому на master я не полагаюсь на одновременный FSD, а вешаю свой NOTIFYCMD: сначала гашу клиентов по SSH, жду, потом NAS, и только потом локальный shutdown.

Грубый скелет, без прикрас:

#!/bin/bash
# /usr/local/sbin/ups-shutdown-order.sh
# вызывается из NOTIFYCMD на ONBATT+LB или FSD, не на каждый ONBATT
set -eu
clients="pc-office.home.lan htpc.home.lan"
nas="nas.home.lan"

for h in $clients; do
  ssh -o ConnectTimeout=5 "shutdown@$h" 'sudo /sbin/shutdown -h +0' || true
done
sleep 45

ssh -o ConnectTimeout=8 "shutdown@$nas" 'sudo /sbin/shutdown -h now' || true
# DSM: часто удобнее synoshutdown / shutdown из их sudoers, не systemd
sleep 90

/sbin/shutdown -h now

Таймауты не универсальные. На живом NAS я один раз засекаю, сколько он гаснет от команды до того, как погасли дисковые LED. Это и есть нижняя граница sleep плюс запас. Если DSM выключается 2,5 минуты, sleep 30 — способ убить том почти наверняка: master погас, ИБП снял нагрузку, NAS ещё писал.

Доступ shutdown@ — отдельная учётка с sudo только на shutdown -h, ключ без пароля, только с nut-master. Не админ «на все команды».

Когда начинать: ONBATT — ещё не повод рубить всё

Короткий провал 220 я не превращаю в массовый reboot. Иначе каждый сварочный сосед и каждый ввод резерва на ТП будут по ночам гасить офис.

Смотрю статус так:

upsc officeups@localhost
# важные поля:
# ups.status     OL / OB / LB / FSD / CHRG
# battery.charge
# battery.runtime

OL — сеть есть. OB — работаем от батареи. LB — мало. FSD — forced shutdown уже идёт.

Практическая схема, которой я пользуюсь:

• ONBATT без LB — лог, письмо или Telegram, ничего не гашу. Жду 30–120 секунд: свет часто возвращается.
• Порог по рантайму, не по красивому проценту. «20%» на старой батарее может быть одной минутой. Смотрю battery.runtime и засечённое время реального гашения контура.
• Старт сценария, когда остатка хватает на: ожидание клиентов + shutdown NAS + запас. Если весь контур гасится 3 минуты, порог «осталось 4 минуты» — уже игра в кости.
• Калибровку батареи и «сколько реально держит» делаю раз в сезон, локально, не в первую командировку.

Вендорские галочки в DSM вроде «выключить при 15%» без замера рантайма я не доверяю. Процент врёт чаще, чем секунды.

Что именно вешать на батарейные розетки

На «battery backup», не на «surge only»:

• роутер и коммутатор, через который NAS получает команду;
• сам NAS;
• хост с USB в ИБП;
• ПК, которые обязаны штатно погаснуть, а не «ну переживём chkdsk».

Не вешаю лазерный принтер, обогреватель, большой монитор «ну раз розетка свободна». Они съедают минуты, которые нужны дискам. PoE-коммутатор с кучей камер может сожрать батарею быстрее NAS — тогда камеры либо на отдельный маленький ИБП, либо сознательно не входят в контур «спасти ФС».

Отдельный камень: модем провайдера. Если он не на ИБП, уведомление «свет пропал» из дома вы не получите: канал умрёт вместе с 220. На shutdown это не влияет — сценарий локальный. На ваше спокойствие в поездке — влияет. Я либо питаю ONT/модем от того же ИБП, либо не жду, что телега доедет.

Windows, DSM, TrueNAS — где люди обычно срезают угол

Windows по умолчанию не слушает NUT. Варианты, которые работают у меня без вендорской простыни: WinNUT-Client как slave, либо SSH/WinRM с master и штатный shutdown /s /t 0 /f. /f закрывает приложения принудительно — для ночного обрыва питания это меньшее зло, чем диалог «сохранить документ» до конца батареи. Для интерактивного ПК днём — неприятно, поэтому порог LB, а не первый ONBATT.

Synology: «Панель управления → Оборудование и питание → ИБП». Если USB в NAS, включаю сетевой UPS-сервер Synology, чтобы другой их же NAS или NUT-совместимый клиент получил сигнал. Если USB в Linux — DSM настраиваю как NUT slave на nut-master. Проверяю, что команда реально гасит DSM, а не пишет «событие ИБП» в журнал и живёт дальше. Разница видна один раз, если посидеть рядом с LED дисков.

TrueNAS: служба UPS — тот же NUT. Не забываю SHUTDOWNCMD и что jail/VM должны уехать до zpool. Иначе пул экспортируется, пока виртуалка ещё пишет в zvol.

systemd на Linux: shutdown -h лучше, чем systemctl halt без понимания, уйдёт ли питание. Для NUT master ещё важен POWERDOWNFLAG /etc/killpower и проверка upsmon -K на старте: ИБП после пачки shutdown должен снять нагрузку, а когда 220 вернётся — подать её снова, чтобы машины включились. Без этого батарея догорит в ноль на уже выключенных ПК, и утром часть железа не встанет, пока кто-то не нажмёт кнопку на ИБП.

Как машины должны просыпаться, когда свет вернулся

Выключение — половина. В BIOS/UEFI хоста и NAS смотрю «Restore AC Power Loss» / «After Power Loss»:

• NAS — обычно Always On. Хранилище должно подняться само.
• nut-master — тоже Always On. Иначе следующий обрыв никто не отследит.
• Офисный ПК — Last State или Off. Мне редко нужно, чтобы он сам ревел в пустой комнате.

Wake-on-LAN тут ни при чём: его некому послать, пока вы спите в другом городе. Это про поведение блока питания после возврата 220.

Роутер на ИБП сам поднимется. Если у провайдера ONT долго регистрируется, это не повод задерживать shutdown: к моменту возврата света компьютеры уже должны быть холодные.

Как я это проверяю, не надеясь на «первый настоящий обрыв»

Первый тест — только локально, днём, с руками на кнопке ИБП и с копией важных томов, которая не на этом же NAS.

• upsc в норме: OL, рантайм похож на правду, USB не отваливается в dmesg.
• Выдёргиваю входную вилку ИБП из стены, не нагрузку. Статус должен стать OB. Клиенты ещё живы.
• Жду порог или форсирую сценарий. Смотрю, что pc-office погас первым, шары отпустились, потом погас NAS, потом master.
• Засекаю время от старта сценария до момента, когда на NAS нет активности дисков. Это число кладу в sleep и в порог батареи.
• Втыкаю вилку обратно. ИБП берёт сеть, поднимает нагрузку, NAS стартует сам.

Форсировать FSD командой NUT можно, но на чужом контуре в пятницу вечером я этого не делаю. Слишком легко получить тот самый обрыв, от которого писали статью.

После теста:

# Linux / TrueNAS
journalctl -u nut-monitor -u nut-server --since today
zpool status
dmesg -T | tail

# DSM: Storage Manager / журналы ИБП, не «всё зелёное в виджете»

# Windows
wevtutil qe System /q:"*[System[EventID=6008 or EventID=6006 or EventID=41]]" /c:5 /f:text

6008 — неожиданное выключение. Если он есть после «успешного» сценария, Windows погасили питанием, не shutdown /s. Сценарий врёт.

Утро после настоящего обрыва, когда меня не было дома

Короткий список, без магии:

• Поднялся ли NAS сам. Если нет — сначала ИБП и «Restore AC», не fsck.
• Тома смонтировались без ручного repair. На ZFS — zpool status, нет ли FAULTED/UNAVAIL после внезапного питания. На DSM — Storage Manager, не «папка открывается в File Station».
• Клиенты, которые писали ночью (бэкап, 1С, камеры на шару). Открыть не «файл на месте», а хвост: последняя запись, целостность архива, не обрезан ли контейнер.
• Журнал NUT: был ли OB → сценарий → shutdown, или сразу смерть на OL (тогда ИБП не участвовал: выбили автомат после ИБП, сдох USB, уехал драйвер).
• Рантайм в логе. Если от OB до смерти прошло меньше, чем длится shutdown NAS — порог надо поднимать или разгружать ИБП.
• Батарея после серии обрывов. Старый аккумулятор «держит на экране 12 минут» и отдаёт три — это уже не настройка NUT, а замена батареи. Цены тут не считаю: если ИБП пищит и рантайм сдулся, это расходник, не «ещё чуть крутануть процент».

Если том всплыл, а один каталог странный — не чиню «на горячую» и не запускаю агрессивный repair, пока нет копии. Сначала снимок/бэкап, потом fsck. ИБП спасает от внезапного питания, но не от желания починить живой диск первой попавшейся галочкой.

Что я отказываюсь считать решением

Не считаю решением плагин умного дома «выключить розетку NAS через минуту». Не считаю решением «поставим ИБП побольше и не будем ничего гасить» — батарея всё равно кончится в длинный обрыв, плюс вы греете комнату зря. Не считаю решением только уведомление в мессенджер: в 03:00 я могу не успеть, а канал может умереть вместе с модемом.

Считаю решением короткую цепочку, которую можно проговорить вслух: кто видит USB, кто гаснет первым, сколько минут это занимает, сколько батарея реально держит, и что должно включиться само, когда 220 вернётся. Это скучно. Зато утром NAS монтирует том, а не просит «ваш диск был извлечён неправильно».

Другие статьи по теме:

• SSH – проброс приватного ключа
• ILSERBY — мой каталог сетевых инструментов в одном месте
• Руководство по работе с планировщиком задач cron
• Поиск в файлах по содержимому в Linux
• WireGuard офис ↔ VPS: маршруты, DNS, split-tunnel и проверка что трафик в туннеле
• Миграция домена WordPress без поломки serialized-данных
• Как безопасно удалить пользователя в Ubuntu Linux
• Application Passwords vs XML-RPC: что оставлять и как не открыть лишнюю дыру