Migracja związana z wymianą ssd lub hdd w maszynie (instalacja bare-metal)

Tą samą metodą możemy odtworzyć instalację posiadając pliki kopii zapasowej (np. korzystając z addona Home Assistant Google Drive Backup możemy sobie ściągnąć ostatnią dobrą kopię z naszego gdrive)

Cała robota to kilka kroków (i sporo czasu):

  1. wykonanie wszelkich aktualizacji (by mieć aktualny system, HA, dodatki)
  2. wykonanie “pełnej kopii zapasowej”,
  3. a w międzyczasie instalacja świeżego systemu na nowym dysku (w przypadku bare-metal to po prostu przepisanie na nowy nośnik)
  4. skopiowanie kopii zapasowej na komputer z którego zwykle obsługujemy HA (można np. skorzystać z Samba czy FTP)
  5. uruchomienie maszyny na nowym dysku
  6. na etapie onboardingu przywrócenie kopii zapasowej wykonanej w kroku 1. zamiast tworzenia konta itd (klikamy w link “Alternatywnie możesz przywrócić z poprzedniej kopii zapasowej.”)

@szopen ograniczeniem jest wielkość pliku backupu.
Nie wiem czy to poprawili - ja gdy tak przenosiłem z PROXMOXA na HA natywnego to czepiał się że plik backupu nie może być większy niż 1024 MB. Tzn można go kopiować ale przy próbie RESTORE był na tamten czas u mnie taki komunikat więc musiałem “odchudzać” kopie do prawilnego rozmiaru.

Jak widać na obrazku udało się z większym plikiem(póki co i tak starego ssd nie kasuję) jeśli będą jakieś problemy to wyjdą w praniu, ale jak na razie na zauważyłem problemów.~

Czyli albo poprawili albo była to “usterka” - skoro Ci poszło :slight_smile:

A jednak możesz mieć rację - plik backupu u mnie ma koło 700MB (w tej testowej instalacji) - nie wiem czemu GUI pokazało takie bzdury (może to jest wielkość po rozpakowaniu?)
Dobrze wiedzieć, że może nastąpić potencjalny fuckup - w rzeczywistej dużej instalacji backup ma koło 2GB (a w zdalnej małej koło 500MB).

edit: pomyliłem pliki backupu przy sprawdzaniu rozmiaru post-factum

U mnie dobija już do 1024 MB - zaraz sprawdzę ile ma pełny backup.

Za miesiąc będę miał trochę czasu, żeby pogrzebać w tym temacie, teraz nie będę ryzykował psucia czegoś co działa, bo cały wolny czas na najbliższe tygodnie już wykorzystałem… (w sumie dlatego dysk odzyskany z testowej instalacji pozostanie nieskasowany, bo plany na dziś miałem ambitniejsze, ale pozostały częściowo niezrealizowane).

A ja specjalnie sprawdzę bo mam na Windowsie w VM PROXMOXA właśnie który zawiera w 99 % moją dawną konfigurację wiec się podzielę wynikiem czy jest dalej ograniczenie wielkości pliku.

EDIT :echhhh XD
image
No to jeszcze musze poczekać aż spuchnie.

1 Like

Obejście problemu jest opisane tu

swoją drogą kiedyś wcale nie było możliwości odtworzenia snapshota na etapie onboardingu, więc jak się przeprowadzałem z RPi na amd64 to wykonywałem dokładnie takie kroki jak tam opisane (pełna instalacja i kopiowanie snapshota przez sambę).

Edit: jednak jest poprawiona obsługa onboardingu (a w zasadzie przesyłania pliku przez hhtp) - nie ten plik sprawdziłem - backup ma faktycznie koło 1,4GB

Moocno się skupiłem… ograniczenie wynikało z samego protokołu http czyli maks wielkość pliku to 1024 MB i przegrywałem poprzez Sambę właśnie.
Ale sprawdzę to jeszcze raz jak mi baza spuchnie jak wspomniałem ( chyba że to zrobisz szybciej niż Ja ).

