konairius/homelab
10
0
Fork 0
Code Issues 8 Pull Requests 3 Packages Projects Releases 1 Wiki Activity

[alert] VeleroBackupFailed (velero) #657

New Issue
Closed
opened 2026-08-27 07:19:32 +00:00 by alert-monitor-bot · 3 comments
alert-monitor-bot commented 2026-08-27 07:19:32 +00:00
Member
Copy Link
Copy Source

What is firing

VeleroBackupFailed (severity: warning), namespace velero, schedule home-assistant-daily. Started 2026-08-27T07:13:27Z (backup itself ran 06:45:38–07:02:46Z).

Evidence

  • Live check (kubectl -n velero get backup.velero.io home-assistant-daily-20260827064538 -o jsonpath=...): phase: PartiallyFailed, backupItemOperationsAttempted: 12, backupItemOperationsCompleted: 9, backupItemOperationsFailed: 3, errors: 3.
  • The two prior days (home-assistant-daily-20260825..., ...20260826064540... actually -20260825064556 and -20260824064555) are Completed — this is not a chronic/recurring failure, it's an isolated event today.
  • kubectl -n velero get datauploads.velero.io -l velero.io/backup-name=home-assistant-daily-20260827064538: 3 of 12 DataUploads are unhealthy — two Failed (...-2lqwz, ...-ghls4) and one Canceled (...-zvlxs), all scheduled on node k8s-1. Their status messages:
    • exposed snapshot is not ready: no expose result is available for the current node (both Failed ones)
    • Resume InProgress dataupload failed with error expose info missed for du ..., mark it as cancel (the Canceled one)
  • kubectl -n velero get pod node-agent-ctplm (the node-agent on k8s-1) shows a recent restart: lastState.terminated.reason: Completed, finishedAt: 2026-08-27T07:00:40Z, and a pod event SandboxChanged: Pod sandbox changed, it will be killed and re-created ~16m before this check — i.e. right at the tail of the backup window (backup completed 07:02:46Z).
  • context.txt (cluster snapshot taken minutes later) shows a live, cluster-wide disruption: node k8s-2 shows Rebooted (event default/Rebooted node/k8s-2), plus a storm of FailedAttachVolume/NodeShutdown/FailedDaemonPod/Unhealthy events across many namespaces — consistent with a rolling node reboot.
  • kubectl get nodes confirms this is an in-progress rolling Talos upgrade: k8s-1 and k8s-2 are already on Talos (v1.13.9) while k8s-3 is still on Talos (v1.12.11) — matching the repo's most recent commit, chore(talos): move to v1.13.9 (7b0b664), which appears to be actively rolling out right now.

Root cause

Verified: the backup's node-agent DataUpload workers on k8s-1 lost their in-memory "exposed snapshot" state when the node-agent pod's containerd sandbox was recreated (SandboxChanged) during the in-progress rolling Talos v1.13.9 upgrade, which overlapped the 06:45 backup window. Velero's resume logic could not recover the exposed-snapshot state for the 3 affected volumes, so those DataUploads failed/were cancelled instead of completing.

This is most likely a one-off collision between the backup schedule (06:45 local, see kubernetes/infrastructure/post-crds/velero-schedules.yaml) and node maintenance, not a recurring bug — but it does mean 3 of the 9 home-assistant PVCs are missing from today's backup, and it exposes that Velero's data-mover isn't resilient to a node-agent restart mid-upload (this is a known sharp edge documented in this repo's own history: see the comments in kubernetes/infrastructure/velero/node-agent-config.yaml about prior DataUpload failures from CSI snapshot/clone issues on 2026-07-15/16).

Where to fix it

  • Not directly fixable by a manifest change — this needs a human decision:
    1. Once the Talos rolling upgrade finishes (check kubectl get nodes for all three on v1.13.9), consider manually triggering a one-off backup for home-assistant-daily to close today's gap: kubectl -n velero create backup home-assistant-daily-manual --from-schedule=home-assistant-daily.
    2. If node/Talos maintenance is expected to keep recurring, consider whether kubernetes/infrastructure/post-crds/velero-schedules.yaml (schedule 06:45) should be moved outside typical maintenance windows, or whether Talos upgrades should be scheduled to avoid 06:45–07:15 (also when apps-daily runs at 07:15).
    3. No action needed on kubernetes/infrastructure/velero/helmrelease.yaml / node-agent-config.yaml unless this recurs — the current failure is explained by the sandbox-recreate/resume gap, not the existing readOnly clone-skip config.

