Przywracanie backupa Home Assistanta przez SSH

Problem

Aktualizacja Home Assistanta poszła nie tak — load jedzie na 100%, UI nie odpowiada, automatyzacje stoją. Jeśli masz dostęp przez SSH (oficjalny Terminal albo Advanced SSH — patrz wcześniejszy wpis o SSH), nie musisz czekać aż UI łaskawie wstanie. Backup przywrócisz z linii poleceń, a jeśli problem leży po stronie konkretnej wersji HA Core — możesz ją zwyczajnie cofnąć bez ruszania backupa.

Co umie komenda ha backups

Supervisor HA ma wbudowany CLI do operacji na backupach. W shellu SSH:

$ha backups

Dostaniesz listę wszystkich backupów z slug (krótkim ID), nazwą, datą i typem:

slug: 212776e9
name: Automatic backup Core 2026.5.6
date: 2026-05-24T03:00:00.000000+00:00
type: partial
protected: true

Pola które się liczą:

• slug — używasz go we wszystkich kolejnych komendach
• type — full (cały system) albo partial (wybrane elementy)
• protected — true oznacza backup zaszyfrowany hasłem

Szczegóły konkretnego backupa:

$ha backups info 212776e9

Pokaże m.in. zawartość:

content:
  homeassistant: true
  addons:
    - core_mosquitto
    - core_zigbee2mqtt
  folders:
    - share
    - ssl

Przywracanie backupa

Pełny restore (HA Core, addony, foldery — wszystko z backupa):

$ha backups restore 212776e9

Tylko HA Core + jego config, bez ruszania addonów i folderów współdzielonych:

$ha backups restore 212776e9 --homeassistant

Wybiórczo, np. tylko jeden addon:

$ha backups restore 212776e9 --addons core_zigbee2mqtt

Bez addonów i folderów (tylko HA):

$ha backups restore 212776e9 --addons "" --folders ""

Backup chroniony hasłem

Automatyczne backupy w nowszych wersjach HA są domyślnie szyfrowane. Próba restore bez hasła zwróci:

Error: Invalid password for backup 212776e9

Podaj hasło flagą --password:

$ha backups restore 212776e9 --homeassistant --password TWOJE_HASLO

Skąd wziąć hasło:

• Automatyczne backupy — używają hasła z Settings → System → Backups → ⚙ → Default backup password
• Google Drive Backup addon — własne hasło z konfiguracji addonu
• Backupy ręczne — to które wpisałeś przy tworzeniu

Jeśli nie pamiętasz, sprawdź managera haseł albo zobacz czy któryś z backupów na liście ma protected: false — taki przywrócisz bez hasła.

Wyciąganie hasła default z konfiguracji HA

Gdy UI nie odpowiada (klasyk przy load 100%), a hasła do automatycznych backupów nie pamiętasz, możesz je wyciągnąć bezpośrednio z konfiguracji HA. Hasło default jest trzymane plaintextem w pliku /config/.storage/backup:

$cat /config/.storage/backup

Szukaj pola default_backup_password:

{
  "version": 1,
  "data": {
    "default_backup_password": "moje-haslo-do-backupow",
    "automatic_backups_configured": true,
    ...
  }
}

Jeśli pole istnieje i ma wartość — masz hasło. Użyj go w ha backups restore <slug> --password ....

Jeśli pole default_backup_password jest puste (null albo "") i wszystkie backupy są protected: true — hasło ustawiał ktoś inny (np. addon Google Drive Backup) albo zostało ustawione przez API. Sprawdź konfiguracje addonów backupowych:

$ha addons list | grep -i backup
$ha addons info <slug-addonu-backup>

Co robić, gdy restore się zawiesi

Czasem Supervisor czeka na proces HA, który mieli CPU i nie odpowiada na sygnał stop. Restore wisi bez postępu. W drugim oknie SSH wymuś stop kontenera:

$docker stop homeassistant

(wymaga Advanced SSH z wyłączonym Protection mode, oficjalny Terminal nie ma docker). Po ubiciu kontenera Supervisor dokończy restore i wystartuje HA z przywróconych plików.

Downgrade HA Core bez restore'a

Jeśli problem to konkretna wersja HA Core (typowy scenariusz: nowy bug w pakiecie Pythona po aktualizacji, np. zigpy 1.4 wali assertami na ZHA), nie musisz przywracać backupa. Wystarczy cofnąć samą wersję:

$ha core update --version 2026.4.5

Podstaw wersję, którą miałeś przed aktualizacją (sprawdź na github.com/home-assistant/core/releases). Supervisor pobierze odpowiedni obraz Dockera i zrestartuje HA z poprzednią wersją Pythona i wszystkich pakietów.

