Бэкап и восстановление openHAB

MAATRIX

Если openHAB крутится на Raspberry Pi с SD-картой три года без единого бэкапа — рано или поздно карта умрёт, и вместе с ней все items, rules, sitemaps и настроенные годами интеграции с реальными устройствами. Восстановить это руками за один вечер не получится: часть логики просто забудется. Ниже — рабочая схема бэкапа и восстановления openHAB, которую можно поставить один раз и забыть, пока не понадобится реально что-то восстанавливать.

Что именно нужно бэкапить в openHAB

openHAB хранит состояние в трёх местах, и их важность сильно различается:

Отдельно держите в уме: если вы завели Things и Items через UI (Main UI / PaperUI), они лежат не в текстовых файлах в /etc/openhab, а в JSONDB внутри userdata/jsondb/*.json. Это частая ошибка новичков — бэкапят только /etc/openhab, потому что «там же конфиги», а потом после восстановления пропадают все UI-Things.

Persistence-сервисы (InfluxDB, MySQL, rrd4j) хранят исторические данные датчиков отдельно от openHAB и в этот бэкап не попадают в принципе — про них ниже отдельный раздел.

Встроенный инструмент openhab-cli backup/restore

Если openHAB установлен из APT/RPM-репозитория (а не в Docker), в комплекте идёт обёртка openhab-cli, которая умеет собирать и разворачивать архив сама, зная нужные пути:

sudo openhab-cli backup /var/lib/openhab/backup/openhab-$(date +%F).zip

Без указания пути утилита создаст архив в текущей директории с именем вида openhab-backup-<timestamp>.zip. По умолчанию она берёт conf и userdata, но пропускает временные и кэш-каталоги (cache, tmp, часть логов) — это осознанно, чтобы архив не разрастался до гигабайтов на пустом месте.

Восстановление — обратная команда:

sudo systemctl stop openhab
sudo openhab-cli restore /var/lib/openhab/backup/openhab-2026-08-20.zip
sudo systemctl start openhab

Важно: openhab-cli не спрашивает подтверждения перед перезаписью — команда restore затирает текущий conf и userdata содержимым архива. Прогонять её на боевом сервере «на всякий случай посмотреть» не стоит — сначала снимите отдельный бэкап текущего состояния.

Ручной бэкап для Docker-установки

В Docker-варианте openhab-cli внутри контейнера тоже доступен, но чаще проще работать с volume-ами напрямую — это не зависит от того, как именно собран образ. Обычный docker-compose.yml для openHAB заводит три тома:

services:
  openhab:
    image: openhab/openhab:4.3
    volumes:
      - openhab_conf:/openhab/conf
      - openhab_userdata:/openhab/userdata
      - openhab_addons:/openhab/addons
volumes:
  openhab_conf:
  openhab_userdata:
  openhab_addons:

Бэкап без остановки контейнера рискует поймать файл jsondb в момент записи — лучше сначала мягко остановить сервис:

docker compose stop openhab

docker run --rm \
  -v openhab_conf:/data/conf \
  -v openhab_userdata:/data/userdata \
  -v $(pwd):/backup \
  alpine tar czf /backup/openhab-backup-$(date +%F).tar.gz -C /data conf userdata

docker compose start openhab

Восстановление — тот же приём в обратную сторону: остановить контейнер, распаковать архив во временный volume, стартовать заново. Если переносите openHAB на другой сервер, убедитесь, что версия образа совпадает или новее — jsondb от более новой версии openHAB может не открыться старым рантаймом.

Автоматизация: cron и офсайт-копии

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

# /etc/cron.d/openhab-backup
0 3 * * * root /usr/bin/openhab-cli backup /var/lib/openhab/backup/openhab-$(date +\%F).zip >> /var/log/openhab-backup.log 2>&1
15 3 * * * root find /var/lib/openhab/backup -name '*.zip' -mtime +14 -delete

Ротация нужна обязательно — без неё каталог с бэкапами тихо съест всё свободное место за пару месяцев.

Для офсайт-копии проще всего rclone до S3-совместимого хранилища:

rclone copy /var/lib/openhab/backup remote:openhab-backups --min-age 1h

Важный нюанс безопасности: в архиве openHAB часто лежат живые секреты — токены Telegram/Alexa/Google Home биндингов, пароли от MQTT-брокера, API-ключи погодных сервисов из services/*.cfg или things в JSONDB. Если копия уходит в облако, шифруйте архив перед отправкой (gpg --symmetric или встроенное шифрование restic, если используете его вместо связки cron+rclone) — просто выгружать zip в открытый бакет не стоит.

Восстановление openHAB на новом сервере

Пошагово, для сценария «старый сервер умер, поднимаем на новом»:

1. Установите openHAB той же мажорной версии, что была на старом сервере (или актуальную, если готовы разбираться с миграцией схемы jsondb — в мажорных релизах она иногда меняется).
2. Остановите сервис: sudo systemctl stop openhab.
3. Скопируйте архив бэкапа на новый сервер (scp, или заберите из офсайт-хранилища через rclone copy).
4. Разверните: sudo openhab-cli restore <файл>.zip.
5. Проверьте владельца файлов — после restore иногда остаются права от пользователя, из-под которого разворачивали архив: sudo chown -R openhab:openhab /etc/openhab /var/lib/openhab.
6. Запустите: sudo systemctl start openhab и сразу смотрите лог: tail -f /var/log/openhab/openhab.log.
7. Дайте системе 2-3 минуты на переиндексацию JSONDB и переподключение биндингов — на слабом железе (тот же Raspberry Pi 3) это заметно дольше, чем на нормальном сервере с SSD.

Если планируете держать openHAB не на домашнем железе, а на VPS или выделенном сервере — это отдельно снимает саму проблему деградации SD-карты как причины бэкапа №1: диски на серверных SSD/NVMe живут ощутимо дольше при той же нагрузке на запись логов и persistence-баз, что и создаёт первичный износ на Raspberry Pi.

Частые проблемы при бэкапе и восстановлении

• Restore прошёл, а UI-Things пропали. Почти всегда причина — бэкапили только /etc/openhab, забыв про userdata/jsondb. Проверьте, что в архиве реально есть каталог jsondb с файлами вроде org.openhab.core.thing.Thing.json.
• После restore на новую версию openHAB сервис не стартует или сыплет ошибками биндингов. JSONDB между мажорными версиями иногда меняет формат. Безопасный путь — восстанавливать на ту же минорную ветку, что была на исходном сервере, и уже потом обновляться штатным апдейтом с рабочей системы.
• Бэкап «не видит» историю датчиков после восстановления. Ожидаемо: openhab-cli backup не трогает внешние persistence-сервисы. InfluxDB бэкапится своим influxd backup, MySQL — mysqldump, это отдельные задачи cron рядом с бэкапом самого openHAB.
• Архив весит гораздо больше, чем ожидалось. Обычно в userdata накопились старые логи или необнулённый cache/tmp. openhab-cli backup их исключает по умолчанию, а вот ручной tar без --exclude тащит всё подряд — стоит явно исключать эти каталоги.
• Restore на другом сервере — permission denied в логах. Классика для ручного tar-варианта: владелец файлов после распаковки — root или тот пользователь, из-под которого делали restore, а сервис openHAB запускается от openhab. Лечится chown -R из шага восстановления выше.

Если работаете с бэкапами Docker-томов и хотите общую картину граблей (permissions, символические ссылки, порядок stop/backup/start), пригодится разбор частых ошибок бэкапа Docker volume — там те же грабли, но не привязаны к конкретному сервису. А если рассматриваете альтернативную или параллельную платформу умного дома, вот как разворачивается Home Assistant в Docker Compose — у него схожая логика бэкапа, только структура каталогов другая. Общий каркас автоматизации бэкапов на сервере — в статье про автоматические бэкапы на AlmaLinux 9 с нуля, если openHAB у вас крутится не на Raspberry Pi, а уже на полноценном сервере.

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