[98_backupToStorage] Modul zum upload des FHEM Backups auf ein Storage

[CoolTux]

Hallo CoolTux,
Bin aktuell wegen Deinem Modul und natürlich denen von DS_Starter von Qnap zu einer Synology gewechselt. Alles sehr schön, nur die Datensicherung kommt nicht auf der Synology an.  - gibt es dazu einen neuen aktuellen Stand?

Hallo,

Leider habe ich aktuell keine Zeit. Es gibt auch keinen lauffähigen Stand.

[softwear]

Moin zusammen und danke cooler Tux!

Für die Nextcloud sehr nice, das Modul: Haken war auch bei mir, dass der Backup zu lange lief, weshalb ich hier nachschaute. 180 Sekunden im Source auf 900 erhöht und fertig war der einfache Backup, der unmittelbar hochgeladen wird. Zum Starten habe ich ein at genutzt:

Code Auswählen Erweitern

define at_backup at *01:11:00 { fhem("backup") if($wday == 3) }
Kurzinfo für Leute, die nicht suchen/ausprobieren bzw. im Quelltext eruieren wollen:
bTS_Host meint den Host oder das Unterverzeichnis der Nextcloud (so wie sie auch im Browser erreichbar ist); bei mir z.B. die IP gefolgt von /nextcloud, also beispielhaft 192.168.1.111/nextcloud. OHNE http(s)://!
bTS_Path meint den Pfad beginnend mit / im Hauptverzeichnis des Benutzers der Nextcloud, z.B. /backup/fhem.
bTS_User meint den Benutzernamen der Authentifizierung in der Nextcloud.

Wenn der Upload erfolgreich ist, wird das reading uploadState erzeugt (später aktualisiert) und erhält den Wert "upload successfully". Diese Eventualität kann man sich zu Nutze machen, um den Backup im fhem-Backup-Ordner zu entfernen. Hierzu habe ich ein Notify kreiert:

Code Auswählen Erweitern

define n_backupFhem_uploadSuccess notify backupFhem:uploadState.* {
  # wenn nicht erfolgreich, dann verlassen
  if (index($EVENT,"upload successfully") == -1) { return;; }
  # Namen des letzten Backups holen (this_NextcloudBackup ist mein backupToStorage-Device)
  my $lastBackupFile = ReadingsVal("this_NextcloudBackup","fhemBackupFile","none");;
  # wenn reading des letzten Backups nicht vorhanden, verlassen
  if ($lastBackupFile eq "none") { return;; }
  # $fileToDelete bezeichnet den absoluten Pfad
  #my $fileToDelete = '/opt/fhem' . substr($lastBackupFile, 1, length($lastBackupFile)-1);;
  # $lastBackupFile bezeichnet den fhembezogenen Pfad
  unlink($lastBackupFile) or die Log 1, "$lastBackupFile konnte nicht gelöscht werden (n_ncBackup_uploadSuccess)";;
  # return verhindet die Logausgabe des return value: 1
  return;;
}
Ein Backup kann sowohl durch Eingabe von "backup" in der Befehlszeile von fhem gestartet werden oder auch per at oder anderen Mitteln wie Events z.B..

Ich sehe zu, dass ich auch noch die Begrenzung der Anzahl von Backups in der Nextcloud hier einbringe.

Den Grund übrigens für die hohe Toleranzzeit von 900s möchte ich auch nicht verschweigen. Der fhem-Server liegt auf einem pi2, die Nextcloud auf einem pi3 im gleichen Netzwerk. 600s waren ebenfalls ausreichend, aber habe ich mir etwas Raum gegeben, weil die fhem-Installation (Doppelsystem mit fhem2fhem - Homematic und EnOcean) gerade noch größer wird. Der Zugriff mit dieser Form von Backup funktioniert auch von außen, aus einem anderen Netzwerk heraus, problemlos (in meinem Fall mit einem pi4). Die Backups sind jeweils zwischen 100 und 150 MB groß. Dabei bestimmt der fhem-Server mit seiner Geschwindigkeit den Flaschenhals.

Ich habe hier übrigens auch noch eine antike DiskStation (216 glaube ich). Eventuell teste ich das Geschehen damit ebenfalls, weil doch einige Fragen und Interessensbekundungen hier vorlagen. Und, ja, ich weiß, dieser Thread ist schon etwas älter. Heißt jedoch nicht, dass man nicht trotzdem auf ihn stoßen könnte. Ich bin's ja auch. So hoffe ich nun, vielleicht ebenfalls ein wenig geholfen zu haben.

Grüße von softwear

[softwear]

Moin zusammen erneut,