Kiedy downgrade, a kiedy restore

Downgrade HA Core jest najmniej inwazyjny — zmienia tylko wersję obrazu Dockera, nie rusza twoich automatyzacji, scen, encji ani historii. Restore z backupa cofa wszystko, co w nim było, łącznie z konfiguracją z dnia backupa.

Cofanie wersji addonu

Analogicznie dla addonów. Najpierw zobacz jakie addony masz zainstalowane:

$ha addons

albo z bardziej czytelnym formatowaniem:

$ha addons list

Dostaniesz listę typu:

- slug: core_mosquitto
  name: Mosquitto broker
  version: 6.4.1
  version_latest: 6.4.1
  state: started
  update_available: false
- slug: core_zigbee2mqtt
  name: Zigbee2MQTT
  version: 1.42.1
  version_latest: 1.43.0
  state: started
  update_available: true
- slug: a0d7b954_ssh
  name: Advanced SSH & Web Terminal
  version: 21.1.0
  version_latest: 21.1.0
  state: started
  update_available: false

Pole slug używasz w komendach (uwaga: addony oficjalne mają prefix core_, community z hassio-addons mają prefix typu a0d7b954_). Cofnięcie wersji konkretnego addonu:

$ha addons update core_zigbee2mqtt --version 1.42.0

Jeśli chcesz zobaczyć szczegóły jednego addonu (dostępne wersje, opis, opcje konfiguracji):

$ha addons info core_zigbee2mqtt

Pole version_latest to najnowsza w repozytorium. Lista historycznych wersji nie jest dostępna w ha addons info — sprawdź repozytorium addonu na GitHubie (link w polu url), tam zobaczysz tagi/releases z numerami wersji i changelogami.

Inne przydatne komendy:

$ha addons restart core_zigbee2mqtt    # restart addonu
$ha addons stop core_zigbee2mqtt       # zatrzymanie
$ha addons logs core_zigbee2mqtt       # logi
$ha addons stats core_zigbee2mqtt      # CPU/RAM użycie

ha addons stats jest szczególnie przydatne, gdy chcesz znaleźć który addon żre zasoby — pokaże procent CPU i zużycie pamięci per addon.

Wyłącz auto-update zanim znowu się popsuje

Po przywróceniu HA do działającego stanu, wyłącz automatyczne aktualizacje, żeby ten sam scenariusz się nie powtórzył przy następnej generacji bugów:

W UI: Settings → System → Updates → ⋮ → Auto-update dla Home Assistant Core, Supervisor, OS i każdego addonu, którego nie chcesz aktualizować automatycznie.

Lepsze podejście: zostaw auto-update Supervisora i OS (mała powierzchnia bugów), ale wyłącz auto-update HA Core i addonów. Updateuj je ręcznie kilka dni po wydaniu, sprawdzając najpierw release notes i forum HA — release-day bugi są częste, weekendowi early-adopterzy wyłapują je dla ciebie.

Backup po restore — od razu

Pierwszy ruch po udanym restore: zrób ręczny backup przed jakimikolwiek zmianami:

$ha backups new --name "post-restore-clean"

Nieszyfrowany, żeby nie zapomnieć hasła. Trzymaj go obok automatycznych — to twoja kotwica do działającej konfiguracji, niezależna od retencji automatycznych backupów (które mogą się przeterminować).

Jeśli chcesz zaszyfrowany:

$ha backups new --name "post-restore-clean" --password TWOJE_HASLO

Backup powstaje w /backup/ na hoście i w /mnt/data/supervisor/backup/ w kontenerze Supervisora. Możesz go zsynchronizować na inne miejsce (Samba addon, Google Drive Backup addon, scp) — ha backups ma też opcje uploadu do zdalnych lokalizacji.

Pod spodem

ha to klient CLI gadający z Supervisorem przez REST API na http://supervisor:80. Wszystkie operacje (backups list, backups restore, core update) to wywołania endpointów Supervisora, który zarządza kontenerami Dockera tworzącymi instalację HA. Restore polega na rozpakowaniu .tar.gz z /backup/, podmianie zawartości odpowiednich woluminów (/data dla HA Core, /data/addons/<slug> dla addonów) i restarcie kontenerów.

Dzięki temu cała logika restore'a żyje poza HA Core — możesz przywrócić nawet zupełnie zepsuty HA, dopóki Supervisor żyje. A Supervisor żyje praktycznie zawsze, bo to osobny kontener, który nie zależy od stanu HA Core.