Jeszcze raz - bo chyba nie zwróciłeś uwagi, że reedytowałem wcześniejsze posty (jak to mówią “jak się człowiek spieszy, to się diabeł cieszy”) podsumowując:

  • przyczyną wspomnianego problemu było kiedyś (a przynajmniej jak tak to odebrałem) ograniczenie w implementacji przesyłania plików po http, czyli błąd w HA, a nie samo ograniczenie protokołu
  • mój plik backupu ma ~1,4GB i udało mi się go przywrócić z sukcesem (wrzucając na etapie onboardingu, czyli przez http) - z tego wynika, że błąd ograniczenia do 1GB usunięto
  • po twoim pierwszym poście chciałem sprawdzić rozmiar pliku spod windowsa, ale sprawdziłem wtedy nie ten plik - był to najświeższy plik (po dacie próbowałem go rozpoznać), ale z innej instalacji, był po prostu w innym lokalnym katalogu (jak wiadomo nazwa pliku backupu jest postaci [slug].tar więc nazwa jest w pełni randomowa, a spod windowsa nie widać metadanych, które w HA m.in. odpowiadają za nazwę kopii zapasowej)
  • później sprawdziłem jeszcze raz, bo coś mi nie grało (bo niby z jakiej paki GUI miałoby źle pokazywać rozmiar, skoro zawsze pokazywało prawidłowo?) i teraz jestem pewien na 1000%, że plik, który skutecznie przywróciłem w opisany na początku sposób ma ~1,4GB
  • mógłbym sprawdzić zachowanie na jeszcze większym pliku (gdybym miał czas na zaoranie jakiejś instalacji HA, ale nie chcę tego robić, bo nie mam na czym, a przewalanie systemu produkcyjnego w ten sposób nie jest nazbyt sensownym posunięciem skoro nie ma takiej konieczności), no ale nie mam czasu na taką zabawę i nie wiem czy to ma sens biorąc pod uwagę powyższe, (ale teoretycznie mógłbym sprawdzić przywracanie backupu z pliku o rozmiarze koło 2GB ale czas i sprzęt na takie zabawy może będę miał w styczniu przyszłego roku…)

XDXD - sprawdzę to jeszcze u siebie bo mam na czym ale pamiętam że tak miałem - chwilkę czasu na to znajdę bo już mnie nie ganiają tak do roboty.
Kużwa - 938 MB XD. No nic - poczekam.

Witam mam pytanie odnośnie odtworzenia z backup. Przeszedłem teraz z karty sd na dysk ssd128gb.Po wygraniu HA przeszedłem tworzenie konta a później dopiero przywrocilem backup,ale nie mam danych z zakładki energia.Byla to pełna kopia więc chyba powinny być?Mam jeszcze jeden problem, po resecie zasilania HA się nie uruchamia, dysk w ogóle nie pracuje,nie bootuje pomaga podłączenie dysku np do laptopa tam to wykryje,później podłączonie do raspberry reset zasilania i się uruchamia.

Zła wiadomość x2

  • zgaduję, że to RPi4 z nieaktualnym fitmware, więc czeka Cię instalacja RPiOS i update firmware
  • a w kwestii long-term Stats to powinieneś przywrócić bakup w trakcie onboardingu tak jak w pierwszym poście, więc też przydałaby się reinstalacja HAOS - zakładam, że przyczyną jest lekko uszkodzona baza recordera.

Używam Rpi3 B+,tez potrzebny jest update?Pewnie jeszcze raz przeinstaluję.Ktoś pisał o wykorzystaniu karty ale tylko do boot,

Nie, ale w takim razie jest prawdopodobne jeszcze gorzej, bo to np. może być problem z kompatybilnością obudowy dysku, a właściwie mostka USB do sata (czy nvme?) z pre-bootloaderem RPi3, ale póki jestem w trasie to nie pomogę - przede wszystkim trzeba sprawdzić kompatybilność lub inną przyczynę która nie pozwala na “czyste” zabootowanie systemu z dysku
PS Potem to zedytuję, bo nie mam teraz warunków do pisania.