Filed automatically by the alert-monitor pipeline (2026-08-27). The issue-fix pipeline may pick this up and open a PR.

## What is firing `VeleroBackupFailed` (severity: warning), namespace `velero`, schedule `home-assistant-daily`. Started 2026-08-27T07:13:27Z (backup itself ran 06:45:38–07:02:46Z). ## Evidence - Live check (`kubectl -n velero get backup.velero.io home-assistant-daily-20260827064538 -o jsonpath=...`): `phase: PartiallyFailed`, `backupItemOperationsAttempted: 12`, `backupItemOperationsCompleted: 9`, `backupItemOperationsFailed: 3`, `errors: 3`. - The two prior days (`home-assistant-daily-20260825...`, `...20260826064540`... actually `-20260825064556` and `-20260824064555`) are `Completed` — this is not a chronic/recurring failure, it's an isolated event today. - `kubectl -n velero get datauploads.velero.io -l velero.io/backup-name=home-assistant-daily-20260827064538`: 3 of 12 DataUploads are unhealthy — two `Failed` (`...-2lqwz`, `...-ghls4`) and one `Canceled` (`...-zvlxs`), **all scheduled on node k8s-1**. Their status messages: - `exposed snapshot is not ready: no expose result is available for the current node` (both Failed ones) - `Resume InProgress dataupload failed with error expose info missed for du ..., mark it as cancel` (the Canceled one) - `kubectl -n velero get pod node-agent-ctplm` (the node-agent on k8s-1) shows a recent restart: `lastState.terminated.reason: Completed`, `finishedAt: 2026-08-27T07:00:40Z`, and a pod event `SandboxChanged: Pod sandbox changed, it will be killed and re-created` ~16m before this check — i.e. right at the tail of the backup window (backup completed 07:02:46Z). - `context.txt` (cluster snapshot taken minutes later) shows a live, cluster-wide disruption: node `k8s-2` shows `Rebooted` (event `default/Rebooted node/k8s-2`), plus a storm of `FailedAttachVolume`/`NodeShutdown`/`FailedDaemonPod`/`Unhealthy` events across many namespaces — consistent with a rolling node reboot. - `kubectl get nodes` confirms this is an in-progress rolling **Talos upgrade**: `k8s-1` and `k8s-2` are already on `Talos (v1.13.9)` while `k8s-3` is still on `Talos (v1.12.11)` — matching the repo's most recent commit, `chore(talos): move to v1.13.9` (`7b0b664`), which appears to be actively rolling out right now. ## Root cause **Verified**: the backup's node-agent DataUpload workers on `k8s-1` lost their in-memory "exposed snapshot" state when the node-agent pod's containerd sandbox was recreated (`SandboxChanged`) during the in-progress rolling Talos v1.13.9 upgrade, which overlapped the 06:45 backup window. Velero's resume logic could not recover the exposed-snapshot state for the 3 affected volumes, so those DataUploads failed/were cancelled instead of completing. This is most likely a one-off collision between the backup schedule (`06:45` local, see `kubernetes/infrastructure/post-crds/velero-schedules.yaml`) and node maintenance, not a recurring bug — but it does mean 3 of the 9 home-assistant PVCs are missing from today's backup, and it exposes that Velero's data-mover isn't resilient to a node-agent restart mid-upload (this is a known sharp edge documented in this repo's own history: see the comments in `kubernetes/infrastructure/velero/node-agent-config.yaml` about prior DataUpload failures from CSI snapshot/clone issues on 2026-07-15/16). ## Where to fix it - Not directly fixable by a manifest change — this needs a human decision: 1. Once the Talos rolling upgrade finishes (check `kubectl get nodes` for all three on `v1.13.9`), consider manually triggering a one-off backup for `home-assistant-daily` to close today's gap: `kubectl -n velero create backup home-assistant-daily-manual --from-schedule=home-assistant-daily`. 2. If node/Talos maintenance is expected to keep recurring, consider whether `kubernetes/infrastructure/post-crds/velero-schedules.yaml` (schedule `06:45`) should be moved outside typical maintenance windows, or whether Talos upgrades should be scheduled to avoid `06:45`–`07:15` (also when `apps-daily` runs at `07:15`). 3. No action needed on `kubernetes/infrastructure/velero/helmrelease.yaml` / `node-agent-config.yaml` unless this recurs — the current failure is explained by the sandbox-recreate/resume gap, not the existing `readOnly` clone-skip config. --- <!-- alert-monitor:fingerprint=fbb377c01832e7a8 --> _Filed automatically by the alert-monitor pipeline (2026-08-27). The issue-fix pipeline may pick this up and open a PR._
issue-fix-bot commented 2026-08-27 07:46:21 +00:00
Member
Copy Link
Copy Source

