I have a running installation with a Raspberry Pi 3B+. I would like to prepare a 2nd installation for backup purposes (for quick replacement in an emergency). Of course, I would also like to update this system from time to time with my backup settings and the latest updates.
How can this be handled and tested without conflicting with the production system?
Just be sure to give the second device a different IP address.
But there are other things you wonāt be able to create an active secondary setup for.
One for sure is zigbee via ZHA since the dongle connects directly to the HA machine and to the HA instance.
But if you take a backup of your HA instance on a regular basis if your production system fails itās as easy as restoring that backup to new machine.
as far as testing goes it really depends on which integrations you have on the production system that you want test on the backup machine. So itās hard to give general advice without specific examples.
I use Docker so if I need to test something I just run a new docker container on the same machine. I still canāt use ZHA since the controller is being used on my production container but I havenāt found that to be a hindrance for things Iāve needed to test.
Not sure this is true with an ethernet zigbee coordinator. I have not had a reason to try. But it seems it should work in my head 
Jeff, You can connect a restored system to the ethernet coordinator (instead of the previous - NOT at the same time as the system you restored from) you cannot connect two systems to the same coordinator.
If youāre not running Proxmox or some other hypervisor the process is.
Image latest
logon with temp user ID
Drop backup
At this point you change ip address of the replacement box.
When you drop the backup it inherits the ENTIRE setup from the system that was backed up (including the IP address if you set static on the box) can you say IP conflicts?
So if you do static IP address, that means donāt have them online at the same time in the same local network or ip conflicts and MDNS problems.
If you set your ip address at the router with a reservation you would then have two machines with different idās stating they are the same box. (also problematic)
Read: donāt bring the HA boxes up on the same network at the same time without addressing the naming / address issues.
I currently run HAOS on bare metal on a NUC, pi are the same basic process. I keep a second boot device (in my case an m.2) imaged with a recent installation of HA. On error (or to test) I install the replacement disk. Boot the box login and initialize, fire up the samba addin and move a copy of the backup to the box. Then kick the restore. 20-30 minutes later, change ip assignment in router if I changed boxes reboot, then reboot again. Done
All it costs me a spare M.2. It fixes almost any issue except a non-storage hardware failure on the NUC. If itās that bad I can get a new box here in 24 hours. The build plan for the home requires everything stay working if HA is down - so all I lose is the fancy automation.
Op, All of that said. Iād not spend too much on the hot swap for a Pi3 so much as Iād be thinking about replacing it. The pi3 is among the absolute minimum you can run current builds of HA on. I wouldnāt throw a lot of money trying to prop it up. Save the cash and start building the replacement and think about how you will restore that.
I cannot wrap my head around this not working. I donāt currently have a second HA setup to test.
But I have seen reports of people connecting both ZHA and Z2M for the same HA setup to a single ethernet coordinator. Both integrations get the sensors from all devices that they know about. I also have not tested this for full transparency.
So, Iād expect two different HA setups pointing to the same coordinator to be able to do the same.
Incorrect reports. This is not possible.
One coordinator - one driving software at one time. Period.
You can disconnect one THEN Connect the other but not at once.
So, someone went through all of this and wrote the article to fake us out?
Using Zigbee2MQTT and ZHA with One Coordinator - SmartHomeScene
I will parade a bunch of links if you wish where itās supposed to be completely impossible. the spec simply isnāt designed for it. I read that as someone who said yeah look I can make this work. They never look at if they should or the long term ramifications.
Go ask if they had issues or if it kept working. It IS VERY much a maybe you might be able to make the connect but itās very much not supported and very much CAN blow stuff up.
People come up on this community site all the time to ask about things.
Those of us whoāve been here done that and got the lumps on the head to prove it say hey donāt do that itās gonna hurt. This is oe of those things.
If you reeeeeeeally want to try it go ahead Iām not going to stop you. Butā¦
Its not supposed to work so donāt gripe when it starts to be unstable. And itās ABSOLUTELY not advisable, thereās zero way anyone should be recommending it.
I have seen multiple threads about wanting to have a 2nd HA setup for emergency reasons but not yet a straightforward answer since HA is just not designed for that (yet).
Yes, I have seen posts where both ZHA and Z2M are being used BUT with separate coordinators for each.
Still, running both integrations simultaneously will not help the OP either.
We donāt even know if the OP is using zigbee at all!
So Thomas: how are you communicating with your devices.
The IP address conflict is only an issue if you would power the 2 working systems at the same time.
Thatās a problem when testing/preparing, not if the first one fails AND is not connected logically to your network.
First of all, I would like to thank you all for this interesting discussion. I didnāt think my question would be met with so much interest.
Anyway, I would like to let you know what integrations my current installation includes:
I currently only use HA for my IR heater and for that I use the Generic Thermostat helpers.
@Nick: Youāre right, I donāt use Zigbee. So that wonāt be a problem.
I want this 2nd setup mainly for my not-so-techy wife in case Iām not available and all this stuff breaks down. She would never be able to install HA and/or a backup.
I want to have a 2nd Raspi and a running SD card available for whatever may happen. With a few useful instructions, sheāll be fine. However, I should make sure that this configuration works.
I donāt know if you are aware of that: running HA with a RPi on a SD card can be your first reason for problems.
Also, maybe it would be better/easier imaging your working SD card (with the latest situation of HA) to another one so your partner just has to swap those, after powering the RPi off/onā¦ just an idea.
I can understand that, when HA has become an important part of everyday life, you want to be able to get back to a working situation if your system fails.
With a RPi, that would the power unit and the SD card.
I didnāt have a HW failure so far (yet) from my server and HA by itself also hasnāt been unusable for more then a few minutes.
Yes, I am aware of this problem and for this reason I replace the SD card once a year and destroy the old card. I have never had a problem with this procedure.
What you are suggesting (the image) is my current procedure.
In fact, I havenāt had a hardware failure yet either. But there seemed to be a strange software problem that destroyed some settings. This didnāt become a real problem because it happened when I was working on the system and I noticed it soon enough. But it made me wonder what would happen ifā¦
TBC: I love RPiās and have 6 running for various tasks.
What I meant was: you donāt need a 2nd RPi, just a power unit and a copy of your SD card, IMHO.
In that case, you donāt have any issues with IP address conflicts or integrations bound to any HW.
For the other part of your question, the testing: you can install HA by using virutalisation software and depending your choice of HA version, you can use that config for both systems by copying them over.
Basically youāre completely right. But I thought Iād use the 2nd Pi to update the backup SD card with the latest backup from time to time.
That right there is the part that makes the difference.
The vast majority of zigbee dongles connect to the HA instance machine directly via USB. In this case if you use ZHA then you can only have one HA instance connecting to the dongle at a time. the ZHA integration in HA (at least via USB) is a direct one to one connection from HA to the zigbee coordinator.
Now if the ādongleā (in this case itās a ethernet based coordinator) is connected over the LAN then thatās not the case anymore and multiple HA instances can connect to the zigbee coordinator at the same time. I doubt the linked procedure would work of you had the zigbee2mqtt software connected to a USB based device and also tried to use ZHA at the same time.
Itās the way zwave used to be before zwavejs created an over the network solution.
Of course I could be completely wrong tho.
Iām running exactly same as you, HA on a bare metal NUC. Interesting point in your reply is to have a complete M2 backup (I do make automatic daily backups, but donāt have a solution in case of a full hd crash).
Could you tell me how I can make a mirror copy of an M2 (I assume the M2 needs to be removed from the NUC, but what kind of tool (hw/sw) do you use?)
TIA, Wim
No mirror necessary, thatās the beauty. I donāt have to care. Itās a bog standard HAOS image use the standard instructions.
I never intend to keep that install. The restore should reinstall the versionl of haos you had. And I periodically drop a new image o it to be sure itās not wildly out of date when I restore the backup. (the original reason op said they wanted the second box.- itās not really necessary)
And yes itās just a swap. It takes literally 10 seconds.!(bad admin I donāt have the screws holding the m2 access door in on my case there anymore, so flip er over remove 1 screw. Do it in reverse. Done)
Youāre not wrong, finity.
And you still should NOT connect two drving rigs to the same network coordinator at once. Bad things can happen. Because each driving software ASSUMES complete control over the 'stick. In that case even if you can TECHNICALLY do it you still should not.
Iām pretty sure I agree with you.
I just donāt have the experience to say one way or the other with any sense of certainty.
Yeah this is one of those that the stick or the software should really prevent this and just because it doesnāt doesnāt mean youāre good to go like the link suggested.
For instance what happens if a ZHA install says join while another instance is removing other nodes. Both things assume they āownā the stick
We have to be very careful not to advise people to do bad things just because we CANā¦ Doesnātean we SHOULD.
(also. This is why multi admin is such a banger of a feature for Matter. - itās designed to work that way. Zigbee is NOT)