Процедура восстановления (Restore)

Урок 2 · Монтаж и пусконаладка контроллера · 10 мин · theory

Введение в процедуру восстановления (Restore)

Процедура восстановления (Restore) — это критически важный процесс, позволяющий вернуть систему автоматизации в рабочее состояние после сбоя или нежелательных изменений. На объекте, где контроллеры управляют освещением, климатом и безопасностью, время простоя системы должно быть сведено к абсолютному минимуму. Наличие отработанной и задокументированной процедуры восстановления является признаком профессионального подхода инсталлятора.

Существует несколько типовых сценариев, при которых требуется восстановление системы:

Сбой оборудования: Наиболее очевидная причина. Выход из строя самого контроллера (например, из-за скачка напряжения) или его накопителя данных (SD-карты). В этом случае старое устройство заменяется новым, на которое "разворачивается" полная копия работоспособной системы.

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

Человеческий фактор: Наиболее частая причина. В процессе эксплуатации или доработки системы кто-то (инженер, продвинутый пользователь) может случайно удалить или некорректно изменить критически важный сценарий, что приводит к нарушению логики работы. Вместо трудоемкого поиска ошибки проще и быстрее восстановить проверенную версию сценариев.

Ключевым моментом является различие между двумя основными типами восстановления:

| Тип восстановления | Описание | Когда применяется |

| :----------------- | :------------------------------------------------------------------------------------------------------------------------------------------ | :---------------------------------------------------------------------------------------------------------------- |

| Частичное | Восстановление только отдельных компонентов системы, чаще всего — файла со сценариями `flows.json` в среде Node-RED. | Ошибки в логике, случайное удаление сценария, неудачный эксперимент с автоматизацией. Конфигурация контроллера не затронута. |

| Полное | Полная замена всех данных на контроллере (сценарии, настройки, история, системные файлы) данными из системного архива (`.tar.gz`). | Замена контроллера на новый, тотальное повреждение данных, необходимость отката к "заводским" настройкам конкретного объекта. |

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

В этом уроке мы последовательно разберем обе процедуры: от простого импорта сценариев в интерфейсе Node-RED до полного системного восстановления контроллера HI через командную строку Linux.

---

Частичное восстановление: импорт сценариев Node-RED

Частичное восстановление — это первая линия обороны при возникновении проблем с логикой автоматизации. Оно позволяет быстро вернуть сценарии к известному рабочему состоянию, не затрагивая при этом системные настройки контроллера, такие как сетевые конфигурации или установленные пакеты.

> 🔗 Связанный материал: Процедура экспорта сценариев и создания резервной копии файла `flows.json` детально рассмотрена в уроках COURSE-03-M08-L01 "Экспорт сценариев (flows) из Node-RED" и COURSE-03-M08-L02 "Создание полного бэкапа системы".

Процесс импорта состоит из нескольких шагов:

Откройте меню импорта. В правом верхнем углу интерфейса Node-RED нажмите на иконку "гамбургер" (три горизонтальные линии) и выберите пункт Импорт.

Выберите источник импорта. В открывшемся окне у вас есть несколько вариантов. Для восстановления из файла выберите вкладку "Выбрать файл для импорта" и укажите путь к вашему файлу `flows.json`.

Определите место импорта. После выбора файла Node-RED покажет вам структуру импортируемых сценариев. Здесь у вас есть два варианта:

* "в новый поток": Node-RED создаст новую вкладку и разместит на ней все импортированные сценарии. Это безопасный способ сравнить старую и новую версии.

* "в текущий поток": Сценарии будут добавлены на ту вкладку, которая у вас сейчас открыта.

Для полного восстановления логики рекомендуется сначала удалить старые (нерабочие) вкладки, а затем импортировать файл `flows.json`, создавая новые потоки.

Разверните изменения. После импорта все новые узлы и потоки появятся в редакторе. Чтобы они начали работать, необходимо нажать красную кнопку "Развернуть" (Deploy) в правом верхнем углу.

Роль файла `flows_cred.json`

Рядом с файлом `flows.json` всегда находится файл `flows_cred.json`. Он содержит в зашифрованном виде все "секреты" ваших сценариев: пароли от баз данных MySQL, пароли для входа в Node-RED, API-ключи для погодных сервисов, логины и пароли от MQTT-брокеров и т.д.

> ⚠️ Внимание: При импорте файла `flows.json` среда Node-RED не импортирует автоматически учетные данные из `flows_cred.json`. Для восстановления паролей и ключей необходимо вручную заменить существующий файл `flows_cred.json` на контроллере файлом из резервной копии, после чего обязательно перезапустить Node-RED.

