Neuer Blogbeitrag: Monatsrückblick - Dezember 2025 🎄

[Azrael42]

@dp20eic

iobroker@RKO-Central:~$ mount
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
udev on /dev type devtmpfs (rw,nosuid,relatime,size=1945708k,nr_inodes=486427,mode=755)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,nodev,noexec,relatime,size=392408k,mode=755)
/dev/sda1 on / type ext4 (rw,relatime,errors=remount-ro)
securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)
cgroup2 on /sys/fs/cgroup type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate,memory_recursiveprot)
pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)
none on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,relatime,mode=700)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=30,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=13452)
mqueue on /dev/mqueue type mqueue (rw,nosuid,nodev,noexec,relatime)
hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime,pagesize=2M)
debugfs on /sys/kernel/debug type debugfs (rw,nosuid,nodev,noexec,relatime)
tracefs on /sys/kernel/tracing type tracefs (rw,nosuid,nodev,noexec,relatime)
configfs on /sys/kernel/config type configfs (rw,nosuid,nodev,noexec,relatime)
fusectl on /sys/fs/fuse/connections type fusectl (rw,nosuid,nodev,noexec,relatime)
sunrpc on /run/rpc_pipefs type rpc_pipefs (rw,relatime)
tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=392404k,nr_inodes=98101,mode=700,uid=1000,gid=1000)

[Ein ehemaliger Benutzer]

@azrael42 sagte in BackITUp: MySQL DB Sicherung schlägt fehl:

Wenn ich das richtig verstehe, darf der User "iobroker" ausführen.

Moin,

ja, das sieht normal aus.

Kannst Du trotz allem noch mal den Einstellungsdialog zeigen

Ich hab das nur mal so installiert, ich nutze den BackItUp Adaper nicht.

Vielleicht auch mal den Pfad leer lassen.

Mir fällt ansonsten heute nichts mehr dazu ein.

VG
Bernd

P.S.: Auf Thai ist die Zahl 5 = ha somit 5555

[Azrael42]

@dp20eic

Jo, ich gebe für heute auch auf. Danke noch an alle, die bis hier mitgedacht haben!

Ansonsten weiß ich schon, wo mein Handtuch ist;)

[Thomas Braun]

@azrael42

Gib mal bei full path das Linkziel ein:

/usr/bin/mariadb-dump

[Azrael42]

@thomas-braun said in BackITUp: MySQL DB Sicherung schlägt fehl:

Gib mal bei full path das Linkziel ein:

Bleibt leider exakt gleich. Geht nicht. :(

[Ein ehemaliger Benutzer]

@azrael42 sagte in BackITUp: MySQL DB Sicherung schlägt fehl:

Ansonsten weiß ich schon, wo mein Handtuch ist;)

Moin,

und die Sonnenbrille nicht vergessen :)

Wenn Du als iobroker das ausführst

iobroker@RKO-Central:~$ mariadb-dump -u iobroker -p  iobroker > /opt/iobroker/backups/mysql_test.sql

Wenn Du das Passwort gleich mitgeben willst, dann -ppasswort ohne Leerzeichen.

Dann kannst Du auch noch mal versuchen, ob Du als iobroker etwas im Verzeichnis anlegen kannst.

touch /opt/iobroker/backups/test.txt

VG
Bernd

[Homoran]

@dp20eic ich bin als Linux-Laie ein wenig verwirrt.

@dp20eic sagte in BackITUp: MySQL DB Sicherung schlägt fehl:

Wenn Du als iobroker das ausführst
iobroker@RKO-Central:.....

passt doch nicht zu

@thomas-braun sagte in BackITUp: MySQL DB Sicherung schlägt fehl:

Der iobroker bekommt keine login shell.

da müsste doch

@thomas-braun sagte in BackITUp: MySQL DB Sicherung schlägt fehl:

sudo -H -u iobroker COMMAND

verwendet werden.
oder/und der iobroker bei @Azrael42 ist ein selbst angelegter user und nicht der Systemuser

[Ein ehemaliger Benutzer]

@homoran sagte in BackITUp: MySQL DB Sicherung schlägt fehl:

passt doch nicht zu

Moin,

ja, da hast Du recht, aber ich hatte ja in einem Post auch gezeigt, wie man trotzdem zum User wird.

Ich finde die Art und Weise, wie ioBroker das aktuell löst sehr gut und ärger mich, dass ich diesen Ansatz hier geschrieben habe.

Du hast natürlich recht, nach ioBroker Paradigma muss, das noch davor, wenn TE als Richard angemeldet ist

sudo -H -u iobroker mariadb-dump ...

Wenn der TE aber wie von mir beschrieben als iobroker angemeldet ist, dann sollte es auch ohne sudo usw. gehen, oder auch nicht, wenn es immer noch klemmt, warum auch immer.

Ich werde, wenn mir Frauchen heute etwas Zeit gibt, mal alles nötige bei mir installieren und auch testen.

Denn ich verstehe es nicht, es sollte klappen, es seiden der TE hat bei seinen arbeiten am 25.5. irgendetwas verstellt, das er uns noch nicht gesagt hat.

VG
Bernd

[Homoran]

@dp20eic sagte in BackITUp: MySQL DB Sicherung schlägt fehl:

Wenn der TE aber wie von mir beschrieben als iobroker angemeldet ist

um Fehler dabei auszuschließen sollte IMHO zuerst immer der "offizielle" Weg beschritten werden.
Leider gibt es sehr viele user, die bei der Installation des OS "ihren" User ebenfalls iobroker nennen.

[Ein ehemaliger Benutzer]

@homoran sagte in BackITUp: MySQL DB Sicherung schlägt fehl:

Leider gibt es sehr viele user, die bei der Installation des OS "ihren" User ebenfalls iobroker nennen.

Moin,

ja, stimmt, das ist verwirrend.

Was noch fehlt, vom TE, sind die Informationen zum User und den Rechten, die dieser in der Datenbank hat.

Mich verwirrt auch, dass obwohl alles auf dem gleichen Rechner läuft, der Rechnername RKO-Central eingetragen ist, sollte da nicht ein localhost oder 127.0.0.1 ausreichen?

Wenn ich das für mich umsetzen würde, dann würde ich das in etwa so machen, dass ich einen speziellen User nur für die Backups in der Datenbank anlegen würde und nicht den gleichen nutze wie der, der die Daten schreibt.

mysql/mariadb Backup Benutzer erstellen

Mein Gedankengang

Um Backups der mysql/mariadb Datenbanken zu erstellen braucht es einen Benutzer, der auf alle Datenbanken zugreifen kann.
Die Backups mit dem root User zu machen ist einfach, aber keine Gute Idee, da dieser User auch alles kaputt machen kann, zu viele Rechte ;)

Voraussetzung

Welche Berechtigungen braucht es mindestens, um dieser Aufgabe gerecht zu werden?
Ein mysql/mariadb Backup User muss lesenden Zugriff auf alle Datenbanken haben, er darf auf keinen Fall Schreibzugriff auf die Daten haben, denn sonst könnte jemand, der den Account des Backupbenutzers übernommen hat, nicht nur die Backups, sondern auch die Daten auf der Datenbank löschen!
Das will man natürlich nicht :)

Umsetzung

Ein minimales Set von Berechtigungen, die problemlos mit mysqldump/mariadb-dump funktioniert, ist:

GRANT SELECT, RELOAD, LOCK TABLES, EVENT ON *.* TO 'backup'@'%' IDENTIFIED BY PASSWORD 'p455w0rd'

Dies erstellt den Benutzer backup mit dem Passwort: p455w0rd.
Der Benutzer kann sich von überall aus mit der Datenbank verbinden (%) und alle Daten lesen, jedoch keine Daten schreiben/löschen.

Wenn man die Backups nur vom Backup Server aus macht, könnte man anstelle von „%“ auch „localhost“, oder „127.0.0.1“ nehmen, um den Benutzer weiter einzuschränken.

VG
Bernd

Edit

1. Ich habe mir in meiner iobroker LXC-Testinstanz, mariadb, mariadb-client installiert, da ich kein KleinWeich Account habe, habe ich anstatt OneDrive halt mal Google-Drive genutzt.
2. Dann habe User angelegt
   • sql_iobroker

     MariaDB [(none)]> CREATE USER 'sql_iobroker'@'localhost' IDENTIFIED BY 'sql-iobroker';
     MariaDB [(none)]> GRANT ALL PRIVILEGES ON iobroker.* TO 'sql_iobroker'@'localhost';
     

   • backup

     MariaDB [(none)]> CREATE USER 'backup'@'localhost' IDENTIFIED BY 'dasgehtdichnichtsan';
     MariaDB [(none)]> GRANT SELECT, RELOAD, LOCK TABLES, EVENT ON *.* TO 'backup'@'localhost';
     

3. Die ioBroker - Adapter installiert
   • SQL und Backitup
4. Die Adapert konfiguriert
   • SQL - Adapter
     
   • Backitup - Adapter
     
     
5. Check alle Adapter sind grün
   
6. Trommelwirbel, Backup angestoßen

   Started iobroker ...
   [DEBUG] [iobroker] - host.arch-iob 6676 states saved
   
   [DEBUG] [iobroker] - host.arch-iob 7596 objects saved
   
   [DEBUG] [iobroker] - Backup created: /opt/iobroker/backups/iobroker_2023_06_11-13_56_22_backupiobroker.tar.gz
   
   [DEBUG] [iobroker] - done
   [DEBUG] [mysql] - MySql-Backup started ...
   [DEBUG] [mysql] - MySql File deleted!
   [DEBUG] [mysql] - MySql-Backup for is finish
   [DEBUG] [mysql] - done
   [DEBUG] [googledrive] - Google Drive: Copy iobroker_2023_06_11-13_56_22_backupiobroker.tar.gz...
   [DEBUG] [googledrive] - Google Drive: Copy mysql_2023_06_11-13_56_27_backupiobroker.tar.gz...
   [DEBUG] [googledrive] - done
   [DEBUG] [clean] - No older backup files are deleted, because this backup was started manually
   [DEBUG] [clean] - done
   [DEBUG] [historyHTML] - new history html values created
   [DEBUG] [historyHTML] - done
   [DEBUG] [historyJSON] - new history json values created
   [DEBUG] [historyJSON] - done
   [EXIT] 0
   

So, bei mir gibt es keine Probleme, der einzige Unterschied, ist, dass meine Testinstallation nicht auf Debian, sondern unter Arch Linux läuft und ich aktuell die z-shell (zsh) anstelle von bash nutze.
Ich habe auch mal einige Fehler gemacht, um zu schauen was so im journal auftaucht

 14:01:53  dp20eic@arch-iob  ~  ⬡ v18.15.0  20s 
$ journalctl -u mariadb 
Jun 11 12:57:15 arch-iob systemd[1]: Starting MariaDB 10.11.3 database server...
Jun 11 12:57:15 arch-iob mariadbd[21738]: 2023-06-11 12:57:15 0 [Note] Starting MariaDB 10.11.3-MariaDB source revision 0bb31039f54bd6a0dc8f0fc7d40e6b58a51998b0 as process 21738
Jun 11 12:57:15 arch-iob mariadbd[21738]: 2023-06-11 12:57:15 0 [Note] InnoDB: The first data file './ibdata1' did not exist. A new tablespace will be created!
Jun 11 12:57:15 arch-iob mariadbd[21738]: 2023-06-11 12:57:15 0 [Note] InnoDB: Compressed tables use zlib 1.2.13
Jun 11 12:57:15 arch-iob mariadbd[21738]: 2023-06-11 12:57:15 0 [Note] InnoDB: Number of transaction pools: 1
Jun 11 12:57:15 arch-iob mariadbd[21738]: 2023-06-11 12:57:15 0 [Note] InnoDB: Using generic crc32 instructions
Jun 11 12:57:15 arch-iob mariadbd[21738]: 2023-06-11 12:57:15 0 [Note] InnoDB: Using liburing
Jun 11 12:57:15 arch-iob mariadbd[21738]: 2023-06-11 12:57:15 0 [Note] InnoDB: Initializing buffer pool, total size = 128.000MiB, chunk size = 2.000MiB
Jun 11 12:57:15 arch-iob mariadbd[21738]: 2023-06-11 12:57:15 0 [Note] InnoDB: Completed initialization of buffer pool
Jun 11 12:57:15 arch-iob mariadbd[21738]: 2023-06-11 12:57:15 0 [Note] InnoDB: Setting file './ibdata1' size to 12.000MiB. Physically writing the file full; Please wait ...
Jun 11 12:57:15 arch-iob mariadbd[21738]: 2023-06-11 12:57:15 0 [Note] InnoDB: File './ibdata1' size is now 12.000MiB.
Jun 11 12:57:15 arch-iob mariadbd[21738]: 2023-06-11 12:57:15 0 [Note] InnoDB: Buffered log writes (block size=512 bytes)
Jun 11 12:57:15 arch-iob mariadbd[21738]: 2023-06-11 12:57:15 0 [Note] InnoDB: Doublewrite buffer not found: creating new
Jun 11 12:57:15 arch-iob mariadbd[21738]: 2023-06-11 12:57:15 0 [Note] InnoDB: 128 rollback segments are active.
Jun 11 12:57:15 arch-iob mariadbd[21738]: 2023-06-11 12:57:15 0 [Note] InnoDB: Setting file './ibtmp1' size to 12.000MiB. Physically writing the file full; Please wait ...
Jun 11 12:57:15 arch-iob mariadbd[21738]: 2023-06-11 12:57:15 0 [Note] InnoDB: File './ibtmp1' size is now 12.000MiB.
Jun 11 12:57:15 arch-iob mariadbd[21738]: 2023-06-11 12:57:15 0 [Note] InnoDB: log sequence number 0; transaction id 3
Jun 11 12:57:15 arch-iob mariadbd[21738]: 2023-06-11 12:57:15 0 [ERROR] Could not open mysql.plugin table: "Table 'mysql.plugin' doesn't exist". Some plugins may be not loaded
Jun 11 12:57:15 arch-iob mariadbd[21738]: 2023-06-11 12:57:15 0 [ERROR] Can't open and lock privilege tables: Table 'mysql.servers' doesn't exist
Jun 11 12:57:15 arch-iob mariadbd[21738]: 2023-06-11 12:57:15 0 [Note] Server socket created on IP: '0.0.0.0'.
Jun 11 12:57:15 arch-iob mariadbd[21738]: 2023-06-11 12:57:15 0 [Note] Server socket created on IP: '::'.
Jun 11 12:57:15 arch-iob mariadbd[21738]: 2023-06-11 12:57:15 0 [ERROR] Fatal error: Can't open and lock privilege tables: Table 'mysql.db' doesn't exist
Jun 11 12:57:15 arch-iob mariadbd[21738]: 2023-06-11 12:57:15 0 [ERROR] Aborting
Jun 11 12:57:15 arch-iob mariadbd[21738]: Warning: Memory not freed: 280
Jun 11 12:57:15 arch-iob systemd[1]: mariadb.service: Main process exited, code=exited, status=1/FAILURE
Jun 11 12:57:15 arch-iob systemd[1]: mariadb.service: Failed with result 'exit-code'.
Jun 11 12:57:15 arch-iob systemd[1]: Failed to start MariaDB 10.11.3 database server.
Jun 11 13:00:02 arch-iob systemd[1]: Starting MariaDB 10.11.3 database server...
Jun 11 13:00:02 arch-iob mariadbd[21927]: 2023-06-11 13:00:02 0 [Note] Starting MariaDB 10.11.3-MariaDB source revision 0bb31039f54bd6a0dc8f0fc7d40e6b58a51998b0 as process 21927
Jun 11 13:00:02 arch-iob mariadbd[21927]: 2023-06-11 13:00:02 0 [Note] InnoDB: Compressed tables use zlib 1.2.13
Jun 11 13:00:02 arch-iob mariadbd[21927]: 2023-06-11 13:00:02 0 [Note] InnoDB: Number of transaction pools: 1
Jun 11 13:00:02 arch-iob mariadbd[21927]: 2023-06-11 13:00:02 0 [Note] InnoDB: Using generic crc32 instructions
Jun 11 13:00:02 arch-iob mariadbd[21927]: 2023-06-11 13:00:02 0 [Note] InnoDB: Using liburing
Jun 11 13:00:02 arch-iob mariadbd[21927]: 2023-06-11 13:00:02 0 [Note] InnoDB: Initializing buffer pool, total size = 128.000MiB, chunk size = 2.000MiB
Jun 11 13:00:02 arch-iob mariadbd[21927]: 2023-06-11 13:00:02 0 [Note] InnoDB: Completed initialization of buffer pool
Jun 11 13:00:02 arch-iob mariadbd[21927]: 2023-06-11 13:00:02 0 [Note] InnoDB: Buffered log writes (block size=512 bytes)
Jun 11 13:00:02 arch-iob mariadbd[21927]: 2023-06-11 13:00:02 0 [Note] InnoDB: 128 rollback segments are active.
Jun 11 13:00:02 arch-iob mariadbd[21927]: 2023-06-11 13:00:02 0 [Note] InnoDB: Setting file './ibtmp1' size to 12.000MiB. Physically writing the file full; Please wait ...
Jun 11 13:00:02 arch-iob mariadbd[21927]: 2023-06-11 13:00:02 0 [Note] InnoDB: File './ibtmp1' size is now 12.000MiB.
Jun 11 13:00:02 arch-iob mariadbd[21927]: 2023-06-11 13:00:02 0 [Note] InnoDB: log sequence number 45468; transaction id 15
Jun 11 13:00:02 arch-iob mariadbd[21927]: 2023-06-11 13:00:02 0 [Note] InnoDB: Loading buffer pool(s) from /var/lib/mysql/ib_buffer_pool
Jun 11 13:00:02 arch-iob mariadbd[21927]: 2023-06-11 13:00:02 0 [Note] InnoDB: Buffer pool(s) load completed at 230611 13:00:02
Jun 11 13:00:02 arch-iob mariadbd[21927]: 2023-06-11 13:00:02 0 [Note] Server socket created on IP: '0.0.0.0'.
Jun 11 13:00:02 arch-iob mariadbd[21927]: 2023-06-11 13:00:02 0 [Note] Server socket created on IP: '::'.
Jun 11 13:00:02 arch-iob mariadbd[21927]: 2023-06-11 13:00:02 0 [Note] /usr/bin/mariadbd: ready for connections.
Jun 11 13:00:02 arch-iob mariadbd[21927]: Version: '10.11.3-MariaDB'  socket: '/run/mysqld/mysqld.sock'  port: 3306  Arch Linux
Jun 11 13:00:02 arch-iob systemd[1]: Started MariaDB 10.11.3 database server.
Jun 11 13:00:25 arch-iob mariadbd[21927]: 2023-06-11 13:00:25 3 [Warning] Access denied for user 'root'@'localhost'
Jun 11 13:07:36 arch-iob mariadbd[21927]: 2023-06-11 13:07:36 5 [Warning] Access denied for user 'root'@'localhost'
Jun 11 13:07:55 arch-iob mariadbd[21927]: 2023-06-11 13:07:55 6 [Warning] Access denied for user 'root'@'localhost'
Jun 11 13:07:59 arch-iob mariadbd[21927]: 2023-06-11 13:07:59 7 [Warning] Access denied for user 'root'@'localhost'
Jun 11 13:08:00 arch-iob mariadbd[21927]: 2023-06-11 13:08:00 8 [Warning] Access denied for user 'root'@'localhost'
Jun 11 13:12:21 arch-iob mariadbd[21927]: 2023-06-11 13:12:21 15 [Warning] Access denied for user 'root'@'localhost'
Jun 11 13:19:13 arch-iob mariadbd[21927]: 2023-06-11 13:19:13 17 [Warning] Access denied for user 'sql_iobroker'@'localhost' (using password: YES)

Hier auch noch mal die Rechte in der Datenbank

VG und schönen Sonntag
Bernd

[Azrael42]

@dp20eic said in BackITUp: MySQL DB Sicherung schlägt fehl:

@azrael42 sagte in BackITUp: MySQL DB Sicherung schlägt fehl:

Wenn Du als iobroker das ausführst

iobroker@RKO-Central:~$ mariadb-dump -u iobroker -p  iobroker > /opt/iobroker/backups/mysql_test.sql

Schon wieder aktiv? Danke!
Verlangt nach dem SQL User Passwort und spring dann sofort wieder in die Shell. Habe es auch mit der "Offiziellen" Version ausgeführt, also "sudo -H -u ..."

Dann kannst Du auch noch mal versuchen, ob Du als iobroker etwas im Verzeichnis anlegen kannst.

touch /opt/iobroker/backups/test.txt

Jip, geht.

-rw-rw-r--+ 1 iobroker iobroker        0 Jun 11 13:20 mysql_test_2.sql
-rw-rw-r--+ 1 iobroker iobroker        0 Jun 11 13:17 mysql_test.sql
-rw-rw-r--+ 1 iobroker iobroker        0 Jun 11 13:17 test.txt

@dp20eic said in BackITUp: MySQL DB Sicherung schlägt fehl:

Wenn der TE aber wie von mir beschrieben als iobroker angemeldet ist, dann sollte es auch ohne sudo usw. gehen, oder auch nicht, wenn es immer noch klemmt, warum auch immer.

Das tut es leider nicht. Nur leere Dateien.
Mit dem sudo ohne dedizierten User davor, funktioniert es.

sudo mariadb-dump -u iobroker -p iobroker > /opt/iobroker/backups/mysql_test_3.sql

-rw-rw-r--+ 1 richard  richard  267923908 Jun 11 13:30 mysql_test_3.sql

Deshalb wäre ich jetzt mal so kühn zu behaupten, das die Userrechte in der MariaDB passen.
Habe aber dennoch mal einen Backupuser angelegt, der das gleiche Verhalten zeigt.

[Azrael42]

@dp20eic said in BackITUp: MySQL DB Sicherung schlägt fehl:

journalctl -u mariadb

@dp20eic said in BackITUp: MySQL DB Sicherung schlägt fehl:

Ich habe mir in meiner iobroker LXC-Testinstanz, mariadb, mariadb-client installiert, da ich kein KleinWeich Account habe, habe ich anstatt OneDrive halt mal Google-Drive genutzt.
Dann habe User angelegt

Danke für die Mühe und den Test.
So war es ja ebenfalls, bis ich da was kaputt gemacht habe.

Ich kapituliere jetzt aber und nehme ein händisches Backup zu einem Restore heran. Auf einem neu installierten System wird es wieder funktionieren.

[Azrael42]

@dp20eic
Hat mir natürlich keine Ruhe gelassen...

Ich bin also nochmal zurück zum Anfang. Habe die "mysqldump" Befehle zerlegt und alle Kombinationen getestet.

Dann wollte ich über die Konsole auf den DB Server, um ein paar weitere Tests zu machen.
Dabei bekam ich dann den ersten aussagekräftigen Fehler:

richard@RKO-Central:/var/log$ mysql -u iobroker -p iobroker
mysql: unknown variable 'log_error=/var/log/mysqld.log'

An die Variable erinnerte ich mich, die hatte ich nach dem Verbindungsabbruch zum SQL Server gesetzt. Das Log war damals wie heute fast leer. Gleicher Befehl mit "sudo" vorweg meldet sich an die DB an.
Also das ganze wieder zurück gesetzt (Variable entfernt) und den Server neu gestartet.

Es funktioniert wieder!

Was soll ich sagen? Auf jeden fall weiß ich jetzt, was ich am 25.05. verändert habe. Asche auf mein Haupt!

Danke nochmal!