Your Hubitat hub failed. You went to restore from the most recent backup. The restore got partway through and errored out. You tried the backup from the day before. Same error. You scrolled through the backup list and discovered all of them are showing the same corruption. This is rare but it happens, usually after a power-related issue that affected several days of backups before you noticed the hub was unhealthy.
Why this happens
Hubitat takes a database snapshot once a day. The snapshot is a binary dump of the working database. If the database had been silently corrupting itself for several days before the hub finally crashed, each snapshot captured a more broken state than the last. By the time you go to restore, every recent backup contains the same corruption.
The good news is that the corruption is usually in specific tables (devices, scenes, automations) not in the entire database. You can often pull out the parts that are still readable and rebuild around them.
Try the older backups first
Hubitat keeps seven automatic backups. Start with the oldest and work forward until you find one that restores cleanly. Even if it is six days stale, a clean restore that you then patch with the few changes you made in the last week is faster than a full rebuild from scratch.
The restore is available from the hub’s recovery interface at http://<hub-ip>:8081/. The interface lists all available backups with timestamps. Choose one and watch the restore progress. If it fails, the recovery interface will usually tell you what table or what record number it failed on.
If no backup restores cleanly
You now have to extract data from a backup that the hub itself cannot restore. The backup file is a tar archive of the underlying H2 database. With some technical work, you can mount the database and read what is still good.
Download the backup to your computer through the recovery UI’s download link. Open it with any archive tool (the file extension is misleading; it is just a tar.gz). Inside you will find the database files and a small metadata directory.
You can browse the H2 database with H2’s own console tool, downloaded from the H2 project’s website. Open the database files in read-only mode and run SQL queries against the tables that are readable. The critical tables to extract:
device: the list of paired devices with their network IDsscene: scene definitionsrule: rule machine rulesapp: installed apps and their settings
Export each readable table to CSV. You now have a manual reconstruction kit.
Rebuilding the hub
With the CSV exports in hand, do a clean factory reset on the hub. This wipes the corrupted database and gives you a fresh starting state.
Pair your Zigbee and Z-Wave devices fresh. Use the device CSV to remember names, room assignments, and which devices you had so you do not miss any. Pairing fifty devices fresh takes about three hours of focused work, less if you pair in the room where the device is to keep context.
Recreate scenes and rules using the exported CSVs as a reference. This is the slowest part. There is no way to import them automatically, because the device IDs change on a fresh hub. You have to manually rebuild each rule and bind it to the new device entries.
What you cannot recover
Some things are not in the backup at all, even when the backup is healthy. These include:
- Zigbee and Z-Wave radio state. After restore, you have to physically re-pair every device. The hub knows the device should exist (from the device table) but the radio has no key.
- Custom app code that was modified directly through the API rather than the UI
- Active timers and counters that were in memory at the time of the crash
If you have heavily customized apps, save copies of their code as text files separately from the backup. Hubitat does not preserve unsaved app code through a restore.
Preventing this in the future
Three things prevent the cascading corrupted backup scenario:
- Get a UPS. Most database corruption traces back to power events. A fifty dollar UPS prevents the vast majority of incidents.
- Use cloud backups. Hubitat offers a paid cloud backup tier that retains thirty days of history. The longer retention is what saves you when the corruption goes back further than seven days.
- Test a restore quarterly. Spin up a spare hub (or borrow a friend’s) and try restoring your latest backup to it. If the restore fails, you know now instead of finding out during a real recovery.
When to give up and rebuild
If your hub had fewer than twenty devices and you cannot recover any backup, rebuilding from scratch is often faster than the H2 extraction route. Allow about three hours. For larger setups with custom rules, the extraction work pays for itself.
Why this story rarely ends in a heroic recovery
Most users who reach the H2 extraction stage end up rebuilding from scratch anyway. The H2 path is documented because it is occasionally the right answer, but the more common honest outcome is to take the corruption as a forcing function: set up the new hub cleanly, only pair devices you still actively use, and rebuild only the automations you actually used in the last six months.
Use this moment to also set up better backup hygiene. Enable cloud backups if you have not already. Take a manual backup once you have your new hub configured, before any device pairings. That snapshot is your future safety net. The wider lesson on hub reliability is in our ISP-resilience guide.
The lesson worth carrying forward
Build the backup habit before you need it. Most users only think about backups after losing data. Set a monthly calendar reminder to verify the cloud backup is current and to test-restore one backup to a spare device every quarter. The test-restore is the only way to know your backups actually work. For broader system reliability patterns, see our mesh roaming guide.
Related reading: Echo Show freeze guide.