Диагностика ошибок импорта: отсутствующие узлы

Часто после импорта сценариев на новом контроллере или в другой среде вы можете увидеть узлы с пунктирной красной рамкой и сообщением об ошибке "Unknown node type". Это означает, что в вашей палитре Node-RED отсутствуют модули (палеты), необходимые для работы этих узлов.

Процедура решения проблемы:

Идентифицируйте отсутствующий модуль. Наведите курсор на узел с ошибкой. Во всплывающей подсказке будет указано имя типа узла (например, `modbus-getter`).

Откройте менеджер палитры. Меню -> Manage palette.

Перейдите на вкладку "Install".

Выполните поиск. В строке поиска введите имя отсутствующего модуля (например, `modbus` или `node-red-contrib-modbus`).

Установите модуль. Нажмите кнопку "Install" рядом с найденным пакетом.

Повторите для всех отсутствующих узлов.

После установки всех необходимых модулей перезагрузите страницу с редактором Node-RED. Импортированные узлы должны принять нормальный вид. Теперь можно нажимать "Развернуть".

После успешного импорта и развертывания необходимо провести визуальную проверку: убедитесь, что все узлы имеют корректный статус (например, узлы MQTT показывают "connected"), а на вкладках нет значков с ошибками.

---

Полное восстановление контроллера из системного бэкапа

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

> ⚠️ Внимание: Процедура полного восстановления необратимо заменяет все существующие на контроллере данные (сценарии, конфигурации, историю) данными из файла резервной копии. Прежде чем приступить, убедитесь, что на контроллере нет никаких важных изменений, которые не были сохранены.

Процесс выполняется через командную строку Linux. Вам потребуется SSH-клиент (например, PuTTY для Windows или встроенный терминал в macOS/Linux).

Шаг 1: Подключение к контроллеру и загрузка бэкапа

Подключитесь к контроллеру по SSH. Используйте IP-адрес контроллера и учетные данные инженера/администратора.

ssh admin@192.168.1.10

Загрузите файл бэкапа на контроллер. Удобнее всего это сделать с вашего рабочего компьютера с помощью утилиты `scp` (Secure Copy). Команда выполняется в терминале вашего компьютера (не на контроллере). Она копирует файл с локального диска в директорию `/tmp` на контроллере.

    # Синтаксис: scp [путь к файлу на вашем ПК] [пользователь]@[IP контроллера]:[путь на контроллере]
    scp C:\backups\hi_backup_2023-10-27.tar.gz admin@192.168.1.10:/tmp/

После выполнения этой команды файл `hi_backup_2023-10-27.tar.gz` окажется во временной директории на контроллере HI.

Шаг 2: Выполнение процедуры восстановления

Теперь все действия выполняются в SSH-сессии на контроллере.

Остановите сервис Node-RED. Это обязательный шаг, чтобы предотвратить конфликт файлов во время их замены.

sudo systemctl stop nodered

Распакуйте архив. Для распаковки системного бэкапа используется стандартная утилита `tar`. Ключевой момент — указание корневой директории (`/`) в качестве цели (`-C /`), чтобы файлы из архива перезаписали существующие файлы по их оригинальным путям.

# Команда для распаковки архива из /tmp в корень файловой системы # Ключи: # x - eXtract (извлечь) # z - gZip (архив сжат с помощью gzip) # p - Preserve permissions (сохранить права доступа к файлам) # f - File (работать с файлом, указанным далее) # -C / - Change directory to / (извлечь файлы относительно корневого каталога) sudo tar -xzpf /tmp/hi_backup_2023-10-27.tar.gz -C /

Процесс может занять от нескольких секунд до минуты.

Шаг 3: Перезагрузка контроллера

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

sudo reboot

После перезагрузки контроллер запустится в том же состоянии, в котором он был на момент создания резервной копии. Время загрузки может быть немного дольше обычного, так как сервисы будут инициализироваться с новыми (или старыми) конфигурациями.

---

Верификация и тестирование после восстановления

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

1. Первичная проверка системных логов

Сразу после перезагрузки контроллера подключитесь к нему по SSH и запустите мониторинг логов сервиса Node-RED в реальном времени.

journalctl -u nodered -f

Эта команда покажет вам все сообщения, которые генерирует Node-RED при старте. Внимательно ищите строки, подсвеченные красным цветом.

Хороший лог: Содержит сообщения `Started Node-RED graphical event-driven wiring tool`, `Flows started`, а также сообщения об успешном подключении к MQTT, Modbus и другим устройствам.
Плохой лог: Содержит ошибки `[error]`, сообщения о невозможности загрузить flow, ошибки подключения `[modbus] Error: Port Not Open` или `[mqtt] Connection failed`. Такие ошибки — первый признак того, что что-то пошло не так.

