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

Урок 4 · Основы умного дома · 30 мин · theory

Важность резервного копирования в системе умного дома

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

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

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

Определение рисков

Существует три основные категории рисков, которые делают бэкапы жизненно необходимыми:

Аппаратный сбой: Это наиболее частая причина потери данных. SD-карты и SSD-накопители, используемые в контроллерах, имеют ограниченный ресурс циклов перезаписи. Внезапный отказ, повреждение файловой системы или физическая поломка могут произойти в любой момент.

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

Человеческий фактор: Случайное удаление важного потока в Node-RED, некорректное изменение `settings.js` или ошибочная команда в консоли — все это может привести к частичной или полной неработоспособности системы. Наличие бэкапа позволяет "откатиться" к последней работающей версии за считанные минуты.

Объекты резервного копирования

Что именно нужно копировать? Критически важные компоненты системы можно разделить на две группы:

Конфигурация: Это "мозг" вашей системы. Потеря конфигурации означает полную потерю всей логики.

* Node-RED: Потоки (`flows.json`), учетные данные (`flows_cred.json`), настройки (`settings.js`), установленные узлы (содержимое папки `node_modules`).

* Системные сервисы: Конфигурация MQTT-брокера (`/etc/mosquitto/`), настройки Zigbee-шлюза (`/opt/zigbee2mqtt/data/`), правила для `wb-rules`.

* Конфигурация ОС: Сетевые настройки (`/etc/network/interfaces`), правила `firewall`, системные таймеры (`crontab`).

Данные: Это история работы вашей системы.

* Исторические данные: Показания датчиков температуры, влажности, энергопотребления, хранящиеся в базах данных (например, InfluxDB, MySQL, PostgreSQL).

* Журналы (логи): Системные журналы и логи аудита, которые могут быть важны для анализа инцидентов.

Последствия отсутствия бэкапов

Полная потеря автоматизации: Все ваши сценарии, созданные в уроках Понятие состояния (State) и Сценарий vs. Flow: где живёт логика, придется создавать с нуля.
Многочасовое ручное восстановление: Даже если у вас есть документация, ручное воссоздание сложной системы — это часы, а иногда и дни кропотливой работы с высоким риском ошибок.
Потеря ценной информации: История потребления ресурсов, температурные графики, данные о работе оборудования — все это будет безвозвратно утеряно, что делает невозможным анализ и оптимизацию системы.

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

---

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

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

> 💡 Подсказка: Для большинства проектов на контроллерах типа Wirenboard или Raspberry Pi рекомендуется стратегия ежедневного полного бэкапа (Full) ключевых конфигурационных файлов с помощью утилиты `rsync` и планировщика `cron` на внешний носитель, например, USB-флешку, подключенную к контроллеру.

Типы резервного копирования

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

| ----------------------------------------- | ------------------------------------------------------------------------- | ---------------------------------------------- | --------------------------------------------------------------------- | ------------------------------------------------------ |

| Full (Полный) | Копируются абсолютно все указанные файлы и папки. | Простое восстановление: нужен только один архив. | Большой объем, высокая нагрузка на систему во время копирования. | Ежедневно для конфигураций. Еженедельно для данных. |

| Incremental (Инкрементальный) | Копируются только файлы, измененные с момента последнего бэкапа любого типа. | Очень быстро, минимальный объем хранения. | Сложное восстановление: требуется полный бэкап и вся цепочка инкрементов. | Для очень больших объемов данных с частыми изменениями. |

| Differential (Дифференциальный) | Копируются файлы, измененные с момента последнего полного бэкапа. | Быстрее полного, проще в восстановлении, чем инкрементальный. | Объем архива растет с каждым днем после полного бэкапа. | Компромиссный вариант для ежедневного бэкапа данных. |

Инструменты в Linux

Наш контроллер работает под управлением Debian, что дает нам доступ к мощным и надежным стандартным инструментам командной строки.

