Создание полного бэкапа системы

Цели и компоненты полного бэкапа

> 🔗 Связанный материал: В предыдущем уроке (COURSE-03-M08-L01) мы рассмотрели экспорт потоков (flows) из Node-RED. Полный бэкап включает в себя эти потоки, но также и многие другие критически важные файлы, обеспечивая целостность и возможность полного восстановления системы.

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

Ключевое отличие полного бэкапа от простого экспорта потоков Node-RED заключается в полноте охвата. Экспорт `flows.json` сохраняет только логику сценариев, но оставляет за рамками множество критически важных элементов.

| Компонент | Частичный экспорт (flows.json) | Полный бэкап системы |

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

| Логика сценариев | Да | Да |

| Учетные данные (credentials) | Нет (`flows_cred.json` не экспортируется) | Да |

| Настройки Node-RED (`settings.js`) | Нет | Да |

| Установленные модули (узлы) | Нет (только список в JSON) | Да (`package.json`) |

| Библиотеки и пользовательские скрипты | Нет | Да (директория `lib`) |

| Настройки сети (статический IP) | Нет | Да (`/etc/network/interfaces`) |

| Пользовательские сервисы `systemd` | Нет | Да |

| Задачи по расписанию (`cron`) | Нет | Да (`/etc/crontab`) |

| Данные контекста Node-RED | Нет | Да (файлы в директории `context`) |

Создание полного бэкапа преследует две главные цели:

Восстановление после сбоев (Disaster Recovery): В случае выхода из строя SD-карты, аппаратного сбоя контроллера или критической ошибки в конфигурации, полный бэкап позволяет развернуть систему на новом устройстве за минуты, а не за дни. Это минимизирует простой объекта и экономит ресурсы инсталлятора.

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

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

---

Практика: Архивирование рабочей директории Node-RED

Рабочая директория Node-RED является сердцем всей системы автоматизации на контроллере HI. Она содержит не только сценарии, но и все сопутствующие настройки, учетные данные и зависимости.

Стандартное расположение и ключевые компоненты

На контроллерах HI, работающих под управлением Debian Linux, рабочая директория Node-RED по умолчанию находится по пути `/home/hi/.node-red`. Обратите внимание, что `.node-red` — это скрытая директория.

> 💡 Подсказка: Для просмотра скрытых файлов и директорий в командной строке используйте команду `ls -la`.

Давайте подробно разберем содержимое этой директории:

• `flows_имя_контроллера.json`: Основной файл сценариев. Это тот самый JSON, который вы экспортируете через интерфейс Node-RED.
• `flows_имя_контроллера_cred.json`: Критически важный файл! Он содержит все секреты и учетные данные, которые вы вводили в полях "credentials" в узлах: пароли от MQTT-брокеров, баз данных MySQL, ключи API для внешних сервисов. Этот файл зашифрован, но без него ваши сценарии не смогут авторизоваться в других системах.
• `settings.js`: Файл глобальных настроек Node-RED. Здесь определяются такие параметры, как имя пользователя для входа в редактор, настройки персистентного контекста (например, для сохранения состояний FSM после перезагрузки), конфигурация библиотек и многое другое.
• `package.json`: Файл-манифест, содержащий список всех дополнительно установленных палитр (узлов) и их версий. При восстановлении на чистой системе этот файл позволяет автоматически установить все необходимые зависимости командой `npm install`.
• `package-lock.json`: Фиксирует точные версии всех зависимостей. Гарантирует, что при восстановлении будут установлены те же версии пакетов, что и в оригинальной системе, предотвращая проблемы совместимости.
• `node_modules/`: Директория, содержащая код всех установленных узлов. Она занимает много места, и в некоторых стратегиях бэкапа ее исключают, полагаясь на восстановление через `package.json`. Однако для максимально быстрого восстановления рекомендуется включать ее в архив.
• `lib/`: Директория для хранения ваших собственных переиспользуемых ресурсов, например, JavaScript-библиотек или конфигурационных JSON-файлов, доступных из узлов `function`.
• `context/`: Если вы используете персистентный контекст (хранение переменных `flow` и `global` в файлах), эта директория будет содержать данные о состоянии ваших сценариев. Ее архивирование обязательно для восстановления системы в том же состоянии, в котором она была на момент бэкапа.