edit2: dopiero teraz zwróciłem uwagę na

Procedura którą opisałeś dalej sugeruje, że masz ustawicznie “brudny” system plików i nigdy nie doczekałeś ukończenia jego naprawy przez HAOS.

Co właściwie masz na myśli jako reset zasilania?
Przecież systemu się nie restartuje przez odcięcie zasilania - to jest dość normalny system operacyjny - np. windowsa nie wyłączasz chyba przez wyciągnięcie wtyczki z gniazdka elektrycznego (w przypadku laptopa by zaemulować taką sytuację musiałbyś najpierw pozbyć się akumulatora), tylko zamykasz system w “elegancki” sposób, natomiast “brudne” zamknięcie np. wskutek zaniku zasilania podczas pracy uruchamia procedury auto-naprawcze przy następnym starcie systemu (możesz to sprawdzić w zasadzie na każdym typowym systemie, jakkolwiek nie biorę odpowiedzialności za ewentualną utratę plików czy poważniejszą awarię).

W przypadku HAOS jest podobnie - jeśli chcesz zamknąć system (de facto chodzi o “eleganckie” zamknięcie systemu hosta) to robisz to z menu supervisora


w przypadku RPi4 zamknięcie systemu HAOS w ten sposób wyłącza zasilanie portów USB więc zwykle widać kiedy można odłączyć zasilanie już po LED w obudowie dysku (jeśli masz obudowę, gdzie LED świeci zawsze gdy jest zasilanie i mruga w trakcie dostępu do hdd/ssd, a takie zachowanie jest najpopularniejsze).
Jedna istotna UWAGA - GUI w trakcie procesu zamykania systemu przestaje być dostępne praktycznie natychmiast, ale to nie jest wyznacznik zamknięcia systemu, bo samo zamykanie systemu jeszcze potem trwa i trwa (i jeszcze trochę trwa i trwa) i wcale nie jest to coś co się dzieje szybko (nie są to sekundy, tylko minuty).

Oprócz tego kontrolki LED w samym RPi pokazują kiedy można wyłączyć zasilanie, to działa z pewnością w RPI4, ale w RPi3 chyba jest identycznie (no na jakieś 99%) - obejrzyj od początku do końca

generalnie to jest RPi4 i filmik trwa ponad 1,5 minuty! bo tyle trwa u mnie prawidłowe zamknięcie systemu (mimo tego, że dysk jest nvme, w obudowie na USB3 z obsługą UASP, a to wszystko jest wpięte do portu USB3 w RPi4, więc to totalnie najszybsze z możliwych rozwiązań), i zaczyna się on w momencie kliknięcia w potwierdzenie zamykania systemu, a kończy w momencie gdy system się prawidłowo zamknął - świadczy o tym 8- luib 10-krotne (policzyć błyski jest trudno) szybkie regularne mignięcie zielonej LED - to końcowe miganie zielonej LED jest tak bardzo charakterystyczne, że nie sposób tego przegapić jeśli się obserwuje kontrolki LED, jest też poprzedzone krótkim mignięciem (zgaśnięciem) kontrolki czerwonej i równoczesnym z wyłączeniem zasilania na portach USB - zielona kontrolka RPi jest słabo widoczna poniżej czerwonej w prawym dolnym rogu kadru).
Nie pamiętam czy w RPI3 też są wyłączane porty USB (mogą nie być) - więc jeśli RPi nie wyłącza portów, to zakryj sobie górną połowę kadru by widzieć tylko kontrolki RPi - te w prawym dolnym rogu, to być może będziesz miał jakieś odniesienie do rzeczywistości.

W każdym razie zasilanie od RPi można odłączyć dopiero, gdy system jest w 100% zamknięty i jest to czynność potrzebna by wystartować system ponownie (bo RPi bootuje natychmiast po ponownym podpięciu zasilania).