`rsync` (remote sync): Это основной инструмент для резервного копирования. Его главное преимущество — эффективность. `rsync` копирует только измененные части файлов, что делает процесс очень быстрым после первого полного копирования. Он также умеет сохранять права доступа и временные метки файлов, что критически важно для корректного восстановления.

`cron`: Стандартный планировщик задач в Linux. Он позволяет автоматически запускать скрипты или команды по заданному расписанию (например, каждую ночь в 3:00). Один раз настроив `cron`, вы можете быть уверены, что бэкапы создаются регулярно без вашего участия.

`tar` (tape archive): Утилита для упаковки множества файлов и папок в один архивный файл (`.tar`). Часто используется в связке с `gzip` или `bzip2` для сжатия (`.tar.gz`), что позволяет экономить место на носителе.

Внешние хранилища

Главное правило резервного копирования: копия должна храниться отдельно от оригинала. Бэкап на той же SD-карте, где работает система, абсолютно бесполезен при ее физическом выходе из строя.

USB-накопитель: Самый простой и доступный вариант. Подключите USB-флешку или внешний HDD к контроллеру и настройте скрипт на копирование данных на него.
NAS (Network Attached Storage): Сетевое хранилище в вашей локальной сети. Это более надежный вариант, часто с RAID-массивами для защиты от отказа дисков. Бэкап на NAS можно настроить с помощью `rsync` по сети.
Облачные сервисы: Копирование в облако (Amazon S3, Google Drive, Dropbox, Яндекс.Диск) обеспечивает географическую распределенность. Если на объекте произойдет пожар или кража, ваши данные останутся в безопасности. Для этого существуют специальные утилиты вроде `rclone`.

Для уровня Foundation мы сфокусируемся на самом распространенном и простом в настройке варианте: автоматическое копирование на USB-накопитель с помощью `rsync` и `cron`.

---

Практика: Автоматизация бэкапа Node-RED и системных сервисов

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

Шаг 1: Идентификация ключевых файлов

Прежде чем что-то копировать, нужно точно знать, где это "что-то" лежит. Для нашей типовой системы на базе Debian (как на Wirenboard) пути будут следующими:

Node-RED: Все самое важное находится в скрытой папке в домашнем каталоге пользователя, от имени которого запущен Node-RED (обычно это `root`).

* `~/.node-red/flows.json`: Основной файл, хранящий все ваши потоки (flows).

* `~/.node-red/flows_cred.json`: Зашифрованный файл с учетными данными, которые вы вводили в узлах (пароли от баз данных, API-ключи). Критически важен!

* `~/.node-red/settings.js`: Файл настроек самого Node-RED.

* Проще всего копировать всю папку `~/.node-red/` целиком, за исключением папки `node_modules`, которая содержит много файлов и может быть восстановлена командой `npm install`.

MQTT-брокер (Mosquitto):

* `/etc/mosquitto/`: Эта директория содержит все файлы конфигурации, включая `mosquitto.conf` и настройки аутентификации.

Zigbee2MQTT:

* `/opt/zigbee2mqtt/data/`: Здесь находится главный файл `configuration.yaml`, а также база данных сопряженных устройств `database.db`. Потеря этих файлов потребует повторного сопряжения всех Zigbee-устройств.

Шаг 2: Создание shell-скрипта для бэкапа

Создадим файл скрипта, который будет выполнять всю работу. Подключитесь к контроллеру по SSH и выполните:

nano /root/backup_script.sh

Вставьте в открывшийся редактор следующий код. Внимательно прочтите комментарии, они объясняют каждую строку.

#!/bin/bash

# ==============================================================================
# Скрипт автоматического резервного копирования для контроллера умного дома
# ==============================================================================