Beschränkung der Backups auf dem NextCloud-Storage, somit Löschung der/des Ältesten bei Verschieben des Neuesten auf das Storage, um eine fixe Anzahl vorzuhalten, läuft jetzt bei mir. Die Anzahl der auf dem Storage vorzuhaltenden Backups habe ich als Attribut hinzugefügt (mein Standard beträgt 4, kann man aber ändern).

Habe ich CoolTux auch bereits übermittelt. Er schreibt das Modul insgesamt gerade um, sodass es etwas dauern kann, bis ihr in den Genuss kommt.

Ferner ist ebenfalls die Synology DiskStation kein Problem. Auch dort habe ich Backups abgelegt. Wenn Bedarf besteht, füge ich die Funktionen der DS noch in die alte Version ein, sodass ihr sie nutzen könnt, bevor die neue steht. Ansonsten belasse ich's soweit mit meinem Testscriptmodul und freue mich selbst auf die Neue von Cool  .

Ich wünsche allen ein schönes Wochenende! Könnte nur sonniger sein 

softwear

[margu]

Hallo CoolTux,

ist zwar schon über ein Jahr seit dem letzten Beitrag, habe das Modul aber erst jetzt entdeckt.

Würde das Modul sehr gerne nutzen um meine Fhem Backups auf einfachem Weg auf meine Nextcloud zu schieben. Aktuell nutze ich ziemlich umständliche Wege für die Sicherung der Backups, die ich mir mit diesem Modul sparen könnte.

Leider funktioniert das Modul in der aktuellen Form für mich nicht, weil meine NC nur per https erreichbar ist (intern über die IP garnicht).

Meine Frage wäre nun, ob hier von dir noch weiterentwickelt wird?

Vielen Dank
Mario

[passibe]

Mein Nextcloud ist auch nur per https erreichbar und auch nur über den Hostnamen.

Ich benutze seit Jahren problemlos diese Config:

Code Auswählen Erweitern

defmod backup_nextcloud backupToStorage
attr backup_nextcloud alias Nextcloud Backup
attr backup_nextcloud bTS_Host cloud.example.org
attr backup_nextcloud bTS_Path /FHEM1
attr backup_nextcloud bTS_User fhem-backup
attr backup_nextcloud devStateIcon upload\ssuccessfully:ampel_gruen .*:ampel_rot
attr backup_nextcloud stateFormat uploadState
Gepaart mit einem Scheduler DOIF, der 1x wöchentlich das Backup ausführt und alte Backups automatisch löscht. Habe ich glaube ich irgendwo aus dem Forum hier.

Code Auswählen Erweitern

defmod backup_schedule DOIF ([01:04|So]) ( {\
Log 1, "Automatisches Backup Startet";;;;\
fhem("backup");;;;\
\
my $BackupDir = AttrVal("global", "backupdir", "/opt/fhem/backup");;;;\
my $BackupsCurrent = qx(ls -A "$BackupDir" | grep -c ".tar.gz");;;;\
## Menge der vorzuhaltenden Backup-Files\
my $BackupsMax = 8;;;;\
my $BackupsDelete = $BackupsCurrent - $BackupsMax;;;;\
\
Log 1, "Aktuelle Backups: $BackupsCurrent";;;;\
Log 1, "Zu löschende Backups: $BackupsDelete";;;;\
Log 1, "Liste der zu löschenden Backups:";;;;\
\
## Ausgabe der zu löschenden Files\
if ($BackupsDelete > 0)\
{\
my $FilesDel = qx(ls -d "$BackupDir/"* | grep ".tar.gz" | head -$BackupsDelete);;;;\
Log 1, $FilesDel;;;;\
## Files löschen\
my $BackupDelete = qx(ls -d "$BackupDir/"* | grep ".tar.gz" | head -$BackupsDelete | xargs rm);;;;\
}\
Log 1, "Backups gelöscht.";;;;\
} )
attr backup_schedule alias Backupplan
attr backup_schedule do always

Vielleicht klappt bei dir irgendetwas mit der Authentifizierung nicht oder so? Ich erinnere mich, dass ich damals auch ein klein wenig rumprobieren musste, bis das ging, aber seitdem läuft es.

[margu]

Sieht bei mir ähnlich aus.
Ich lasse täglich das Backup von Fhem über die global parameter laufen.
Die Anmeldeparameter für Nextcloud sind korrekt, weil es auch die sind, die ich für meinen Login verwende.

Habe nun mal verbose auf 5 gesetzt und das Backup manuell angestoßen. Ändert aber trotzdem nichts daran, daß die Datei nicht auf meiner Nextcloud landet.
Hier der Auszug aus dem Log dazu:

