Главная → Академия → Основы умного дома → Резервное копирование и восстановление Flows

Резервное копирование и восстановление Flows

Урок 1 · Основы умного дома · 30 мин · theory
id: COURSE-01-M07-L02

title: "Резервное копирование и восстановление Flows"


level: foundation


tags: ["резервное копирование", "восстановление", "node-red", "backup", "restore", "cron", "shell", "отказоустойчивость"]


prerequisites: ["COURSE-01-M07-L01", "COURSE-00-M03"]


version: 1.0


status: published

---

Введение: критическая важность резервных копий

> ⚠️ Внимание: Даже самый надежный промышленный контроллер не застрахован от сбоя накопителя. Резервная копия — это не рекомендация, а обязательное условие для любой профессиональной инсталляции.

В предыдущем уроке, COURSE-01-M07-L01 «Что может пойти не так?», мы подробно рассмотрели различные риски, угрожающие стабильной работе системы умного дома, от аппаратных сбоев до человеческого фактора. Центральным элементом, уязвимым для всех этих угроз, является логика автоматизации — ваши сценарии Node-RED.

Сценарии Node-RED (flows) — это не просто набор соединенных узлов. Это интеллектуальная собственность инженера и квинтэссенция функциональности всего объекта. В них заложены часы, а иногда и недели работы: отладка алгоритмов климат-контроля, настройка световых сцен, интеграция с внешними сервисами и создание уникальных пользовательских функций. Потеря этих данных равносильна потере «мозга» умного дома.

