Обновление NAS проходит по накатанной, пока однажды не проходит мимо: сервис не стартует, интерфейс недоступен, а время идёт. Хорошая новость - если система стоит на Btrfs со снапшотами, такая ситуация решается откатом за минуты: снапшот до обновления содержит целое состояние системы, и задача сводится к одной команде rollback. В этой статье разбор процедуры целиком: как готовиться к обновлениям правильно, как понять, что случилось и нужно ли откатываться, как выполняется откат через snapper и вручную через Btrfs, и как вернуть данные в целости даже без снапшотов.
Подготовка - лучшая часть процедуры
История удачного отката начинается за недели до него. Snapper с конфигурацией timeline создаёт снапшоты по расписанию; хук обновления пакетного менеджера создаёт снимки до и после каждой установки; root на Btrfs с layout под subvolumes. У OpenSUSE и производных это складывается из коробки, у openmediavault и TrueNAS - собственные обвязки, но принцип везде один: состояние до обновления сохранено внутри той же файловой системы, и откат не требует внешних носителей.
Проверка готовности - команда snapper list: вывод показывает снимки с номерами, типами и описаниями. Отсутствие снапшотов до обновлений - сигнал, что механика не настроена, и это первое, что стоит исправить на любом NAS. Снапшоты ничего не стоят при неиспользовании: Btrfs пишет копирование при записи, и снимок живёт, пока его блоки реально нужны.
Диагностика перед откатом
Откат - сильное средство, и потому сначала диагноз, а не лечение. Если после обновления сервис не стартует, читается журнал: journalctl -u имя-сервиса на новых релизах, логи пакетного менеджера на предмет ошибок скриптов, система - в состоянии загрузки или нет. Часто проблема точечная - один сломанный конфиг или один пакет, и точечное лечение проще глобального отката.
Другой исход: система не грузится вовсе или NAS не отвечает по сети. Здесь откат становится оправданным по умолчанию, потому что диагностика негрузящейся системы сложнее отката к заведомо рабочему состоянию. Практическое правило для выбора: если система хоть как-то работает - диагностика точечно; если не работает совсем - откат, а диагностика причин уже после, на свежем воздухе рабочего состояния.
Откат через snapper step-by-step
Snapper делает откат процедурой из четырёх шагов. Шаг первый: snapper list - найдите снапшот до неудачного обновления, обычно с описанием pre или таймстампом за минуты до него. Шаг второй: перезагрузка - важно, потому что откат корневой файловой системы выполняется только на незагруженной системе: при работе снапшот занят процессами. Шаг третий: в загрузчике (при наличии меню) или через rescue-среду выполняется snapper rollback <номер>. Шаг четвёртый: перезагрузка в систему из снапшота, с проверкой всех сервисов.
Механика под капотом изящна: snapper меняет местами subvolumes, назначая снапшот новым корнем, а текущее состояние сохраняет как новый снапшот - то есть откат сам по себе не разрушителен, и если откат не помог, можно откатиться обратно. В связке с snapper, реализованной из коробки в OpenSUSE, этот цикл отточен до состояния одной команды и одной перезагрузки.
Ручной откат через Btrfs без snapper
Если snapper не установлен, вся механика доступна вручную, потому что снапшоты - свойство файловой системы, а не обвязки. Для систем с layout в стиле openSUSE: subvolume снапшота подставляется на место корня изменением default subvolume - btrfs subvolume set-default идентификатор, который берётся из btrfs subvolume list. Для ручной разметки применяется перемонтирование снапшота поверх корня.
Ручной путь требует понимания своего layout, поэтому зрелая практика - один раз смоделировать откат на тестовом NAS, записать шаги и хранить их в runbook именно для случая, когда snapper недоступен. Моделирование занимает полчаса и выполняется при настройке NAS, а не в ночь аварии.
Откат данных без снапшотов системы
Особый случай - когда снапшоты системы есть, а данные пострадали отдельно, или снапшотов нет вовсе. Для данных на Btrfs: undelete через ext:/ snapper-snapshots или восстановление из предыдущих снапшотов данных. Для систем без снапшотов: загрузка с live-носителя, монтирование и точечная починка - возврат конфигов из /etc, переустановка конкретного пакета, отмена конкретного изменения.
Именно про этот сценарий в индустрии повторяют главное правило: NAS без внешнего бэкапа - это не система хранения данных, а система отложенного стресса. Снапшоты защищают от плохих обновлений, но не от отказа носителя, и потому зрелая конфигурация NAS всегда состоит из трёх слоёв: снапшоты для быстрых откатов, зеркалирование для отказоустойчивости, внешний бэкап для последнего рубежа.
Восстановление после отката
После успешного rollback система возвращается в состояние до обновления, и далее начинается аккуратный второй заход. Стратегия повторного обновления: небольшими порциями с тестированием каждой - сначала один пакет, проверка, потом следующий. Если обновление большое, пауза между порциями даёт время проблемам проявиться до накопления. При повторной ошибке на том же пакете вопрос уже не в обновлении, а в его совместимости с текущим состоянием, и это уже отдельный разбор с журналами в руках.
Профилактика на будущее
Минимальный набор, превращающий следующее обновление из риска в рутину: snapper с привязкой к пакетному менеджеру; проверка снапшотов перед каждым крупным обновлением; расписание maintenance-окна на случай неудачи; внешний бэкап данных NAS. Час настройки - и страшная история этой статьи становится историей из четырёх команд: list, rollback, reboot, проверка.
Памятка
Финальный порядок: снапшоты до обновления - проверяются заранее; после неудачи - диагностика если система жива, откат если мертва; snapper rollback к снапшоту pre-обновления; перезагрузка и проверка сервисов; повторное обновление малыми порциями. Btrfs с snapper - это страховка, встроенная в саму файловую систему, и в умелых руках она превращает самые драматичные обновления в обратимые события.
Частный случай - root не на Btrfs
Если корень NAS живёт на ext4, автоматического отката со снапшотами нет, и процедура переходит в разряд классического восстановления: загрузка с live-носителя, chroot, откат пакетов через history пакетного менеджера - zypper, apt и dnf умеют откатывать по номерам транзакций, - и точечный возврат конфигурации. Данные на отдельном Btrfs-томе при этом откатываются своими средствами независимо от системы: снапшоты данных живут своей жизнью, и неудачное обновление их не касается. На практике эта схема встречается часто, и она ещё один аргумент за layout с разделением системы и данных: чем они независимее, тем меньше любая авария затрагивает.
Откат на готовых NAS - TrueNAS и производные
Готовые NAS-платформы привносят собственный порядок. TrueNAS CORE хранит систему в двух загрузочных окружениях и переключается между ними из меню при загрузке - неудачное обновление откатывается выбором предыдущего boot environment ещё до входа в систему, одной стрелкой. TrueNAS SCALE и Synology DSM ведут себя похоже: снапшоты системы делаются автоматически перед обновлением, и в интерфейсе всегда есть путь назад. Для владельцев этих систем главный навык - знать, где в их конкретной платформе лежит кнопка отката, и проверять её работу на тестовом обновлении заранее, потому что интерфейсы меняются от версии к версии.
Разбор типичных ошибок при откате
Первая ошибка - откат в спешке без сохранения журналов текущего состояния: причины неудачи исчезают вместе с состоянием, и следующее обновление наступает на те же грабли. Правильный порядок - сначала скопировать логи и изменения наружу, потом откат. Вторая ошибка - откат без перезагрузки: команды snapper на живой системе меняют только заготовку, и без рестарта эффект нулевой, а у новичка складывается впечатление, что инструмент не работает. Третья - откат данных вместе с системой, когда пострадали только конфиги: данные новее снапшота, и откат без разбора стирает часы работы пользователей. Все три ошибки лечатся одной привычкой - минутой осмотра перед любой сильной командой.
Снапшоты и место на диске
Хозяйственный аспект: снапшоты Btrfs потребляют место по мере расхождения с текущим состоянием. Обновление с заменой половины пакетов расходит снапшот на гигабайты, и на тесных NAS это иногда становится неожиданностью: откат хочется сделать, а места уже нет. Практические меры: quota-группы в snapper, ограничивающие снимки по объёму; разумный размер диска под систему; регулярная чистка старых снапшотов через snapper list и delete. С учётом копирования при записи место под снапшоты - это не резерв, а общая ёмкость, и планировать её стоит так же, как планируют место под логи.
История из практики
Типичный кейс: после планового обновления медиа-сервера на OpenSUSE веб-интерфейс перестал отвечать, а через десять минут и SSH перестал принимать соединения. Диагностика по серийной консоли показала зависание на старте нового сервиса, входившего в обновление. Быстро: snapper list - номер снапшота за четыре минуты до обновления с пометкой pre; reboot; в меню загрузчика - откат к снапшоту; система поднялась в состояние до обновления за две минуты. Причина одиночного сервиса нашлась позже спокойно, на обновлённой копии стенда, а данные за эти два часа - не пострадали ни на секунду, потому что снапшот данных не входил в откат.
Эта история - лучшая иллюстрация того, зачем вся статья: не для того, чтобы откатывать, а для того, чтобы плохие обновления перестали быть событием. Снапшот до обновления превращает самую неуклюжую выкатку в обратимый эксперимент, и именно с этим ощущением обратимости живётся спокойнее всего.
Итог для вдумчивого читателя
Btrfs со снапшотами - редкий пример технологии, которая превращает самую болезненную операцию системного администрирования - обновление - в безопасный эксперимент с кнопкой отмены. Настройте эту кнопку до того, как она понадобится, проверьте её работу на тестовом стенде, и ваши обновления перестанут быть событиями с риском: они станут просто обновлениями, какими и должны быть.
И в этом весь замысел статьи: не инструкция по лечению, а приглашение к профилактике. Здоровая инфраструктура узнаётся по тому, что о её обновлениях никто не пишет историй - истории пишутся только там, где кнопки отмены не оказалось под рукой.
Чек перед каждым обновлением NAS
Отточенная привычка перед любым крупным обновлением занимает две минуты и спасает часы. Проверка первого: snapper list показывает свежий снапшот с меткой до обновления - если хук пакетного менеджера не сработал, снапшот создаётся вручную перед стартом. Проверка второго: df -h убеждается в месте под снапшот после обновления. Проверка третьего: внешний бэкап данных выполнен и свеж - на случай, если сама файловая система пострадает от обновления. Три проверки, тридцать секунд на каждую, и кнопка отмены гарантированно существует - остальное уже механика.
И последнее соображение для вдумчивого владельца NAS: выбирайте платформу, где снапшоты встроены по дизайну, а не прикручены скриптами по случаю. Разница между этими двумя подходами проявляется именно в ночь неудачного обновления: встроенная механика откатывает за минуты, а самодельная требует человека, который помнит, какой из десяти самописных скриптов за что отвечал. Готовность проверяется не в паспорте продукта, а в одном коротком вопросе - как на этой платформе откатиться к вчерашнему состоянию, и если ответ занимает больше двух команд, стоит искать другую платформу для своих данных.
И пусть все ваши обновления завершаются первой попыткой, а снапшоты останутся страховкой, которая просто ждёт своего часа без дела.
Счастья вашему хранилищу данных и спокойных обновлений!