Бэкап и восстановление Node-RED

MAATRIX

Полгода автоматизаций — датчики, MQTT-топики, интеграции с Home Assistant, кастомные function-ноды — и всё это живёт в одном файле flows.json на диске сервера. Если диск умрёт или кто-то случайно нажмёт «Deploy» поверх нужной версии, восстанавливать логику вручную по памяти долго и обидно. Ниже — рабочая схема бэкапа Node-RED: что именно копировать, как делать это руками и по расписанию, и как поднять окружение заново на чистом сервере за несколько минут.

Что и где хранится: структура userDir Node-RED

Все данные Node-RED живут не в самом приложении, а в рабочей директории — userDir. По умолчанию это ~/.node-red (для systemd-установки) или /data внутри контейнера, если вы разворачивали через Docker.

Внутри найдёте:

~/.node-red/
├── flows.json          # сами потоки: ноды, связи, конфигурация
├── flows_cred.json      # зашифрованные credentials (пароли, токены API)
├── package.json         # список установленных npm-нод (contrib-пакеты)
├── package-lock.json
├── settings.js           # конфигурация редактора, порты, авторизация
├── node_modules/         # установленные ноды (можно не бэкапить — переустанавливаются)
├── lib/                   # библиотеки функций, если используете
└── .config.*.json        # состояние палитры и рантайма

Ключевой момент: node_modules бэкапить не обязательно — это восстанавливаемый артефакт (npm install по package.json вернёт всё как было). А вот flows.json, flows_cred.json, settings.js и package.json — это и есть ваш проект, без них потоки нужно будет собирать заново руками.

Отдельно про flows_cred.json: он зашифрован ключом, который либо задан явно в settings.js через credentialSecret, либо сгенерирован автоматически и лежит в .config.runtime.json. Если бэкапите flows_cred.json без ключа шифрования — восстановить пароли из него не получится. Правило простое: credentialSecret в settings.js должен быть зафиксирован вручную (а не оставлен на автогенерацию), и сам settings.js обязан попадать в бэкап вместе с flows_cred.json.

Быстрый бэкап через экспорт потоков в интерфейсе

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

В редакторе: меню (☰) → Export → выбираете all flows (или конкретный таб) → формат Export to clipboard либо download — второй вариант сразу сохранит flows.json-подобный файл на диск вашего компьютера.

Обратный процесс — Import → Clipboard/file → new flow или replace flow, если хотите откатиться поверх текущего состояния.

Ограничение этого способа: он экспортирует только сами потоки (ноды и связи), но не credentials и не settings.js. Для полноценного восстановления окружения — включая пароли в credentials-нодах — этого недостаточно, нужен файловый бэкап всего userDir (ниже). UI-экспорт хорош как быстрый снапшот «до и после» правки, а не как основной механизм бэкапа.

Полный бэкап userDir: вручную и по cron

Для systemd-установки (Node-RED запущен как сервис, не в контейнере) бэкап — это архивация каталога:

sudo systemctl stop nodered
tar -czf /root/backups/node-red-$(date +%F).tar.gz \
  --exclude='node_modules' \
  -C /home/pi .node-red
sudo systemctl start nodered

Останавливать сервис на секунду для консистентности архива правильно, но не всегда обязательно: flows.json перезаписывается только при явном Deploy, так что риск словить архив «на полпути записи» невелик. Если простой недопустим — снимайте tar без остановки, но тогда убедитесь, что в момент бэкапа никто не жмёт Deploy.

Автоматизация через cron с ротацией (храним 14 последних копий):

cat > /root/scripts/nodered-backup.sh << 'EOF'
#!/bin/bash
set -e
DEST=/root/backups/node-red
SRC=/home/pi/.node-red
DATE=$(date +%F_%H%M)

mkdir -p "$DEST"
tar -czf "$DEST/node-red-$DATE.tar.gz" \
  --exclude='node_modules' \
  -C "$(dirname $SRC)" "$(basename $SRC)"

# оставляем только последние 14 архивов
ls -1t "$DEST"/node-red-*.tar.gz | tail -n +15 | xargs -r rm --
EOF
chmod +x /root/scripts/nodered-backup.sh

# ежедневно в 03:15
echo "15 3 * * * root /root/scripts/nodered-backup.sh" | sudo tee /etc/cron.d/nodered-backup

Локальные копии на том же диске не спасают от отказа самого сервера — их нужно выгружать за его пределы. Проще всего добавить rclone в тот же скрипт и синхронизировать каталог с бэкапами в S3-совместимое хранилище или на другой VPS:

rclone sync /root/backups/node-red remote:node-red-backups --min-age 1m