Рассмотрим типичные сценарии, ведущие к потере данных:

  • Сбой носителя информации. В большинстве контроллеров, включая нашу платформу, операционная система и пользовательские данные хранятся на SD-карте или eMMC-накопителе. Эти компоненты имеют ограниченный ресурс циклов перезаписи и чувствительны к сбоям питания. Внезапный выход накопителя из строя — одна из самых частых причин отказа контроллера.
  • Аппаратный отказ контроллера. Физическое повреждение устройства (скачок напряжения, перегрев, попадание влаги) может сделать невозможным доступ к данным, даже если сам накопитель остался цел.
  • Человеческая ошибка. Это может быть как случайное удаление важной части flow в процессе редактирования без возможности отката, так и ошибочная команда в консоли, которая затирает или повреждает файлы конфигурации.
  • Программный сбой или неудачное обновление. Иногда обновление Node-RED или одного из его модулей (палет) может привести к несовместимости и повреждению существующего файла flows.

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

    Анатомия Node-RED: что и где хранит свои данные

    Для того чтобы грамотно выполнять резервное копирование и восстановление, необходимо точно знать, какие файлы являются критически важными и где они расположены в файловой системе контроллера. Вся конфигурация Node-RED по умолчанию хранится в скрытой директории в домашнем каталоге пользователя (`/home/user/` или `/root/`), который её запускает. Эта директория называется `.node-red`.

    Структура этой директории выглядит следующим образом:

    /home/user/.node-red/

    |-- flows.json
    

    |-- flows_cred.json
    

    |-- settings.js
    

    |-- package.json
    

    |-- package-lock.json
    

    |-- node_modules/
    

    |   |-- node-red-contrib-example-1/
    

    |   `-- node-red-contrib-example-2/
    

    `-- lib/
    

        |-- flows/
    

        `-- functions/

    Рассмотрим ключевые файлы и их назначение:

    * Порт, на котором работает веб-интерфейс.

    * Включение/отключение аутентификации для доступа к редактору.

    * Настройки логирования.

    * Путь к библиотеке пользовательских функций.

    * Ключ для шифрования `flows_cred.json`.

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

    > 💡 Подсказка: Для упрощения миграции и восстановления всегда храните файл `package.json` вместе с резервными копиями flow. Это позволит быстро переустановить все необходимые узлы одной командой `npm install` в директории `~/.node-red`.

    Практика: ручное резервное копирование и восстановление

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

    Метод 1: Экспорт через веб-интерфейс Node-RED

    Это самый простой и быстрый способ сохранить копию текущего сценария.

  • Откройте интерфейс Node-RED в браузере.
  • Нажмите на кнопку "бургер-меню" (три горизонтальные линии) в правом верхнем углу.
  • Выберите пункт Export.
  • В появившемся окне вы можете выбрать, что экспортировать:

    • * Current flow: Только активная в данный момент вкладка.

    * All flows: Все вкладки в вашем редакторе.

    * Selected nodes: Только выделенные узлы.

  • Рекомендуется выбирать All flows. Скопируйте содержимое в текстовый файл и сохраните его с расширением `.json` или нажмите Download для загрузки файла.
    • Плюсы: Минусы:

    Этот метод подходит для быстрого обмена фрагментами сценариев, но не годится для полноценного резервного копирования системы.

    Метод 2: Копирование файлов из файловой системы

    Это профессиональный и единственно верный способ создания полной ручной резервной копии. Он требует доступа к контроллеру по сети через SSH. Для копирования файлов используются утилиты `scp` (Secure Copy) или `sftp` (SSH File Transfer Protocol).

    Пошаговый процесс резервного копирования:

    Предполагается, что вы подключены к контроллеру по SSH.

  • Перейдите в директорию Node-RED: `cd ~/.node-red`
  • Теперь скопируйте необходимые файлы на ваш локальный компьютер.
    • Примеры команд `scp`: 
        # Создадим на локальной машине папку для бэкапа

        mkdir -p ~/backups/nodered_controller_backup_$(date +%F)
    


        # Копируем файлы с контроллера (замените user и 192.168.1.10 на ваши данные)
    

        scp user@192.168.1.10:~/.node-red/flows.json ~/backups/nodered_controller_backup_$(date +%F)/
    

        scp user@192.168.1.10:~/.node-red/flows_cred.json ~/backups/nodered_controller_backup_$(date +%F)/
    

        scp user@192.168.1.10:~/.node-red/settings.js ~/backups/nodered_controller_backup_$(date +%F)/
    

        scp user@192.168.1.10:~/.node-red/package.json ~/backups/nodered_controller_backup_$(date +%F)/
    

        

        # pscp.exe должен быть в системном PATH или в текущей директории

        # Создадим папку для бэкапа
    

        New-Item -ItemType Directory -Force -Path "C:\backups\nodered_controller_backup"
    


        # Копируем файлы
    

        pscp.exe user@192.168.1.10:/home/user/.node-red/flows.json C:\backups\nodered_controller_backup\
    

        pscp.exe user@192.168.1.10:/home/user/.node-red/flows_cred.json C:\backups\nodered_controller_backup\

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

    •     sudo systemctl stop nodered.service

  • Скопируйте файлы из вашей резервной копии обратно на контроллер, заменяя существующие.

    •     scp ~/backups/nodered_controller_backup_YYYY-MM-DD/flows.json user@192.168.1.10:~/.node-red/
    

        # Повторите для flows_cred.json и других файлов

  • Если вы разворачиваете бэкап на новом, "чистом" контроллере, сначала установите все палеты.

    •     # На контроллере, в директории ~/.node-red
    

        npm install

  • Запустите сервис Node-RED и проверьте логи на наличие ошибок.

    •     sudo systemctl start nodered.service
    

        sudo journalctl -f -u nodered.service

    Практика: автоматизация бэкапов с помощью Cron и Shell-скрипта

    Ручное резервное копирование эффективно, но зависит от дисциплины инженера. Для надежной защиты данных этот процесс необходимо автоматизировать. Стандартным инструментом для решения этой задачи в Linux является планировщик `cron`.

    > 🔗 Связанный материал: Подробно о работе с командной строкой и скриптами в Linux мы говорили в модуле COURSE-00-M03 «Основы Linux для инженера умного дома». Рекомендуем освежить знания.

    План действий:
  • Создать shell-скрипт, который будет архивировать нужные файлы.
  • Добавить задание в `cron`, чтобы этот скрипт выполнялся автоматически по расписанию (например, каждую ночь).

    • 1. Создание Shell-скрипта для бэкапа

    Создадим файл `nodered_backup.sh` в домашней директории пользователя, например, в `~/scripts/`.

    #!/bin/bash


    # --- НАСТРОЙКИ ---
    

    # Директория с файлами Node-RED
    

    SOURCE_DIR="/home/user/.node-red"
    

    # Директория для хранения локальных бэкапов
    

    BACKUP_DIR="/home/user/backups/nodered"
    

    # Количество дней хранения локальных бэкапов
    

    RETENTION_DAYS=7
    

    # Имя файла бэкапа с датой
    

    TIMESTAMP=$(date +"%Y-%m-%d_%H-%M-%S")
    

    BACKUP_FILENAME="nodered-backup-${TIMESTAMP}.tar.gz"
    


    # --- ОСНОВНАЯ ЛОГИКА ---
    

    echo "Starting Node-RED backup..."
    


    # Создаем директорию для бэкапов, если она не существует
    

    mkdir -p ${BACKUP_DIR}
    


    # Создаем архив .tar.gz с необходимыми файлами
    

    # ВАЖНО: Указываем абсолютные пути к файлам для надежности
    

    tar -czvf ${BACKUP_DIR}/${BACKUP_FILENAME} \
    

        ${SOURCE_DIR}/flows.json \
    

        ${SOURCE_DIR}/flows_cred.json \
    

        ${SOURCE_DIR}/settings.js \
    

        ${SOURCE_DIR}/package.json
    


    echo "Backup created at ${BACKUP_DIR}/${BACKUP_FILENAME}"
    


    # Удаляем старые бэкапы (старше RETENTION_DAYS)
    

    echo "Cleaning up old backups..."
    

    find ${BACKUP_DIR} -type f -mtime +${RETENTION_DAYS} -name 'nodered-backup-*.tar.gz' -delete
    


    echo "Backup process finished."

    Не забудьте сделать скрипт исполняемым: `chmod +x ~/scripts/nodered_backup.sh`.

    Этот скрипт архивирует 4 ключевых файла в один `tar.gz` архив с меткой времени и удаляет архивы старше 7 дней.

    2. Настройка `crontab`

    Теперь добавим задание в `cron`.

  • Откройте редактор crontab командой: `crontab -e`
  • Добавьте в конец файла следующую строку, чтобы запускать скрипт каждую ночь в 03:00:

    •     # Запускать бэкап Node-RED каждый день в 3:00 ночи
    

        0 3   * /home/user/scripts/nodered_backup.sh >> /home/user/logs/nodered_backup.log 2>&1

    `0 3 `: означает "в 0 минут 3-го часа, каждый день, каждый месяц, каждый день недели".

    * `/home/user/scripts/nodered_backup.sh`: полный путь к нашему скрипту.

    * `>> /home/user/logs/nodered_backup.log 2>&1`: перенаправляет весь вывод (стандартный и ошибки) в лог-файл для последующего анализа.

    Для повышения надежности архив можно копировать на внешний носитель, например, на сетевой диск (NAS). Для этого в конец скрипта можно добавить команду `rsync`:

    # ... после создания архива tar ...


    # --- КОПИРОВАНИЕ НА ВНЕШНИЙ СЕРВЕР (NAS) ---
    

    # Адрес и директория на удаленном сервере
    

    REMOTE_USER="backupuser"
    

    REMOTE_HOST="192.168.1.50"
    

    REMOTE_DIR="/volume1/backups/smart_home_controller/"
    


    echo "Syncing backup to remote server..."
    

    rsync -avz --remove-source-files ${BACKUP_DIR}/${BACKUP_FILENAME} ${REMOTE_USER}@${REMOTE_HOST}:${REMOTE_DIR}

    Эта команда скопирует архив на NAS и удалит исходный файл с контроллера, чтобы не занимать место. Для работы `rsync` по SSH без пароля требуется предварительная настройка SSH-ключей.

    Итоги и лучшие практики: стратегия 3-2-1

    Мы рассмотрели ручные и автоматизированные методы резервного копирования. Но наличие бэкапа — это лишь половина дела. Важна целостная стратегия его хранения и проверки.

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

    Золотым стандартом в индустрии является правило «3-2-1»:

    Применение стратегии 3-2-1 для нашего контроллера:
  • Копия 1 (рабочая): Файлы на SD-карте контроллера.
  • Копия 2 (локальный бэкап): Ежедневный автоматический бэкап по `cron` на локальный NAS (другой носитель).
  • Копия 3 (off-site бэкап): Еженедельная синхронизация папки с бэкапами на NAS с зашифрованным облачным хранилищем.

    • Наконец, документируйте вашу стратегию и процедуру восстановления. Создайте простой runbook, который станет частью проектной документации для объекта. В нем должно быть четко описано, где хранятся бэкапы, как получить к ним доступ и какие шаги необходимо предпринять для полного восстановления системы. Это сэкономит драгоценное время и нервы в экстренной ситуации, особенно если восстановление будет проводить другой специалист.

    ---

    Лабораторные работы

    COURSE-01-M07-LAB01: Ручное резервное копирование и восстановление

    1. [ ] Подключиться к контроллеру по SSH.

    2. [ ] С помощью `scp` или SFTP-клиента (FileZilla, WinSCP) скопировать файлы `flows.json`, `flows_cred.json`, `settings.js`, `package.json` из `~/.node-red` на ваш локальный ПК.

    3. [ ] Открыть интерфейс Node-RED, удалить один или несколько узлов/вкладок и нажать "Deploy". Убедиться, что логика удалена.

    4. [ ] Остановить сервис Node-RED на контроллере (`sudo systemctl stop nodered.service`).

    5. [ ] Скопировать файл `flows.json` из резервной копии обратно на контроллер.

    6. [ ] Запустить сервис Node-RED (`sudo systemctl start nodered.service`).

    7. [ ] Открыть интерфейс Node-RED и убедиться, что удаленная логика восстановлена.

    COURSE-01-M07-LAB02: Настройка автоматического бэкапа

    1. [ ] Создать директорию `~/scripts` и `~/backups/nodered` на контроллере.

    2. [ ] Создать исполняемый файл `~/scripts/nodered_backup.sh`, используя шаблон из урока.

    3. [ ] Запустить скрипт вручную (`./scripts/nodered_backup.sh`) и убедиться, что в папке `~/backups/nodered` появился архив `.tar.gz`.

    4. [ ] Открыть `crontab -e` и добавить задание на запуск скрипта в любое время (например, каждые 5 минут для теста: `/5 *`).

    5. [ ] Подождать указанное время и проверить, появился ли новый архив в папке `~/backups/nodered`.

    6. [ ] Проверить, что механизм ротации (удаления старых бэкапов) работает, изменив `RETENTION_DAYS=0` и запустив скрипт несколько раз.

    7. [ ] Вернуть настройки `crontab` к запуску раз в день (например, `0 3 *`).

    ---

    Тест для самопроверки (Quiz)

    COURSE-01-M07-QUIZ
  • Какой файл содержит логику ваших сценариев, связи между узлами и их настройки?
  • Почему опасно публиковать файл `flows_cred.json` в открытом доступе?
  • Какой метод ручного бэкапа НЕ сохраняет учетные данные (пароли, API-ключи)?
  • Какая команда в Linux используется для остановки сервиса Node-RED перед восстановлением?
  • Что делает команда `crontab -e`?
  • В чем основное преимущество автоматического бэкапа перед ручным?
  • Расшифруйте правило «3-2-1» применительно к данным.
  • Вы восстановили `flows.json` на новом контроллере, но узлы показывают ошибку "unknown node type". Какого файла, скорее всего, не хватает и какое действие нужно выполнить?
  • Какая команда используется для архивации файлов в Linux?
  • Зачем в скрипте бэкапа нужна функция удаления старых архивов?

    • ---

    Мини-runbook: "Что делать, если..."

    Проблема: После восстановления из бэкапа Node-RED не запускается или падает в цикле перезагрузки.
  • Проверьте логи: `sudo journalctl -f -u nodered.service`. Ищите сообщения об ошибках. Чаще всего это синтаксическая ошибка в `flows.json` или `settings.js`.
  • Запустите Node-RED в безопасном режиме: `node-red --safe`. Это запустит редактор без запуска самих flows. Вы сможете отредактировать и исправить проблемную логику.
  • Проверьте права доступа: Убедитесь, что восстановленные файлы принадлежат пользователю, от имени которого запускается Node-RED (`sudo chown -R user:user ~/.node-red`).
    • Проблема: После восстановления flows работают, но не могут подключиться к MQTT/базе данных.
  • Проверьте `flows_cred.json`: Скорее всего, вы забыли восстановить этот файл, или он был поврежден. Восстановите его из той же резервной копии, что и `flows.json`.
  • Проверьте ключ шифрования: Если вы переносили Node-RED на новый контроллер и задавали `credentialSecret` в `settings.js` вручную, убедитесь, что он идентичен старому. Иначе Node-RED не сможет расшифровать `flows_cred.json`.
    • Проблема: Автоматический бэкап по `cron` не создается.
  • Проверьте лог-файл бэкапа: Посмотрите файл, в который вы перенаправили вывод в `crontab` (например, `/home/user/logs/nodered_backup.log`). Там может быть информация об ошибке.
  • Проверьте пути: Убедитесь, что в скрипте и в `crontab` используются абсолютные (полные) пути к файлам (`/home/user/scripts/...` вместо `~/scripts/...`). Cron работает в ином окружении и может не знать о ваших переменных.
  • Проверьте права на исполнение: Убедитесь, что на файл скрипта установлены права на выполнение (`chmod +x`).

    • ---

    📋 Ключевые понятия:

    ✨ Результаты обучения:

    ---

    Что дальше?

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

    ➡️ Следующий урок: COURSE-01-M07-L03: Использование EEPROM и функции ПЛК для критически важных сценариев