2. Тестирование оборудования

Далее необходимо проверить связь с физическим оборудованием. Откройте интерфейс Node-RED и выполните несколько простых тестов.

Управление реле: Создайте узел `Inject` и соедините его с узлом, управляющим реле (например, `Modbus-Write` или `rpi gpio out`). Настройте `Inject` на отправку команды на включение (например, `true` или `{ "command": "ON" }`). Нажмите на кнопку узла `Inject` и убедитесь, что вы слышите щелчок реле и видите, что подключенная к нему нагрузка (например, лампа) включилась. Проверьте обратную связь в окне "Отладка".

Чтение датчиков: Проверьте узлы, которые отвечают за опрос датчиков (1-Wire, Modbus). Убедитесь, что под ними горит зеленый индикатор статуса и отображается актуальное значение, например `OK: 23.5°C`. Если статус "disconnected" или "error", необходимо проверить физическое подключение, как мы рассматривали в модуле про картирование физического уровня.

3. Проверка логики сценариев

Теперь проверьте работу нескольких ключевых автоматизаций. Это — мини-версия Smoke Test.

Сценарий "Свет по движению": Войдите в помещение, где установлен датчик движения. Проверьте, что свет включился. Выйдите из помещения и убедитесь, что свет выключился через заданный таймаут.

Сценарий "Климат-контроль": Через интерфейс управления (или тестовый `Inject`) задайте новую уставку температуры. Проверьте, что узел FSM (конечный автомат) перешел в правильное состояние (`Heating` или `Cooling`) и отправил команду на соответствующее оборудование (клапан радиатора, фанкойл).

Сценарий "Защита от протечки": Если в системе есть датчики протечки, выполните их имитацию (например, замкнув контакты влажной тканью). Проверьте, что система корректно отработала сценарий: перекрыла краны и отправила уведомление.

Пример сообщения `msg.payload` при проверке отправки команды на Modbus-устройство:

{
  "value": true,
  "fc": 5,
  "unitid": 10,
  "address": 0,
  "quantity": 1,
  "status": "success - Bit Write: true"
}

Получение такого сообщения в отладке после отправки команды подтверждает, что связь с Modbus-устройством (ID=10) установлена и команда на запись в Coil 0 была успешно выполнена.

4. Проверка внешних интеграций

Последний шаг — проверка связи с "внешним миром".

MQTT: С помощью внешнего инструмента (например, MQTT Explorer) убедитесь, что контроллер публикует телеметрию (температуру, влажность, состояния) в правильные топики и реагирует на команды, приходящие извне.
API и облачные сервисы: Если система получает данные из интернета (например, прогноз погоды), проверьте, что эти данные обновляются. Если система отправляет уведомления (Telegram, Push), инициируйте тестовое событие и убедитесь, что уведомление пришло.

---

Итоги и передача документации заказчику

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

> 💡 Подсказка: При передаче объекта заказчику рекомендуется хранить у себя копию "золотого" бэкапа — финальной, полностью отлаженной конфигурации системы. Это позволит быстро восстановить объект в случае критического сбоя, даже если локальные бэкапы заказчика будут утеряны или повреждены.

Давайте подведем итоги. Мы рассмотрели два метода восстановления:

Частичное (импорт flows.json): Быстрый способ исправить ошибки в логике сценариев без затрагивания системы.
Полное (восстановление из .tar.gz): Кардинальный метод для восстановления системы после серьезного сбоя или при замене оборудования.

Формирование пакета документации

При передаче объекта в эксплуатацию ваш пакет документации должен включать не только Рабочую документацию (РД), но и цифровые артефакты:

Финальный системный бэкап: Файл `hi_backup_YYYY-MM-DD.tar.gz`, являющийся "золотым" образом системы.
Файлы сценариев: Отдельно сохраненные файлы `flows.json` и `flows_cred.json` для удобства частичного восстановления.
Краткая инструкция (Runbook): Документ на 1-2 страницы, описывающий для службы эксплуатации заказчика:

1. Процедуру создания нового бэкапа.

2. Процедуру полного восстановления (со всеми предупреждениями).

3. Контактные данные для технической поддержки.

Критически важно не просто передать эти файлы, но и провести краткое обучение для ответственного лица со стороны заказчика. Клиент или его служба эксплуатации должны понимать важность регулярного создания резервных копий и быть в состоянии выполнить его самостоятельно.

Что дальше

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