Code Auswählen Erweitern

2024.10.22 13:27:39 4: backupToStorage (myCloudBackupUpload) -
          Devname: global
          Name: myCloudBackupUpload
          Notify: $VAR1 = [
          'ATTR myCloudBackupUpload verbose 5'
        ];

2024.10.22 13:27:39 4: backupToStorage (myCloudBackupUpload) - Read password from file
2024.10.22 13:27:39 4: backupToStorage (myCloudBackupUpload) - Read password from file
2024.10.22 13:27:39 4: backupToStorage (myCloudBackupUpload) - Read password from file
2024.10.22 13:27:39 4: backupToStorage (myCloudBackupUpload) - Read password from file
2024.10.22 13:27:41 4: backupToStorage (myCloudBackupUpload) -
          Devname: global
          Name: myCloudBackupUpload
          Notify: $VAR1 = [
          'SAVE'
        ];

2024.10.22 13:27:51 2: Backup with command: tar czf /opt/Filetransfer/fhembackups/FHEM-20241022_132750.tar.gz "./killwatchdog.sh" "./startfhem" "./log" "./backup" "./fhem.cfg.demo" "./certs" "./watchdog.pl" "./configDB.pm" "./webfrontend" "./MAINTAINER.txt" "./README.SVN" "./watchdogloop.sh" "./conf" "./reverse-search-cache.txt" "./stopfhem" "./restoreDir" "./unused" "./killfhem.sh" "./CHANGED" "./fhem_fritz_traffic.py" "./README_DEMO.txt" "./hmccu_defattr.txt" "./Makefile" "./lib" "./HISTORY" "./fhem.pl" "./script" "./nas" "./www" "./docs" "./demolog" "./fhem.cfg.dpkg-dist" "./runfhem.sh" "./fhem.cfg.debug" "./fhem.cfg" "./fhem.conf.alt" "./FHEM" "./startwatchdog" "./contrib" "./cache" "./runwatchdog.sh" "./watchdog.log" "./GPL_V2.txt" "./fhem_fritz_link.py"
2024.10.22 13:27:53 4: backupToStorage (myCloudBackupUpload) - Read password from file
2024.10.22 13:27:53 4: backupToStorage (myCloudBackupUpload) - Read password from file
Backup done
2024.10.22 13:35:29 4: backupToStorage (myCloudBackupUpload) -
          Devname: global
          Name: myCloudBackupUpload
          Notify: $VAR1 = [
          'backup done'
        ];

2024.10.22 13:35:29 4: backupToStorage (myCloudBackupUpload) - push to storage function
2024.10.22 13:38:45 4: backupToStorage (myCloudBackupUpload) - Read password from file
2024.10.22 13:38:45 4: backupToStorage (myCloudBackupUpload) - Read password from file

Hier auch noch mein List vom Device

Code Auswählen Erweitern

Internals:
   .FhemMetaInternals 1
   CFGFN     
   FUUID      671603ce-f33f-db67-28a5-8f610fdc0e7c41b1
   NAME       myCloudBackupUpload
   NOTIFYDEV  global,myCloudBackupUpload
   NR         895
   NTFY_ORDER 51-myCloudBackupUpload
   STATE      ready
   STORAGETYPE Nextcloud
   TYPE       backupToStorage
   VERSION    v1.2.3
   eventCount 10
   .attraggr:
   .attrminint:
   READINGS:
     2024-10-22 13:11:24   fhemBackupFile  /opt/Filetransfer/fhembackups/FHEM-20241022_131123.tar.gz
     2024-10-22 08:24:56   state           ready
   hmccu:
Attributes:
   bTS_Host   die.xxxxxxxx.cloud
   bTS_Path   /Backups/FHEM-Backup/pi4
   bTS_Type   Nextcloud
   bTS_User   Mario
   group      Backup
   room       9.97 FHEM,9.98 Programme

[passibe]

Ah, ich glaube ich sehe das Problem. Dein Backup braucht länger als 3 Minuten (gestartet um 13:27:51 Uhr, beendet erst um 13:35:29 Uhr).
Dürfte damit zu fixen sein: https://forum.fhem.de/index.php?topic=112216.msg1141572#msg1141572

Weitere Dinge (falls das nichts bringt):
Hast du 2FA bei deinem Account an? Wenn ja, musst du auch ein App-Passwort nutzen (oder einen zweiten Benutzer anlegen, der nur das FHEM-Backup macht).
Und: Was sagt denn dein Webserver log dazu? Kommen da irgendwelche Requests von FHEM?

[margu]

