Nah, it would appear that the backups I have are only partial and the also appear to be corrupt.
I’ve mounted and archived the data partition from the drive and am cherry picking things back together. Both slots have gone corrupt and fail to boot. Slot A hangs at a blinking cursor and Slot B hits a squashfs corruption issue , panics and reboots. Logs and DB’s corrupted and filled the tiny 32 SSD which I assume to be failing.
The drive in question filled itself and corrupted along with the announcement, can’t say if related or not, so I’m renewing smarthings and such along the way.
512GB installed now fresh balena-etcher x86 flash, coming back together.
What I would suggest here is that the json file that’s included in the backup file contain a crc/md5 or better of the included backup tar. This backup can then be checked against this value.
I’m able to unpack the hex.tar to an @PaxHeader , backup.json and homeassitant.tar.gz
Unpacking the tar fails. This kinda seems like the backup that got created failed.
What I would like to see here in the backend unpack the file and verify the checksum before giving the option to restore, and even hinting at the ability to be able to restore that file.
Verifying the backup tar at creation would be key here to be sure you have a valid checksum and not just a sum of a corrupt tar.
New here. After two weeks I got HA running in containers, etc but decided to try a HAOS only install on a NUC. It worked (except for no Python to add my Bluetti AC300). I added quite a few add-ons and configured a lot of home systems. However it would not boot correctly and would hang up requiring manual intervention (type EXIT). OK so I decided to re-install. I did a full backup. Reinstalled. Opening screen showed option to restore from previous backup. Cool. Except no reaction. So I did the normal new customer login and figured I would just go to restore backup in Settings. Except that does not work since I cannot point it to any external directory where the file is located. Any help appreciated or is this just a bug that needs fixing?
it’s unbelievable that in 2023 there are still problems with backups, it’s been 2 weeks with many hours a day that i’m trying to migrate home assistant on my server, i’ve seen several tutorials, i even asked for help on this forum: Hassio migration backup problems
I even made a VM with haos_ova-10.2.qcow2 which is the exact same version as the one I have on the Raspberry, the only difference is that one is aarch64 and the other x86_64, in all this time I couldn’t get anything working, maybe the only way would be to take the ssd connected to my Raspberry where inside there is hassio and connect it directly into my server? and with some command make it boot directly inside the vm where I have haos_ova-10.2.qcow2
I think there is at least one command to run in the CLI interface to boot it from the ssd or to import all the files inside it or not?
The best solution I found was to simply install HA on your new device from scratch. Then add all your integrations. After that, you can try to copy/paste all your yaml files into your new configuration. At that point, some weirdness started to manifest. I then spent the time commenting out lines within the yaml files associated with any entities/integrations that were not working right. I have no idea why lines of code which worked well in a previous install would not work in a new install. But what I believe I ended up doing to resolve that was completely remove the integration and re-install it from scratch. Allow it to rebuild itself. Perhaps some glitched out in the process of copying over the yaml/configuration files themselves.
I think this post should not be flagged as inappropriate. Instead it should be a warning shot to anyone who does not have the skill or the money to get HA properly deployed, for deployments which are critical to function to commercial/industrial standards.
@Talk2Giuseppe instead of blaming HA for your inadequate deployment, you should blame yourself IMHO. Why? Because if you have a critical system the least you have to do is have a proper recent backup.
Your problem cannot be resolved by going down another route. Why? Because in any other controller-based system is you lose the controller you lose your entire system; and if you do not have a backup you are royally snookered.
At least with HA we can deploy it in a high availability environment where you can get up to tier-4 datacentre protection (SLA). HA can be deployed with no single point of failure, even in scenarios where disaster recovery and business continuity are required.
No other domotics controller can provide that, with the exception of node-red. So your problem with your present mindset cannot be solved by any other platform, regardless how hard you try.
There are multiple options to backup HA and it does not have to be from inside HA, if you are running HA like your life depends on it.
Other platforms do not even give you the ability to backup, therefore HA viewed from any angle is more advanced than anything out there. Have you ever tried to backup a PLC or a Crestron system or Control4, or Lutron/Dynalite, or anything else for that matter?
Yes, this is one of the many methods I have resorted to now, I just manually backup the folders by copying them via SMB share and back them up. The most important files are the YAML files anyway.
Container backups and manual file copying.
But since moving to the supervised HA install, I can backup and restore fine in HA directly.
Perhaps you missed the point of this entire thread. The methods provided for backing up a HA environment are unreliable. Therefore, your suggestion of using the backup functionality within HA to protect from disaster is kinda mute.
Also, I find it funny that HA, an open source, community based project for home automation enthusiasts/hobbyists is now considered a commercial/industrial grade product. I’m happy to hear that the HA team is thinking of that happening. But in all honesty, the product is far from it. Until the culture changes and end users who are reporting bugs are treated with a little more respect for their effort of reporting bugs, the HA culture will drive more people away than it attracts. HA is a complex piece of software. It has gotten better over time. But it is an absolute house of cards that requires constant attention as updates are constantly breaking functionality.
Anyway, I don’t know why I bother posting here as it just seems to be that the HA team gets defensive when people post bugs and they remove posts cause someone’s feelings are hurt. As a community, the developers and end users need to have channels of communication to express disappointment, frustration and constructive dialogue. Insulting the end user base, or removing their posts is simply telling the end users they don’t matter in this project. Members of the HA team should learn to simply not get so emotional about constructive criticism. Take it with a grain of salt and learn to ask appropriate questions to ferret out the problems with the bugs.
Without any insults I can also confirm the restore option is not working for me as well on multiple HA instances.
I am restoring from a backup of a debian based:
Home Assistant 2023.8.1
Supervisor 2023.07.1
Frontend-versie: 20230802.0 - latest
I am also not able to restore my backup. I’ve waited for 5 hours and home assistant only went down. After a “force” reboot nothing was restored. I am not able to migrate to another disk/system.
Is there another way to install backups or migrate to another system, maybe by just copying some files?
pleas help me out, after a crash of my sd card i cannot restore. i download yesterdays full backup to my newly created ha with the imager. i selected the backup to restore and now did wait 3 hours! now i restarted my pi4, ander there has nothing changed No RESTORE !!! Help!!!
It is unfortunate how long this issue has taken to resolve. this is indeed a serious problem that needs to be resolved as soon as possible but it seems that no one listens to users
Everyone here needs to understand that restoring from a backup on a pi (or equivalent) can take hours especially if you include your database in the backup. Run into this every day on discord. People are impatient and don’t wait for the restore to finish before deeming it “broken”. Take the time to watch the supervisor logs to see it’s progress.
If you aren’t running HAOS, just extract the config from the file. It’s a zip file. Literally. You can even do this on HAOS.