Jeśli potrzebujesz zrestartować hosta (czyli zrobić restart systemu HAOS), to do tego służy pozycja po lewej

Natomiast jeśli chcesz zrestartować tylko sam serwer HA (czyli w/g obecnej terminologii “HA core”) to jest do tego taki przycisk


który w zasadzie dubluje ten przycisk z kontroli serwera

I teraz do clou - jeśli odetniesz zasilanie to myślę, że w 9 na 10 przypadków następuje uszkodzenie bazy danych (bo jest to najczęściej zapisywany plik)
HAOS traktuje taki zanik zasilania na nie zamkniętym “czysto” systemie jako awarię systemu i wdraża przy następnym starcie procedury ratunkowe, które możesz odbierać jako brak startu, bo trwają przynajmniej kilka minut dłużej od czystego startu (ponieważ RPi3 ma tylko USB2 to może to nawet być kilkanaście minut) - HAOS po pierwsze startuje z drugiego “slotu” z systemem (w każdej instalacji są po 2 kopie systemu, być może różne, to zapewne zależy od historii uruchomień, ale nie wnikałem jak aktualizacja systemu hosta wygląda technicznie od środka), ponadto podejmuje wtedy próbę naprawy systemu plików na partycji hassio-data co właśnie trwa dosyć długo szczególnie jeśli są błędy (u mnie zawsze się ona udawała w przypadku wielokrotnych zaników zasilania moich maszyn na bazie x86-64) oraz ostatnie ale może najważniejsze - nawet naprawa systemu plików może nie być wystarczająco skuteczna aby baza danych pozostała w dobrej kondycji (co może choć nie musi być przyczyną utraty historii).

Nie , bo w RPi3 nie da się zaktualizować firmware, a właściwy bootloader znajduje się na dysku (w firmware jest zaszyty tylko pre-bootloader), dlatego RPi3 jest bardziej wybredne jeśli chodzi o dobór obudowy na dysk (mimo, to teraz po przemyśleniu, że być może nieprawidłowo zamykasz system sądzę, że nie masz żadnych problemów ze sprzętem tylko jesteś zbyt niecierpliwy jeśli chodzi o możliwości używanego sprzętu).

Właściwie najprostszą sugestią może być podłączenie monitora do RPi (mimo, że pewnie nie będzie w tym momencie bardzo użyteczny, to zobaczysz jak wygląda proces uruchamiania się systemu oraz później zamykania systemu) i przede wszystkim ile to faktycznie trwa w Twojej konfiguracji sprzętowej.

RPi 3 zawsze najpierw próbuje startować z karty TF, dopiero później z nośnika USB (nie pamiętam czy kolejność można zmienić w nieodwracalny sposób - ale pewne ustawienia pre-bootloadera można w RPi 3 zmienić w nieodwracalny sposób tylko jeden jedyny raz, jakkolwiek RPi3B+ kolejność bootowania jest już ustawiona OK fabrycznie i nie polecam grzebać - jeśli mnie pamięć nie myli to tylko “trójka beż plusa” wymagała takiej modyfikacji).

No i na koniec powrócę do tego od czego zacząłem - na tym dysku powinieneś zainstalować przede wszystkim najpierw RPiOS by się przekonać czy sprzęt pracuje w pełni stabilnie (oraz jak się zachowuje po czystym zamknięciu systemu i przy czystym restarcie, możesz też na tak spreparowanym systemie sprawdzić czy udaje się “brudny” restart - jakkolwiek RPiOS jest skonstruowany inaczej, więc nie oczekuj w pełni identycznego zachowania z HAOS), do tego przyda się też monitor klawiatura i mysz.

Zakładam, że może (choć nie musi) występować problem z zasilaniem - w HA stan zasilania można monitorować za pomocą tej integracji

