After a version update I am getting a corrupt database error on my C7 running 2.3.9.166. I tried creating a backup before the update but it did that bug where it didn't download an actual file. I have a few local backups but after a soft reset and restore the issue persists. I have a number of local backups downloaded but some of them are dates months.
When I try to go to any device I get an Error 500, so at this point it isn't usable. I was going to try and upgrade to a C8 Pro I have available but it wouldn't even do the backup to allow for that migration.
I have tried a number of the troubleshooting steps mentioned in other corrupt database posts.
From diagnostic tool, make sure you have downloaded all available backups for safe keeping.
Do a soft reset from there WITH the option to purge logs.
When it reboots do not restore from a backup, see if you can get booted into a fully function UI. Your "devices" list will be blank but the z-wave details will still show z-wave devices so do not worry about loosing your devices.
If that works, then you can try to restore one of your backups, which should put things back in order. Hopefully without a corrupted DB this time.
I got the a fully functional GUI, restored a backup from download instead of device and it said it was corrupted. I went so far as to use a backup from September 2023 running 2.3.5.152
This is supposed to be disabled in the new build by default but worth a shot. You can also click the link and check that full post for more details. I suspect this is where your issue stems from since you were on a version below 2.3.8.140
I reverted to 2.3.7.146, got a working GUI, went to the endpoint, rebooted. Clean GUI, tried to restore from a backup made by 2.3.7.146 and now it is stuck at initializing hub - updating database.
The platform version listed for the backup is not relevant, you can restore any backup to any platform.
Did you run the endpoint to disable the zwave debug logging? (sounds like you did)
Did you do the soft reset with the clear logs option?
Probably was no reason to roll back, you were already updated past where the issue got fixed but your symptoms suggested you were on the brink of having that specific issue anyway, not sure why.
I would try using the diag tool to go back to the current platform. Soft reset and clear logs. See if you can get back into a clean platform.
I can get to a clean platform with a soft reset on any of the versions available but restoring a backup fails (either stuck at updating database or corrupt database) in every scenario.
I let @bobbyD know about it. I would wait to see if staff has any suggestions.
Maybe all of your old backups are corrupted somehow, but it really feel like the hub storage is full which will give the false corrupted DB errors. Not sure how to get past it though.
So here is what I did to try to fix it, which it sort of did but actually didn't 100%.
Soft reset
Clean platform (w/ zwave still)
Cloud backup for migration
Setup C8 Pro
Restore cloud backup to migrate zwave
Restore oldest backup I had downloaded from 2023-05-04 running 2.3.4.153 (2023-06-27 on 2.3.5.131 also worked)
Everything works! Well sort of. That backup is so old it doesn't have a number of devices setup, including apps, integrations and other items.
So that leaves me saving some time, not having to reconnect many many devices but still a number of unknown devices that I have to guess what they actually are because they aren't mapped to anything. So here are the questions now
How can I map zwave devices seen in zwave list to a hubitat device when I don't know which physical device it is?
How am I supposed to know when a backup is bad? It seems I would only find this out when I try to restore it. I have half a dozen updates since things when bad but there was no way to know that.
Is there a way to compare backups for changes so I can cherrypick to get some of my missing things back?
So that old backup was the only one that worked? All the others said corrupted?
2.3.8.117 was supposed to have added some checks to detect corrupted backups. There was a rash of issues like yours prior to that release and actually this is the first case I remember seeing since those fixes were put in place. Release 2.3.8 Available
Do they have a discover button? You can try pressing that. If its a main powered device it might respond so the hub can create a device for it.
You can also try creating a "virtual" device for it, and then edit the DNI to match the 2 char HEX node ID to link it to that node. Use this driver [RELEASE] Z-Wave Universal Device Scanner and try sending on/off commands which might help you find what it is. It sends Basic On/Off which just about any device that can be turned on or off will respond to. I have never seen anyone have luck making a virtual device like this but it should work in theory.
Last resort you would need to run an exclusion on the hub/device to remove the dead nodes, then include the device back again. The device should still be paired to the radio so the exclude should remove the node without leaving a ghost node.
I don't think there is a way. @gopher.ny would it be feasible to have some sort of backup integrity checker that checks the local backups on the hub and/or you can upload a backup to be checked (but it does not actually restore it)?
No, they are encrypted, only the hub itself has the encryption keys.
Can you PM me the hub id, I'll check the engineering logs on the hub.
Yes, firmware versions 2.3.8 and later have integrtiy checks to verify the backup. They're not exhaustive, but they catch most common database corruption issues.
@jtp10181 I followed those steps and have most everything back. I have a few unknown devices still but I think I know what they are and just need to discover them again after they send some signals. One device had a discover button but it went away. I think I know what the device is and will see what I can do to recover it.
It would still be great to be able to load a backup into an interface to see a changelog of differences. I have no idea what I changed over the last 14 months, hard to track.
I haven't tried the virtual device technique yet but may need to. I will report back if it works.
