Fehler im BackUp der history DB

[wcag22]

@homoran Danke für den Hinweis.

[wcag22]

@wcag22
Es war mir schon klar, dass es schwierig sein wird, den Fehler einzugrenzen. An einen Bug im BackItUp-Adapter habe ich eigentlich auch nicht geglaubt.

Nachdem am Vortag 18:00 Uhr eine manuelle Sicherung fehlerfrei war, dachte ich das Problem hätte sich in Luft ausgelöst. Heute die 06:00 Uhr-Sicherung wieder mit Fehler.

Daher habe ich eine Testreihe aufgesetzt, um dem Spuk auf die Spur zu kommen.
Die Archive aus dem BackUp prüfe ich mit 7zip.

Gedanke:

Fehlerhafter Stick "/usbshare1/iobroker_backup" am NAS

Ergebnis:
Alle Sicherungen der historyDB fehlerhaft. iob, jarvis und javascript in Ordnung

1. Lösungsversuch: anderes Speichergerät (anderer Stick)
(Sicherungsziel gewechselt auf "/usbshare2/iobroker_backup" am NAS)

Ergebnis:
Erste Sicherung um 10:59 Uhr fehlerfrei (Ursache gefunden?)
Drei weitere Versuche wieder mit Fehler ausschließlich in der history DB

2. Lösungsversuch: Stick gewechselt

Ergebnis:
Archiv der history DB mit Datenfehler

3. Lösungsversuch: Sicherung direkt auf eine HD am NAS

Ergebnis:
Alle 3 Versuche mit Datenfehler in der history DB

weitere Versuche mit smb Version und WebDAV

Ergebnis:
Aller Archive der history DB mit datenfehler.

Versuche zum Entpacken enden entweder mit leeren Verzeichnissen oder enden bei unterschiedlichen Prozentzahlen des Entpackungsvorganges.

[wcag22]

@wcag22
Ich habe zwar von Allem keine Ahnung, aber das ganz viel.
Und:
Wenn es um Ursachenforschung geht, bin ich fast nicht zu bremsen. Wird vermutlich Keinem etwas nutzen, ich stelle es aber dennoch zur Diskussion.

Da der Fehler (?) bzw. die Ursache möglichweise doch im BackItUp-Adapter zu suchen ist, habe ich etwas tiefer gegraben.

Die fehlerhaften Archive lassen sich über Umwege entpacken und melden dann am Ende den Ort des Fehlers. So kam ich an die betreffenden .json files heran, in denen die Ursachen für die Inkonsistenz des Archives stecken.

Ich habe die entpackten Dateien mit denen verglichen, die sich auf dem Raspi/ioB befinden.

Fazit:
Während die Dateien in der history (in den Bildern als original bezeichnet) fehlerfrei sind, haben die entpackten Dateien Fehler.
Eine Systematik des Auftretens konnte ich nicht erkennen. Das betrifft sowohl das betroffene Tagesdatum, also auch den betroffenen Datenpunkt. Ebenso lässt sich in der fehlerhaften Datei keine Systematik der Ursache erkennen.

Beispiel - 22.01.2024
Betroffene Datei/Datenpunkt:

 history.shelly.0.SHPLG-S#80646F8270BF#1.Relay0.Energy.json

Dateivergleich:

Beispiel - 24.11.2024
Betroffene Datei/Datenpunkt:

history.deyeidc.0.info.connection.json

Beispiel - 06.02.2025
Betroffene Datei/Datenpunkt:

history.0_userdata.0.EDV.Static_NAS_ThisYear.json

Mehr werde ich wohl zunächst nicht herausfinden. Es bleibt für mich nicht erkennbar, ob der Fehler beim packen der history DB entsteht oder anderswo seine Ursache hat.

Ein BackUp der history DB macht also derzeit zumindest bei mir keinen Sinn, da die Archive mit hoher Wahrscheinlichkeit nutzlos sind. Das Problem: Es fällt halt im normalen Betrieb nicht auf, da die Sicherungen als fehlerfrei gemeldet werden.

Niemand wird sich die Mühe machen, ohne Anlass die Archive auf Fehlerfreiheit zu kontrollieren. Das fällt dann erst auf, wenn ein Restore fehlschlägt.

[Homoran]

@wcag22 ich möchte dich nicht entmutigen.
meine History ist erheblich größer und da passiert so etwas nicht.
Also ist es kein grundsätzliches Problem von backitup..

Ob der Fehler beim packen passiert oder vorher beim lesen der Daten wäre noch zu prüfen.

ganz aus der Hüfte geschossen
Hast du ausreichend RAM zur Verfügung?
Ist dein Rechner übertaktet?

fiel mir als mögliche Ursache ein.
ein Raspi mit SSD an USB3 ist es ja nicht, oder?

[wcag22]

@homoran sagte in Fehler im BackUp der history DB:

@wcag22 ich möchte dich nicht entmutigen.

Tust Du nicht

meine History ist erheblich größer und da passiert so etwas nicht.
Also ist es kein grundsätzliches Problem von backitup..

Ja, ich weiß. Ich hatte das schon mal gelesen in einem Post von Dir.

Aber hast Du mal ein Archiv getestet? Denn wie gesagt: Laut Meldungen des Adapters gibt es keine Fehler und beim manuellen BackUp kann man ja auch zuschauen, wie der Prozess durchläuft. Alles ohne Auffälligkeiten.

Ob der Fehler beim packen passiert oder vorher beim lesen der Daten wäre noch zu prüfen.

Ja, sicher. Ist irgendwie ziemlich unklar die Geschichte und Zeitpunkt des Auftretens nicht mehr nachvollziehbar.

ganz aus der Hüfte geschossen
Hast du ausreichend RAM zur Verfügung?
Ist dein Rechner übertaktet?
fiel mir als mögliche Ursache ein.
ein Raspi mit SSD an USB3 ist es ja nicht, oder?

Alle Daten im ersten Post: Hardware , Software und diag lang und kurz. Schaust Du bitte...
Und nein: Nicht übertaktet, sogar gekühlt durch das argon-Gehäuse mit Lüfter
Es laufen 22 Prozesse.

[Homoran]

@wcag22 sagte in Fehler im BackUp der history DB:

dev/sda5 ext4 27G 2.2G 24G 9% /media/USBintern

heisst was?

@wcag22 sagte in Fehler im BackUp der history DB:

das argon-Gehäuse

bindet die SSD wie an?

[simatec]

@wcag22 Mache mal bitte zu Testzwecken folgendes... Stoppe den History Adapter und führe im Anschluß ein Backup durch.
Möchte nur ausschließen, dass der History Adapter beim schreiben neuer daten da beim Backup etwas zerschießt...

[wcag22]

Moin Moin,

@homoran sagte in Fehler im BackUp der history DB:

@wcag22 sagte in Fehler im BackUp der history DB:

dev/sda5 ext4 27G 2.2G 24G 9% /media/USBintern
heisst was?

Verstehe die Frage nicht. Stand doch alles in dem ersten Post, auf den ich nochmals verwiesen hatte.
Inkl. dem immer wieder eingeforderten diag-output

Alle Daten im ersten Post: Hardware , Software und diag lang und kurz. Schaust Du bitte...

Aber gut, dann noch einmal:

Festplattenart: SD-Karte (für OS und ioB, USB-Stick für history DB)

Es ist der 32GB- USB-Stick für die history DB, als sda5 gemounted.

@wcag22 sagte in Fehler im BackUp der history DB:

das argon-Gehäuse

bindet die SSD wie an?

Erstens wird "ein Gehäuse" keinen Datenträger einbinden - das macht allenfalls der Raspi; und zweitens war von einer SSD nirgends die Rede.

Ich nehme mal wohlwollend an, dass Dir die Threads durcheinander geraten sind.

Nix für ungut...

[Homoran]

@wcag22 sagte in Fehler im BackUp der history DB:

Es ist der 32GB- USB-Stick für die history DB, als sda5 gemounted.

ist doch egal ob stick oder ssd.

Auf die Frage nach dem Anschluss finde ich keine Antwort!
Deswegen die Nachfrage

@homoran sagte in Fehler im BackUp der history DB:

an USB3

??

[wcag22]

Moin Moin,

@simatec sagte in Fehler im BackUp der history DB:

@wcag22 Mache mal bitte zu Testzwecken folgendes... Stoppe den History Adapter und führe im Anschluß ein Backup durch.
Möchte nur ausschließen, dass der History Adapter beim schreiben neuer daten da beim Backup etwas zerschießt...

Besten Dank!
Das ist eine verdammt gute und naheliegende Idee. Eigentlich müsste ja die DB verriegelt werden, wenn BackItUp anspringt.
Hatte die halbe Nacht gegrübelt, wo und wie ich weiter mache in der Ursachenforschung - jetzt weiß ich es

Mache mich gleich ans Werk und melde mich mit Resultat.

Bis nachher...

[wcag22]

@homoran sagte in Fehler im BackUp der history DB:

Auf die Frage nach dem Anschluss finde ich keine Antwort!
Deswegen die Nachfrage

OK, verstehe.

ein Raspi mit SSD an USB3 ist es ja nicht, oder?

Das hatte ich explizit auf die nicht vorhandene SSD bezogen.
Aber ja, der USB-Stick steckt am USB3 Port.

Wenn der Probleme bereiten würde, müsste m.E schon die DB im laufenden Betrieb fehlerhaft sein, denn ioB schreibt ja ständig auf den Stick. Offensichtlich ohne Fehler.

Der Gedanke vom @simatec liegt da für mich näher am Problem.
Aber schaun wir mal...

[Homoran]

@wcag22 sagte in Fehler im BackUp der history DB:

Der Gedanke vom @simatec liegt da für mich näher am Problem.

durchaus möglich!

@wcag22 sagte in Fehler im BackUp der history DB:

Wenn der Probleme bereiten würde, müsste m.E schon die DB im laufenden Betrieb fehlerhaft sein, denn ioB schreibt ja ständig auf den Stick.

aber nicht in der Intensität wie beim Auslesen der gesamten History.
Das Probkem mit dem USB3 liegt in einer Störung dieses Anschlusses, durch hochfrequente Signale der CPU.

letztere dürfte bei der Backup-Arbeit auch deutlich höher liegen als im Regelbetrieb.
Die von @simatec genannte Möglichkeit kommt dann noch oben drauf, wenn der Datenverkehr sowieso schon gestört ist.

[wcag22]

@simatec sagte in Fehler im BackUp der history DB:

@wcag22 Mache mal bitte zu Testzwecken folgendes... Stoppe den History Adapter und führe im Anschluß ein Backup durch.

Gesagt - getan. Leider kein wirklich aussagekräftiges Ergebnis.
Um überhaupt belastbare Daten zu haben, habe ich sowohl mit aktivem BackItUp Adapter, als auch mit gestoppten Adapter jeweils 10 Sicherungen durchgeführt.

Ergebnis mit laufendem History-Adapter: (60% Fehler)
10_03_28 mit history fehlefrei
10_10_28 mit history unerwartetes Datenende
11_01_28 mit history unerwartetes Datenende
11_20_28 mit history fehlerfrei
11_28_28 mit history Headersfehler & Warnungen
12_00_28 mit history Headersfehler & Warnungen
12_20_28 mit history fehlerfrei
12_35_28 mit history fehlerfrei
12_45_28 mit history Headersfehler & Warnungen
12_55_28 mit history unerwartetes Datenende

Ergebnis bei gestopptem History Adapter: (40% Fehler)
13_06_01 ohne history - fehlerfrei
13_16_01 ohne history - Headersfehler & Warnungen
13_25_01 ohne history - fehlerfrei
13_30_01 ohne history - fehlerfrei
13_43_01 ohne history - fehlerfrei
13_49_01 ohne history - fehlerfrei
14_37_01 ohne history - Headersfehler & Warnungen
14_44_01 ohne history - unerwartetes Dateiende
14_53_01 ohne history - fehlerfrei
14_59_01 ohne history - unerwartetes Dateiende

Die Fehlerquote ist zwar ohne aktivem BackItUp-Adapter deutlich geringer, aber ein klares Ergebnis sieht anders aus.

