NEWS
Test Adapter ioBroker.backitup v3.0.x
-
@simatec Hmm, kann eigentlich nicht sein. Hab gerade zum Testen von einer Windowskiste aus das Verzeichnis gemounted mit den gleichen Credentials die auch der backitup Adapter nutzt. So kann ich dort Dateien erstellen und löschen, auch im influxDBtmp Ordner.
Verstehe nicht so ganz warum die Instanz vom Raspi aus dort schreiben kann aber die Instanz vom NUC aus nicht. -
@firebowl cifs-utils installiert?
-
@firebowl sagte in Test Adapter Backitup v2.2.x:
Verstehe nicht so ganz warum die Instanz vom Raspi aus dort schreiben kann aber die Instanz vom NUC aus nicht.
Nutzt du auf dem NUC Proxmox? Wenn ja VM oder LXC?
-
@simatec Ähh sorry, ja ist drauf.
-
@simatec Proxmox und VM weil ich bei LXC den ConBee II nicht sauber zum laufen bekomm.
-
@firebowl Laut der Log Ausgabe würde ich daruf tippen, dass dein Mount-Point bereits belegt ist.
Also einfach mal alle Systeme inkl. NAS neustartenmount error(16): Device or resource busy
-
@simatec sagte in Test Adapter Backitup v2.2.x:
@firebowl Laut der Log Ausgabe würde ich daruf tippen, dass dein Mount-Point bereits belegt ist.
Also einfach mal alle Systeme inkl. NAS neustartenmount error(16): Device or resource busy
Hat nicht geholfen:
Started restore ... [DEBUG] [influxDB] - Try deleting the old InfluxDB tmp directory [DEBUG] [influxDB] - InfluxDB old tmp directory was successfully deleted [DEBUG] [influxDB] - Created tmp directory [DEBUG] [influxDB] - Start infuxDB Restore ... [ERROR] [influxDB] - Error: EPERM: operation not permitted, utime '/opt/iobroker/backups/influxDBtmp/' [ERROR] [influxDB] - infuxDB Restore not completed [EXIT] 0
Scheinbar kann er ja den alten Temp Ordner löschen und auch neu anlegen...
-
@firebowl Da dein mount ja nicht funktioniert kann das auch nicht funktionieren.
Er hat ja kein Backup für den restoreMache mal folgendes
iobroker stop iobroker fix iobroker start
Dann deine Backups für den restore lokal in den Ordner
/opt/iobroker/backups
mit einen SFTP Tool (z.B. Filezilla) legen und den Restore lokal starten.Wenn alle Restores durchgelaufen sind, würde ich mal komplett die Einstellungen an deinem NAS prüfen und die Einstellungen zu deinen alten PI vergleichen. Eventuell hat der NUC mit neuer IP keine Rechte auf deinem NAS und der alte PI mit seiner IP schon
-
@fila612 hast du das mit den Rechten auf dem NAS hinbekommen? Ich kriege das nicht hin, bei mir ist und bleibt der CIFS-gemountete Ordner unter /opt/iobroker/backups beim Benutzer root und damit funktioniert das Wiederherstellen vom NAS nicht. Der mysql-dump wird zwar entpackt aber nicht wieder hergestellt, wobei ich den entpackten Dump manuell mit
mysql -u iobroker -p iobroker < *.sql
wieder herstellen kann.
Ich behelfe mir im Moment damit, die .gz-Backups vom NAS nach lokal (opt/iobroker/backups) zu kopieren und dann restore von lokal.Hast du eine Lösung?
-
@simatec sagte in Test Adapter Backitup v2.2.x:
@firebowl Da dein mount ja nicht funktioniert kann das auch nicht funktionieren.
Er hat ja kein Backup für den restoreMache mal folgendes
iobroker stop iobroker fix iobroker start
Dann deine Backups für den restore lokal in den Ordner
/opt/iobroker/backups
mit einen SFTP Tool (z.B. Filezilla) legen und den Restore lokal starten.Wenn alle Restores durchgelaufen sind, würde ich mal komplett die Einstellungen an deinem NAS prüfen und die Einstellungen zu deinen alten PI vergleichen. Eventuell hat der NUC mit neuer IP keine Rechte auf deinem NAS und der alte PI mit seiner IP schon
Hab das Backup jetzt "lokal" abgelegt und versucht wiederherzustellen:
Started restore ... [DEBUG] [influxDB] - Created tmp directory [DEBUG] [influxDB] - Start infuxDB Restore ... [ERROR] [influxDB] - 2021/12/02 11:27:07 error updating meta: DB metadata not changed. database may already exist restore: DB metadata not changed. database may already exist [DEBUG] [influxDB] - Try deleting the InfluxDB tmp directory [DEBUG] [influxDB] - InfluxDB tmp directory was successfully deleted [DEBUG] [influxDB] - infuxDB Restore completed successfully [EXIT] influxDB restore done
Wurde jetzt was restored oder nicht?
Die DB hat aber garantiert nicht existiert vorher, hab influxdb vorhin ganz frisch installiert. -
@fu_zhou
ja der Restore hat bei mir nicht direkt vom NAS geklappt. Hab daher die Files ins lokale Backup-Verzeichnis kopiert und von dort den Restore gemacht. Ist zwar nicht perfekt, aber ein akzeptabler Workaround. -
@firebowl sagte in Test Adapter Backitup v2.2.x:
Die DB hat aber garantiert nicht existiert vorher, hab influxdb vorhin ganz frisch installiert.
Wenn du den Influx Adapter installierst und und konfigurierst, wird durch den Adapter die DB angelegt
Also vorher den Adapter stoppen und die DB löschen. Influx kann leider kein kompletten Restore in eine bestehende DB. -
@simatec sagte in Test Adapter Backitup v2.2.x:
@firebowl sagte in Test Adapter Backitup v2.2.x:
Die DB hat aber garantiert nicht existiert vorher, hab influxdb vorhin ganz frisch installiert.
Wenn du den Influx Adapter installierst und und konfigurierst, wird durch den Adapter die DB angelegt
Also vorher den Adapter stoppen und die DB löschen. Influx kann leider kein kompletten Restore in eine bestehende DB.Bringt leider nix.
Hab die VM noch mal zurückgesetzt auf einen Stand vor der Influx Installation.
Dann hab ich folgendes gemacht:- influxdb installiert
- admin und normalen User mit CREATE USER angelegt
- Datenbank mit CREATE DATABASE angelegt
- dem User Rechte auf die DB gegeben
- Influx Adapter im ioBroker installiert
- Adapter angehalten und Datenbank mit DROP DATABASE geleert
- Backup eingespielt bzw. es versucht, der Fehler bleibt gleich
Started restore ... [DEBUG] [influxDB] - Created tmp directory [DEBUG] [influxDB] - Start infuxDB Restore ... [ERROR] [influxDB] - 2021/12/02 12:54:54 error updating meta: DB metadata not changed. database may already exist restore: DB metadata not changed. database may already exist [DEBUG] [influxDB] - Try deleting the InfluxDB tmp directory [DEBUG] [influxDB] - InfluxDB tmp directory was successfully deleted [DEBUG] [influxDB] - infuxDB Restore completed successfully [EXIT] influxDB restore done
Mod-Edit: Code in </> Code-Tag gepackt!
-
@firebowl Dann hat deine Datenbank noch existiert ... Der Fehler sagt es ja eindeutig
-
Bitte mal folgendes aus der Konsole zeigen:
influx show databases drop database "dein-DB-Name" show databases exit
Bitte unbedingt vorher den Influx Adapter und andere Systeme, die auf diese DB schreiben stoppen
-
mike@iobroker:~$ influx Connected to http://localhost:8086 version 1.8.10 InfluxDB shell version: 1.8.10 > show databases name: databases name ---- _internal ioBroker > drop database ioBroker > show databases name: databases name ---- _internal >
Nach dem droppen is die DB weg.
Adapter ist weiterhin gestoppt und ich spiel das Backup ein, richtig? -
@firebowl Genau nun das Backup zurückspielen
-
@simatec Leider genau das gleiche.
Started restore ... [DEBUG] [influxDB] - Created tmp directory [DEBUG] [influxDB] - Start infuxDB Restore ... [ERROR] [influxDB] - 2021/12/02 13:28:53 error updating meta: DB metadata not changed. database may already exist restore: DB metadata not changed. database may already exist [DEBUG] [influxDB] - Try deleting the InfluxDB tmp directory [DEBUG] [influxDB] - InfluxDB tmp directory was successfully deleted [DEBUG] [influxDB] - infuxDB Restore completed successfully [EXIT] influxDB restore done
Ein show database zeigt keine DB an und wenn ich den Adapter starte dann wird wieder die DB angelegt.
Wurde jetzt was zurückgespielt oder hat der Adapter einfach ne leere DB angelegt?EDIT: Ist ne leere DB /var/lib/influxdb/data/ sind 88KB und auf dem alten System sind es 75MB.
Mod-Edit: Code in </> Code-Tag gepackt!
-
@firebowl Zeige doch mal bitte die Einstellungen in Backitup
-
@simatec Vom Adapter der sichert oder von dem der wiederherstellen soll?
Letzterer is ja noch sehr leer.