# --- Настройки ---
# Точка монтирования USB-накопителя. Убедитесь, что флешка монтируется сюда.
BACKUP_DEST="/mnt/backup"
# Директории, которые мы хотим забэкапить.
SOURCE_DIRS=(
    "/root/.node-red"
    "/etc/mosquitto"
    "/opt/zigbee2mqtt/data"
    "/var/lib/influxdb" # Добавим для примера бэкап данных InfluxDB
)
# Файлы, которые нужно скопировать отдельно
SOURCE_FILES=(
    "/etc/crontab"
)
# Папки для исключения из бэкапа (например, тяжелые node_modules)
EXCLUDE_NODE_RED="--exclude 'node_modules' --exclude 'externalModules'"

# --- Логика скрипта ---
# Создаем имя папки для сегодняшнего бэкапа в формате ГГГГ-ММ-ДД
TODAY=$(date +"%Y-%m-%d")
DEST_DIR="${BACKUP_DEST}/${TODAY}"

# Проверяем, смонтирован ли USB-накопитель. Если нет - выходим.
if ! mountpoint -q "$BACKUP_DEST"; then
    echo "Ошибка: Директория для бэкапа $BACKUP_DEST не является точкой монтирования."
    exit 1
fi

# Создаем директорию для сегодняшнего бэкапа
mkdir -p "$DEST_DIR"

# Копируем директории с помощью rsync
echo "Начинаю копирование директорий..."
for dir in "${SOURCE_DIRS[@]}"; do
    if [ -d "$dir" ]; then
        # Если это директория .node-red, применяем исключения
        if [[ "$dir" == "/root/.node-red" ]]; then
            rsync -a --delete $EXCLUDE_NODE_RED "$dir/" "$DEST_DIR/node-red/"
        else
            # Для остальных директорий просто копируем
            dir_name=$(basename "$dir")
            rsync -a --delete "$dir/" "$DEST_DIR/$dir_name/"
        fi
        echo "  - Директория $dir скопирована."
    else
        echo "  - Предупреждение: директория $dir не найдена."
    fi
done

# Копируем отдельные файлы
echo "Копирую отдельные файлы..."
mkdir -p "$DEST_DIR/etc_files/"
for file in "${SOURCE_FILES[@]}"; do
    if [ -f "$file" ]; then
        cp "$file" "$DEST_DIR/etc_files/"
        echo "  - Файл $file скопирован."
    else
        echo "  - Предупреждение: файл $file не найден."
    fi
done

# Создаем архив из скопированной папки для экономии места
echo "Создаю сжатый архив..."
tar -czf "${BACKUP_DEST}/backup-${TODAY}.tar.gz" -C "$DEST_DIR" .

# Удаляем временную папку, оставляем только архив
rm -rf "$DEST_DIR"

# Удаляем старые бэкапы (старше 30 дней)
echo "Удаляю старые бэкапы..."
find "$BACKUP_DEST" -name "backup-*.tar.gz" -mtime +30 -exec rm {} \;

echo "Резервное копирование успешно завершено: ${BACKUP_DEST}/backup-${TODAY}.tar.gz"
exit 0

Сохраните файл (`Ctrl+X`, затем `Y`, затем `Enter`) и сделайте его исполняемым:

chmod +x /root/backup_script.sh

Шаг 3: Настройка `cron` для ежедневного запуска

Теперь настроим автоматический запуск этого скрипта. Откройте таблицу `cron` для пользователя `root`:

crontab -e

В конец файла добавьте следующую строку:

# Запускать скрипт резервного копирования каждый день в 3:30 ночи
30 3   * /root/backup_script.sh > /var/log/backup.log 2>&1

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

`/root/backup_script.sh`: Путь к нашему скрипту.
`> /var/log/backup.log 2>&1`: Эта часть перенаправляет весь вывод (и стандартный, и ошибки) в лог-файл. Это очень полезно для диагностики, если что-то пойдет не так.

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

---

Восстановление системы из резервной копии

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

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

Пошаговый алгоритм восстановления

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

Подготовка:

* Подключитесь к контроллеру по SSH.

* Убедитесь, что USB-накопитель с бэкапами подключен и смонтирован в `/mnt/backup`.

* Найдите нужный архив, например `backup-2023-10-27.tar.gz`.

