WebDav: Backup Problem für Meta Daten

Bei mir ist es so, dass beim Backup auf OneDrive, die json-Datei neben dem Archiv gespeichert wird.

Bei Speichern auf den NAS wird nur eine tar-Datei erzeugt.

Allerdings ist die json-Datei dann im tar-Archiv enthalten.


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 :slight_smile:

Zitat (nicht von mir):

Mögliche Gründe für den JSON-Datei-Fehler

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.

danke @Schorsch und @MarzyHA

im Grunde gibt es 2 Issues

  • 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.

1 „Gefällt mir“

Habe in nextcloud (PHP) 2 zeitrelevante Konfigurationen reichlich hoch gesetzt:

max_input_time=3600
max_execution_time=3600

@jbenecke die sind vermutlich viel zu hoch, oder? Nehme gerne Empfehlungen :slight_smile:

Bisschen was zur Architektur der Backups:

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.

2 „Gefällt mir“

@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.
:slight_smile:

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!))

1 „Gefällt mir“

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

Dashboard

php.ini für NextCloud

max_input_time=3600
max_execution_time=3600
1 „Gefällt mir“