Ah, ich glaube ich sehe das Problem. Dein Backup braucht länger als 3 Minuten (gestartet um 13:27:51 Uhr, beendet erst um 13:35:29 Uhr).
Dürfte damit zu fixen sein: https://forum.fhem.de/index.php?topic=112216.msg1141572#msg1141572

Wie das immer so ist: Wald und lauter Bäume ... 
Hatte den Beitrag völlig übersehen/vergessen/wat auch immer.
Habe das Timeout auf 600 gesetzt und schon läufts 

Vielen Dank

[margu]

Eine Kleinigkeit ist mir noch aufgefallen (Ursache muß ich aber wohl auf meinem ReverseProxy oder in Nextcloud suchen):
Obwohl das Modul als uploadState "upload successfully" meldet, sagen die Logs was anderes.
Da meine Perl Kenntnisse nicht ganz ausreichen um das im Modul selbst abzufangen, soll das als Info für CoolTux sein.
Hier der entsprechende Auszug aus dem Log (die IP habe ich unkenntlich gemacht):

Code Auswählen Erweitern

96  384M    0     0   96  370M      0  22.3M  0:00:17  0:00:16  0:00:01 23.3M
100  384M    0     0  100  384M      0  21.0M  0:00:18  0:00:18 --:--:-- 18.8M
100  384M  100   574  100  384M     31  21.0M  0:00:18  0:00:18 --:--:-- 17.6M
<?xml version="1.0" encoding="utf-8"?>
<d:error xmlns:d="DAV:" xmlns:s="http://sabredav.org/ns">
<s:exception>Interner Serverfehler</s:exception>
<s:message>
Der Server konnte die Anfrage nicht fertig stellen. Sollte dies erneut auftreten, sende bitte die nachfolgenden technischen Einzelheiten an deinen Server-Administrator. Weitere Details können im Server-Protokoll gefunden werden. </s:message>

<s:technical-details>
<s:remote-address>xxx.xxx.xxx.xxx</s:remote-address>
<s:request-id>UKAt3YcNkkOsizzfX5v4</s:request-id>

</s:technical-details>
</d:error>

2024.10.23 10:09:15 4: backupToStorage (myCloudBackupUpload) - got result from asynchronous parsing: {"ncUpload":"upload successfully"}
2024.10.23 10:09:15 4: backupToStorage (myCloudBackupUpload) - asynchronous finished.
2024.10.23 10:09:15 4: backupToStorage (myCloudBackupUpload) - clean Subprocess
2024.10.23 10:09:15 3: backupToStorage (myCloudBackupUpload) - _CheckIsDisabledAfterSetAttr
2024.10.23 10:09:15 4: backupToStorage (myCloudBackupUpload) -
          Devname: myCloudBackupUpload
          Name: myCloudBackupUpload
          Notify: $VAR1 = [
          'state: ready',
          'uploadState: upload successfully'
        ];


[margu]

Eine Kleinigkeit ist mir noch aufgefallen (Ursache muß ich aber wohl auf meinem ReverseProxy oder in Nextcloud suchen):
Obwohl das Modul als uploadState "upload successfully" meldet, sagen die Logs was anderes.

Code Auswählen Erweitern

    <s:message>
        Der Server konnte die Anfrage nicht fertig stellen.        Sollte dies erneut auftreten, sende bitte die nachfolgenden technischen Einzelheiten an deinen Server-Administrator.        Weitere Details können im Server-Protokoll gefunden werden.            </s:message>


Kann es sein, daß das Passwort keine Sonderzeichen (oder zumindest nicht das $-Zeichen) enthalten darf?
Ich habe auf meinem Server gesehen, daß es Probleme mit dem Login gab.
Um das zu testen, habe ich einen neuen Benutzer auf der Nextcloud angelegt (Passwort ohne Sonderzeichen) und dann hat auch der automatische Upload vom Modul aus funktioniert.

[passibe]

Was du noch probieren könntest: Bei Nextcloud kann man auch App-Passwörter erstellen, die sind dann (glaube ich) ohne Sonderzeichen und dann brauchst du keinen zusätzlichen Benutzer.

[margu]

Was du noch probieren könntest: Bei Nextcloud kann man auch App-Passwörter erstellen, die sind dann (glaube ich) ohne Sonderzeichen und dann brauchst du keinen zusätzlichen Benutzer.

Ja, wäre auch eine Option.
Aber ich lasse das jetzt mit dem separaten User und nutze Gruppenordner, damit ich auch mit meinem eigenen User auf die Backups zugreifen kann.
Hat zusätzlich den Vorteil, daß der FHEM-Zugriff von meinem User getrennt ist und ich mit den Zugriffsrechten flexibler bin.