Если храните бэкапы отдельного сервиса именно ради архивов и снапшотов, логичнее держать их не рядом с рабочим Node-RED, а на отдельной машине — тогда сбой основного сервера не заденет копии. Подходы к организации такого хранилища и настройке restic/rclone разобраны в статье про бэкап Docker volume на сервере.

Бэкап Node-RED в Docker

Если Node-RED развёрнут через Docker (частый вариант — в связке с Home Assistant), данные лежат в volume, смонтированном на /data внутри контейнера. Посмотреть, где физически находится volume:

docker inspect nodered --format '{{ range .Mounts }}{{ .Source }} -> {{ .Destination }}{{ "\n" }}{{ end }}'

Бэкап volume без остановки контейнера — через временный контейнер, который монтирует тот же volume и архивирует его:

docker run --rm \
  -v nodered_data:/data:ro \
  -v /root/backups/node-red:/backup \
  alpine tar -czf /backup/node-red-docker-$(date +%F).tar.gz -C /data .

Такой подход не трогает работающий контейнер и не требует его останавливать. Восстановление — обратная операция: залить архив в новый volume.

docker run --rm \
  -v nodered_data_new:/data \
  -v /root/backups/node-red:/backup \
  alpine sh -c "tar -xzf /backup/node-red-docker-2026-08-20.tar.gz -C /data"

Если вы уже используете docker-compose со связкой сервисов — Node-RED, Mosquitto, Home Assistant — стоит смотреть на бэкап не изолированно, а как на часть общего compose-стека. Готовый файл для быстрого разворачивания Node-RED в Docker с правильными volume-путями есть в статье Node-RED в Docker Compose — там же видно, как volume для потоков соотносится с volume для конфигов Home Assistant.

Git для истории версий потоков

Файловый архив хорош для катастроф, но плох для вопроса «что именно я изменил вчера и как откатить только этот кусок». Для этого у Node-RED есть встроенная поддержка Git-проектов (Projects feature).

Включается в settings.js:

editorTheme: {
    projects: {
        enabled: true
    }
}

После перезапуска редактор предложит превратить текущий flows.json в git-проект. Дальше userDir становится git-репозиторием, и в интерфейсе Node-RED появляется вкладка History с diff между версиями, commit прямо из UI и возможность откатиться на любой предыдущий коммит.

Практическая польза: если вы правите сложный поток по частям в течение дня, можно коммитить контрольные точки и откатывать только неудачный шаг, не поднимая архив целиком. Для команды это ещё и способ хранить потоки в собственном GitLab/Gitea — git remote add origin ... и git push работают как в обычном репозитории.

Минус — Projects feature не включает автоматически credentials в историю (это осознанное решение: пароли не должны попадать в git-лог в открытом виде), так что flows_cred.json по-прежнему нужно бэкапить отдельно, файловым способом из предыдущего раздела.

Восстановление: локально, после краха, на новом сервере

Три разных сценария требуют немного разных действий.

Откат к предыдущей версии на том же сервере (например, после неудачного Deploy):

sudo systemctl stop nodered
tar -xzf /root/backups/node-red/node-red-2026-08-25.tar.gz -C /home/pi
sudo systemctl start nodered

Если использовали Git-проекты — проще откатиться через вкладку History в редакторе, без остановки сервиса.

Восстановление после полного краха сервера (диск умер, ОС переустановлена): ставите Node-RED заново (sudo npm install -g --unsafe-perm node-red или через Docker-образ), затем разворачиваете архив userDir поверх пустой установки, ставите недостающие npm-ноды по package.json:

cd ~/.node-red
npm install
sudo systemctl restart nodered

Здесь важен порядок: сначала распаковать flows.json/flows_cred.json/settings.js, потом npm install — иначе Node-RED при первом запуске может создать пустой flows.json и вы потеряете точку восстановления, если архив ещё не распакован.

Перенос на новый сервер (миграция, апгрейд железа) — по сути то же восстановление после краха, но с живым исходником: rsync каталог напрямую между машинами вместо архива-посредника —

rsync -avz --exclude=node_modules /home/pi/.node-red/ user@new-server:/home/pi/.node-red/

Отдельно проверьте версию Node.js на новом сервере — Node-RED и его ноды чувствительны к версии рантайма, и после переноса иногда требуется пересобрать нативные npm-модули (npm rebuild внутри ~/.node-red), если версия Node.js отличается от исходного сервера.

Если Node-RED — часть связки с Home Assistant, восстанавливайте оба компонента синхронно: у Home Assistant свой отдельный бэкап (снапшоты через встроенный Backup или файловый архив /config), и рассинхрон версий между HA и потоками Node-RED, которые дергают его WebSocket API, — частая причина, почему после восстановления автоматизации формально «работают», но половина нод показывает статус disconnected. Детали бэкапа именно Home Assistant разобраны в статье бэкап и восстановление Home Assistant.

Частые вопросы