jest ona standardowym składnikiem HAOS w wersji dla RPi (od jakiegoś dłuższego czasu - chyba już rok albo dwa).

Wskaźnik zasilania na filmiku ma uszkodzony jeden z segmentów, co utrudnia odczyt, ale w praktyce gdy jestem w stanie nim zmierzyć napięcie większe od 4,7V na portach USB, to RPi nie raportuje jeszcze problemów z zasilaniem (a przez większość czasu jest ono bliższe 4,8V)

Ja pisałem, ale tutaj nie szukaj problemu (a w szczególności jego rozwiązania) jeśli masz jakikolwiek problem ze stabilnością lub kompatybilnością to takie rozwiązanie na 99% nie pomoże (zostawiam sobie ten 1% jeśli przypadek okaże się beznadziejny - przecież nie ma musu by bootować z dysku, można go traktować tylko jako nośnik danych ale nie zwalnia nas to z obowiązku prawidłowej obsługi systemu).

Dodatkowe parę screenshotów mi.in. do tematu instalacji bare-matal (generic x86-64) oraz migracji między nośnikami (ostatnio wprowadzono również kompatybilne Backupy również w innych rodzajach instalacji - więc ułatwia to migracje).

Tym razem robiłem to wykorzystując Windows 10, screenshoty uwzględniają możliwe błędy, ale komentarz i uzupełnienia w innym terminie:

  1. Balena Ether

Tu rozwinąłem ukryty dysk by pokazać dysk systemowy (NIGDY go nie wolno wybrać!)

Wciskamy “Yes, I’m sure” oczywiście tylko gdy mamy 100% pewności, że wybraliśmy właściwy nośnik!

miejsce na komentarz - tu wyskakuje okienko UAC (nie mam pomysłu jak zrobić z niego screeshota, a jestem zbyt leniwy by użyć do tego grabbera) oczywiście trzeba zaakceptować, bo jeśli nie damy uprawnień to skończymy z błędem z poniższego obrazka

  1. podgląd na układ partycji (tylko dla ciekawskich), jeśli diskmgmt.msc zaproponowałoby inicjalizację nośnika po działaniach Balena Ether to w żadnym wypadku na to nie pozwalamy!

  2. Przywracanie backupu na etapie onboardingu

zapomniałem zrobić screenshota… ale użyłem innego który wygląda identycznie

Możliwe błędy:

  • nie wyświetla się linijka z “alternatywnie możesz przywrócić…” - rozwiązanie - poczekać minutę do kilku minut i odświeżyć stronę.
  • formularz nie chce przyjąć poprawnego pliku z backupem (z bliżej niewyjaśnionej przyczyny zdarzyło mi się to na Firefoxie nie dociekałem czemu, bo o dziwo systemowa przeglądarka MS Edge dala radę…)

Powtórnie widzimy tą samą stronę na której wrzucaliśmy backup - pozornie nic się nie dzieje - zalecam spacer (jeśli pamiętacie ile czasu zajęło przygotowanie backupu, to przygotujcie siły na niedotykanie niczego przez czas przynajmniej 2x dłuższy)

PS @Krzyszof_K celowo “wyhodowałem” backup o rozmiarze koło 3GB (wybierając “full backup” dorzuciłem po prostu media, których normalnie nie zachowuję w produkcyjnych backupach).

PPS innych moderatorów proszę o nie scalanie tego postu z niczym innym nawet jeśli użyte tu stwierdzenia wskazują, że może służyć też w innym wątku…

Nie puszcza dalej, nie rozpoznaje pliku *.tar. pomimo, że to JEST .*tar.
obraz

O co chodzi? Jak to obejść?

Czy ten plik możesz poprawnie otworzyć innym programem? Bez problemu mozesz wypakowac wszystko z tego pliku? Może plik tar jest uszkodzonym archiwum.

tak, bez problemu otwieram go np. WinRAR’em:

Ufff… na szczęście ruszyło z MS Edge :slight_smile: Kluczowa informacja jest tutaj: