partieller Datenverlust InfluxDB?

IOJoker

InfluxDB v1.8.10 (Shell und Server)
InfluxDB-Adapter v3.2.0
node v16.20.2
js-controller v4.0.24

Hallo ioBroker-Gemeinde,

ich logge mit dem InfluxDB-Adapter diverse Datenpunkte (mittlerweile 40 Stück) in eine Datenbank auf die SSD des raspi. Das lief jetzt knapp zwei Jahre lang eigentlich problemfrei. Das hatte ich jedenfalls gedacht, bis ich vor kurzem beim Betrachten der Datenbank in Grafana festgestellt habe, dass es einige Lücken in den Daten gibt. Die Lücken betreffen alle Datenpunkte, sind meist genau ein oder zwei Wochen lang und beginnen und enden fast ausschließlich am Montag um 00:00 Uhr UTC, also 01:00 oder 02:00 Uhr Lokalzeit, je nach Sommer- oder Winterzeit. Es gibt einige Lücken, die nicht diesem Muster entsprechen, der Großteil tut es jedoch. Die Lücken sind im gesamten Aufzeichnungszeitraum zu finden, also auch bereits 2022.
Als ich das zuerst bemerkt habe (vor ca. zwei Wochen), war ich total überrascht, weil ich eigentlich recht regelmäßig einen Blick auf die Daten werfe. Ich war mir sicher, dass diese Datenlücken nicht schon immer vorhanden waren, sondern dass sie erst seit kurzem auftreten.

Eine google-Suche zeigte schnell, dass Datenverlust in der InfluxDB im Zusammenhang mit Reboots und/oder Spannungsausfällen auftreten kann. Nun, ich war in der Vergangenheit leider recht häufig mit Abstürzen des raspi konfrontiert, weil das Betriebssystem auf der SSD liegt und der SATA-auf-USB-Adapter fehlerhaft war. Dieses Problem ist jedoch seit längerem durch Tausch des Adapters behoben und es gab keinerlei ungeplante Abstürze mehr seit dem. Ich bin mir sehr sicher, dass die Datenlücken bis zu diesem Zeitpunkt noch nicht vorhanden waren. Ich hatte bis zuletzt (und auch schon seit langer Zeit) mittels crontab einen täglichen Reboot um 04:05 Uhr durchgeführt. Ich hatte die Hoffnung, dadurch die sporadischen Abstürze zu verhindern, als ich noch nicht wusste, dass der Adapter die Ursache war. Diesen täglichen Reboot habe ich vorgestern erstmal ausprogrammiert und in einen wöchentlichen Reboot am Sonntag morgen um 04:05 Uhr reduziert.

Heute morgen (nach dem letzten planmäßigen Reboot) habe ich die Datenlücken mit denen von Vorgestern verglichen und musste feststellen, dass es in einem Bereich erneut einen Datenverlust gibt! Schock! Ich habe jetzt sofort den crontab deaktiviert. Bis zur Klärung werde ich keine geplanten Reboots mehr machen. Der Verdacht liegt nahe, dass es damit zusammenhängt.

Die zentralen Fragen, die ich mir jetzt stelle sind:

Sind die Daten tatsächlich verloren oder "nur" korrupiert? Kann man sie möglicherweise wieder herstellen?
Wie kann ich verhindern, dass es zu diesem "Datenverlust" selbst beim geplanten Reboot kommt.
Kann es andere Gründe für Datenverlust geben außer dem Reboot? Mehr als Abfragen auf die DB mache ich eigentlich nicht...

Die Influx-Community kommuniziert hauptsächlich in Englischer Sprache. Ich komme damit zwar einigermaßen zurecht, ich versuche es jedoch lieber zunächst hier in deutscher Sprache. Ich weiß, dass die Kombination ioBroker / InfluxDB / Grafana hier sehr gebräuchlich ist. Vielleicht kann mir ja jemand bei der Beantwortung meiner Fragen helfen.

Vielen Dank!

? Offline

@iojoker sagte in partieller Datenverlust InfluxDB?:

Vielleicht kann mir ja jemand bei der Beantwortung meiner Fragen helfen.

Moin,

viel Text und auch versucht es so gut wie geht zu beschreiben, aber Du solltest mal zeigen, was, wo, wie.
Dann würde ich auch mal in die Logs, einmal vom ioBroker, zu der Zeit wo Dir Daten fehlen und auch die System-Logs, journal, schauen, was zu den Zeiten auf der Kiste los war.

# sudo journalctl -S "yyyy-MM-dd HH:MM:SS" -U "yyyy-MM-dd HH:MM:SS"

-S gleich since, also wann begann das Problem
-U bis wann ging das Problem

Dann ist node 16.x schon etwas angestaubt, das lässt vermuten, dass das System allgemein nicht auf dem aktuellen Stand ist, das ist natürlich nur eine Vermutung.
Zeig mal die lange Fassung von

# iob diag

VG
Bernd

Thomas Braun

@dp20eic sagte in partieller Datenverlust InfluxDB?:

Dann ist node 16.x schon etwas angestaubt,

Die ist sogar im Jenseits. EndOfLife erreicht. Muss auf 18 gebracht werden.

IOJoker

Hi Bernd, vielen Dank für die Antwort. Ich versuche etwas weniger Text und mehr Substanz hinzuzufügen.

Fangen wir mal hiermit an:

@dp20eic said in partieller Datenverlust InfluxDB?:

Zeig mal die lange Fassung von
# iob diag

Skript v.2023-10-10

*** BASE SYSTEM ***
   Static hostname: unger-pi
         Icon name: computer
  Operating System: Raspbian GNU/Linux 10 (buster)
            Kernel: Linux 5.10.103-v7l+
      Architecture: arm

Model           : Raspberry Pi 4 Model B Rev 1.4
Docker          : false
Virtualization  : none
Kernel          : armv7l
Userland        : armhf

Systemuptime and Load:
 16:59:03 up 12:53,  1 user,  load average: 1.22, 1.01, 0.85
CPU threads: 4


*** RASPBERRY THROTTLING ***
Current issues:
No throttling issues detected.

Previously detected issues:
No throttling issues detected.

*** Time and Time Zones ***
               Local time: Sun 2023-10-22 16:59:03 CEST
           Universal time: Sun 2023-10-22 14:59:03 UTC
                 RTC time: n/a
                Time zone: Europe/Berlin (CEST, +0200)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

*** User and Groups ***
unger
/home/unger
unger adm dialout cdrom sudo audio video plugdev games users input netdev gpio i2c spi iobroker

*** X-Server-Setup ***
X-Server:       false
Desktop:
Terminal:       tty
Boot Target:    multi-user.target

*** MEMORY ***
              total        used        free      shared  buff/cache   available
Mem:           7.9G        1.3G        2.0G        379M        4.6G        6.4G
Swap:           99M          0B         99M
Total:         8.0G        1.3G        2.1G

         7897 M total memory
         1342 M used memory
          922 M active memory
         4763 M inactive memory
         1980 M free memory
          278 M buffer memory
         4296 M swap cache
           99 M total swap
            0 M used swap
           99 M free swap

Raspberry only:
oom events: 0
lifetime oom required: 0 Mbytes
total time in oom handler: 0 ms
max time spent in oom handler: 0 ms

*** FAILED SERVICES ***

  UNIT                  LOAD   ACTIVE SUB    DESCRIPTION
* bthelper@hci0.service loaded failed failed Raspberry Pi bluetooth helper
* openplc.service       loaded failed failed OpenPLC Service

LOAD   = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB    = The low-level unit activation state, values depend on unit type.

2 loaded units listed. Pass --all to see loaded but inactive units, too.
To show all installed unit files use 'systemctl list-unit-files'.

*** FILESYSTEM ***
Filesystem     Type      Size  Used Avail Use% Mounted on
/dev/root      ext4      917G   27G  853G   4% /
devtmpfs       devtmpfs  3.7G     0  3.7G   0% /dev
tmpfs          tmpfs     3.9G  3.7M  3.9G   1% /dev/shm
tmpfs          tmpfs     3.9G  372M  3.5G  10% /run
tmpfs          tmpfs     5.0M  4.0K  5.0M   1% /run/lock
tmpfs          tmpfs     3.9G     0  3.9G   0% /sys/fs/cgroup
/dev/sda1      vfat      253M   49M  204M  20% /boot
tmpfs          tmpfs     790M     0  790M   0% /run/user/1001

Messages concerning ext4 filesystem in dmesg:
[Sun Oct 22 04:05:20 2023] Kernel command line: coherent_pool=1M 8250.nr_uarts=0 snd_bcm2835.enable_compat_alsa=0 snd_bcm2835.enable_hdmi=1 video=HDMI-A-1:1280x720M@60D smsc95xx.macaddr=E4:5F:01:25:03:02 vc_mem.mem_base=0x3eb00000 vc_mem.mem_size=0x3ff00000  console=ttyS0,115200 console=tty1 root=PARTUUID=eb45b446-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait quiet splash plymouth.ignore-serial-consoles
[Sun Oct 22 04:05:22 2023] EXT4-fs (sda2): mounted filesystem with ordered data mode. Opts: (null)
[Sun Oct 22 04:05:22 2023] VFS: Mounted root (ext4 filesystem) readonly on device 8:2.
[Sun Oct 22 04:05:25 2023] EXT4-fs (sda2): re-mounted. Opts: (null)

Show mounted filesystems \(real ones only\):
TARGET        SOURCE    FSTYPE OPTIONS
/             /dev/sda2 ext4   rw,noatime
|-/sys/fs/bpf none      bpf    rw,nosuid,nodev,noexec,relatime,mode=700
`-/boot       /dev/sda1 vfat   rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,errors=remount-ro

Files in neuralgic directories:

/var:
13G     /var/
5.2G    /var/cache/apt/archives
5.2G    /var/cache/apt
5.2G    /var/cache
4.3G    /var/log

Archived and active journals take up 369.5M in the file system.

/opt/iobroker/backups:
67M     /opt/iobroker/backups/

/opt/iobroker/iobroker-data:
260M    /opt/iobroker/iobroker-data/
142M    /opt/iobroker/iobroker-data/files
82M     /opt/iobroker/iobroker-data/backup-objects
52M     /opt/iobroker/iobroker-data/files/javascript.admin
34M     /opt/iobroker/iobroker-data/files/javascript.admin/static

The five largest files in iobroker-data are:
23M     /opt/iobroker/iobroker-data/objects.jsonl
21M     /opt/iobroker/iobroker-data/files/web.admin/static/js/main.edf7552a.js.map
8.3M    /opt/iobroker/iobroker-data/files/web.admin/static/js/main.edf7552a.js
7.1M    /opt/iobroker/iobroker-data/files/javascript.admin/static/js/610.f22de4ab.chunk.js.map
6.6M    /opt/iobroker/iobroker-data/files/modbus.admin/static/js/main.8083c40d.js.map

USB-Devices by-id:
USB-Sticks -  Avoid direct links to /dev/* in your adapter setups, please always prefer the links 'by-id':

/dev/serial/by-id/usb-Silicon_Labs_CP2102N_USB_to_UART_Bridge_Controller_9c6ff58c7ebfeb119605fc3965476099-if00-port0

*** NodeJS-Installation ***

/usr/bin/nodejs         v16.20.2
/usr/bin/node           v16.20.2
/usr/bin/npm            8.19.4
/usr/bin/npx            8.19.4
/usr/bin/corepack       0.17.0


nodejs:
  Installed: 16.20.2-deb-1nodesource1
  Candidate: 16.20.2-deb-1nodesource1
  Version table:
 *** 16.20.2-deb-1nodesource1 500
        500 https://deb.nodesource.com/node_16.x buster/main armhf Packages
        100 /var/lib/dpkg/status
     10.24.0~dfsg-1~deb10u3 500
        500 http://raspbian.raspberrypi.org/raspbian buster/main armhf Packages

Temp directories causing npm8 problem: 0
No problems detected

Errors in npm tree:

*** ioBroker-Installation ***

ioBroker Status
iobroker is running on this host.


Objects type: jsonl
States  type: jsonl

Core adapters versions
js-controller:  4.0.24
admin:          6.10.1
javascript:     7.1.4

Adapters from github:   0

Adapter State
+ system.adapter.admin.0                  : admin                 : unger-pi                                 -  enabled, port: 8081, bind: 0.0.0.0, run as: admin
+ system.adapter.backitup.0               : backitup              : unger-pi                                 -  enabled
+ system.adapter.email.0                  : email                 : unger-pi                                 -  enabled
  system.adapter.icons-ultimate-png.0     : icons-ultimate-png    : unger-pi                                 -  enabled
+ system.adapter.influxdb.0               : influxdb              : unger-pi                                 -  enabled, port: 8086
+ system.adapter.javascript.0             : javascript            : unger-pi                                 -  enabled
+ system.adapter.mielecloudservice.0      : mielecloudservice     : unger-pi                                 -  enabled
+ system.adapter.modbus.0                 : modbus                : unger-pi                                 -  enabled
+ system.adapter.modbus.1                 : modbus                : unger-pi                                 -  enabled
+ system.adapter.modbus.2                 : modbus                : unger-pi                                 -  enabled
+ system.adapter.psa.0                    : psa                   : unger-pi                                 -  enabled
+ system.adapter.rpi2.0                   : rpi2                  : unger-pi                                 -  enabled
+ system.adapter.smartmeter.0             : smartmeter            : unger-pi                                 -  enabled
  system.adapter.vis-hqwidgets.0          : vis-hqwidgets         : unger-pi                                 -  enabled
  system.adapter.vis-materialdesign.0     : vis-materialdesign    : unger-pi                                 -  enabled
  system.adapter.vis.0                    : vis                   : unger-pi                                 -  enabled
+ system.adapter.web.0                    : web                   : unger-pi                                 -  enabled, port: 8082, bind: 0.0.0.0, run as: admin

+ instance is alive

Enabled adapters with bindings
+ system.adapter.admin.0                  : admin                 : unger-pi                                 -  enabled, port: 8081, bind: 0.0.0.0, run as: admin
+ system.adapter.influxdb.0               : influxdb              : unger-pi                                 -  enabled, port: 8086
+ system.adapter.web.0                    : web                   : unger-pi                                 -  enabled, port: 8082, bind: 0.0.0.0, run as: admin

ioBroker-Repositories
stable        : http://download.iobroker.net/sources-dist.json
beta          : http://download.iobroker.net/sources-dist-latest.json

Active repo(s): stable

Installed ioBroker-Instances
Used repository: stable
Adapter    "admin"        : 6.10.1   , installed 6.10.1
Adapter    "backitup"     : 2.8.1    , installed 2.8.1
Adapter    "email"        : 1.2.0    , installed 1.2.0
Adapter    "icons-ultimate-png": 1.0.1, installed 1.0.1
Adapter    "influxdb"     : 3.2.0    , installed 3.2.0
Adapter    "javascript"   : 7.1.4    , installed 7.1.4
Controller "js-controller": 5.0.12   , installed 4.0.24 [Updatable]
Adapter    "mielecloudservice": 6.5.4, installed 6.5.4
Adapter    "modbus"       : 5.0.11   , installed 5.0.11
Adapter    "psa"          : 0.0.11   , installed 0.0.11
Adapter    "rpi2"         : 1.3.2    , installed 1.3.2
Adapter    "simple-api"   : 2.7.2    , installed 2.7.2
Adapter    "smartmeter"   : 3.3.4    , installed 3.3.4
Adapter    "socketio"     : 6.5.5    , installed 6.5.5
Adapter    "vis"          : 1.4.16   , installed 1.4.16
Adapter    "vis-hqwidgets": 1.4.0    , installed 1.4.0
Adapter    "web"          : 6.1.2    , installed 6.1.2
Adapter    "ws"           : 2.5.5    , installed 2.5.5

Objects and States
Please stand by - This may take a while
Objects:        1570
States:         1404

*** OS-Repositories and Updates ***
Hit:1 http://archive.raspberrypi.org/debian buster InRelease
Hit:2 http://raspbian.raspberrypi.org/raspbian buster InRelease
Hit:3 https://repos.influxdata.com/debian buster InRelease
Hit:4 https://packages.grafana.com/oss/deb stable InRelease
Get:5 https://dl.cloudsmith.io/public/evcc/stable/deb/raspbian buster InRelease [5123 B]
Hit:6 https://deb.nodesource.com/node_16.x buster InRelease
Fetched 5123 B in 2s (2828 B/s)
Reading package lists...
Pending Updates: 0

*** Listening Ports ***
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       User       Inode      PID/Program name
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      0          17180      712/lighttpd
tcp        0      0 0.0.0.0:53              0.0.0.0:*               LISTEN      999        19434      634/pihole-FTL
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      0          18135      612/sshd
tcp        0      0 127.0.0.1:631           0.0.0.0:*               LISTEN      0          15972      399/cupsd
tcp        0      0 127.0.0.1:8088          0.0.0.0:*               LISTEN      998        18696      597/influxd
tcp        0      0 0.0.0.0:445             0.0.0.0:*               LISTEN      0          22679      985/smbd
tcp        0      0 127.0.0.1:4711          0.0.0.0:*               LISTEN      999        19440      634/pihole-FTL
tcp        0      0 127.0.0.1:9000          0.0.0.0:*               LISTEN      1002       22119      1043/iobroker.js-co
tcp        0      0 127.0.0.1:9001          0.0.0.0:*               LISTEN      1002       22112      1043/iobroker.js-co
tcp        0      0 127.0.0.1:3306          0.0.0.0:*               LISTEN      116        17285      751/mysqld
tcp        0      0 0.0.0.0:139             0.0.0.0:*               LISTEN      0          22680      985/smbd
tcp6       0      0 :::80                   :::*                    LISTEN      0          17181      712/lighttpd
tcp6       0      0 :::8081                 :::*                    LISTEN      1002       21326      1077/io.admin.0
tcp6       0      0 :::8082                 :::*                    LISTEN      1002       25227      1570/io.web.0
tcp6       0      0 :::53                   :::*                    LISTEN      999        19436      634/pihole-FTL
tcp6       0      0 :::8086                 :::*                    LISTEN      998        21085      597/influxd
tcp6       0      0 :::22                   :::*                    LISTEN      0          18137      612/sshd
tcp6       0      0 ::1:631                 :::*                    LISTEN      0          15971      399/cupsd
tcp6       0      0 :::3000                 :::*                    LISTEN      117        22357      1042/grafana
tcp6       0      0 :::445                  :::*                    LISTEN      0          22677      985/smbd
tcp6       0      0 ::1:4711                :::*                    LISTEN      999        19441      634/pihole-FTL
tcp6       0      0 :::139                  :::*                    LISTEN      0          22678      985/smbd
udp        0      0 0.0.0.0:53              0.0.0.0:*                           999        19433      634/pihole-FTL
udp        0      0 0.0.0.0:67              0.0.0.0:*                           999        19430      634/pihole-FTL
udp        0      0 0.0.0.0:68              0.0.0.0:*                           0          20704      445/dhcpcd
udp        0      0 0.0.0.0:51820           0.0.0.0:*                           0          17155      -
udp        0      0 0.0.0.0:631             0.0.0.0:*                           0          16061      518/cups-browsed
udp        0      0 10.2.28.255:137         0.0.0.0:*                           0          21059      594/nmbd
udp        0      0 10.2.28.20:137          0.0.0.0:*                           0          21058      594/nmbd
udp        0      0 0.0.0.0:137             0.0.0.0:*                           0          18419      594/nmbd
udp        0      0 10.2.28.255:138         0.0.0.0:*                           0          21061      594/nmbd
udp        0      0 10.2.28.20:138          0.0.0.0:*                           0          21060      594/nmbd
udp        0      0 0.0.0.0:138             0.0.0.0:*                           0          18420      594/nmbd
udp        0      0 0.0.0.0:46222           0.0.0.0:*                           108        17436      403/avahi-daemon: r
udp        0      0 0.0.0.0:5353            0.0.0.0:*                           108        17434      403/avahi-daemon: r
udp6       0      0 :::59834                :::*                                108        17437      403/avahi-daemon: r
udp6       0      0 :::546                  :::*                                0          20808      445/dhcpcd
udp6       0      0 :::53                   :::*                                999        19435      634/pihole-FTL
udp6       0      0 :::51820                :::*                                0          17156      -
udp6       0      0 :::5353                 :::*                                108        17435      403/avahi-daemon: r

*** Log File - Last 25 Lines ***

2023-10-22 15:25:51.527  - error: javascript.0 (1308) Request error: Error: read ECONNRESET
2023-10-22 15:25:53.195  - error: javascript.0 (1308) script.js.Energie.Ladestation: Fehler bei http-request mit filter=amp,psm,frc,nrg,modelStatus,err: Error: socket hang up
2023-10-22 15:25:53.195  - error: javascript.0 (1308) Request error: Error: socket hang up
2023-10-22 15:25:59.219  - error: javascript.0 (1308) script.js.Energie.Ladestation: Fehler bei http-request mit filter=amp,psm,frc,nrg,modelStatus,err: Error: socket hang up
2023-10-22 15:25:59.221  - error: javascript.0 (1308) Request error: Error: socket hang up
2023-10-22 15:26:04.237  - error: javascript.0 (1308) script.js.Energie.Ladestation: Fehler bei http-request mit filter=amp,psm,frc,nrg,modelStatus,err: Error: socket hang up
2023-10-22 15:26:04.238  - error: javascript.0 (1308) Request error: Error: socket hang up
2023-10-22 15:26:07.644  - error: javascript.0 (1308) script.js.Energie.Ladestation: Fehler bei http-request mit filter=amp,psm,frc,nrg,modelStatus,err: Error: socket hang up
2023-10-22 15:26:07.645  - error: javascript.0 (1308) Request error: Error: socket hang up
2023-10-22 15:26:11.201  - error: javascript.0 (1308) script.js.Energie.Ladestation: Fehler bei http-request mit filter=amp,psm,frc,nrg,modelStatus,err: Error: socket hang up
2023-10-22 15:26:11.202  - error: javascript.0 (1308) Request error: Error: socket hang up
2023-10-22 15:26:16.147  - error: javascript.0 (1308) script.js.Energie.Ladestation: Fehler bei http-request mit filter=amp,psm,frc,nrg,modelStatus,err: Error: read ECONNRESET
2023-10-22 15:26:16.148  - error: javascript.0 (1308) Request error: Error: read ECONNRESET
2023-10-22 15:26:23.146  - error: javascript.0 (1308) script.js.Energie.Ladestation: Fehler bei http-request mit filter=amp,psm,frc,nrg,modelStatus,err: Error: socket hang up
2023-10-22 15:26:23.146  - error: javascript.0 (1308) Request error: Error: socket hang up
2023-10-22 15:26:25.369  - error: javascript.0 (1308) script.js.Energie.Ladestation: Fehler bei http-request mit filter=amp,psm,frc,nrg,modelStatus,err: Error: socket hang up
2023-10-22 15:26:25.369  - error: javascript.0 (1308) Request error: Error: socket hang up
2023-10-22 15:26:34.855  - error: javascript.0 (1308) script.js.Energie.Ladestation: Fehler bei http-request mit filter=amp,psm,frc,nrg,modelStatus,err: Error: read ECONNRESET
2023-10-22 15:26:34.856  - error: javascript.0 (1308) Request error: Error: read ECONNRESET
2023-10-22 15:26:59.352  - error: javascript.0 (1308) script.js.Energie.Ladestation: Fehler bei http-request mit filter=amp,psm,frc,nrg,modelStatus,err: Error: socket hang up
2023-10-22 15:26:59.353  - error: javascript.0 (1308) Request error: Error: socket hang up
2023-10-22 15:27:01.168  - error: javascript.0 (1308) script.js.Energie.Ladestation: Fehler bei http-SET amp=13: Error: socket hang up
2023-10-22 15:27:01.169  - error: javascript.0 (1308) Request error: Error: socket hang up
2023-10-22 15:27:11.157  - error: javascript.0 (1308) script.js.Energie.Ladestation: Fehler bei http-request mit filter=wh,eto,car,rssi,tma: Error: socket hang up
2023-10-22 15:27:11.157  - error: javascript.0 (1308) Request error: Error: socket hang up

Thomas Braun

@iojoker sagte in partieller Datenverlust InfluxDB?:

buster

Ist auch im Jenseits. Bring das ganze Spiel auf einen aktuellen Stand.

? Offline

@iojoker sagte in partieller Datenverlust InfluxDB?:

Fangen wir mal hiermit an:

Moin,

machen wir mal damit weiter :)

...
2023-10-22 15:26:25.369  - error: javascript.0 (1308) script.js.Energie.Ladestation: Fehler bei http-request mit filter=amp,psm,frc,nrg,modelStatus,err: Error: socket hang up
2023-10-22 15:26:25.369  - error: javascript.0 (1308) Request error: Error: socket hang up
2023-10-22 15:26:34.855  - error: javascript.0 (1308) script.js.Energie.Ladestation: Fehler bei http-request mit filter=amp,psm,frc,nrg,modelStatus,err: Error: read ECONNRESET
2023-10-22 15:26:34.856  - error: javascript.0 (1308) Request error: Error: read ECONNRESET
2023-10-22 15:26:59.352  - error: javascript.0 (1308) script.js.Energie.Ladestation: Fehler bei http-request mit filter=amp,psm,frc,nrg,modelStatus,err: Error: socket hang up
...

Dass Du mit angestaubten Softwareständen unterwegs bist, haben @Thomas-Braun und ich ja schon gesagt.

Jetzt mal schauen, ob Du noch Logs aus dem Zeitraum hast, ein denen die Daten verloren gegangen sind!

VG
Bernd

P.S.: Ein weiterer Punkt, warum Daten fehlen können, ist ein erhöhter Load, wenn die Kiste nur noch mit Fehlermeldung schreiben zu tun hat, z. B.

IOJoker

@dp20eic said in partieller Datenverlust InfluxDB?:

Dass Du mit angestaubten Softwareständen unterwegs bist, haben @Thomas-Braun und ich ja schon gesagt.

Ja gut, würde ich prinzipiell versuchen, auch wenn ich es bisher noch nicht gemacht habe und großen Respekt davor habe...
Wie hoch ist das Risiko eines Updates von buster und node? Sollte ich die Updates erst machen, bevor wir hier fortsetzen?

@dp20eic said in partieller Datenverlust InfluxDB?:

Jetzt mal schauen, ob Du noch Logs aus dem Zeitraum hast, ein denen die Daten verloren gegangen sind!

Es sieht so aus, dass ich kein persistentes Journal eingerichtet habe. :man-bowing:

-- Logs begin at Sun 2023-10-22 11:21:25 CEST, end at Sun 2023-10-22 17:56:17 CEST. --

Selbst, wenn es so wäre, liegen die Datenlücken teilweise sehr weit in der Vergangenheit. Die letzte Datenlücke endet am Fr., den 13.10.23.
Daten2023 2023-10-22 111104.png

@dp20eic said in partieller Datenverlust InfluxDB?:

P.S.: Ein weiterer Punkt, warum Daten fehlen können, ist ein erhöhter Load, wenn die Kiste nur noch mit Fehlermeldung schreiben zu tun hat, z. B.

Hierbei bitte bedenken, dass bereits vorhandene Daten verloren gegangen sind. Das habe ich beim Vergleich zwischen den Daten von vorgestern und heute eigentlich bewiesen. Ich glaube nicht, dass es ein Problem des Schreibens in die Datenbank ist. Vielmehr gehen Daten verloren, ich vermute beim Reboot.

Danke für eure Hilfe in der Sache! Ich weiß das sehr zu schätzen.

Thomas Braun

@iojoker sagte in partieller Datenverlust InfluxDB?:

Wie hoch ist das Risiko eines Updates von buster und node? Sollte ich die Updates erst machen, bevor wir hier fortsetzen?

Je länger du das schleifen lässt desto komplizierter wird das.
Ich würde hier aber gleich ein komplette Neuinstallation von Debian12 'Bookworm' vorsehen, diesmal als 64bit-Version 'Lite'.

? Offline

@iojoker sagte in partieller Datenverlust InfluxDB?:

Danke für eure Hilfe in der Sache! Ich weiß das sehr zu schätzen.

Moin,

@iojoker sagte in partieller Datenverlust InfluxDB?:

Wie hoch ist das Risiko eines Updates von buster und node?

@Thomas-Braun hat da ja schon einen guten Einwand gegeben, ich möchte das nur noch insoweit ergänzen, je höher der Linux Skill ist, umso leichter fällt es Dir, Updates über mehrere Releases zu machen. Somit kann ich das von @Thomas-Braun gesagte, nur unterstützen, sauberes Backup dann neu aufsetzen.

@iojoker sagte in partieller Datenverlust InfluxDB?:

Vielmehr gehen Daten verloren, ich vermute beim Reboot.

Wenn die Datenlücken, mit den in Deiner Erinnerung befindlichen Reboots zusammenpassen, dann ist die Frage, warum gab es die Reboots, vielleicht weil Deine Kiste mit sich selbst beschäftigt war?
Ein Reboot sollte ja in wenigen Minuten durch sein und nicht Tage dauern :)

VG
Bernd

IOJoker

@dp20eic said in partieller Datenverlust InfluxDB?:

je höher der Linux Skill ist, umso leichter fällt es Dir

Ich befürchte, hier liegt eines der größten Probleme. Mein Skill-Level würde ich selbst nicht so hoch einschätzen. Erschwerend kommt hinzu, dass ich bereits beim Einrichten des raspi (wahrscheinlich?) eine Fehlentscheidung getroffen habe, die mir jetzt auf die Füße fällt. Ich habe das Betriebssystem auf eine 1TB große SSD aufgespielt und nicht auf eine SD-Karte. Es ist mir momentan überhaupt nicht möglich, ein komplettes Systembackup zu erstellen, weil ich keine freie SSD mit dieser Reserve habe. So habe ich es zumindest verstanden. Das ist ein anderes Thema, um das ich mich noch kümmern wollte. Jedenfalls muss ich das Risiko im Blick behalten, weil der raspi mittlerweile wichtige Aufgaben im Haushalt übernimmt.

@dp20eic said in partieller Datenverlust InfluxDB?:

Wenn die Datenlücken, mit den in Deiner Erinnerung befindlichen Reboots zusammenpassen, dann ist die Frage, warum gab es die Reboots

Nein, die Datenlücken passen zeitlich überhaupt nicht mit den Reboots zusammen. Den Grund für die Reboots habe ich in dem vielen Text im ersten Post geschildert. :grimacing:

Thomas Braun

@iojoker sagte in partieller Datenverlust InfluxDB?:

ein komplettes Systembackup zu erstellen

Kannst du eh nichts mit anfangen, weil eine 64bit-Installation komplett von Null an vorgenommen werden muss.

? Offline

@iojoker sagte in partieller Datenverlust InfluxDB?:

Betriebssystem auf eine 1TB große SSD

Moin,

meine Schwäche sind die RasPIs, ich kann da nicht immer mit Gewissheit sagen, ob sich die so verhalten, wie die großen Brüder der PC.
Aber wenn es möglich ist, dann würde ich der SSD eine neue Partition verpassen, dann darauf das neue System installieren und grub von der ersten Installation so anpassen, dass es von der neuen startet.
Wenn alles gut ist, dann kann man die alte Partition löschen und den Speicher, der neuen Installation zuschieben.

@iojoker sagte in partieller Datenverlust InfluxDB?:

Nein, die Datenlücken passen zeitlich überhaupt nicht mit den Reboots zusammen.

Na, dann habe ich ja vielleicht mit meiner Annahme doch recht, dass Du die Daten verlierst, verloren hast, weil die Kiste mit sich selbst beschäftigt ist, aber ohne aussagekräftige Logs, sind es halt nur Annahmen, Vermutungen.

VG
Bernd

Thomas Braun

@dp20eic sagte in partieller Datenverlust InfluxDB?:

Aber wenn es möglich ist,

Nein, nicht so. Raspberry nutzen keinen grub.
Da wird in der cat /boot/cmdline.txt das Dateisystem gemountet (und noch anderes Zeug getrieben, das ich aber auch nicht auf dem Schirm habe).

? Offline

@thomas-braun sagte in partieller Datenverlust InfluxDB?:

Da wird in der cat /boot/cmdline.txt das Dateisystem gemountet (und noch anderes Zeug getrieben, das ich aber auch nicht auf dem Schirm habe).

Moin,

ja, jetzt wo Du das erwähnst, da war was, genau.
Dann muss ich mal weiter meine Fantasie bemühen, aber da ich keine passende Hardware habe, kann ich da nichts probieren, sorry.

VG
Bernd

P.S.: Sollte doch gehen, wenn ich mir die Dokumentation -> https://www.raspberrypi.com/documentation/computers/config_txt.html anschaue

[all]
tryboot_a_b=1
boot_partition=2
[tryboot]
boot_partition=3

IOJoker

@dp20eic said in partieller Datenverlust InfluxDB?:

Na, dann habe ich ja vielleicht mit meiner Annahme doch recht, dass Du die Daten verlierst, verloren hast, weil die Kiste mit sich selbst beschäftigt ist, aber ohne aussagekräftige Logs, sind es halt nur Annahmen, Vermutungen.

Also als ersten Schritt habe ich das journal jetzt auf persistant gestellt (hoffentlich erfolgreich). Zweitens habe ich den geplanten Reboot deaktiviert. Ich lasse das System jetzt mal eine Zeit durchlaufen und kontrolliere regelmäßig die Datenbank auf neue Lücken. Ich kann mir nicht vorstellen, dass ich Daten verliere, weil die Kiste mit sich selbst beschäftigt ist.

Dann werde ich versuchen, tiefer in die Influx-Community einzutauchen. Ich habe immernoch die Hoffnung, dass die Daten garnicht verloren sind, sondern möglicherweise nur nicht gefunden werden.

Mittelfristig werde ich das Gesamtkonzept auf den Prüfstand stellen. Ich würde schon gern eine Lösung haben, wo ich vom kompletten System ein Backup machen kann. Ich hoffe, dass ich die jetzige Partition teilen und die große Datenbank auf eine andere Partition verschieben kann. Die Systempartition sollte dann klein genug sein, dass ein Backup möglich sein sollte. Partitionieren habe ich jedoch bisher nur in der Windows-Welt gemacht und auch noch nicht oft.

Ich melde mich, wenn es neue Erkenntnisse gibt.

Vielen Dank bis hierhin! :handshake:

Marc Berg

@iojoker sagte in partieller Datenverlust InfluxDB?:

Vielleicht kann mir ja jemand bei der Beantwortung meiner Fragen helfen.

Ähnliche Probleme kannst du auf github in den InfluxDB Issues einige finden. Die Ursache scheint hier im begrenzten adressierbaren Speicherbereich auf 32bit Systemen zu liegen.

InfluxDB führt regelmäßig "compaction" Jobs durch, in diesen Jobs werden die Datenbankfiles optimiert und neu geschrieben. Wenn es dann zu einem Speicherproblem kommt, gehen Daten verloren. Sehr gut passt dazu, dass meist ganze Wochen fehlen. Diese Fehler findet man dann aber in den Logs (wenn man welche hat).

Bin mir ziemlich sicher, dass sich dein Problem mit einem 64bit OS in Luft auflöst.

Edit: habe gerade gesehen, dass du auch "naturfreund" angefragt hast, da er ähnliche Probleme hatte. Auch er hat(te) übrigens ein 32bit System.

Marc Berg

doppelt, gelöscht

IOJoker

@marc-berg said in partieller Datenverlust InfluxDB?:

Die Ursache scheint hier im begrenzten adressierbaren Speicherbereich auf 32bit Systemen zu liegen.

Puh, das ist ja ein ganz schöner Hammer. 2,8GB groß ist die Datenbank auf der SSD. Also sind die Daten wirklich unwiederbringlich verloren. :disappointed_relieved:
Ich werde schnellstmöglich das BS neu aufsetzen. Zunächst kaufe ich mir einen zweiten kleinen raspi, auf den ich Pi-hole auslagern werde. Wireguard wollte ich schon länger auf die Fritzbox bringen. Dann kann ich mich voll und ganz auf den ioBroker / InfluxDB / Grafana auf dem Hauptsystem kümmern. Mir geht schon ein Bisschen die Düse. :fearful:

Trotzdem Danke für die wichtige Info!

Marc Berg

@iojoker sagte in partieller Datenverlust InfluxDB?:

Also sind die Daten wirklich unwiederbringlich verloren.

Wenn du noch ein paar ältere Backups rumliegen hättest, könnte man da sicher etwas wiederholen.

Wenn...

IOJoker

@marc-berg said in partieller Datenverlust InfluxDB?:

Wenn du noch ein paar ältere Backups rumliegen hättest, könnte man da sicher etwas wiederholen.

Nein, leider nicht. Der Datenverlust ist zwar ärgerlich, jedoch kein Weltuntergang. Die wichtigsten Werte für die Photovoltaikanlage habe ich zum Monatsübergang auch immer in eine Excel-Datei gesichert. Mund abwischen und weitermachen. Wichtiger ist, dass der ioBroker zuverlässig läuft. Ich muss jetzt zusehen, dass ich die Neuinstallation gut vorbereite, damit ich das alles hinbekomme. Ist jetzt schließlich auch schon wieder eine Weile her, dass ich das gemacht habe.

Community Forum

NEWS

partieller Datenverlust InfluxDB?

Support us

839

32.4k

81.5k

1.3m