Ich bin gestern aus einem 14tägigen Urlaub zurückgekommen.
Wollte dann einmal auf Home Assistant zugreifen und bekam die Fehlermeldung „Ho ho, es sieht so aus als ob wir keine Verbindung herstellen können.“
Diese Meldung kommt über die App als auch über Safari.
Ich habe den Pi mehrere male ausgeschaltet und nach einiger Zeit wieder eingeschaltet. Es bleibt die Fehlermeldung. Die FritzBox erkennt immer noch die IP-Adresse vom Pi, hat aber nicht mehr farbig hinterlegt das man auf eine Weboberfläche zugreifen kann. Man sied die LED am Pi blinken, was mich vermuten lässt, das da noch etwas lebt. Die regelmäßige externe Datensicherung endet am 02.06.25. Hat jemand eine Vermutung was das seine kann? Vielleicht sogar einen Lösungsansatz?
Würde mir sehr Helfen.
Moin,
schwer zu sagen was da los ist. Läuft dein HA auf einer Speicherkarte? Die könnte sich verabschiedet haben
Ich habe eine externe SSD.
Ich würde mal einen Bildschirm über HDMI an den Raspberry anschließen und schauen, was dort zu sehen ist 
Das müsste mit einem Mini-HDMI zu HDMI Kabel problemlos möglich sein, falls du soetwas hast.
Alternativ mal einen nmap auf die Kiste machen und schauen was da an Ports noch offen ist. Bei meinem funktionierenden RaspberryPi mit Home Assistant sieht das so aus:
$ nmap -p 1-10000 192.168.0.94
Starting Nmap 7.94 ( https://nmap.org ) at 2025-06-14 19:52 CEST
Nmap scan report for homeassistant.fritz.box (192.168.0.94)
Host is up (0.0017s latency).
Not shown: 9992 closed tcp ports (conn-refused)
PORT STATE SERVICE
22/tcp open ssh
111/tcp open rpcbind
1883/tcp open mqtt
1884/tcp open idmaps
4357/tcp open qsnet-cond
5355/tcp open llmnr
8097/tcp open sac
8123/tcp open polipo
Und wenn SSH offen ist mal versuchen, per SSH auf die Kiste zu gehen und nachschauen, was da im Argen ist.
Auch SSDs sterben irgendwann. Dein „stehengebliebenes“ Backup deutet darauf hin.
Oftmals (ich sage nicht, dass es bei dir so ist), startet man solche Projekte ja in einer Testumgebung. Da ist es völlig legitim auch Mal eine bereits gerbrauchte HW-Komponente an den Start zu bringen.
Irgendwann läuft dann alles wie gewünscht und man überführt es, ohne dass es einem tatsächlich bewusst wäre, in die Produktion. So nach dem Motto: „Hey! Läuft ja richtig gut! Nutze ich dann jetzt Mal.“ Bei der ganzen Freude vergisst man dann häufig, dass man keine ganz frische HW mehr verwendet. Die läuft dann noch ein Weilchen, aber irgendwann fällt sie dann halt (früher) aus, als die übrigen neue(re)n Komponenten.
Ich bin noch nicht so lange hier in diesem Forum, habe aber bereits 2x in genau so einem Szenario unterstützt. Gebrauchte HW bei ebay geschossen. Keiner wusste, wie viele Km die schon auf dem Tacho hat. Nichts erneuert, einfach neues OS mit SW d’raufgenagelt und in Betrieb genommen. Irgendwann kommt dann halt das böse Erwachen.
Ich starte Serversetups immer auf einer gebrauchten SSD. Wenn alles so läuft, wie ich mir das vorstelle, kommen zwei neue SSDs in den Server. Dann clone ich von der alten auf die neuen SSD und richte direkt ein RAID 1 ein. Damit schlage ich gleich zwei Fliegen mit einer Klappe.
Berichte trotzdem gerne, wie du mit der Lösung des Problems vorankommst. Evtl. kann man ja noch etwas retten…
Kann man eigentlich eine M2 NVMe SSD (eingebaut ) und eine SSD (die am USB hängt) clonen?
Ja, klar! Clonen kannst du grds. von „überall“ nach „überall“. (Wenn das Zielmedium kleiner als das Quellmedium ist, wird es jedoch etwas kniffliger.)
Aufpassen musst du nur, wenn du boot-fähige Partitionen clonest und diese nach dem Clonen direkt produktiv nutzen möchtest (Wie in meinem Szenario dargestellt). Hier wäre es jedoch wieder unkritisch, da ich ja die alte NVMe nach dem Clonen durch eine bzw. zwei neue NVMe austausche.
In deinem Szenario, stellt sich die Frage: Möchtest du auf der externen SSD nur ein Backup anlegen oder soll anschließend von der externen SSD ge-booted werden?
In letzterem Fall musst du dann natürlich Bootreihenfolge im BIOS entsprechend einstellen. Ggf. muss die initiale RAM Disk so angepasst werden, dass sie auch den (USB-)Treiber für die externe SSD enthält. Ansonsten booted das System zwar, kann dann aber nicht auf die / (Root)-Partition zugreifen => Kernelpanic
Fazit: Für reines Backup (also eine Zwischenspeicherung) ist das alles supereasy. Wenn du ein Produktivsystem auf ein anderes Medium „umziehen“ möchtest, muss man schon bissi aufpassen.
Wird dieses Medium dann auch noch über eine andere HW-Schnittstelle angesteuert (NVMe PCI auf SSD USB)…s.o.
Wäre vielleicht nicht unbedingt das Szenario, welches ich mir für meinen ersten Clone-Versuch auswählen würde. 
Also ich habe gestern ein Dashboard „zerschossen“ (aus Versehen) und habe letztendlich ein Backup eingespielt. Muss sagen, das läuft echt easy und alles ist innerhalb einer kurzen Zeit (waren gefühlt keine 20 Minuten, inklusive Youtube Studium „wie spiele ich ein Backup ein“) erledigt. Finde ich sehr gut gemacht (wenn man es weiß wie es geht 
) , so gesehen reicht es mir eigentlich wenn HA jede Nacht ein Backup auf GDrive fährt.
Also wenn mal der Raspi ausfällt kann ich einen neuen besorgen (oder SSD wenn die defekt ist) und mittels Backup einspielen das System wirder ans Laufen bringen.
Leider: Nope!
Das HA Backup sichert lediglich die Settings von HA, nicht jedoch das gesamte HA-System (inkl. letztem Updatestatus) und schon gar nicht das zugrundeliegende OS (Linux).
Hier hat jeder ein anderes Sicherheitsbedürfnis. Einige ändern ihre Sicht auf die Dinge erst dann, wenn sie ein Linux zzgl. HA komplett neu installieren und ggf. auch konfigurieren müssen.
Ein Clonen ist, in diesem Szenario, sowieso nicht als daily backup Methode gedacht, sondern vielmehr um ganze Systeme duplizieren oder (einmalig) raw wegzuschreiben / zu sichern.
Zwischen „HA integriertes Backup reicht“ und „Voll durch clonen“ gibt es ja noch etwas anders: Ein vernünftiges daily backup auf OS-Ebene.
Hier die Fotos über den Ablauf beim Booten.
Nach dem letzten Foto blinkt der Curser und es geht nicht weiter.
Leider kann ich nur ein Foto hochladen.
Ich kann leider damit überhaupt nichts anfangen.
Ich habe dafür extra eine neue ssd gekauft.
@Stevie : Das ist natürlich korrekt, ich müsste erst ein Image auf den Datenträger flashen, dann starten und dann ein Backup einspielen. Bei Raid würde ja der Clone dann starten - richtig??
Alles gut! 
So wie es auf dem Foto aussieht, hast du das coredns Addon von HA installiert…???
…und das läuft jetzt Amok. Wenn du das Addon nicht benötigst (und ich würde DNS immer auf einem zentralen Server / Router laufen lassen), kannst du versuchen es zu deinstallieren. Das LAN selbst scheint ja zu funktionieren. Du müsstest also über die IP-Adresse an das System 'ran kommen (Browser, ssh). Vermutlich ist da in der Vergangenheit ein Update fehlgeschlagen.
…Versuch macht kluch.
Versuch
Fast! Bei RAID 1 läuft der Mirror ja immer mit. Sowohl lesend als auch schreibend. Daraus ergibt sich ja auch, zusätzlich zur Datenkonistenz, der Performancevorteil. 
Wenn dir also eine NVMe in die Knie geht, läuft erst mal eine Reparatur im Hintergrund an. Hier werden dann die korrekten Daten vom intakten Device auf neue Sektoren der defekten NVMe ge-synched. (Die Aussage gilt für NVMe nicht mehr vollständig, weil deren Onboardcontroller das alles selber managed).
Du siehst: Bei einem RAID 1 startet der Mirror (kein Clone im eigentlichen Sinne) nicht dediziert.
Gibt ein RAID Member komplett auf, wird er als „dirty“ gekennzeichnet und nicht weiterverwendet (hier gibt es aber unterschiedliche , herstellerspezifische Strategien). All das wird aber auch in den Logfiles protokolliert.
Tauscht man den defekten Datenträger aus, nimmt man diesen zuvor aus dem RAID-Verbund, baut das Substitut ein (geht auch im laufenden Betrieb…hot swap) und nimmt ihn in den RAID-Verbund auf. Dann wird sofort erkannt, dass der neue Kollege noch völlig blank ist 
…und im Hintergrund startet unmittelbar ein full sync des neuen Kollegen. Von da an ist dann alles wieder schicki.
Bei einem RAID läuft das halt bissi anders…
Vielen Dank für die Hilfe. Ich habe Home Assistant jetzt neu aufgesetzt und aus einer Datensicherung wieder hergestellt. Leider fehlen mir jetzt ca. 14 Tage. Da ich Home Assistant als Hobby betreibe ist es nicht ganz so schlimm. einen schönen Sonntag.
KI-Deep Thinking! Früher hätte man gesagt: „Kleiner Nachtrag!“ 
Die UEFI-Bootpartition kann man in einem SoftRAID-System zwar auf beiden RAID-Membern anlegen, befüllt / beschrieben wird jedoch nur die während der Installation aktive Partition der jeweiligen NVMe. Welche das ist weiß tatsächlich nur der Zufallsgenerator der Installationsroutine. Einige munkeln, es wäre immer die UEFI-Bootpartition auf der ersten physischen NVMe.
Klingt wirr? Stimmt! …aber nur auf den ersten Blick.
Alle Partitionen (auch SWAP) können im SoftRAID liegen. Nicht jedoch die UEFI-Bootpartition! Diese muss physisch direkt auf der / den NVMe(s) liegen!
Warum? Der Bootprozess ist herzerfrischend dumm. D.h. zum Zeitpunkt des Bootvorgangs gibt es noch kein SoftRAID, da kein initramfs geladen (Hier liegen die SoftRAID-Treiber). Kurzum: Der Bootloader kann die UEFI-Bootpartition nur dumpf von einer physischen Partition adressieren und anprechen.
I.R. der Installation wird jedoch quasi ausschließlich nur eine der beiden UEFI-Bootpartitionen beschrieben / befüllt! Das passiert auch, wenn bereits auf beiden NVMe eine solche UEFI-Bootpartition vorhanden ist.
Fällt nun irgendwann genau die NVMe aus, auf der die UEFI-Bootpartition von der Installationsroutine sinnvoll beschrieben wurde (die Chancen hierzu stehen, bei RAID 1 auf 50%), wird das System nicht neu booten, weil die zweite vorhanden UEFI-Bootpartition schlicht leer ist.
Hier bedarf es also, nach der inititalen Installation des Systems, noch ein paar manueller Konfigurationsschritte. dd() is your friend.
Wie komme ich d’rauf? Ich baue gerade meinen Hypervisor um…da sind mir noch ein paar Punkte bewusst geworden, die ich irgendwie routinemäßig einfach mache🤦🏻. Sorry for this🤷🏼