Распаковка архива: Создайте временную папку и распакуйте туда архив.

mkdir /tmp/restore_temp tar -xzf /mnt/backup/backup-2023-10-27.tar.gz -C /tmp/restore_temp

Теперь в `/tmp/restore_temp` у вас лежит точная копия файлов на момент бэкапа.

Остановка сервисов: Остановите ВСЕ сервисы, конфигурацию которых вы собираетесь восстанавливать.

systemctl stop nodered systemctl stop mosquitto # systemctl stop zigbee2mqtt

Восстановление файлов: Используйте `rsync` для копирования файлов из временной папки в их оригинальное расположение. `rsync` с ключом `-a` позаботится о правах доступа.

# Восстанавливаем Node-RED rsync -a --delete /tmp/restore_temp/node-red/ /root/.node-red/ # Восстанавливаем Mosquitto rsync -a --delete /tmp/restore_temp/mosquitto/ /etc/mosquitto/

Ключ `--delete` важен: он удалит в целевой папке файлы, которых не было в бэкапе (например, поврежденные или ошибочно созданные).

Проверка прав доступа (опционально, но рекомендуется): Хотя `rsync -a` должен сохранять права, не лишним будет убедиться, что владелец и права корректны. Например, для папки Node-RED:

chown -R root:root /root/.node-red

Запуск сервисов: Запустите сервисы в обратном порядке и проверьте их статус.

systemctl start mosquitto systemctl status mosquitto systemctl start nodered systemctl status nodered

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

Частичное восстановление

Иногда не нужно восстанавливать всю систему. Например, вы случайно удалили один важный `flow` и хотите вернуть только его. В этом случае алгоритм похож, но проще:

Распакуйте архив во временную папку.

Остановите только нужный сервис (`systemctl stop nodered`).

Скопируйте только один файл, например `flows.json`.

cp /tmp/restore_temp/node-red/flows.json /root/.node-red/flows.json

Запустите сервис (`systemctl start nodered`).

"Холодное" и "Горячее" восстановление

"Холодное" восстановление: Процедура с полной остановкой сервисов, которую мы рассмотрели выше. Это самый надежный и предпочтительный метод для систем умного дома, так как гарантирует целостность данных.
"Горячее" восстановление: Восстановление без остановки сервиса. Применимо только для систем, которые специально это поддерживают (например, некоторые базы данных). В нашем случае для Node-RED, Mosquitto и других сервисов "горячее" восстановление недопустимо и почти гарантированно приведет к проблемам.

---

Итоги и контрольный список

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

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

Резервное копирование (backup): Процесс создания копии данных для защиты от их потери.
Восстановление (recovery): Процесс возвращения системы в рабочее состояние из резервной копии.
Full, Incremental, Differential backup: Различные стратегии копирования с компромиссом между скоростью, объемом и сложностью восстановления.
cron: Стандартный планировщик задач в Linux для автоматизации.
rsync: Эффективная утилита для синхронизации и копирования файлов.

Ваш контрольный список по резервному копированию:

[ ] Резервное копирование — не опция, а обязательный компонент надежной системы. Убедитесь, что оно настроено на каждом вашем объекте.
[ ] Автоматизация — ключ к регулярности. Настроенный один раз `cron` работает без вашего участия. Ручные бэкапы почти всегда забывают делать.
[ ] Храните копии отдельно от основного устройства. Бэкап на той же SD-карте бесполезен при ее физическом выходе из строя. Используйте USB-драйв, NAS или облако.
[ ] Регулярно проверяйте возможность восстановления. Хотя бы раз в квартал проводите тестовое восстановление на стенде. Непроверенный бэкап — это лишь ложное чувство безопасности.
[ ] Документируйте вашу стратегию бэкапа и процесс восстановления. Запишите, что, куда и как часто копируется, и приложите пошаговую инструкцию по восстановлению. Это сэкономит вам массу времени и нервов в экстренной ситуации.

Что дальше?

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