Создание архива с помощью `tar`

Для создания архива всей директории используется стандартная утилита Linux — `tar` (Tape Archive). Мы будем использовать ее для создания сжатого архива формата `.tar.gz`.

Подключитесь к контроллеру по SSH и выполните следующую команду:

# Переходим в домашнюю директорию пользователя 'hi'
cd /home/hi

# Создаем сжатый архив директории .node-red
# Ключи:
# c - create (создать архив)
# z - gzip (сжать с помощью gzip)
# v - verbose (выводить имена файлов в процессе)
# f - file (указать имя файла архива)
tar -czvf node-red-backup.tar.gz .node-red

После выполнения этой команды в директории `/home/hi` появится файл `node-red-backup.tar.gz`. Он содержит полную копию всех ваших сценариев, учетных данных, настроек и установленных узлов. Этот один файл является первым и самым важным компонентом вашего полного бэкапа.

---

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

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

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

Идентификация и копирование важных файлов

Наиболее частые системные файлы, которые модифицируются инженером-инсталлятором, включают:

• `/etc/network/interfaces`: Настройки сетевых интерфейсов. Критически важно, если вы настраивали статический IP-адрес для Ethernet-порта контроллера, вместо использования DHCP.
• `/etc/systemd/system/`: Директория, где хранятся пользовательские юнит-файлы `systemd`. Например, если вы создавали сервис для автоматического запуска скрипта при старте системы.
• `/etc/crontab` и директория `/etc/cron.d/`: Файлы конфигурации планировщика задач `cron`. Если вы настраивали периодический запуск каких-либо скриптов (например, для очистки логов или создания бэкапов), эти файлы нужно сохранить.
• `/home/hi/.ssh/authorized_keys`: Файл, содержащий публичные SSH-ключи для беспарольного доступа к контроллеру. Его сохранение упростит удаленное администрирование после восстановления.
• `/etc/hi_eeprom.conf` (гипотетический пример): Некоторые специфичные для платформы конфигурации могут храниться в директории `/etc`. Важно документировать все нестандартные изменения, вносимые в систему.

Создание скрипта для выборочного архивирования

Чтобы не копировать каждый файл вручную, удобно создать небольшой shell-скрипт, который соберет все необходимые системные файлы в одну временную директорию. Для этого идеально подходит утилита `rsync`, так как она умеет сохранять структуру директорий.

Создайте временную директорию для сбора системных файлов:

    mkdir -p /home/hi/system_backup/etc

    

