Hub backup restore still running after 20 mins … seems to be hanging


  • upgraded to the latest hubitat release yesterday afternoon (believe its
  • overnight found hub had locked
  • had to pull plug to reboot hub
  • after reboot try to check zwave info … hub hangs
  • again pull plug to reboot hub
  • after reboot try to go to settings … hub hangs
  • again pull plug to reboot hub
  • trying to restore pre upgrade backup
  • the backup restore is ongoing for 20 mins
  • looks like it might be hanging too

could use some help please.

thank you

noticed this status update at the bottom of the screen … it seems to be hanging here:


on the third pull plug to reboot then restore backup the restore apparently went thru but still seeing the pre-restore version.

rebooting hub from portal to see what comes back.

after reboot the version still shows as but looks like it is back to 1.1.2.* because the groups app has disappeared.

still checking if things work with this old version like it was before upgrading.

Have a read of this thread.
What you are seeing is correct.
To revert to a previous hub version you need to do something different. Its about halfway through i think.

Post 32.
Just to clarify somethings.

The backups are just the database on the hub. You can backup and restore this at any point and the hub stores 5 backups, which are taken daily or on reboot for that day.

Firmware is the software running on the hub. You can roll back to the previous firmware via http://hub ip:8081

Backups are somewhat tied to firmware, but in most cases, restoring a backup to a newer firmware should be fine. Restoring a newer backup to older firmware could cause problems.

We are looking at ways we can make firmware roll back more obvious of a choice to help with this confusion. One idea is to provide a link to the rollback tool (port 8081) on the backup and restore page itself.

We appreciate everyone's feedback as we continue to improve and expand Hubitat Elevation.


Sure wish there was a really good way to get the knowledge out about the exactly what the backup is. Once you read about it, it's easy... backup what's unique. YOUR db is unique, but the OS image is same for everyone. The Hub retains a copy of previous OS Images (visible at :8081) but all the WOW is in the fact we can backup our unique portion.

thank you for the clarifying link. thought the backup package included all deployable bits on the hub to maintain consistent state. i guess not.

will downgrade to 1.1.2.* using ip:8081

now to get some help on why just hangs overnight.

How big is your DB?
Do you have IFTTT installed?

26 MB.

dont use webcore / lutron / telnet / IFTTT on this hub.

There we go again with the gigantic database.
cuboy, myself and some others have reported 20+ mb databases, and have been hanging up at night.

I make the correlation, because the one defining spec, since I've stopped crashing is the Db is now <8mb.
I have nothing to prove causation, except that over the very first night in over 2 weeks that I didn't crash, the database shrank from 36mb to <7mb.

how did you get it to stop crashing? :slight_smile:

may be there is some sort of compaction job that runs before backup where it crashes?

I suspect that it's crashing during the clean up processes, yes. It's relatively the same time every night when it was happening to me. 2-4am.

I think, in my case, because I began eliminating all the apps (especially custom), non-native Telnet, IFTTT (which was bugged at the time) that eventually the cleanup process was able to make it through in that one night without crashing and reverting. I then could build back what I had.

Obviously everything I've said is pure speculation and only meant to be helpful in discovery.

I also suspect, that we're causing it, because as developers we're making more unusual changes than typical users. Again, speculation.


other than loading my own app i actually havent tinkered with the hub at all. so a bit surprised that this is still happening.

Pretty sure I know one owner that doesn't code that experienced lockups at around the last two firmwares. Just another observation to add.

sure sounds like it needs some triaging.

Definitely get in touch with support. They can verbosely log the backend. Might help them find it.

wouldnt it be funny if the backend logs were the problem? the backend is on the hub as well. :slight_smile:

earlier the client side logging used to be sync which was causing significant performance issues. after bringing that up saw that was changed to async with 1.1.4.*. dont know if it was related to my highlighting it.

think the backend logging is also always on and sync in nature.



12 posts were split to a new topic: Rule Machine bug with valve open/close action