Bei mir ist es allerdings immer gleich. Nicht mal 1 und mal 2 Dateien.
Ich habe mal einen guten Freund gefragt.
Der sagt, dass es daran liegt, wie das Backup-Addon, in meinem Fall OneDrive, das Backup verwaltet.
Allerdings ist deine Frage damit evtl. nicht hinreichend beantwortet.
Du könntest mal schauen, ob in so einem „Single-Backup“ die json-Datei im tar-Archiv enthalten ist.
Yep, so hatte ich das auch in Erinnerung. Je nachdem was/ wie unterstützt wird, schreiben die Integrationen die metadaten entweder mit rein oder packen sie eine Ebene drüber. Bei der webdav Integration scheint es aber so, dass die json Files mit den .tar Files ins gleiche Verzeichnis geschrieben werden. Da müsste ja eigentlich ein konsistentes Verhalten zu beobachten sein, da die gleiche Integration die json Files vermutlich nicht an verschiedenen Orten ablegt
Der Kern des Problems scheint zu sein, dass der HA Supervisor das Backup nicht als vollständig abgeschlossen betrachtet, solange die kleine, abschließende JSON-Datei nicht erfolgreich hochgeladen und/oder die Transaktion bestätigt wurde.
1. WebDAV-Sperren, Timeouts oder Server-Bestätigungen (Probable Cause)
Zwei separate Schreibvorgänge: Der Supervisor muss zwei Dateien nacheinander erstellen: Zuerst die große .tar-Datei und dann die kleine Metadaten-JSON-Datei.
Fehlende Atomarität: WebDAV ist im Vergleich zu dedizierten Dateisystem-Protokollen (wie SMB/CIFS bei der Synology NAS) komplexer in Bezug auf Sperren und das Schreiben von Metadaten. Es ist möglich, dass der WebDAV-Server (Nextcloud) die Verbindung nach dem zeitraubenden Upload der großen .tar-Datei kurzzeitig sperrt, eine Bestätigung verzögert oder ein Timeout eintritt, bevor die winzige JSON-Datei erfolgreich hochgeladen werden kann.
Unvollständige Transaktion: Obwohl die .tar-Datei in der Cloud liegt, ist die Backup-Operation für den HA Supervisor erst beendet, wenn alle erwarteten Dateien (inkl. der finalen JSON-Metadaten) erfolgreich geschrieben wurden. Wenn dies fehlschlägt, hängt der Backup-Vorgang im Status „Upload läuft“ fest und die GUI lässt keinen Abbruch zu.
Prüfen, ob es in der Nextcloud oder im WebDAV-Server Timeout-Einstellungen gibt, die man verlängern kann.
die json Datei mit den Metadaten wird nicht immer per WebDav in die NextCloud geschrieben.
dies resultiert dann darin, dass HA meint, das Backup liefe noch.
und lässt dann kein weiteres Backup mehr zu
Das tar file ist immer das Gleiche, denn das wird von HA ja nur einmal erzeugt, und dann an die verschiedenen Backup-Orte (bei mir local, Synology NAS und Webdav) kopiert. und enthält bei mir nicht das json File mit den Metadaten.
probier ich gerne - wenn mir jemand sagt (oder auf eine Doku verweist), wie’s geht.
Alles was in dem .tar File ist, wird vom Core erzeugt und verschlüsselt. Da haben die Integrationen dann keinen Einfluss mehr drauf und können auch keine Datei in das File packen. Sprich die Integrationen bekommen den verschlüsselten Datei-Stream und laden es dann einfach hoch.
Einige Integrationen legen neben dem .tar File noch ein Metadata File an, was eben Infos zum Backup enthält. Das ist dem geschuldet, dass nicht jedes Ziel eigene Metadaten für eine Datei unterstützt. Das ist eben auch der Fall bei WebDAV. Ohne das Metadaten File wird das Backup dann auch nicht in Home Assistant angezeigt.
@Nicknol deine 2xx sind in Ordnung (wie @MarzyHA schon richtig geschrieben hat), das sind durchaus normale Statuscodes für WebDAV.
Solltest du in ein Timeout beim Upload laufen, dann solltest du eigentlich eine 5xx Fehler im Log sehen. Das Timeout von PHP hochzustellen schadet zum testen jetzt erstmal nicht.
@jbenecke Vielen Dank für die Informationen zur Architektur des Backups. Das klärt sicher einiges hier im Thread, insbesondere wann es das Metadaten File gibt.
ja, ich weiß, 2xx und auch 3xx sind „gute“ HTTP Return Codes.
und die traten ja auch beim erfolgreichen Backup gestern auf.
Heute Nacht lief das Backup durch und so finde ich wieder 2xx im Debug Log.
Ich werde also weiter beobachten, und loggen.
Vielleicht haben die geänderten Timeouts ja eine Wirkung.
Insgesamt halte ich es aber für unglücklich, wenn die über Stunden fehlende Quittung des Backup-Ziels den Eindruck erweckt, das Backup liefe noch, und, fast schlimmer, kein weiteres Backup ermöglicht (außer nach einem HA-Restart über den entsprechenden Service-Aufruf (nicht GUI!))
Update nach knapp einer Woche: alle Backups sind durchgelaufen und an den konfigurierten Orten abgelegt worden.
Ist es Zufall oder hat eine der Maßnahmen etwas geändert? Ich weiß es nicht, werde aber weiter beobachten.
debug mode für webdav eingeschaltet - kann eigentlich nix bewirkt haben
Automatisierungen geschrieben, die fehlgeschlagene oder lang laufende Backups bemerkt - können eigentlich nix bewirkt haben
IT-Dashboard um Backup informationen erweitert - kann eigentlich nix bewirkt haben
php.ini Werte für timeouts für NextCloud geändert - könnte was bewirkt haben
Automatisierungen
alias: Backup failed
description: ""
triggers:
- trigger: state
entity_id:
- event.backup_automatic_backup
conditions:
- condition: state
entity_id: event.backup_automatic_backup
attribute: event_type
state: failed
actions:
- action: script.notification_home
metadata: {}
data:
title: Automatic backup failed
message: >-
The last automatic backup failed due to {{
state_attr('event.backup_automatic_backup', 'failed_reason') }}
persistent: "Y"
send_always: "Y"
info_url: /dashboard-it/home
mode: single
alias: Backup taking too long
description: ""
triggers:
- trigger: template
value_template: >
{% set ts_start =
states('sensor.backup_zuletzt_versuchtes_automatisches_backup') %} {% set
ts_end =
states('sensor.backup_letztes_erfolgreiches_automatisches_backup') %}
{% if ts_start not in ['unknown', '', None] and ts_end not in ['unknown',
'', None] %}
{% set dt_start = as_datetime(ts_start) %}
{% set dt_end = as_datetime(ts_end) %}
{% set diff_now_start = (now() - dt_start).total_seconds() / 60 %}
{% set diff_end_start = (dt_start - dt_end).total_seconds() / 60 %}
{% set duration_success = (dt_end - dt_start).total_seconds() / 60 %}
{{ (diff_now_start > 20 and diff_end_start > 0) or (duration_success > 30) }}
{% else %}
false
{% endif %}
conditions: []
actions:
- action: script.notification_home
metadata: {}
data:
title: Automatic backup took too long
message: The last automatic backup took too long or didn't start prpoerly
persistent: "Y"
send_always: "Y"
info_url: /dashboard-it/home
mode: single