Создайте и выполните скрипт `prepare_system_backup.sh`:

    # /home/hi/prepare_system_backup.sh


    #!/bin/bash

    # Директория назначения для бэкапа
    BACKUP_DIR="/home/hi/system_backup"

    # Очищаем директорию от предыдущих бэкапов (если есть)
    rm -rf ${BACKUP_DIR}/*

    # Создаем структуру директорий. Ключ --parents у `mkdir` создает вложенные директории.
    mkdir -p ${BACKUP_DIR}/etc/network
    mkdir -p ${BACKUP_DIR}/etc/systemd
    mkdir -p ${BACKUP_DIR}/home/hi/.ssh

    echo "Копирование системных конфигурационных файлов..."

    # Копируем файл сетевых настроек
    cp /etc/network/interfaces ${BACKUP_DIR}/etc/network/

    # Копируем пользовательские сервисы systemd. Используем rsync для сохранения структуры.
    rsync -av /etc/systemd/system/ ${BACKUP_DIR}/etc/systemd/system/

    # Копируем настройки cron
    cp /etc/crontab ${BACKUP_DIR}/etc/

    # Копируем SSH ключи
    cp /home/hi/.ssh/authorized_keys ${BACKUP_DIR}/home/hi/.ssh/

    echo "Копирование завершено. Файлы сохранены в ${BACKUP_DIR}"
    

Сделайте скрипт исполняемым и запустите его:

    chmod +x /home/hi/prepare_system_backup.sh

    /home/hi/prepare_system_backup.sh
    

После выполнения скрипта у вас в директории `/home/hi/system_backup` будет аккуратно разложенная копия всех важных системных файлов. Теперь все готово к созданию единого финального архива.

---

Объединение, проверка и хранение архива

На последнем этапе мы объединим архив Node-RED и копию системных файлов в один общий бэкап, проверим его целостность и обсудим лучшие практики хранения.

Создание единого архива проекта

Имея два компонента — `node-red-backup.tar.gz` и директорию `system_backup` — мы можем создать финальный архив проекта. Рекомендуется использовать осмысленное имя файла, включающее название объекта и дату создания.

# Переходим в домашнюю директорию, где лежат наши заготовки
cd /home/hi

# Создаем финальный архив.
# Мы уже находимся в /home/hi, поэтому указываем относительные пути.
# В архив попадет файл 'node-red-backup.tar.gz' и вся директория 'system_backup'.
tar -czvf SmartHome_Petrova_Backup_2023-10-27.tar.gz node-red-backup.tar.gz system_backup

# После создания архива временные файлы можно удалить
rm node-red-backup.tar.gz
rm -rf system_backup

Теперь у вас есть один файл `SmartHome_Petrova_Backup_2023-10-27.tar.gz`, который является полной резервной копией вашего проекта.

Проверка целостности с помощью контрольных сумм

Чтобы убедиться, что файл архива не повредился при копировании (например, на флешку или по сети), необходимо вычислить его контрольную сумму (checksum). Это уникальный цифровой отпечаток файла. Если хоть один бит в файле изменится, контрольная сумма будет совершенно другой.

Наиболее популярные утилиты — `md5sum` и `sha256sum`.

# Рассчитать контрольную сумму MD5
md5sum SmartHome_Petrova_Backup_2023-10-27.tar.gz

# Вывод будет выглядеть так:
# a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4  SmartHome_Petrova_Backup_2023-10-27.tar.gz

# Рассчитать более надежную контрольную сумму SHA256
sha256sum SmartHome_Petrova_Backup_2023-10-27.tar.gz

# Вывод:
# 123...abc  SmartHome_Petrova_Backup_2023-10-27.tar.gz

Сохраните эту строку с контрольной суммой в текстовом файле рядом с бэкапом. После копирования архива на другой носитель, запустите команду `sha256sum` на нем и сравните полученный результат с эталонным. Если они совпадают — файл скопирован без ошибок.

Рекомендации по хранению

Один бэкап — это не бэкап. Правило "3-2-1" гласит:

• 3 копии данных.
• На 2 разных типах носителей.
• 1 копия вне основной локации.

Для инсталлятора это означает:

Локальная копия: Скопируйте архив с контроллера на свой рабочий ноутбук.

Внешний носитель: Сохраните копию на отдельную флешку или внешний жесткий диск, который хранится в офисе.

Облачное/Удаленное хранилище: Загрузите архив в защищенное корпоративное облачное хранилище (например, Nextcloud, Google Drive, Dropbox) или на файловый сервер компании.

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

Файл бэкапа — это результат вашей многодневной работы. Относитесь к его хранению с той же серьезностью, что и к физическому оборудованию на объекте.

---

Итоги и рекомендации

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

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

Давайте подытожим ключевые шаги:

• Резервное копирование должно включать как минимум два компонента: рабочую директорию Node-RED (`/home/hi/.node-red`) и кастомные системные конфигурации (сеть, сервисы, cron).
• Для создания архивов используйте стандартную утилиту `tar`.
• Всегда проверяйте целостность созданного архива с помощью контрольных сумм (`md5sum` или `sha256sum`).
• Придерживайтесь строгой политики хранения бэкапов: используйте несколько носителей и храните одну копию вне объекта.

Автоматизация процесса

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

Пример записи в `/etc/crontab`:

# Каждую субботу в 3:00 ночи запускать скрипт полного бэкапа
0 3   6   hi   /usr/local/bin/full_backup_script.sh

Документирование процесса восстановления

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

Что дальше

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