Ich werde nun noch den Hinweisen von @Homoran (Störsignale auf USB 3) nachgegehen.
Wenn ich mehr weiß, melde ich mich wieder.

[simatec]

@wcag22 wie aktiver/inaktiver Backitup Adapter. Den History Adapter musst du vor dem Backup stoppen.

Bitte alles Debug Logs vom Backup Prozess posten

[wcag22]

@simatec sagte in Fehler im BackUp der history DB:

aktiver/inaktiver Backitup Adapter.

My fault, habe es berichtigt. In den Ergebnissen war es ja korrekt: mit history / ohne history (laufende Instanz / gestoppte Instanz)
Sorry.

Rest kommt auch noch...

[wcag22]

@simatec

pi@iobroker:~ $ iob stop history
The adapter "history.0" was stopped.

2025-02-07 16:19:28.717 - debug: backitup.0 (72377) Backup has started ...
2025-02-07 16:19:38.719 - debug: backitup.0 (72377) [iobroker/mount] cifs-mount command: "sudo mount -t cifs -o username=xxx,password=****,domain=xxx,rw,forceuid,uid=iobroker,forcegid,gid=iobroker,file_mode=0777,dir_mode=0777,vers=3.1.1 //192.168.178.x/usbshare1/iobroker_backup /opt/iobroker/backups"
2025-02-07 16:19:38.838 - debug: backitup.0 (72377) [iobroker/mount] mount successfully completed
2025-02-07 16:19:38.840 - debug: backitup.0 (72377) [iobroker/mount] done
2025-02-07 16:19:43.249 - debug: backitup.0 (72377) [iobroker/iobroker] host.iobroker 5444 objects saved
2025-02-07 16:19:43.724 - debug: backitup.0 (72377) [iobroker/iobroker] host.iobroker 4379 states saved
2025-02-07 16:19:43.726 - debug: backitup.0 (72377) [iobroker/iobroker] host.iobroker Validating backup ...
2025-02-07 16:19:43.730 - debug: backitup.0 (72377) [iobroker/iobroker] host.iobroker "config.json" is valid
2025-02-07 16:19:43.731 - debug: backitup.0 (72377) [iobroker/iobroker] host.iobroker "objects.jsonl" exists
2025-02-07 16:19:43.731 - debug: backitup.0 (72377) [iobroker/iobroker] host.iobroker "states.jsonl" exists
2025-02-07 16:19:44.260 - debug: backitup.0 (72377) [iobroker/iobroker] host.iobroker JSONL lines are valid
2025-02-07 16:19:44.266 - debug: backitup.0 (72377) [iobroker/iobroker] host.iobroker The backup is valid!
2025-02-07 16:19:45.214 - debug: backitup.0 (72377) [iobroker/iobroker] Backup created: /opt/iobroker/backups/iobroker_2025_02_07-16_19_38_Raspi4_9_backupiobroker.tar.gz
2025-02-07 16:19:45.215 - debug: backitup.0 (72377) [iobroker/iobroker] This backup can only be restored with js-controller version 7.0 or higher
2025-02-07 16:19:46.267 - debug: backitup.0 (72377) [iobroker/iobroker] done
2025-02-07 16:19:47.171 - debug: backitup.0 (72377) [iobroker/historyDB] compress from historyDB started ...
2025-02-07 16:19:57.172 - debug: backitup.0 (72377) [iobroker/historyDB] Packed 15MB so far...
2025-02-07 16:20:07.171 - debug: backitup.0 (72377) [iobroker/historyDB] Packed 32MB so far...
2025-02-07 16:20:17.172 - debug: backitup.0 (72377) [iobroker/historyDB] Packed 48MB so far...
2025-02-07 16:20:27.171 - debug: backitup.0 (72377) [iobroker/historyDB] Packed 65MB so far...
2025-02-07 16:20:37.171 - debug: backitup.0 (72377) [iobroker/historyDB] Packed 83MB so far...
2025-02-07 16:20:47.171 - debug: backitup.0 (72377) [iobroker/historyDB] Packed 101MB so far...
2025-02-07 16:20:57.171 - debug: backitup.0 (72377) [iobroker/historyDB] Packed 119MB so far...
2025-02-07 16:21:07.171 - debug: backitup.0 (72377) [iobroker/historyDB] Packed 139MB so far...
2025-02-07 16:21:17.171 - debug: backitup.0 (72377) [iobroker/historyDB] Packed 159MB so far...
2025-02-07 16:21:27.171 - debug: backitup.0 (72377) [iobroker/historyDB] Packed 179MB so far...
2025-02-07 16:21:37.171 - debug: backitup.0 (72377) [iobroker/historyDB] Packed 197MB so far...
2025-02-07 16:21:47.171 - debug: backitup.0 (72377) [iobroker/historyDB] Packed 217MB so far...
2025-02-07 16:21:53.698 - debug: backitup.0 (72377) [iobroker/historyDB] Backup created: /opt/iobroker/backups/historyDB_2025_02_07-16_19_47_Raspi4_9_backupiobroker.tar.gz
2025-02-07 16:21:53.698 - debug: backitup.0 (72377) [iobroker/historyDB] done
2025-02-07 16:21:55.506 - debug: backitup.0 (72377) [iobroker/cifs] used copy path: /usbshare1/iobroker_backup
2025-02-07 16:21:55.506 - debug: backitup.0 (72377) [iobroker/cifs] done
2025-02-07 16:21:56.109 - warn: backitup.0 (72377) [iobroker/clean] No older backup files are deleted, because this backup was started manually
2025-02-07 16:21:56.110 - debug: backitup.0 (72377) [iobroker/clean] done
2025-02-07 16:21:56.266 - debug: backitup.0 (72377) [iobroker/historyHTML] new history html values created
2025-02-07 16:21:56.364 - debug: backitup.0 (72377) [iobroker/historyHTML] done
2025-02-07 16:21:56.525 - debug: backitup.0 (72377) [iobroker/historyJSON] new history json values created
2025-02-07 16:21:56.526 - debug: backitup.0 (72377) [iobroker/historyJSON] done
2025-02-07 16:21:56.693 - debug: backitup.0 (72377) [iobroker/umount] mount active, umount is started ...
2025-02-07 16:22:01.767 - debug: backitup.0 (72377) [iobroker/umount] umount successfully completed
2025-02-07 16:22:01.768 - debug: backitup.0 (72377) [iobroker/umount] done
2025-02-07 16:22:12.078 - debug: backitup.0 (72377) [iobroker/email] done
2025-02-07 16:22:12.081 - info: email.0 (39359) Send email: {"text":"Backitup:\nEin neues iobroker (Raspi4_9) Backup wurde am 07. Februar 2025 um 16:22 Uhr erstellt.\n\nSpeicherorte:\n1. NAS (CIFS) (//192.168.178.x/usbshare1/iobroker_backup)\n","to":"xxx@yyy.de","subject":"Backitup","from":"iob@yyy.de"}
2025-02-07 16:22:12.427 - info: email.0 (39359) sent to xxx@yyy.de
2025-02-07 16:22:14.137 - debug: backitup.0 (72377) [iobroker/notification] done
2025-02-07 16:22:14.294 - debug: backitup.0 (72377) [iobroker] exec: done

Reicht Dir das?

[Homoran]

@wcag22 sagte in Fehler im BackUp der history DB:

Reicht Dir das?

Vielleicht noch die Info, ob das Backup (nicht) defekt ist

[wcag22]

@homoran
Gern:

[wcag22]

@homoran @simatec

Hinweis:
Die Sache mit dem USB3 Port hat sich erledigt. Der Stick steckte entgegen meiner Annahme doch im USB2 Port.
Hatte ich nicht auf dem Schirm. Dachte, ich hätte ihn in den USB3 gesteckt.

Somit fällt das auch erst einmal vermutlich als Ursache weg. Schade eigentlich...

[Homoran]

@wcag22 Danke!

hab gerade noch das letzte Backup angesehen

soweit ohne Probleme.

Hab dann übermütig gedacht çmal eben" zu entpacken.
Wird aber auf dem Tablet wohl mehrere Stunden dauern