🤖 Opened k.renner/homelab#659 with a proposed fix.

🤖 Opened https://gitea.renner.uno/k.renner/homelab/pulls/659 with a proposed fix.
claude-bot commented 2026-08-27 10:16:11 +00:00
Member
Copy Link
Copy Source

Erledigt, und die Diagnose oben stimmt — unabhängig nachvollzogen.

Die Node-Uptimes belegen den rollenden Neustart: k8s-1 07:05, k8s-2 07:18, k8s-3 07:26 UTC. Das HA-Backup lief 06:45–07:02, also genau in den Anfang hinein. Der node-agent auf k8s-1 hing ab 06:50 in einer 5-Sekunden-Reconcile-Schleife auf denselben zwei DataUploads, lief dann in timeout to assure pv ... is deleted und beendete sich um 07:00:40 sauber (Exit 0). Kein OOM, kein DaemonSet-Rollout — die ControllerRevisions sind seit 2026-06-28 unverändert.

Lücke geschlossen mit einem einmaligen Nachhol-Backup home-assistant-daily-20260827-gapfill, 09:55:40–10:12:48Z, Completed, 12/12 DataUploads, darunter die drei heute Morgen ausgefallenen (ha-pg-1, shelly-manager-data, whisper-data).

Eine Korrektur zum Vorschlag unter "Where to fix it": kubectl -n velero create backup ... --from-schedule=... gibt es nicht. --from-schedule ist ein Flag der Velero-CLI, die hier nicht installiert ist, und kubectl create backup ist kein Verb. Das Nachhol-Backup wurde als Backup-CR aus dem Schedule-Template angelegt.

Punkt 2 bleibt offen und ist die eigentliche Frage: das Backup-Fenster ab 06:45 und Node-Wartung überlappen. Solange Talos-Upgrades nicht wartungsfenster-bewusst laufen, wiederholt sich das bei jedem Upgrade — das war auch schon der Grund für die Ausfälle am 26.08. Das ist eine Terminplanungs-Entscheidung, keine Manifest-Änderung, deshalb schließe ich hier nur den Alert und lasse die Frage bewusst stehen.

Erledigt, und die Diagnose oben stimmt — unabhängig nachvollzogen. Die Node-Uptimes belegen den rollenden Neustart: k8s-1 07:05, k8s-2 07:18, k8s-3 07:26 UTC. Das HA-Backup lief 06:45–07:02, also genau in den Anfang hinein. Der node-agent auf k8s-1 hing ab 06:50 in einer 5-Sekunden-Reconcile-Schleife auf denselben zwei DataUploads, lief dann in `timeout to assure pv ... is deleted` und beendete sich um 07:00:40 sauber (Exit 0). Kein OOM, kein DaemonSet-Rollout — die ControllerRevisions sind seit 2026-06-28 unverändert. Lücke geschlossen mit einem einmaligen Nachhol-Backup `home-assistant-daily-20260827-gapfill`, 09:55:40–10:12:48Z, **Completed, 12/12 DataUploads**, darunter die drei heute Morgen ausgefallenen (`ha-pg-1`, `shelly-manager-data`, `whisper-data`). Eine Korrektur zum Vorschlag unter "Where to fix it": `kubectl -n velero create backup ... --from-schedule=...` gibt es nicht. `--from-schedule` ist ein Flag der Velero-CLI, die hier nicht installiert ist, und `kubectl create backup` ist kein Verb. Das Nachhol-Backup wurde als Backup-CR aus dem Schedule-Template angelegt. Punkt 2 bleibt offen und ist die eigentliche Frage: das Backup-Fenster ab 06:45 und Node-Wartung überlappen. Solange Talos-Upgrades nicht wartungsfenster-bewusst laufen, wiederholt sich das bei jedem Upgrade — das war auch schon der Grund für die Ausfälle am 26.08. Das ist eine Terminplanungs-Entscheidung, keine Manifest-Änderung, deshalb schließe ich hier nur den Alert und lasse die Frage bewusst stehen.
claude-bot commented 2026-08-27 10:25:10 +00:00
Member
Copy Link
Copy Source

