Saltar a contenido

Procedimiento de rollback de Home Assistant

Dos rutas oficiales: full restore desde backup (recomendada para fallos mayores) y rollback core-only via CLI (rápida pero limitada). Decidir cuál usar antes del upgrade es parte del checklist pre-update.

Contexto

El rollback no es un plan B abstracto: es una decisión operativa con criterio de disparo. La fuente da una regla concreta: si pasaste 1–2 horas troubleshooteando y no funciona, restaurá. Esto evita el anti-patrón de "ya estoy adentro, sigo cavando" que aparece en los postmortems del foro.

Contenido

Criterio para disparar el rollback

"Rollback si experimentás inestabilidad, broken core functions, o non-functioning critical devices/automations que no se pueden arreglar en 1–2 horas."

Aplicado al setup del usuario: si las luces / calefacción / seguridad no funcionan post-upgrade y no hay fix en 2 horas, se restaura sin más debate.

Opción A — Full restore desde backup (recomendada)

Aplica cuando el fallo es mayor o no está claramente aislado al Core.

Pasos (HA OS / Supervised):

  1. Settings → System → Backups.
  2. Seleccionar el full backup creado antes del update (debería ser el más reciente).
  3. Click "Restore" → "Full restore".
  4. El sistema se reinicia y restaura al estado pre-upgrade.

HA Container (equivalente):

  1. docker compose down.
  2. Restaurar el bind mount /config desde snapshot pre-upgrade.
  3. Cambiar el tag de la imagen en docker-compose.yml a la versión previa (ghcr.io/home-assistant/home-assistant:2026.X.Y).
  4. docker compose up -d.
  5. Verificar que la base de datos externa (si hay) esté en estado consistente; rollback de DB si aplica.

Opción B — Core-only rollback (CLI)

Aplica cuando estás seguro de que el problema está en HA Core y no en Supervisor / OS / Add-ons.

ha core update --version <previous_version>
# ejemplo
ha core update --version 2026.4.3

Caveat documentado: "This only reverts the Core, not the Supervisor, OS, or Add-ons, so it might not fix issues caused by other component updates."

Cuándo elegirla: - El issue es claramente del Core (un integration core dejó de funcionar, una automation deja de ejecutar). - Supervisor / OS / Add-ons no se actualizaron en este upgrade (lo confirmás revisando Settings → System → Updates antes de aplicar la opción B).

Cuándo NO elegirla: - Hiciste un update masivo donde se actualizó todo. La opción B no toca lo demás → no resuelve. Ir directo a A.

Post-rollback

  1. Anotar por qué falló el upgrade (qué integration / device / automation se rompió, qué error en logs).
  2. Mover el item a "Resueltos" o "Blocked" en el equivalente local del gaps.md del setup propio (no del wiki — el repo de configs del usuario). El wiki no debe tener PII del setup.
  3. Esperar el siguiente release que arregle el issue, o quedarse en la versión actual hasta que aparezca un workaround.

Relaciones

Citas / evidencia

Abierto / gaps

  • Documentar rollback de DB (MariaDB, InfluxDB) cuando se usa Recorder externo y un upgrade aplica migración de schema.
  • Documentar caso edge: rollback en HA Yellow específicamente (eMMC, partition layout).
  • ¿Existe una opción C automática (auto-rollback en boot fallido)? No mencionada en este source — verificar en docs canónicas de HAOS.