backup blockierend?

mahowi · 28 November 2017, 08:49:10

Ich lasse nachts um 0:30 Uhr per at backup laufen. In der Zeit ist FHEM komplett blockiert, das Log wird erst nach Beendigung weiter geschrieben.

Code Auswählen

2017.11.28 00:30:00.066 1: NOTE: make sure you have a database backup!
2017.11.28 00:30:00.081 2: Backup with command: tar -chf - "configDB.conf" "./_Inline" "./alexa-fhem" "./certs" "./CHANGED" "./configDB.conf" "./configDB.db" "./configDB.pm" "./contrib" "./db.conf" "./demolog" "./docs" "./FHEM" "./fhem.cfg" "./fhem.cfg.demo" "./fhem.db" "./fhem.pl" "./kindle" "./log" "./MAINTAINER.txt" "./README_DEMO.txt" "./restoreDir" "./scripts" "./tmp.png" "./unsed" "./unused" "./www" "./ZME_UZB1.bin" |gzip > /media/fhem/backup/FHEM-20171128_003000.tar.gz
2017.11.28 00:53:20.215 1: backup done: FHEM-20171128_003000.tar.gz (925011606 Bytes)
2017.11.28 00:53:20.215 3: backup : 
backup done: FHEM-20171128_003000.tar.gz (925011606 Bytes)
2017.11.28 00:53:20.220 1: Perfmon: possible freeze starting at 00:30:00, delay is 1400.22

Aufgefallen ist es mit hauptsächlich, weil meine Z-Wave Zwischenstecker um die Zeit regelmäßig die Verbindung verlieren und wild vor sich hinblinken. Es läuft also in den über 20 Minuten gar nichts. Ein at, daß bei mir minütlich läuft, wird nach dem Backup sooft hintereinander gestartet, wie es eigentlich hätte laufen sollen in der Zeit, hier also 23mal innerhalb von 3 Sekunden.

Läßt sich das irgendwie nicht blockierend machen?

Thyraz · 28 November 2017, 09:02:17

Da sind schon viele drüber gestolpert.

Backup blockiert nur dann nicht, wenn es durch den Update Prozess angestoßen wird und dieser im Hintergrund läuft.

Alternative wäre das FHEM Verzeichnis einfach über ein Shellscript zu sichern.
Was anderes als die Dateien in ein Archiv zu packen macht der Backup Befehl ja sicher auch nicht.

mahowi · 28 November 2017, 09:24:13

Ok, natürlich könnte ich einfach ein externes Skript per cron laufen lassen.

Aber warum verhält sich backup anders, wenn man es selbst anstößt als wenn es durch ein Update angestoßen wird? Meiner Meinung nach sollte eigentlich alles, was länger braucht, non-blocking laufen.

dev0 · 28 November 2017, 09:31:13

Zitat von: mahowi am 28 November 2017, 09:24:13
Meiner Meinung nach sollte eigentlich alles, was länger braucht, non-blocking laufen.

Genau, das wäre der Idealzustand. Der Code ist etwas wirr und es gibt einen Unterschied, ob das Backup über FHEMWEB oder Telnet/Command line angestoßen wurde, wenn ich mich recht erinnere. Schreib einen Patch, der das Problem ohne Nebenwirkungen behebt und biete diesen dann dem Maintainer an, wenn es Dich stört.

mahowi · 28 November 2017, 10:05:20

Ich muß zugeben, ich hab mir den zugehörigen Code noch nicht angesehen. Ich dachte, es gäbe eine Möglichkeit, das Backup im Hintergrund laufen zu lassen, da es beim Update ja auch funktioniert.

Frank_Huber · 28 November 2017, 10:07:53

Ich mache meine täglichen Backups damit:
http://www.meintechblog.de/2015/05/fhem-howto-automatisches-backup-auf-externem-nas/
Und ich meine es ist nicht blockierend.

mahowi · 28 November 2017, 10:12:50

Klar, ist ja auch ein externes Skript. Es hat ja keinen Einfluß auf FHEM, außer ein paar Readings zu setzen.

Es ging mir hier um den internen Befehl backup. Und der blockiert, wenn man ihn ~~händisch oder~~ per at/notify aufruft, tut dies aber nicht, wenn er beim Update aufgerufen wird.

Beta-User · 28 November 2017, 10:21:26

Dürfte daran liegen, dass update standardmäßig als "updateInBackground" ausgeführt wird.
Wenn dann dort backup aufgerufen wird, ist es Teil des fork-Prozesses, oder?

marvin78 · 28 November 2017, 10:24:43

Ein backup aus der Kommandozeile ist nicht blockierend.

mahowi · 28 November 2017, 10:36:11

Ok, verhält sich backup je nach Aufruf anders oder liegt es eventuell doch an at?

dev0 · 28 November 2017, 11:39:59

ZitatIch dachte, es gäbe eine Möglichkeit, das Backup im Hintergrund laufen zu lassen

Wie Du festgestellt hast (und ich schon schrieb) verhält sich das Modul, je nachdem wie es aufgerufen wird, anders. Da kannst Du jetzt viel fragen und diskutieren, dadurch wird es nicht besser. Einarbeiten, besser machen und ggf. Patch einreichen, gut is... Oder?

mahowi · 28 November 2017, 12:10:52

Ich will ja gar nix schlecht machen oder unnötig diskutieren. Aber es muß ja schließlich einen Grund für das Verhalten geben oder gegeben haben, sonst hätte Rudi es ja nicht extra so eingebaut.

Ich kann ja nix ändern, wovon ich nicht weiß, was der Maintainer sich dabei gedacht hat. Ansonsten bräuchte man vermutlich nur die Zeilen 200 und 209 bis 223 zu löschen.

dev0 · 28 November 2017, 12:17:15

Zitat von: mahowi am 28 November 2017, 12:10:52
sonst hätte Rudi es ja nicht extra so eingebaut.

Ich glaube zu wissen, dass Rudi nicht der Autor sondern nur der kommissarische Maintainer ist und es jemand anderes "verbrochen" hat.

mahowi · 29 November 2017, 20:55:19

Ich hab Martin mal angeschrieben. Laut Source hat er das Modul wohl 2012 geschrieben.

rudolfkoenig · 29 November 2017, 23:00:25

Ich verwalte backup komissarisch, und ich habe es bisher nur "kosmetisch" geaendert, z.Bsp. der Aufruf wird ins Hintergrund verlagert, wenn es aus FHEMWEB direkt aufgerufen wird. Es laeuft auch im Hintergrund, wenn es durch update gestartet wird, der wiederum (als Voreinstellung) im Hintergrund laeuft.

Ich habe es nochmal angepasst: backup wird jetzt mit der "FHEMWEB" Methode im Hintergrund gestartet, wenn nicht bereits im Hintergrund ist, z.Bsp. wg. update.