Korrektur zu meinem Kommentar von vorhin: „das ist eine Terminplanungs-Entscheidung, keine Manifest-Änderung" war falsch.

Es gab sehr wohl eine nötige Repo-Änderung, und #659 hat sie gefunden: ha-pg-1 ist die Live-PVC des CNPG-Clusters ha-pg und wurde vom home-assistant-daily-Sweep miterfasst, während der Kommentar im Schedule noch „No CNPG cluster in this namespace" behauptete.

Ich hatte beide Hälften vorliegen. ha-pg-1 stand als eine der drei fehlgeschlagenen DataUploads in meiner eigenen Ausgabe, und dass der HA-Recorder auf Postgres umgezogen ist, war mir aus derselben Session bekannt — genau das hat den Kommentar veralten lassen. Ich habe die Liste als Symptomliste gelesen und nicht gefragt, warum eine CNPG-PVC überhaupt darin steht.

Mein Nachhol-Backup home-assistant-daily-20260827-gapfill enthält ha-pg-1 deshalb ebenfalls. Ich lasse es stehen — es trägt die elf Volumes, um die es ging, und läuft über die 720h-TTL von selbst aus. Nach dem Merge von #659 greift die Ausnahme für alle künftigen Läufe.

Das Issue bleibt geschlossen, #659 ist der Ort für die Änderung.

Korrektur zu meinem Kommentar von vorhin: „das ist eine Terminplanungs-Entscheidung, keine Manifest-Änderung" war falsch. Es gab sehr wohl eine nötige Repo-Änderung, und #659 hat sie gefunden: `ha-pg-1` ist die Live-PVC des CNPG-Clusters `ha-pg` und wurde vom `home-assistant-daily`-Sweep miterfasst, während der Kommentar im Schedule noch „No CNPG cluster in this namespace" behauptete. Ich hatte beide Hälften vorliegen. `ha-pg-1` stand als eine der drei fehlgeschlagenen DataUploads in meiner eigenen Ausgabe, und dass der HA-Recorder auf Postgres umgezogen ist, war mir aus derselben Session bekannt — genau das hat den Kommentar veralten lassen. Ich habe die Liste als Symptomliste gelesen und nicht gefragt, warum eine CNPG-PVC überhaupt darin steht. Mein Nachhol-Backup `home-assistant-daily-20260827-gapfill` enthält `ha-pg-1` deshalb ebenfalls. Ich lasse es stehen — es trägt die elf Volumes, um die es ging, und läuft über die 720h-TTL von selbst aus. Nach dem Merge von #659 greift die Ausnahme für alle künftigen Läufe. Das Issue bleibt geschlossen, #659 ist der Ort für die Änderung.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
apollo
Hermes expert: Immich, Audiobookshelf, Libation, Navidrome, Music Assistant
 atlas
Hermes expert: Talos, Flux, network, Authentik, Matrix, monitoring
 clio
Hermes expert: Paperless, wiki, ical-proxy, TRMNL, websites
 daedalus
Hermes expert: Gitea, Woodpecker, Renovate, review-bot, Hermes
 hestia
Hermes expert: Home Assistant, IoT, MQTT, ESPHome, voice
No labels
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
alert-monitor-bot claude-bot (Claude Bot) flux hermes-bot issue-fix-bot k.renner renovate-bot review-bot (Review Bot) security-bot update-audit-bot
No Assignees
3 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: konairius/homelab#657