Nächtliche Sicherung der Haussteuerung auf ein Netzlaufwerk
Nachdem ich meine Hausautomatisierung FHEM seit ziemlich genau drei Jahren auf einem Raspberry Pi der ersten Generation laufen hatte, fing das System plötzlich an, komische Dinge zu machen. Manchmal funktionierte beim Restart ein Hilfsmodul nicht mehr, und irgendwann wurde die zentrale Konfigurationsdatei fhem.cfg beim Speichern zerstört. Nächtliche Sicherungen hatte ich noch nicht eingerichtet.
Meine letzte manuelle Sicherung lag Monate zurück, und ausgerechnet in diesem Zeitraum hatte ich umfangreiche Umbauarbeiten an meiner Hausautomatisierung vorgenommen.
Was war passiert? Die am meisten beanspruchte Komponente eines Raspberry Pi ist die Speicherkarte. Nachdem der Raspberry die Speicherkarte wie eine Festplatte benutzt, passieren alle Lese- und Schreibvorgänge auf der Speicherkarte. Ausserdem schreibt die Haussteuerung auch ständig in Logfiles. Irgendwann ist der Lebenszyklus einer Speicherkarte erreicht und sie muss ausgetauscht werden.
Welche Hardware für die Sicherung?
In der Standardkonfiguration erstellt FHEM im Unterverzeichnis /backup eine Sicherung in Form eines Archivfiles. Dementsprechend wird das Archivfile ebenso unzugänglich, wenn die Speicherkarte seinen Dienst quittiert. Folglich sollte das Backup auf einer externen Hardware erfolgen.
Man könnte natürlich an den Raspberry eine kleine externe USB-Festplatte hängen, nur würde diese am Raspberry ständig laufen. Die besser Wahl ist hier ein NAS (network attached storage). Diese Geräte sind meistens ausfallsicher konfiguriert und haben ein Powermanagement, bei dem sich das Gerät bei Nichtbenutzung in standby abschaltet.
Hardwareempfehlung
Grundsätzlich funktioniert jedes NAS ähnlich. Aufgrund der weiten Verbreitung und der guten Verfügbarkeit von Softwarepaketen und deren einfachen Wartbarkeit habe ich mich für eine Synology entschieden. Ferner sollte es ein Modell sein, das mindestens zwei Festplatten beinhaltet und das System als RAID-1 oder SHR (Synology Hybrid RAID) konfiguriert sein.
Ich habe mich für folgendes NAS entschieden:
Ferner betreibe ich das NAS mit zwei NAS Festplatten:
Wichtig ist in diesem Zusammenhang, spezielle Festplatten zu wählen, die sowohl für den Dauereinsatz geeignet sind als auch eine geringe Geräuschentwicklung aufweisen.
Vorbereitung des NAS
Zuerst legen wir in der Systemsteuerung des Synology ein neues Verzeichnis fhembackup an. Dazu klicken wir in der Systemsteuerung auf „Gemeinsamer Ordner“ tragen Name und Beschreibung ein und klicken auf OK
und tragen in den Berechtigungen den admin und die entsprechenden Benutzer mit Lese/Schreiben-Recht ein.
Danach wechseln wir auf den Reiter „NFS-Berechtigungen„. Wenn dort die Meldung kommt, dass der NFS-Dienst nicht aktiviert sei, müssen wir uns zuerst darum kümmern.
Dazu gehen wir in der Systemsteuerung in den Reiter „Dateidienste“ und scrollen dort unter „Win/Mac/NFS“ ganz nach unten und setzen den Haken bei „NFS aktivieren“
Weiters kehren wir zurück zum neu angelegten Ordner fhembackup und tragen unter NFS-Berechtigungen den IP-Namen und/oder IP-Adresse unseres Raspberry Pi ein.
Ich habe hier zwei bis auf den Namen identische Einträge für den Raspberry Pi erstellt, da es manchmal nach dem Booten einer der beiden Komponenten Timingprobleme gab und der Raspberry Pi nicht unter seinem IP-Namen, sondern nur unter seiner IP-Adresse bekannt war.
Mit diesen Einstellungen können wir nun das neu angelegte Verzeichnis per NFS-Zugriff direkt vom Raspberry Pi verbinden. Somit ist das NAS für die nächtliche Sicherung vorbereitet.
Vorbereitung des Raspberry Pi
Zuerst müssen am Raspberry Pi einige Pakete nachinstalliert werden, sofern noch nicht geschehen.
sudo apt-get install autofs sudo apt-get install autofs5
Weiters sollten wir uns überlegen, wo wir das Netzwerkverzeichnis des Synology NAS in das Filesystem einhängen. Ich habe mich entschieden, im Verzeichnis /mnt einen Unterordner syno anzulegen und das Netzwerkverzeichnis fhembackup dorthin zu mounten.
Dafür erstellen wir mit
sudo mkdir /mnt/syno sudo chmod 777 /mnt/syno
das Unterverzeichnis /mnt/syno und sorgen dafür, dass es für jeden Benutzer erst einmal erreichbar wird. Zumal läuft unsere Hausautomatisierungssoftware FHEM unter dem User fhem, und dieser muss natürlich das Recht erhalten, seine nächtliche Sicherung auf dem Netzlaufwerk vorzunehmen. Weiter müssen wir noch eine Konfigurationsdatei für den eben installierten Automounter erzeugen und zur Verfügung stellen. Dazu legen wir in /etc ein Verzeichnis autofs
sudo mkdir /etc/autofs
an und erzeugen eine neue Konfigurationsdatei auto.synology in diesem Verzeichnis und editieren diese mit sudo nano /etc/autofs/auto.synology wie folgt:
fhembackup -fstype=nfs,rw,nouser,atime,auto,dev,exec,suid spock:/volume1/fhembackup
Mein NAS heißt spock, dementsprechend bitte hier den richtigen Namen eintragen!
Weiterhin müssen wir jetzt noch in der Datei /etc/auto.master den Pfad angeben, in dem wir ganz unten in der Datei mithilfe von sudo nano /etc/auto.master folgende Zeile anfügen:
/mnt/syno /etc/autofs/auto.synology --ghost, --timeout=60
Nun wäre die Konfiguration bereits abgeschlossen und wir müssen eigentlich nur noch den Automounter neu starten. Dies machen wir mit beiden Kommandos
sudo service autofs restart sudo service rpcbind restart
Folglich sollten wir schon auf das Sicherungsverzeichnis auf dem NAS zugreifen können:
Bei dem einzigen Eintrag, dem Verzeichnis @eaDir handelt es sich um ein internes Verzeichnis, welches das NAS für die Verwaltung benutzt. Dieses müssen wir später bei unserem Backupalgorithmus ausschließen. Falls es aber wie hier zu sehen ist, haben wir alles richtig gemacht, auf einige NAS wird dieses Verwaltungsverzeichnis allerdings nicht dargestellt.
Nächtliche Sicherung von FHEM
Nun müssen wir in FHEM nur noch ein paar Einträge vornehmen, um die nächtliche Sicherung auf das Netzlaufwerk auf dem NAS vorzunehmen. Dazu öffnen wir die zentralen Konfigurationsdatei fhem.cfg und fügen am Ende folgende Zeilen ein.
define SYS_Backup dummy
attr SYS_Backup alias FHEM Backup ausführen
attr SYS_Backup room System
attr SYS_Backup webCmd Ausführen
define SYS_last_Backup_date dummy
attr SYS_last_Backup_date alias letztes FHEM Backup Datum
attr SYS_last_Backup_date room System
define SYS_last_Backup_size dummy
attr SYS_last_Backup_size alias letztes FHEM Backup Größe
attr SYS_last_Backup_size room System
define SYS_BackupRun notify SYS_Backup:* {\
fhem("backup");;\
sleep(5);;\
while(my $psoutput = `ps -ef | grep -v grep | grep FHEM | grep tar`) {\
sleep(10);;\
}\
opendir DIR, "./backup" or die $!;;\
my @mybackups = ();;\
my $lastbackupdatedatum = "";;\
my $lastbackupdatesize = "";;\
my %lastbackupsize;;\
my %lastbackuptime;;\
while(my $file = readdir DIR){ \
next if($file eq "." || $file eq "..");;\
push(@mybackups,$file);;\
}\
closedir DIR;;\
foreach my $file (sort @mybackups) {\
my $longfile = "./backup/".$file;;\
my $destination = "/mnt/syno/fhembackup/";;\
`sudo mv $longfile $destination`;;\
}\
opendir DIR, "/mnt/syno/fhembackup" or die $!;;\
@mybackups =();;\
while(my $file = readdir DIR){ \
next if($file eq "." || $file eq ".." || $file eq "\@eaDir");;\
my $mybackupfile = "/mnt/syno/fhembackup/".$file;;\
push(@mybackups,$file);;\
$lastbackuptime{$mybackupfile} = (stat($mybackupfile))[9];;\
$lastbackupsize{$mybackupfile} = (stat($mybackupfile))[7];;\
}\
closedir DIR;;\
@mybackups = sort { eval($lastbackuptime{$a}) <=> eval($lastbackuptime{$b}) } (@mybackups);;\
if($#mybackups > 0) {\
my $mybackupfile = "/mnt/syno/fhembackup/".$mybackups[$#mybackups];;\
my ($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst)=localtime($lastbackuptime{$mybackupfile});;\
$year += 1900;;\
$mon += 1;;\
$lastbackupdatedatum = sprintf("%02d.%02d.%04d %02d:%02d:%02d",$mday,$mon,$year,$hour,$min,$sec);;\
$lastbackupdatesize = $lastbackupsize{$mybackupfile}." Bytes";;\
$mybackups[$#mybackups] = "<b>".$mybackups[$#mybackups]."</b>";;\
} else {\
$lastbackupdatedatum = "kein Backup gefunden";;\
$lastbackupdatesize = "kein Backup gefunden";;\
}\
@mybackups = join("</br>", @mybackups );;\
fhem("set SYS_Backup @mybackups");;\
fhem("set SYS_last_Backup_date $lastbackupdatedatum");;\
fhem("set SYS_last_Backup_size $lastbackupdatesize");;\
}
attr SYS_BackupRun room System
define job_BackupRun at *23:15:00 set SYS_Backup Ausführen
attr job_BackupRun room System
In meinem Beispiel läuft die nächtliche Sicherung um 23:15 Uhr. Man sollte nur sicherstellen, dass das NAS so konfiguriert ist, dass es nicht zu dieser Zeit heruntergefahren ist.
Überprüfung der Sicherungen
Um zu sehen, ob die nächtliche Sicherung auch geklappt hat, ist es mit unserer Konfiguration in FHEM direkt möglich, nachzusehen, welche Sicherungen in unserem Netzlaufwerk auf dem NAS vorhanden sind. Diese werden als nach Datum der Erstellung sortierte Liste im Attribut SYS_Backup direkt ausgegeben:
Des Weiteren wird das Datum und die Größe des letzten Backups, das darüber in der Liste fett markiert ist in zwei weiteren Attributen gespeichert. In diesem Zusammenhang auch ein Dankeschön für die Anregung von Jörg, die ich gleich mit aufgenommen habe!
Mit Klick auf „Ausführen“ kann das Backup auch manuell durchgeführt werden, ansonsten erfolgt es täglich um 23:15 Uhr
Anzahl der Backups begrenzen
Damit die Anzahl der Sicherungen nicht übermässig ansteigt, sollten wir dafür sorgen, dass die ältesten Backups regelmässig gelöscht werden. Hierfür würde ich empfehlen, dies nicht auch noch in das oben vorgestellte Skript zu implementieren, sondern hierfür ein eigenes Programm regelmässig über die crontab aufzurufen. Dies klappt mit folgendem Skript, das wir delete_fhembackup.pl nennen und einfach im Hauptverzeichnis des Users pi erstellen.
#!/usr/bin/perl
$keeplatest = 10;
opendir DIR, "/mnt/syno/fhembackup" or die $!;
@mybackups =();
while(my $file = readdir DIR){
next if($file eq "." || $file eq ".." || $file eq "\@eaDir" || $file eq ".DS_Store");
my $mybackupfile = "/mnt/syno/fhembackup/".$file;
push(@mybackups,$file);
}
closedir DIR;
@mybackups = sort @mybackups;
if($#mybackups <= $keeplatest) {
exit;
}
for($i = 0;$i <= $#mybackups - $keeplatest; $i++) {
$mybackupfile = "/mnt/syno/fhembackup/".$mybackups[$i];
print "lösche ".$mybackupfile."\n";
unlink $mybackupfile;
}
Danach machen wir mitchmod +x delete_fhembackup.pl das Skript ausführbar und erstellen in der crontab mit dem Befehl crontab -e folgende Zeile:
15 0 * * * /home/pi/delete_fhembackup.pl
Nun wird täglich um 0:15 Uhr die Anzahl der Backups auf die letzten 10 (siehe Variable $keeplatest) begrenzt und die älteren gelöscht.
Energiesparmaßnahmen an der NAS
Normalerweise benötige ich mein NAS nachts nicht. Deswegen gibt es die Möglichkeit, in der Systemsteuerung einzustellen, wann es sich abends/nachts herunterfährt und ab wann wir wieder darauf zugreifen müssen.
Dazu geht man in der Systemsteuerung der Synology auf das Icon für „Hardware & Energie“ und wählt den Reiter „Energie-Zeitplan„. Dieser ist bei mir so eingestellt, dass mein NAS täglich um 06:15 hochfährt und um 23:59 Uhr heruntergefahren wird.
Zuletzt aktualisiert am 24.02.2019.
Hallo,
klasse Anleitung und Ergänzung zum FHEM WIKI.
Wäre es noch möglich, zusätzliche Infos in ein dummy zu schreiben.
z.B. Größe des BackupFiles
Datum/Uhrzeit der letzten Sicherung
Grüße
Jörg
Hallo,
danke für die Anregung! Ich werde das aufgreifen und nächste Woche dahin gehend ein wenig erweitern.
Gruß Martin
Hallo,
ich habe die Anregung aufgenommen und speichere nun noch Größe und Datum/Uhrzeit der letzten Sicherung jeweils in einem Dummy weg. Die Liste der vorhanden Files in dem Backupverzeichnis wird hierzu nochmal nach Erstellungsdatum sortiert und das neueste Backup markiert sowie die genannten Zusatzdaten ausgegeben.
Hallo,
obwohl ich mich an deine Anleitung gehalten habe, erhalte ich folgende Fehlermeldung:
SYS_BackupRun return value: Keine Berechtigung at (eval 2658) line 19
Auch fehlt bei mir der Eintrag @eaDir in der fhembackup Datei. Wo könnte der Fehler liegen?
Hallo,
die Zeile 19 bezieht sich auf das Öffnen des Verzeichnis, das unter /mnt/syno/fhembackup gemounted sein sollte. Was passiert denn, wenn Du ls -al /mnt/syno/ ausführst? Da sollte etwas kommen wie:
insgesamt 4
drwxr-xr-x 3 root root 0 Feb 21 18:19 .
drwxr-xr-x 3 root root 4096 Feb 18 14:49 ..
dr-xr-xr-x 2 root root 0 Feb 21 18:19 fhembackup
Wenn nicht, dann ist das Mounten des Verzeichnisses der NAS fehlgeschlagen. Die @eaDir muss es nicht immer geben. Wir schließen diese bei der Selektion nur aus.
Sobald das Verzeichnis fhembackup zu sehen ist, mal ausprobieren, ob das Verzeichnis aussieht so wie:
pi@fhem:~ $ ls -al /mnt/syno/fhembackup/
insgesamt 4947888
drwxrwxrwx 3 root root 4096 Mär 21 23:18 .
drwxr-xr-x 3 root root 0 Feb 21 18:19 ..
Im Zweifelsfalle beim Thema autofs suchen, es scheint hier einfach das Anmelden per NFS nicht zu klappen…
Gruß
Martin
Vielen Dank Martin für Antwort,
mit showmount kann ich das Backupverzeichnis auf meiner Synology sehen. Die Berechtigungen müssten doch dann ok sein?!
Ich aber jetzt aber gesehen, dass die Sicherung bei Ablauf von SYS_BackupRun bei mir immer in den Pfad /opt/fhem/backup/ gespeichert wird. Dieses Backup kann ich dann aber mit Putty auf meine Synology in das entsprechende Verzeichnis (/mnt/syno/fhembackup/) kopieren.
Hast du noch eine Idee was ich falsch gemacht habe?
Deinen Eintrag habe ich ohne Änderung in fhem.cfg kopiert.
Grüße
Hallo,
das hört sich nach einem Berechtigungsproblem für den User fhem an. Wenn Du alles manuell machen kannst – ich nehme an, Du arbeitest mit dem User pi auf dem putty – dann kann der einzige Grund der sein, dass der User fhem, unter dem FHEM läuft, keine Berechtigung hat, in das Verzeichnis /mnt/syno/fhembackup zu schreiben. Was sagt denn das fhem-Log? Normalerweise müsste dort SYS_BackupRun auftauchen und dann eine Fehlermeldung, wenn FHEM nicht schreiben kann.
Melde Dich doch mal mit
su fhem –
als User fhem an. Wenn das nicht klappt, musst Du dem User fhem erst mal eine Shell (bash) zuordnen. Das kannst Du als sudoer in der /etc/passwd machen, indem Du den Eintrag in etwa so änderst:
fhem:x:999:20::/opt/fhem:/bin/bash
Entscheidend ist hinten die Shell. Dann setzt Du noch ein passwd für den User und meldest Dich über su fhem – an.
Dann probierst Du mal ls -al /mnt/syno/fhembackup.
Ich nehme an, hier fehlen dann Berechtigungen für den User fhem. Sag mir einfach, wenn Du hier nicht weiterkommst.
Gruß
Martin
Also,
user fhem ist jetzt eingerichtet und mit password versehen.
Wenn ich dann „ls -al /mnt/syno/fhembackup“ eingebe, erhalte ich die Meldung: „Öffnen von Verzeichnis /mnt/syno/fhembackup nicht möglich: Keine Berechtigung“
Im fhem-log taucht diese Meldung auf: „SYS_BackupRun return value: Keine Berechtigung at (eval 38191) line 19“
Vielen Dank für Deine Hilfe.
Martin F.
Hallo,
da fehlt noch die Berechtigung auf dem Verzeichnis /mnt/syno/fhembackup
Führe mal als User pi den Befehl aus:
sudo chmod go+rwx /mnt/syno/fhembackup
Danach melde Dich nochmal als user fhem an und probiere den ls -al /mnt/syno/fhembackup erneut aus.
Gruß
Martin
Jau, jetzt hat es geklappt.
Tausend Dank.
Hallo Martin,
ich habe mich ebenfalls an Deine Anleitung gehalten, um auf meiner Synology regelmäßig Backups meiner FHEM-Installation zu machen.
Leider bekomme ich nach
ls -al /mnt/syno/fhembackup
die Meldung ls: cannot open directory /mnt/syno/fhembackup: No such file or directory.
Allerdings sehe ich auch mit Filezilla z.B. das Verzeichnis „/mnt/syno/fhembackup“. Aber auch Filezilla gibt als Meldung aus, wenn ich versuche den Inhalt des Ordners „fhembackup“ anzuzeigen bzw. in das Verzeichnis zu springen
Fehler: Directory /mnt/syno/fhembackup: no such file or directory
Fehler: Verzeichnisinhalt konnte nicht empfangen werden.
Was mache ich falsch?
Hallo Thomas,
als welcher Benutzer fragst Du per
ls -al /mnt/syno/fhembackup
ab?
Als User pi solltest Du normalerweise das Verzeichnis sehen können. Wahrscheinlich ist es nicht gemountet.
Wechsle mal in das Verzeichnis per
cd /mnt/syno
und liste mal dort den Inhalt auf.
ls -al
Was kommt nun? Wenn nur
drwxr-xr-x 3 root root 0 Mai 1 19:54 .
drwxr-xr-x 3 root root 4096 Feb 18 14:49 ..
aufgelistet wird, dann ist das Verzeichnis fhembackup definitiv nicht gemountet.
Hier musst Du erst mal beim Automounter ansetzen.
Hast Du in der Synology zwei Einträge gemacht – einen über den DNS-Namen im fritz.box-Namensraum und über die IP-Adresse?
Wenn ja, dann müssen wir mal sehen, warum der Automounter das NFS-Verzeichnis der Synology nicht mounten kann….
Gibt es eine Fehlermeldung in /var/log/messages ?
Gruß
Martin
Hallo Martin, danke super Anleitung.
Eine Frage: Bei Sys_Backup (dummy) stehen nun alle vorhandenen Backups. Das sieht etwas unschön aus, bei mehr als 10. Kann man das nicht unterbinden? Diese stehen auch unter Readings. Oder stimmt da was nicht bei mir?
Hallo Torsten,
da hast Du Recht. Bei mehr als 10 sieht das unschön aus. Ich würde das aber nicht im Rahmen des Skripts machen, sondern ich würde hierfür in der crontab eher ein Löschskript erstellen und dies täglich laufen lassen.
Ich würde das ungern auch noch in das Skript packen, denn während des Skripts sind alle Reaktionen der Haussteuerung verzögert. Wenn wir das als eigenes Skript machen, kann das im Hintergrund als eigener Task laufen.
Vielleicht erstelle ich zum Wochenende schnell ein Perl-Skript, das ich dann hier poste. Ist kein großes Problem.
Mein Ansatz wäre folgender: Das Skript holt sich ebenfalls den Inhalt des Verzeichnisses und löscht alle Backups, die über eine Anzahl hinausgehen, angefangen von den ältesten.
Ich melde mich
Gruß
Martin
Hallo Torsten,
ich habe jetzt den Beitrag direkt um Deine Idee erweitert.
Gruß
Martin
Super! Klasse Idee, ja so dachte ich mir das, die letzten 3 Backups meinetwegen drin lassen. Kann sich ja jeder einstellen dann.
Daumen hoch, Martin!
Hab es mal getestet, soweit klappt das auch. Nur bei eingestellten: $keeplatest = 3;
(5 Backups waren vorhanden), löscht er nicht 2 sondern nur einen und auch dann nicht den ältesten. Da muss du nochmal gucken.
Hallo Torsten,
sorry, war jetzt einige Tage auf Dienstreise. Das Skript hatte einen Tippfehler. Die For-Schleife soll bei $i=0 zum Zählen anfangen, denn in Perl fängt man beim Array ja bei 0 und nicht bei 1 zu zählen an. Somit hat er immer das älteste File stehen gelassen.
Bei mir hat es geklappt. Probier doch nochmal….
Gruß
Martin
Hallo Martin,
perfekt nun funktioniert es!
Habe nun wieder das Problem mit:
pi@Raspi-FHEM-Server:~ $ showmount
clnt_create: RPC: Program not registered
Dadurch wird delete_fhembackup.pl nicht korrekt mit cronjob ausgeführt. Bei meinen anderen Raspi hatte ich das auch mal, hatte ich gelöst weiß nur nicht mehr wie … 🙂
Hi Torsten,
der showmount bringt bei mir auch dieselbe Meldung. Das liegt m.E. an dem Automounter. Trotzdem kann ich aber das Verzeichnis ansprechen. Mach mal einfach ein
ls /mnt/syno/fhembackup/
Dann sollte durch den Zugriff das Verzeichnis gemountet werden, falls es noch nicht gemountet ist. Ich hatte auch mal das Problem, dann hatte ich die NAS mit
sudo service autofs restart
sudo service rpcbind restart
gelöst.
Sollte es danach immer funktionieren, dann kannst Du ja auch in der crontab die beiden Aktionen vor der Sicherung und Ausführung der Löschung der überflüssigen Backups einplanen.
Gruß
Martin
Hallo Martin,
Ja mit:
sudo service autofs restart
sudo service rpcbind restart
hatte ich das beim anderen Raspi auch immer gelöst. Jaja mounten tut er korrekt, manuell mit
perl delete_fhembackup.pl funktioniert nun auch alles und er lässt die letzen 3 Backups in mnt/syno/fhembackup stehen. Auf dem NAS auch alles ok.
Nur die Automatisierung über crontab -e will nicht funzen. 🙁
Hallo Torsten,
poste doch mal Deine crontab. Das kannst Du mit
crontab -l
machen.
Die Kommentarzeilen kannst Du weglassen (alle Zeilen, die vorne mit # beginnen)
Zeig mir mal, wie die crontab aussieht. Oftmals steckt der Teufel im Detail….
Gruß
Martin
Hallo Martin,
hier die crontab Einträge:
@reboot ntpdate -s 0.de.pool.ntp.org
0 */6 * * * ntpdate -s 0.de.pool.ntp.org
00 03 * * 0 /usr/local/bin/raspiBackupWrapper.sh > /dev/null 2>&1
0 15 * * * /home/pi/delete_fhembackup.pl
root@Raspi-FHEM-Server:~#
Danke für die Anleitung.
Leider läuft es bei mir noch nicht.
Ich habe alles genau nach deiner Anleitung gemacht(auch die Kommentare angesehen)
das Backup wird aber nicht auf den „fhembackup“ NAS Ordner geschrieben sondern unter opt/fhem/backup
Irgendwie passt da was mit den Berechtigungen nicht.
———————————————————————–
pi@raspberrypi3:~ $ ls -al /mnt/syno/
insgesamt 4
drwxr-xr-x 3 root root 0 Nov 9 16:00 .
drwxr-xr-x 4 root root 4096 Nov 9 14:13 ..
drwxrwxrwx 1 root root 12 Nov 9 15:46 fhembackup
————————————————————————–
bei:
pi@raspberrypi3:~ $ ls -al /mnt/syno/fhembackup/
ls: Zugriff auf /mnt/syno/fhembackup/ nicht möglich: Datei oder Verzeichnis nicht gefunden
——————————————————————
wenn ich jetzt ein:
sudo service autofs restart
sudo service rpcbind restart
ausführe komme ich drauf > siehe:
———————————————————————-
pi@raspberrypi3:~ $ ls -al /mnt/syno/fhembackup/
insgesamt 0
drwxrwxrwx 1 root root 12 Nov 9 15:46 .
drwxr-xr-x 3 root root 0 Nov 9 16:00 ..
————————————————————————-
nach einem „sudo shutdown -r 0“ geht es dann wieder nicht.
(das gleiche sehe ich, wenn ich per FTP auf den Ordner „fhembackup“ zugreifen möchte.
nach „autofs / rpcbind restart“ hat der Ordner 777 Rechte und ich an ihn anklicken
Aber nach einem „sudo shutdown -r 0“ vom Pi komme ich nicht mehr drauf da die Rechte auf 555 stehen.
Es ist aber egal ob „sudo shutdown -r 0“ oder nicht das backup wird immer auf die SD geschrieben
Danke im voraus
Hallo,
Hier scheint etwas mit dem Mounten des NAS nicht richtig zu funktionieren. Ich kann aber momentan nicht auf mein Raspberry zugreifen, da ich mich momentan dienstlich in den USA befinde. Vielleicht kann ich am Wochenende einmal Remote auf meinen Raspberry zugreifen. Vielleicht kann ich am Wochenende einmal Remote auf meinen Raspberry zugreifen.
eines aber schon mal vorweg:hier klappt definitiv nur das mounten des NAS nicht. Vielleicht mal in /var/log/messages nachsehen, was hier autofs macht.
Gruß aus South Carolina
Martin
Hallo,
bin mittlerweile wieder zurück aus den USA. Habe eben mal auf meiner Synology nachgesehen, wie denn hier die Einstellungen sind.
Ich bin mir nicht sicher, ob nach dem Restarten von autofs und rpcbind wirklich eine Datei geschrieben werden kann.
Vielleicht mal vom Pi aus dann in das Verzeichnis mit
cd /mnt/syno/fhembackup
wechseln und dort mit
touch test.txt
eine Datei namens test.txt erstellen. Diese leere Datei sollte sich dort erstellen lassen.
Funktioniert das, dann würden sich der Pi und die Synology schon mal „verstehen“, es kann also nicht an der Konfiguration in der NAS liegen.
Die Zugriffsrechte wären schon ok, so wie sie sind, das sieht bei mir nicht anders aus:
pi@fhem:/mnt/syno/fhembackup $ ls -al
insgesamt 50844108
drwxrwxrwx 4 root root 4096 Nov 25 14:09 .
drwxr-xr-x 3 root root 0 Sep 19 20:16 ..
-rwxrwxrwx 1 1026 users 6148 Okt 13 16:59 .DS_Store
-rw-r–r– 1 fhem dialout 576892463 Nov 18 23:25 FHEM-20171118_231500.tar.gz
-rw-r–r– 1 fhem dialout 940410783 Nov 19 23:27 FHEM-20171119_231500.tar.gz
-rw-r–r– 1 fhem dialout 687512865 Nov 20 23:25 FHEM-20171120_231500.tar.gz
-rw-r–r– 1 fhem dialout 576798299 Nov 21 23:24 FHEM-20171121_231500.tar.gz
-rw-r–r– 1 fhem dialout 475027768 Nov 22 23:23 FHEM-20171122_231500.tar.gz
-rw-r–r– 1 fhem dialout 492882539 Nov 23 23:23 FHEM-20171123_231500.tar.gz
-rw-r–r– 1 fhem dialout 520009227 Nov 24 23:24 FHEM-20171124_231500.tar.gz
-rw-r–r– 1 fhem dialout 15931539456 Jul 1 10:06 raspi3-20170701.img
-rw-r–r– 1 fhem dialout 15931539456 Jul 16 12:06 raspi3-20170716-1105.img
-rw-r–r– 1 fhem dialout 15931539456 Jul 26 18:37 raspi3-20170726-1651.img
Nun sollte sich nach dem touch die Datei namens test.txt dort drin befinden.
Dass das Backup zunächst auf die SD geschrieben wird, ist ok, von dort aus wird es erst aufs NAS kopiert. Wenn der Pi aber nicht hinkommt, bricht das Kopieren ab.
Dazu sollte im fhem.log auch eine entsprechende Meldung drin sein. Mal vielleicht da drin die Meldungen ansehen.
Grundsätzlich vermute ich aber ein Problem beim autofs.
Hier nochmal der Inhalt meiner
/etc/autofs/auto.synology:
fhembackup -fstype=nfs,rw,nouser,atime,auto,dev,exec,suid scotty:/volume1/fhembackup
Und die entscheidenden Zeilen meiner auto.master:
+auto.master
/mnt/syno /etc/autofs/auto.synology –ghost, –timeout=60
Hope, this helps….
Grüße
Martin
Hallo Martin,
bei mir funktioniert zur Zeit auch nicht mehr deine Funktion. Muss mal sehen woran das liegen kann.
Sehe nur gerade:
/mnt/syno /etc/autofs/auto.synology –ghost, –timeout=60
Dort stande früher ja immer –timeout=600 ! Ist das nun ein Schreibfehler von dir , oder hast du das Timeout tatsächlich reduziert?
Hallo,
nein, kein Schreibfehler, meine aktuelle auto.master beinhaltet folgende Zeile:
/mnt/syno /etc/autofs/auto.synology –ghost, –timeout=60
Hab ich das mal verändert? Ein kürzerer Timeout macht aber durchaus Sinn, da 600 s = 10 min relativ lange sind für den Timeout.
Gruß
Martin
So, lt. Log kann nicht mehr mit mv verschoben werden. Früher ging das immer.
2017.12.15 19:32:01 3: backup : Started the backup in the background, watch the log for details
mv: reguläre Datei „/mnt/syno/fhembackup/FHEM-20171215_184237.tar.gz“ kann nicht angelegt werden: Die Operation ist nicht erlaubt
FHEM ist uptodate, muss da etwas am Script angepasst werden? Funktioniert das bei Dir?
Offensichtlich hat der User fhem kein Recht mehr, die Datei auf /mnt/syno/fhembackup zu verschieben.
Wurde der User fhem, unter dem FHEM läuft aus einer Gruppe genommen oder wurden die Rechte auf o.g. Verzeichnis verändert?
Kannst Du auf das Verzeichnis über die Shell zugreifen und dorthin wechseln?
Dorthin wechseln sollte jeder dürfen, sowohl der User pi als auch der User fhem.
Das Verzeichnis /mnt/syno/fhembackup hat bei mir folgende Einstellungen:
dr-xr-xr-x 2 root root 0 Sep 19 20:16 fhembackup
Mein Verzeichnis sieht dann wie folgt aus:
drwxrwxrwx 5 root root 4096 Dez 14 23:15 .
drwxr-xr-x 3 root root 0 Sep 19 20:16 ..
-rwxrwxrwx 1 1026 users 6148 Okt 13 16:59 .DS_Store
-rw-r–r– 1 fhem dialout 456434652 Dez 10 23:22 FHEM-20171210_231500.tar.gz
-rw-r–r– 1 fhem dialout 78823424 Dez 11 23:16 FHEM-20171211_231500.tar.gz
-rw-r–r– 1 fhem dialout 131072 Dez 12 23:15 FHEM-20171212_231500.tar.gz
-rw-r–r– 1 fhem dialout 65536 Dez 13 23:15 FHEM-20171213_231500.tar.gz
-rw-r–r– 1 fhem dialout 65536 Dez 14 23:15 FHEM-20171214_231500.tar.gz
Ich habe daran eigentlich nie etwas verändert, auf einmal geht es nicht mehr.
Per Shell komme ich drauf und gemountet wird auch korrekt.
root@Raspi-FHEM-Server:~# cd /mnt/syno/fhembackup
root@Raspi-FHEM-Server:/mnt/syno/fhembackup# ls
test.txt
root@Raspi-FHEM-Server:/mnt/syno/fhembackup# ls -la
insgesamt 8
drwxrwxrwx 3 root root 4096 Dez 15 19:54 .
drwxr-xr-x 3 root root 0 Dez 15 19:03 ..
-rwxrwxrwx 1 root root 0 Dez 15 19:18 test.txt
Was heißt den der FHEM User ? Auf dem NAS gibt es den Benutzer „fhem“ mit Schreibrechten. So wie auch in der Anleitung …
Übrigens, siehe deine Anleitung oben mit dem Timeout in der auto.master, dort steht ja 600 !
Ich habe keine Ahnung, warum das Backup-Script nicht mehr geht.
So, ich denke das FHEM da irgendwas angepasst hat. Die Warnung hatte ich nie:
2017.12.22 08:54:48 1: PERL WARNING: Useless use of a constant („mv $longfile $destination“) in void context at (eval 15493) line 17.
Hallo,
das ist in der Tat komisch. Wenn in „mv $longfile $destination“ etwas als Konstante interpretiert wird, dann stimmt hier etwas nicht. Schau mal bitte, ob die Backticks vor dem mv $longfile $destination noch da sind. Ohne die kann die Shell-Operation für das Verschieben mit „mv“ nicht durchgeführt werden.
Wenn die Backticks („) da sind, dann müssen wir weitersuchen.
Gruß
Martin
Guten Abend Martin,
auch ich bedanke mich für das tolle Script.
Grundsätzlich funktioniert es gut, d.h. die Verbindung zum NAS wird aufgebaut, das Backup erstellt und auch erfolgreich auf der Synology abgelegt.
Allerdings ist funktioniert die Sortierung in der Liste der vorhandenen Backups auf der FHEM-Seite (Raum „System“) nicht. Es werden dort zwar alle Backups aufgelistet, aber in einer falschen Reihenfolge.
Im Logfile des FHEM finde ich nach dem Backup-Lauf folgende Fehlermeldung:
2018.01.15 23:53:30 1: PERL WARNING: Use of uninitialized value in numeric comparison () at (eval 809852) line 29.
2018.01.15 23:53:30 3: eval: my $SELF=’SYS_BackupRun‘;my $TYPE=’dummy‘;my $EVTPART0=’Ausführen‘;my $NAME=’SYS_Backup‘;my $EVENT=’Ausführen‘;{
fhem(„backup“);
opendir DIR, „./backup“ or die $!;
my @mybackups = ();
…. (es wird dann im Logfile der komplette Code des Scripts ausgegeben).
Den einzigen numerischen Vergleichsoperator findet man im Code ja bei der „sort“-Funktion:
@mybackups = sort { eval($lastbackuptime{$a}) eval($lastbackuptime{$b}) } (@mybackups);
Hast Du vielleicht eine Idee, warum sich FHEM über eine nicht initialisierte Variable / Konstante beschwert?
Einen Kopierfehler des Scripts kann ich ausschliessen. Habe es mehrfach geprüft und die restliche Funktion des Scripts ist ja auch einwandfrei gewährleistet.
Vielen Dank für den tollen Blog-Artikel!
Freundlicher Gruß,
Daniel
Hallo Daniel,
Danke für das freundliche Feedback. Es freut mich, wenn die Arbeit ankommt, die ich reinstecke 🙂
Aber zum Thema:
Hier scheitert anscheinend der numerische Vergleich. Hast Du auch das <=> in dem sort drin? In Deinem Post fehlen nämlich die 3 Zeichen.
Die Zeile muß heißen:
@mybackups = sort { eval($lastbackuptime{$a}) <=> eval($lastbackuptime{$b}) } (@mybackups);;\
Wenn das <=> allerdings drin ist, dann ist der stat-Befehl ins Leere gelaufen und hat die Zeit des letzten Backups nicht in den Hash %lastbackuptime gespeichert. Das würde den leeren Hash erklären.
Du kannst ja mal unter der Zeile
$lastbackuptime{$mybackupfile} = (stat($mybackupfile))[9];;\einfach einen Log 3 machen mit
Log 3, $mybackupfile."time=".$lastbackuptime{$mybackupfile};;\Dann im Log nachsehen, welche Zeit für das jeweilige File ausgelesen wurde. Ich nehme an, dass dann Hash leer war.
Sobald hier eine Zeit drin steht, sollte er auch sortieren können.
Gruß
Martin
Hallo,
erstmal ein Großes Lob und einen Großen Dank an deine Arbeit, eine wirklich sehr hilfreiche Anleitung die ich zu schätzen weiß.
Jedoch habe ich ein kleines Problem seit einigen Tagen.
Bisher lief bei mir alles bestens, bis vor einigen Tagen mein Raspberry abgestürzt war. Ich habe ihn neu gestartet (nicht in der Zeit als ein Backup lief) und seit dem Neustart geht es nicht mehr richtig.
Auf meinem NAS kommen zwar noch Backupdateien an, aber die sind alle zu klein (nur wenige kb) und immer unterschiedlich groß. Der Fhem Backup Ordner ist leer, auch wenn ich das Backup manuell starte kommt kein komplettes Backup an. Kannst du mir eventuell eine kleine Hilfestellung oder einen Tipp geben woran es liegen könnte?
Ich habe schon versucht einiges zu ändern oder neu zu starten, aber es ändert sich leider nichts an der Situation.
Danke.
Hallo,
wenn das Backup auch beim manuellen Starten unvollständig ist, dann ist wohl am Filesystem etwas kaputt.
Als erstes würde ich mal prüfen, ob auf dem Filesystem überhaupt noch genügend Platz ist. Es könnte ja auch theoretisch vollgelaufen sein.
sollte darüber Aufschluss geben.
Bei mir sehen die erste beiden Zeilen der Ausgabe so aus:
Dateisystem Größe Benutzt Verf. Verw% Eingehängt auf
/dev/root 15G 7,0G 6,9G 51% /
Auf der 16G-Karte sind noch 51% im root-Filesystem frei.
Wenn das nicht der Fall ist, dann mal das Filesystem checken.
Mit
wird beim nächsten Reboot das Filesystem des Raspberry Pi gecheckt.
Siehe dazu auch den Artikel
https://www.raspberrypi.org/forums/viewtopic.php?t=113669
Hier würde ich erst mal ansetzen.
Gruß
Martin
Hallo, ist glaube ich voll Okay so:
Dateisystem Größe Benutzt Verf. Verw% Eingehängt auf
/dev/root 29G 2,0G 26G 8% /
devtmpfs 426M 0 426M 0% /dev
tmpfs 430M 0 430M 0% /dev/shm
tmpfs 430M 44M 387M 11% /run
tmpfs 5,0M 4,0K 5,0M 1% /run/lock
tmpfs 430M 0 430M 0% /sys/fs/cgroup
/dev/mmcblk0p1 60M 23M 38M 38% /boot
//192.168.178.250/Volume_1 1,4T 1,3T 145G 90% /mnt/DLink
tmpfs 86M 4,0K 86M 1% /run/user/1000
Hallo,
ja, das sieht gut aus. Hast Du das Filesystem mal nach einem Reboot checken lassen? Wenn das nichts gebracht hat, dann würde mich mal interessieren, wie die Standard-Backup-Funktionalität von FHEM tut.
Wenn Du oben in der Statuszeile mal
backupaufrufst, was kommt nach Abschluss der Aktion im Verzeichnis /opt/fhem/backup an?
Das ist ja auch die erste Aktion im eingesetzten Notify-Skript, bevor es auf das NAS verschoben wird.
Wie groß ist das File? Wenn das schon zu klein ist, dann solltest Du mal im Log nachsehen, ob FHEM hier etwas angemeckert hat.
Ich hatte das beschriebene Phänomen mit zu kleinen oder leeren Files nur, als einmal die Speicherkarte den Geist aufgab. Seitdem verwende ich nur noch die Karten von Sandisk.
Gruß
Martin
Hallo, ich habe jetzt mal getestet und gleich über ftp die Entwicklung im Verzeichnis /opt/fhem/backup beobachtet.
Gebe ich in Statuszeile backup ein so kommt ein normales Backup raus.
Starte ich SYS_BackupRun so beendet er das Backup zu früh (ca. 3MB zu wenig) und kopiert mir eine 0Kb bis 15MB große Datei auf mein NAS und dann beendet er alles und behält die erzeugte Backup-Datei im /opt/fhem/backup Verzeichnis .
Wie genau kann ich mir das log ansehen?
Danke für die Hilfe.
Hallo,
das ist ja in der Tat sehr komisch. Mir ist im Augenblick schleierhaft, welcher Teil meines Skripts da nicht funktioniert.
Das gehen wir jetzt mal schrittweise an. Zuerst würde ich Dir mal raten, das in /opt/fhem/backup erzeugte Backup mal manuell mit mv auf das NAS zu schieben, um zu sehen, ob es dort noch ganz ankommt.
Wenn das aber klappt, dann habe ich hier nur noch die Idee, das Skript einfach mal per Log-Ausgabe genauer zu betrachten.
Das Logfile findest Du im normalen FHEM Menü der Weboberfläche links unterhalb von Everything und oberhable von Commandref.
Hier mal das um Log-Ausgaben angereicherte Skript.
define SYS_Backup dummy
attr SYS_Backup alias FHEM Backup ausführen
attr SYS_Backup room System
attr SYS_Backup webCmd Ausführen
define SYS_last_Backup_date dummy
attr SYS_last_Backup_date alias letztes FHEM Backup Datum
attr SYS_last_Backup_date room System
define SYS_last_Backup_size dummy
attr SYS_last_Backup_size alias letztes FHEM Backup Größe
attr SYS_last_Backup_size room System
define SYS_BackupRun notify SYS_Backup:* {\
fhem("backup");;\
Log 3, "Backup erfolgreich";;\
opendir DIR, "./backup" or die $!;;\
my @mybackups = ();;\
my $lastbackupdatedatum = "";;\
my $lastbackupdatesize = "";;\
my %lastbackupsize;;\
my %lastbackuptime;;\
while(my $file = readdir DIR){ \
next if($file eq "." || $file eq "..");;\
push(@mybackups,$file);;\
Log 3, "lese $file in ./backup";;\
}\
closedir DIR;;\
foreach my $file (sort @mybackups) {\
my $longfile = "./backup/".$file;;\
my $destination = "/mnt/syno/fhembackup/";;\
`mv $longfile $destination`;;\
Log 3, "File $longfile verschoben nach $destination";;\
}\
opendir DIR, "/mnt/syno/fhembackup" or die $!;;\
@mybackups =();;\
while(my $file = readdir DIR){ \
next if($file eq "." || $file eq ".." || $file eq "\@eaDir");;\
my $mybackupfile = "/mnt/syno/fhembackup/".$file;;\
push(@mybackups,$file);;\
$lastbackuptime{$mybackupfile} = (stat($mybackupfile))[9];;\
$lastbackupsize{$mybackupfile} = (stat($mybackupfile))[7];;\
Log 3, "Daten von File $file gelesen";;\
}\
closedir DIR;;\
Log 3, "Backups vor Sortierung";;\
@mybackups = sort { eval($lastbackuptime{$a}) <=> eval($lastbackuptime{$b}) } (@mybackups);;\
Log 3, "Backups nach Sortierung";;\
if($#mybackups > 0) {\
my $mybackupfile = "/mnt/syno/fhembackup/".$mybackups[$#mybackups];;\
my ($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst)=localtime($lastbackuptime{$mybackupfile});;\
$year += 1900;;\
$mon += 1;;\
$lastbackupdatedatum = sprintf("%02d.%02d.%04d %02d:%02d:%02d",$mday,$mon,$year,$hour,$min,$sec);;\
$lastbackupdatesize = $lastbackupsize{$mybackupfile}." Bytes";;\
$mybackups[$#mybackups] = "".$mybackups[$#mybackups]."";;\
Log 3, "$lastbackupdatesize Bytes Groesse fuer letztes Backup ermittelt ";;\
} else {\
$lastbackupdatedatum = "kein Backup gefunden";;\
$lastbackupdatesize = "kein Backup gefunden";;\
Log 3, "$lastbackupdatesize";;\
}\
@mybackups = join("", @mybackups );;\
fhem("set SYS_Backup @mybackups");;\
fhem("set SYS_last_Backup_date $lastbackupdatedatum");;\
fhem("set SYS_last_Backup_size $lastbackupdatesize");;\
Log 3, "Backup Ausgabe erfolgt";;\
}
attr SYS_BackupRun room System
define job_BackupRun at *23:15:00 set SYS_Backup Ausführen
attr job_BackupRun room System
Probier das mal aus und sieh dann im Logfile nach.
Im log steht des immer:
PERL WARNING: Use of uninitialized value in eval „string“ at (eval 272038) line 29
Im log steht immer:
PERL WARNING: Use of uninitialized value in eval „string“ at (eval 272038) line 29.
eval: my $TYPE=’dummy‘;my $SELF=’SYS_BackupRun‘;my $EVTPART0=’on‘;my $NAME=’SYS_Backup‘;my $EVENT=’on‘;{
fhem(„backup“);
folgender Fehler kommt bei mv
mv: die Zeiten für „/mnt/DLink/fhembackup/FHEM-20180128_121931.tar.gz“ werden beibehalten: Die Operation ist nicht erlaubt
mv: Erhalten der Zugriffsrechte für „/mnt/DLink/fhembackup/FHEM-20180128_121931.tar.gz“: Die Operation ist nicht erlaubt
er kopiert nur einen kleinen Teil der Datei!
Ich habe keine Ahnung warum, naja…
Ha,
jetzt haben wir’s. Es geht um die Zugriffsrechte. Offensichtlich hat Dein user „fhem“ keine Schreibrechte auf dein Verzeichnis auf dem NAS.
Vielleicht hapert’s am Zugriffsrecht des gemounteten Verzeichnisses.
Bei mir ist das am Raspberry Pi so eingehängt:
pi@fhem:~ $ ls -al /mnt/syno/insgesamt 8
drwxr-xr-x 3 root root 0 Jan 26 11:34 .
drwxr-xr-x 3 root root 4096 Feb 18 2017 ..
drwxrwxrwx 5 root root 4096 Jan 27 23:15 fhembackup
Ich habe das gemountete Verzeichnis world readable (chmod 777 fhembackup) gemacht, da es nur um den Mount selbst geht.
Wichtig ist, dass der User
Schreibrechte auf dem NAS hat.
Ehrlich gesagt verstehe ich aber nicht, warum er überhaupt etwas kopiert bzw. verschiebt. Entweder es klappt, oder die Verschiebeaktion bricht ab.
Sobald das aber mit den Schreibrechten wieder passt, funktioniert das Skript auch wieder…
Gruß
Martin
Hallo nochmal,
heute habe ich meine FHEM Installation upgedated. Und was soll ich sagen – jetzt geht auch mein automatisches Backup nicht mehr. Größen von 65535 Bytes, danach ist Schluss.
Dann dachte ich mir, kann ja nicht sein, ich habe bei mir „nur“ FHEM upgedated.
Das Problem ist (zumindest bei mir), dass der Aufruf von „backup“ jetzt im Hintergrund ist und somit nicht mehr blockierend, wie es in der Vergangenheit war.
Somit kommt der nächste Schritt meines Skripts zum Einsatz, bevor das Update im Hintergrund abgeschlossen ist. Somit kopiert er nur den Teil auf das NAS, der bis dahin auf der Speicherkarte angekommen ist.
Je nach Installation und Hardwareausstattung ist das mal früher, mal später….
Siehe dazu auch
https://forum.fhem.de/index.php?topic=80237.0
Ich werde jetzt mal mein Skript anpassen, und abfragen, ob das Update schon fertig ist. Da muss ich wohl auf den Prozess abfragen. Erst dann darf das Skript weitermachen. Ich werde dann mein Skript entsprechend updaten.
Gruß
Martin
So. Es ist soweit. Ich habe das Skript angepasst.
Jetzt warte ich in einer Schleife so lange, bis das Backup im Hintergrund erstellt ist.
Sobald der Prozess beendet ist geht dann mein Skript erst weiter.
Die fundamentale Änderung, das backup im Hintergrund zu starten, hat mein Skript ins Wanken gebracht.
Danke in diesem Zusammenhang an Henri, der mich auf das Problem hingewiesen hat, auch wenn bei ihm offensichtlich 2 Probleme gleichzeitig aufgetreten sind.
Gruß
Martin
Hallo Martin,
danke für deine Hilfe. Ich habe soeben alles geändert und es scheint so als ob alles wieder normal läuft. Morgen früh werde ich sehen ob auch die Automatik in der Nacht ohne Probleme abläuft. Danke.
Ich hätte da aber noch eine andere Frage (ist aber nicht so wichtig) bei mir stimmt die Sortierung / Reihenfolge der erstellten Backups und die Angabe des letztes FHEM Backup Datum nicht. Die Liste ist durcheinander gewürfelt. Es sieht fast so aus als wenn die Sortierung des Monats nicht funktioniert, hast du da eventuell auch eine Idee?
Danke Henri.
Hallo Henri,
also bei mir klappt die Sortierung. Wenn die Sortierung nicht richtig ist, kann es nur daran liegen, dass das Filedatum der Backups im gelesenen Verzeichnis nicht zum Filenamen passt.
Ich sortiere nämlich nicht einfach nach dem Dateinamen, obwohl dies auch eine Möglichkeit wäre, sondern ich lese jeweils das Erstellungsdatum des Backups aus.
Hier siehst Du mein Verzeichnis auf meinem NAS:
pi@fhem:/opt/fhem/FHEM $ ls -al /mnt/syno/fhembackup/FHEM*.tar.gz-rw-r--r-- 1 fhem dialout 464654265 Jan 29 23:19 /mnt/syno/fhembackup/FHEM-20180129_231500.tar.gz
-rw-r--r-- 1 fhem dialout 675594212 Jan 30 23:21 /mnt/syno/fhembackup/FHEM-20180130_231500.tar.gz
-rw-r--r-- 1 fhem dialout 469312861 Jan 31 23:19 /mnt/syno/fhembackup/FHEM-20180131_231500.tar.gz
-rw-r--r-- 1 fhem dialout 479855452 Feb 1 23:19 /mnt/syno/fhembackup/FHEM-20180201_231500.tar.gz
Und es wird hier nach diesem Datum links des Filenamens sortiert.
Ist das evtl. schon anders sortiert als nach dem Filenamen?
Gruß
Martin
Bei mir sieht es so aus…
-rwxrwxrwx 1 1008 501 42477418 Jan 28 12:22 FHEM-20180128_121931.tar.gz
-rwxrwxrwx 1 1008 501 42477596 Jan 29 20:12 FHEM-20180128_122715.tar.gz
-rwxrwxrwx 1 1008 501 42510707 Jan 29 20:12 FHEM-20180129_020000.tar.gz
-rwxrwxrwx 1 1008 501 42557163 Jan 31 02:00 FHEM-20180130_020000.tar.gz
-rwxrwxrwx 1 1008 501 42573830 Feb 1 02:00 FHEM-20180131_020000.tar.gz
-rwxrwxrwx 1 1008 501 42642532 Feb 2 10:02 FHEM-20180202_095723.tar.gz
-rwxrwxrwx 1 1008 501 42642227 Feb 2 11:00 FHEM-20180202_105934.tar.gz
Henri
Hi,
verstehe ich nicht, warum er dann nicht richtig sortiert. Auch wenn das Erzeugungsdatum nicht ganz zum Dateinamen passt, so wären sie bei der Sortierung nach dem Dateidatum trotzdem richtig sortiert.
Warum er das Datum nicht richtig ausliest, verstehe ich nicht
Sortiere einfach mal nach dem Dateinamen, in dem Du die Zeile im Skript
@mybackups = sort { eval($lastbackuptime{$a}) <=> eval($lastbackuptime{$b}) } (@mybackups);;\ersetzt durch
@mybackups = sort @mybackups;;\Dann schau mal, ob es beim nächsten Backup richtig sortiert ist.
Gruß
Martin
Hallo Martin,
jetzt geht wieder alles.
Danke für die schnelle und super Hilfe.
Henri
Hallo Martin,
danke erst mal für die tolle Anleitung, Bei mir gibt es leider Probleme mit dem mounten,
Mit ls -al erhalte ich zwar
total 4
drwxr-xr-x 3 root root 0 May 24 11:37 .
drwxr-xr-x 3 root root 4096 May 24 09:55 ..
dr-xr-xr-x 2 root root 0 May 24 11:37 fhembackup
mit dem Befehl
root@WuehrlsFhem /mnt/syno # ls fhembackup/
ls: cannot access fhembackup/: No such file or directory
Ich kann das Verzeichnis zwar sehen, aber habe keinen Zugriff. Im NAS (Synology DS 213+) habe ich dienZugriffsrechte analog deinen Vorgaben erstellt.
Danke für die Hilfe
Martin
Hallo Martin,
mein ls -al im Verzeichnis /mnt/syno
ergibt schon mal ein anderes Bild:
drwxr-xr-x 3 root root 0 Apr 8 10:26 .
drwxr-xr-x 3 root root 4096 Feb 18 2017 ..
drwxrwxrwx 5 root root 4096 Apr 6 23:20 fhembackup
Das Verzeichnis fhembackup hat bei Dir keine Schreibrechte, weder für den User, die Gruppe, noch für den Rest.
Mach mal
sudo chmod 777 fhembackup
Nun müssten zumindest die Rechte für das Verzeichnis richtig gesetzt werden.
Dann probier noch mal…
Gruß
Martin
…so, wollte nur mal das Ergebnis zurückmelden. Leider hat der chmod als user pi nichts gebracht. User fhem konnte nicht auf fhemback schreiben.
Musste mich als user fhem einloggen, in sudoers fhem hinzufügen und dann mit
sudo chmod 777 /mnt/syno/fhembackup
die Berechtigung für den user fhem ändern. Warum das bei mir so kompliziert war – ich bin eben noch am Linux lernen.
Herzlichen Dank für den Support.
Liebe Grüße
Martin
Moin
ich versuche zurzeit die nächtliche Sicherung nachzubauen, doch leider klappt es bei mir nicht richig und ich finde den Fehler nicht.
Das Backup wird erzeugt und in das Verzeichnis /opt/fhem/backup geschrieben. Alles andere schein dann nicht mehr zu funktionieren.
In der Log Datei kommt dann folgende Meldung ( auch wenn ich auf Ausführen drücke)
2018.07.11 17:21:12 2: Backup with command: tar -cf – „./CHANGED“ „./configDB.pm“ „./contrib“ „./demolog“ „./docs“ „./FHEM“ „./fhem.cfg“ „./fhem.cfg.demo“ „./fhem.pl“ „./log“ „./MAINTAINER.txt“ „./README_DEMO.txt“ „./restoreDir“ „./unused“ „./www“ |gzip > ./backup/FHEM-20180711_172112.tar.gz
2018.07.11 17:21:12 3: backup : Started the backup in the background, watch the log for details
Backup done
mv: cannot stat ‚/mnt/syno/fhembackup/FHEM-20180704_225302.tar.gz‘: Permission denied
mv: cannot stat ‚/mnt/syno/fhembackup/FHEM-20180707_134718.tar.gz‘: Permission denied
mv: cannot stat ‚/mnt/syno/fhembackup/FHEM-20180707_142403.tar.gz‘: Permission denied
mv: cannot stat ‚/mnt/syno/fhembackup/FHEM-20180707_142530.tar.gz‘: Permission denied
mv: cannot stat ‚/mnt/syno/fhembackup/FHEM-20180707_231500.tar.gz‘: Permission denied
mv: cannot stat ‚/mnt/syno/fhembackup/FHEM-20180708_231500.tar.gz‘: Permission denied
mv: cannot stat ‚/mnt/syno/fhembackup/FHEM-20180709_231500.tar.gz‘: Permission denied
mv: cannot stat ‚/mnt/syno/fhembackup/FHEM-20180710_231500.tar.gz‘: Permission denied
mv: cannot stat ‚/mnt/syno/fhembackup/FHEM-20180711_172112.tar.gz‘: Permission denied
2018.07.11 17:21:38 1: ERROR evaluating my $TYPE=’dummy‘;my $EVENT=’Ausführen‘;my $SELF=’SYS_BackupRun‘;my $NAME=’SYS_Backup‘;my $EVTPART0=’Ausführen‘;{
fhem(„backup“);
sleep(5);
while(my $psoutput = `ps -ef | grep -v grep | grep FHEM`) {
sleep(10);
}
opendir DIR, „./backup“ or die $!;
my @mybackups = ();
my $lastbackupdatedatum = „“;
my $lastbackupdatesize = „“;
my %lastbackupsize;
my %lastbackuptime;
while(my $file = readdir DIR){
next if($file eq „.“ || $file eq „..“);
push(@mybackups,$file);
}
closedir DIR;
foreach my $file (sort @mybackups) {
my $longfile = „./backup/“.$file;
my $destination = „/mnt/syno/fhembackup/“;
`mv $longfile $destination`;
}
opendir DIR, „/mnt/syno/fhembackup“ or die $!;
@mybackups =();
while(my $file = readdir DIR){
next if($file eq „.“ || $file eq „..“ || $file eq „\@eaDir“);
my $mybackupfile = „/mnt/syno/fhembackup/“.$file;
push(@mybackups,$file);
$lastbackuptime{$mybackupfile} = (stat($mybackupfile))[9];
$lastbackupsize{$mybackupfile} = (stat($mybackupfile))[7];
}
closedir DIR;
@mybackups = sort { eval($lastbackuptime{$a}) eval($lastbackuptime{$b}) } (@mybackups);
if($#mybackups > 0) {
my $mybackupfile = „/mnt/syno/fhembackup/“.$mybackups[$#mybackups];
my ($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst)=localtime($lastbackuptime{$mybackupfile});
$year += 1900;
$mon += 1;
$lastbackupdatedatum = sprintf(„%02d.%02d.%04d %02d:%02d:%02d“,$mday,$mon,$year,$hour,$min,$sec);
$lastbackupdatesize = $lastbackupsize{$mybackupfile}.“ Bytes“;
$mybackups[$#mybackups] = „„.$mybackups[$#mybackups].“„;
} else {
$lastbackupdatedatum = „kein Backup gefunden“;
$lastbackupdatesize = „kein Backup gefunden“;
}
@mybackups = join(„“, @mybackups );
fhem(„set SYS_Backup @mybackups“);
fhem(„set SYS_last_Backup_date $lastbackupdatedatum“);
fhem(„set SYS_last_Backup_size $lastbackupdatesize“);
}: Permission denied at (eval 172) line 23.
2018.07.11 17:21:38 3: SYS_BackupRun return value: Permission denied at (eval 172) line 23.
Kann mir jemand sagen was noch falsch sein könnte.
Danke
Gruß Peter
Hallo,
Entschuldigung, dass ich mich so lange nicht gemeldet habe, ich war eine Zeit lang nicht online. Mein iMac hat die Grätsche gemacht…
Das beschriebene Problem sieht mir wieder mal danach aus, dass die Zugriffsrechte für den User fhem ins Verzeichnis /mnt/syno/fhembackup fehlen.
Bitte mal als User pi die Rechte für das Verzeichnis komplett öffnen, es handelt sich ja nur um die Rechte für das Verzeichnis, in dem das NAS gemountet wird.
sudo chmod 777 /mnt/syno/fhembackup
Damit sollte es klappen, wen nicht dann so verfahren wie der User im Post zuvor, also als user fhem.
Wenn es immer noch nicht klappt, dann bitte mal einen
ls -al
im Verzeichnis /mnt/syno
ausführen und das Ergebnis posten.
O.g. User hatte zu allererst mal das Problem, dass die Schreibrechte fehlten. Das sollte mit dem 777 aber nicht mehr der Fall sein…
Gruß
Martin
Hallo Martin,
erstmal danke für deine Antwort.
Kannst du mir erklären was er mit “ in sudoers fhem hinzufügen und dann mit “ meint.
Wenn ich in
im Verzeichnis /mnt/syno
ls -al
ausführen und ist das Ergebnis :
fhem@raspberrypi:/mnt/syno$ ls -al
insgesamt 4
drwxr-xr-x 3 root root 0 Jul 19 10:29 .
drwxr-xr-x 3 root root 4096 Jul 7 13:49 ..
drwxrwxrwx 2 root root 0 Jul 19 10:29 fhembackup
Gruß Peter
Hallo Peter,
das mit den sudoers ist das letzte Mittel. Man könnte einen Eintrag in der /etc/sudoers für den user fhem machen. Das wäre damit gemeint. /mnt/syno/fhembackup
Aber der Auszug aus Deinem log sagt ja, dass der User fhem, unter dem die Haussteuerung läuft keine Berechtigung hat, das File nach /mnt/syno/fhembackup zu verschieben.
Gehe doch mal als User fhem in das Verzeichnis /opt/fhem/backup und versuche, eine Datei davon manuell über
mv
zu verschieben. Wenn das nicht klappt, dass darf der User fhem das Verzeichnis /mnt/syno/fhembackup nicht auslesen bzw. die Dateien darin.
Weise mal diesen Dateien den User fhem zu, so mit
sudo chown -R fhem:dialout FHEM*.tar.gz
Ich mache diese Operationen auf der Shell mit dem User pi, dieser hat bei mir sudo-Rechte.
Nun muss der User fhem beim Backup definitiv das Recht haben, auch die alten Backups auszulesen.
Wenns immer noch nicht klappt, melde Dich!
Gruß
Martin
Hallo Martin,
Ich habe alles so gemacht wie du es geschrieben hast, ich bekomme beim ausführen von :
fhem@raspberrypi:~/backup$ mv /mnt/syno/fhembackup FHEM-20180728_231500.tar.gz
folgende Meldung:
mv: das Überschreiben des Nicht‐Verzeichnisses ‚FHEM-20180728_231500.tar.gz‘ mit Verzeichnis ‚/mnt/syno/fhembackup‘ ist
nicht möglich.
Wenn ich mir WinSp in das Verzeichnis Backup schaue ist der Besitzer der Dateien „fhem“
Gruß Peter
Hallo Peter,
vielleicht habe ich mich nicht genau genug ausgedrückt, denn jetzt hast Du versucht das Verzeichnis auf eine bestehende Datei zu verschieben.
Wenn im Verzeichnis /opt/fhem/fhembackup die Datei FHEM-20180728_231500.tar.gz liegt,
dann musst Du mit
mv FHEM-20180728_231500.tar.gz /mnt/syno/fhembackup
versuchen, die Datei zu verschieben.
Dann sag mal, ob das geklappt hat oder auch zu einem Fehler führt…
Gruß
Martin
Hallo Martin
ich hoffe ich habe jetzt alles richtig gemacht.
fhem@raspberrypi:~$ cd /opt/fhem/backup
fhem@raspberrypi:~/backup$ ls
FHEM-20180728_231500.tar.gz FHEM-20180729_141740.tar.gz
FHEM-20180729_115011.tar.gz FHEM-20180729_231500.tar.gz
fhem@raspberrypi:~/backup$ mv FHEM-20180728_231500.tar.gz /mnt/syno/fhembackup
mv: der Aufruf von stat für ‚/mnt/syno/fhembackup/FHEM-20180728_231500.tar.gz‘ ist nicht möglich: Keine Berechtigung
fhem@raspberrypi:~/backup$
Hallo Peter,
ok, passt, jetzt kommen wir der Sache näher. Der Benutzer fhem hat offensichtlich kein Recht, ins Verzeichnis /mnt/syno/fhembackup zu schreiben.
Es liegt also an den Berechtigungen.
Kannst Du als User fhem ins Verzeichnis /mnt/syno/fhembackup wechseln?
Also mit
cd /mnt/syno/fhembackup
?
Oder geht das auch nicht?
Dann gibt dem Verzeichnis als Benutzer pi mal einen anderen Eigentümer:
sudo chown -R fhem:dialout /mnt/syno/fhembackup/
jetzt sollte das Verzeichnis und alle darin liegenden Dateien dem User fhem gehören.
Versuche danach mal den move erneut. Also:
mv FHEM-20180728_231500.tar.gz /mnt/syno/fhembackup
Kommt dann immer noch ein Fehler? Dann liegt es am Automounter, dann müssen wir dort weitersuchen…
Hope this helps
Gruß
Martin
Hallo Martin,
Ich habe als erstes mit
cd /mnt/syno/fhembackup versucht in das Verzeichnis zu wechsel (unter User fhem), es kam die Meldung “ keine Berechtigung“
Dann habe ich mit „sudo chown -R fhem:dialout /mnt/syno/fhembackup/ “ (als User pi) ausgeführt.
Dann habe ich nochmal versucht in das Verzeichnis zu wechseln , mit folgender Meldung:
fhem@raspberrypi:~$ cd /mnt/syno/fhembackup
-bash: cd: /mnt/syno/fhembackup: Keine Berechtigung
fhem@raspberrypi:~$
Gruß Peter
Hallo Peter,
das ist ja übel. Als Beweis sehen wir aber jetzt, dass es nicht am Filesystem und den Berechtigungen unter Linux liegt.
Hast Du auf dem NAS die NFS-Regel wie unter
https://hausautomatisierung-koch.de/wp-content/uploads/2017/02/blog_synology_nfsregel.jpg
eingestellt? Wichtig ist hier das Lesen/Schreiben-Privileg.
Wenn ja, dann versuche doch mal auf das NAS zuzugreifen mittels
ls /mnt/syno/fhembackup
und mach anschließend ein
df
Da müsste ein Eintrag kommen ähnlich wie meiner:
meinnas:/volume1/fhembackup 3836212864 1776843392 2059267072 47% /mnt/syno/fhembackup
Geht das auch nicht, dann ist das NAS nicht richtig gemountet.
Schau mal, ob der autofs service richtig läuft.
Hier müsste nach der Eingabe von
sudo service autofs status
etwas kommen wie:
● autofs.service – LSB: Automounts filesystems on demand
Loaded: loaded (/etc/init.d/autofs)
Active: active (running) since So 2018-04-08 10:26:56 CEST; 3 months 23 days ago
CGroup: /system.slice/autofs.service
├─10207 /usr/sbin/automount –pid-file /var/run/autofs.pid
└─10234 rpc.statd –no-notify
Im Zweifelsfalle kannst Du ja mal den Autofs Service Restarten mit:
sudo service autofs restart
Und damit hier auch abhängige Dienst funktionieren würde ich auch noch
sudo service nbm restart
sudo service rpcbind restart
Dann schauen wir mal weiter.
Gruß
Martin
Hallo Martin, erstmal vielen Dank das du dir soviel Mühe mit mir gibst ( ist mit schon irgendwie Peinlich)
bei :
pi@raspberrypi:~ $ ls /mnt/syno/fhembackup
Test.txt
pi@raspberrypi:~ $ df
Dateisystem 1K-Blöcke Benutzt Verfügbar Verw% Eingehängt auf
/dev/root 15254896 1594984 13007520 11% /
devtmpfs 470116 0 470116 0% /dev
tmpfs 474724 0 474724 0% /dev/shm
tmpfs 474724 12256 462468 3% /run
tmpfs 5120 4 5116 1% /run/lock
tmpfs 474724 0 474724 0% /sys/fs/cgroup
/dev/mmcblk0p1 43539 22420 21119 52% /boot
tmpfs 94944 0 94944 0% /run/user/1000
Gottschalk:/volume1/fhembackup 3840822656 3720584192 120119680 97% /mnt/syno/fhembackup
pi@raspberrypi:~ $
kommt das raus (also wie bei dir,m richtig)
bei : „sudo service autofs status“ kommmt
pi@raspberrypi:~ $ sudo service autofs status
● autofs.service – Automounts filesystems on demand
Loaded: loaded (/lib/systemd/system/autofs.service; enabled; vendor preset: enabled)
Active: active (running) since Thu 2018-07-19 10:29:10 CEST; 1 weeks 6 days ago
Process: 560 ExecStart=/usr/sbin/automount $OPTIONS –pid-file /var/run/autofs.pid (code=exited, status=0/SUCCESS)
Main PID: 577 (automount)
CGroup: /system.slice/autofs.service
└─577 /usr/sbin/automount –pid-file /var/run/autofs.pid
Jul 19 10:29:10 raspberrypi systemd[1]: Starting Automounts filesystems on demand…
Jul 19 10:29:10 raspberrypi systemd[1]: Started Automounts filesystems on demand.
pi@raspberrypi:~ $
wenn ich die drei Befehle ausführe kommt das :
pi@raspberrypi:~ $ sudo service autofs restart
pi@raspberrypi:~ $ sudo service nbm restart
Failed to restart nbm.service: Unit nbm.service not found.
pi@raspberrypi:~ $ sudo service rpcbind restart
pi@raspberrypi:~ $
Gruß Peter
Hallo Peter,
ich helfe gerne. Ich bin selbst froh, wenn mir geholfen wird, wenn ich selbst nicht mehr weiter komme.
Ich bin aber noch nicht dahintergekommen, was genau bei Dir nicht funktioniert. Die Ausgaben des Automounters sehen in Ordnung aus, alles läuft, nach dem Neustart scheint sich ja das Problem auch nicht gelöst zu haben.
Aber eins fällt mir bei der Ausgabe des df auf:
User pi kann offensichtlich unter /mnt/syno/fhembackup zumindest das Verzeichnis auslesen und gibt die Datei Test.txt aus.
User fhem darf das nicht, obwohl wir ihm sogar als Eigentümer für das Verzeichnis eingetragen haben.
Dein NAS ist allerdings fast voll! Lösche vielleicht mal ein paar Dateien herunter, die Du nicht mehr brauchst, bist Du wieder etwas mehr Platz hast. So erfahrungsgemäß ab 80% Füllstand sollte man etwas tun. Ich hab mir irgendwann mal 2 neue NAS Platten geholt und die 2 alten nacheinander gegen neue, größere ausgetauscht. In der Synology kann man dann nach dem Austausch der beiden die Partitionen vergrößern, so dass das letztendlich alles „im Laufenden Betrieb“ passieren kann, ohne dass man die Dateien irgendwo zwischenlagern muss.
Zurück zum Problem:
Melde Dich mal als User fhem an und gib seine Gruppenzugehörigkeit mit
groups
aus.
Bei mir gehört der User fhem zu den Gruppen:
dialout tty audio video fhemftp
Wie sieht das bei Dir aus?
Und nochmal zusammengefasst:
Als user pi ruf mal auf
ls -al /mnt
ls -al /mnt/syno
ls -al /mnt/syno/fhembackup
danach das selbe bitte nochmal als User hem
Ich will noch mal die Rechte für den Pfad bis dorthin überprüfen.
Vielleicht kommen wir dann weiter…
Gruß
Martin
Hallo Peter,
und noch eins ist mir eingefallen:
Gib doch mal die Konfiguration des automounters unter User pi aus mit:
sudo automount -m
Bei mir kommt hier:
autofs dump map information
===========================
global options: none configured
Mount point: /mnt/syno
source(s):
instance type(s): file
map: /etc/autofs/auto.synology
fhembackup | -fstype=nfs,rw,nouser,atime,auto,dev,exec,suid meinnas:/volume1/fhembackup
Gruß
Martin
Hallo Martin
ich hoffe das hilft weiter.
1.fhem@raspberrypi:~$ groups
dialout
2.pi@raspberrypi:~ $ ls -al /mnt
insgesamt 8
drwxr-xr-x 3 root root 4096 Jul 7 13:49 .
drwxr-xr-x 22 root root 4096 Jul 4 16:30 ..
drwxr-xr-x 3 root root 0 Aug 1 19:19 syno
3.pi@raspberrypi:~ $ ls -al /mnt/syno
insgesamt 4
drwxr-xr-x 3 root root 0 Aug 1 19:19 .
drwxr-xr-x 3 root root 4096 Jul 7 13:49 ..
dr-xr-xr-x 2 root root 0 Aug 1 19:19 fhembackup
4.pi@raspberrypi:~ $ ls -al /mnt/syno/fhembackup
insgesamt 8
drwxrwxrwx 3 fhem dialout 4096 Aug 1 19:14 .
drwxr-xr-x 3 root root 0 Aug 1 19:19 ..
-rwxrwxrwx 1 fhem dialout 0 Jul 7 14:10 Test.txt
5.fhem@raspberrypi:~$ ls -al /mnt
insgesamt 8
drwxr-xr-x 3 root root 4096 Jul 7 13:49 .
drwxr-xr-x 22 root root 4096 Jul 4 16:30 ..
drwxr-xr-x 3 root root 0 Aug 1 19:19 syno
6.fhem@raspberrypi:~$ ls -al /mnt/syno
insgesamt 4
drwxr-xr-x 3 root root 0 Aug 1 19:19 .
drwxr-xr-x 3 root root 4096 Jul 7 13:49 ..
dr-xr-xr-x 2 root root 0 Aug 1 19:19 fhembackup
7.fhem@raspberrypi:~$ ls -al /mnt/syno/fhembackup
ls: Öffnen von Verzeichnis ‚/mnt/syno/fhembackup‘ nicht möglich: Keine Berechtigung
8.pi@raspberrypi:~ $ sudo automount -m
autofs dump map information
===========================
global options: none configured
Mount point: /mnt/syno
source(s):
instance type(s): file
map: /etc/autofs/auto.synology
fhembackup | -fstype=nfs,rw,nouser,atime,auto,dev,exec,suid Gottschalk:/volume1/fhembackup
Hallo Peter,
sieht alles gut aus.
Nur der User fhem hat als einzige Gruppe die dialout.
Bei mir sind das mehrere Gruppen.
Mach mal als user pi:
usermod -a -G dialout,tty,audio,video fhem
Damit sollte fhem mehr dürfen.
Danach starte mal den Autofs neu mit
sudo service autofs restart
Wenns dann immer noch nicht geht, müssen wir beim Autofs weitersuchen. Die Meldungen sehen dort zwar alle gut aus, möglicherweise
hast Du aber eine andere Version des Autofs, da hatte ich auch schon mal Probleme. Aber probier erst mal obiges aus…
Gruß
Martin
Hallo Martin,
bei :
pi@raspberrypi:~ $ usermod -a -G dialout,tty,audio,video fhem
kommt:
usermod: Permission denied.
usermod: /etc/passwd konnte nicht gesperrt werden; versuchen Sie es später noch einmal.
Gruß Peter
Hi Peter,
oh sorry, mein Fehler. Natürlich per sudo. User pi darf natürlich die User nicht verändern.
Also:
sudo usermod -a -G dialout,tty,audio,video fhem
Nächster Versuch. Sorry…
Gruß
Martin
nach :
pi@raspberrypi:~ $ cd /mnt/syno
pi@raspberrypi:/mnt/syno $ sudo chmod 777 fhembackup
pi@raspberrypi:/mnt/syno $ ls -al /mnt/syno
insgesamt 4
drwxr-xr-x 3 root root 0 Aug 3 15:34 .
drwxr-xr-x 3 root root 4096 Jul 7 13:49 ..
drwxrwxrwx 2 root root 0 Aug 3 15:34 fhembackup
sieht jetzt wie bei dir aus oder?
als fhem:
fhem@raspberrypi:~$ ls -al /mnt/syno
insgesamt 4
drwxr-xr-x 3 root root 0 Aug 3 15:34 .
drwxr-xr-x 3 root root 4096 Jul 7 13:49 ..
drwxrwxrwx 2 root root 0 Aug 3 15:34 fhembackup
fhem@raspberrypi:~$ ls -al /mnt/syno/fhembackup
ls: Öffnen von Verzeichnis ‚/mnt/syno/fhembackup‘ nicht möglich: Keine Berechtigung
Hi Peter,
jetzt wird’s wirklich eklig.
Das Linux-Filesystem können wir jetzt definitiv ausschliessen. Da haben wir irgendein Problem am Automount.
Stoppe mal den Automount mit
sudo service autofs stop
Danach mal das System updaten bzw. upgraden
sudo apt-get update
sudo apt-get upgrade
Danach den Automount wieder starten
sudo service autofs start
Versuche mal auf das Verzeichnis /mnt/syno/fhembackup zuzugreifen,
erst als pi, dann als fhem.
Schau mal mit
tail -100 /var/log/daemon.log
in die Logs der Dämonen:
Da müsste ein Eintrag nach dem Starten des Autofs drin sein wie etwa:
Aug 4 08:10:48 fhem autofs[21454]: Starting automount….
Vielleicht siehst Du drunter noch Einträge des Autofs wg. gescheiterter Berechtigungen.
Es muss jedenfalls definitiv etwas mit dem Autofs zu tun haben. Linux inclusive Berechtigungen passen!
Gruß
Martin
Hallo Martin
wenn ich das richtig sehe ist mein System auf dem neusten Stand:
pi@raspberrypi:~ $ sudo service autofs stop
pi@raspberrypi:~ $ sudo apt-get update
Holen:1 http://archive.raspberrypi.org/debian stretch InRelease [25,3 kB]
OK:2 http://raspbian.raspberrypi.org/raspbian stretch InRelease
Es wurden 25,3 kB in 0 s geholt (29,2 kB/s).
Paketlisten werden gelesen… Fertig
pi@raspberrypi:~ $ sudo apt-get upgrade
Paketlisten werden gelesen… Fertig
Abhängigkeitsbaum wird aufgebaut.
Statusinformationen werden eingelesen…. Fertig
Paketaktualisierung (Upgrade) wird berechnet… Fertig
0 aktualisiert, 0 neu installiert, 0 zu entfernen und 0 nicht aktualisiert.
Zugriff ist leider immer noch nicht möglich.
bei
tail -100 /var/log/daemon.log
kommt
Aug 4 11:04:38 raspberrypi systemd[1]: Stopping Automounts filesystems on deman d…
Aug 4 11:04:38 raspberrypi systemd[1]: Stopped Automounts filesystems on demand .
Aug 4 11:52:41 raspberrypi systemd[1]: Starting Automounts filesystems on deman d…
Aug 4 11:52:42 raspberrypi systemd[1]: Started Automounts filesystems on demand .
keine weiteren Zeilen darunter.
Gruß Peter
Hallo Peter,
sorry, dass es immer noch nicht läuft. Aber das ist eine echt harte Nuss bei Dir! Alle Eventualitäten, die in 95% der Fälle helfen, brachten keinen Erfolg.
Ich würde trotzdem beim autofs ansetzen.
Was bringt denn
automount –version
bei Dir?
Ich habe als Ausgabe:
Linux automount version 5.0.8
Directories:
config dir: /etc/default
maps dir: /etc
modules dir: /usr/lib/arm-linux-gnueabihf/autofs
Compile options:
ENABLE_FORCED_SHUTDOWN ENABLE_IGNORE_BUSY_MOUNTS WITH_HESIOD
WITH_LDAP WITH_SASL LIBXML2_WORKAROUND
Was ich überhaupt nicht verstehe:
Du scheinst über den User pi Zugriff auf das NAS zu haben, der User fhem aber nicht.
Also scheint der Automount grundsätzlich zu funktionieren, allerdings userspezifisch.
Der User pi kann aber eine Datei in /mnt/syno/fhembackup erstellen und wieder löschen, richtig?
Meine /etc/autofs/auto.synology hat folgende Zeile:
fhembackup -fstype=nfs,rw,nouser,atime,auto,dev,exec,suid meinnas:/volume1/fhembackup
Und meine /etc/auto.master sieht so aus:
#
# Sample auto.master file
# This is an automounter map and it has the following format
# key [ -mount-options-separated-by-comma ] location
# For details of the format look at autofs(5).
#
#/misc /etc/auto.misc
#
# NOTE: mounts done from a hosts map will be mounted with the
# „nosuid“ and „nodev“ options unless the „suid“ and „dev“
# options are explicitly given.
#
#/net -hosts
#
# Include /etc/auto.master.d/*.autofs
#
+dir:/etc/auto.master.d
#
# Include central master map if it can be found using
# nsswitch sources.
#
# Note that if there are entries for /net or /misc (as
# above) in the included master map any keys that are the
# same will not be seen as the first read key seen takes
# precedence.
#
+auto.master
/mnt/syno /etc/autofs/auto.synology –ghost, –timeout=60
Vergleich bitte mal, langsam gehen mir die Ideen aus…
Du könntest natürlich mal einen zweiten User anlegen bsp. fhemtest, selbe Gruppen wie der fhem
und mal probieren, ob Du damit weiterkommst als mit dem User fhem.
Dann wäre in der Tat der User fhem verkorkst….
Gruß
Martin
Hallo Martin
das schein es auch nicht gewesen zu sein.
fhem@raspberrypi:~$ groups
dialout tty audio video
bei mir fehlt nur fhemftp ( da weiß ich aber nicht ob das wichtig ist)
wenn ich das wieder ausführe:
fhem@raspberrypi:~$ ls -al /mnt
insgesamt 8
drwxr-xr-x 3 root root 4096 Jul 7 13:49 .
drwxr-xr-x 22 root root 4096 Jul 4 16:30 ..
drwxr-xr-x 3 root root 0 Aug 3 15:34 syno
fhem@raspberrypi:~$ ls -al /mnt/syno
insgesamt 4
drwxr-xr-x 3 root root 0 Aug 3 15:34 .
drwxr-xr-x 3 root root 4096 Jul 7 13:49 ..
dr-xr-xr-x 2 root root 0 Aug 3 15:34 fhembackup
fhem@raspberrypi:~$ ls -al /mnt/syno/fhembackup
ls: Öffnen von Verzeichnis ‚/mnt/syno/fhembackup‘ nicht möglich: Keine Berechtigung
also immer noch keine Berechtigung den Ordner fhembackup zu öffnen.
Gruß Peter
Hallo Peter,
ok, verstanden.
Ich hab mir noch mal die Ausgabe von ls -al /mnt/syno angesehen.
Du hast
dr-xr-xr-x 2 root root 0 Aug 3 15:34 fhembackup
Bei mir:
drwxrwxrwx 5 root root 4096 Aug 1 23:35 fhembackup
Gehe noch mal als pi mit
cd /mnt/syno
in dieses Verzeichnis
Danach
sudo chmod 777 fhembackup
Danach sollte das Verzeichnis fhembackup auch den komplett geöffneten Verzeichnisast /mnt/syno/fhembackup
haben.
Schau mal, was ls -al /mnt/syno als pi danach sagt. Offen? Dann probier nochmal als User fhem.
Gruß
Martin
Hallo, erstmal DANKE für den tollen Bericht. Ich bin noch in der Einrichtung und zwar beim Punkt „Anzahl der Backups begrenzen.“
Bei: Dies klappt mit folgendem Skript, das wir delete_fhembackup.pl nennen und einfach im Hauptverzeichnis des Users pi erstellen.
hänge ich etwas:
Ich weis nicht genau wann ich mich im Hauptverzeichnis befinde.
Das:
pi@raspberrypi:~ $
?
bzw wo ich deinen Text hinein kopieren?
Grüße
Hallo.
Du bist als User pi angemeldet.
Einfach in sein Homeverzeichnis reinkopieren.
Am $ sieht man, dass Du sowieso gerade im Homeverzeichnis bist.
Also einfach dorthinein nach $ (= /home/pi ) eine Datei mit dem Editor nano erstellen.
Also:
cd
nano delete_fhembackup.pl
dort den Text hineinkopieren.
CTRL+O
CTRL+X
Fertig.
Gruß
Martin
Hallo Martin,
ich bin deiner Anleitung gefolgt.
Soweit funktioniert auch alles, doch leider wird das Backup in
/opt/fhem/\192.168.188.25backupFHEM geschrieben und nicht auf die NAS!
Danke für deine Hilfe
Martin
Hallo Martin,
kommt das Backup wirklich in /opt/fhem/\192.168.188.25backupFHEM an?
Mein Skript fügt hier normalerweise nicht eine IP-Adresse ein, sondern legt das Backup über den Standard unter
/opt/fhem/fhembackup ab, bevor es von dort aus auf das NAS verschoben wird – nämlich auf /mnt/syno/fhembackup.
Prüfe doch bitte nochmal, ob sich beim Kopieren des Skripts nicht ein Fehler eingeschlichen hat.
Sollte alles passen, dann prüfe mal, ob ein Backup unter /opt/fhem/fhembackup liegt. Das sollte nämlich fhem mit dem Befehl
backup immer machen. Das kannst Du übrigens auch in der FHEM-Kommandozeile durch Eintippen auch mal manuell auslösen. Liegt
ein File namens FHEM-2018mmdd_hhmmss.tar.gz in /opt/fhem/fhembackup ?
Gruß
Martin
Hallo Martin,
in der Tat habe ich in einem früheren Anlauf (Backup ->NAS) im global Device mal backupdir definiert. Daher der Speicherort: /opt/fhem/\192.168.188.25backupFHEM!
Ich habe backupdir in FHEM gelöscht und nach deiner O.g. Anleitung alles neu installiert und alles ist gut!
Danke für deine Mühen und für den Schubs in die richtige Richtung.
LG Martin
Eine Frage hätten ich noch!
Wie würde denn der „menuEntries“ Eintrag aussehen, um das Backup direkt aus der Menüleiste in FHEM zu starten?
Hallo Martin ,
so wie es scheint kann ich dir in unsere Unterhaltung nicht mehr schreiben, deshalb mach ich eine neue Unterhaltung auf.
Wenn ich das richtig sehe schein mein System auf den aktuellen Stand zu sein:
pi@raspberrypi:~ $ sudo service autofs stop
pi@raspberrypi:~ $ sudo apt-get update
Holen:1 http://archive.raspberrypi.org/debian stretch InRelease [25,3 kB]
OK:2 http://raspbian.raspberrypi.org/raspbian stretch InRelease
Es wurden 25,3 kB in 0 s geholt (29,2 kB/s).
Paketlisten werden gelesen… Fertig
pi@raspberrypi:~ $ sudo apt-get upgrade
Paketlisten werden gelesen… Fertig
Abhängigkeitsbaum wird aufgebaut.
Statusinformationen werden eingelesen…. Fertig
Paketaktualisierung (Upgrade) wird berechnet… Fertig
0 aktualisiert, 0 neu installiert, 0 zu entfernen und 0 nicht aktualisiert.
wenn ich „tail -100 /var/log/daemon.log“ ausführe kommt
Aug 4 11:04:38 raspberrypi systemd[1]: Stopping Automounts filesystems on deman d…
Aug 4 11:04:38 raspberrypi systemd[1]: Stopped Automounts filesystems on demand .
Aug 4 11:52:41 raspberrypi systemd[1]: Starting Automounts filesystems on deman d…
Aug 4 11:52:42 raspberrypi systemd[1]: Started Automounts filesystems on demand .
es sind keine weiteren Zeilen vorhanden.
Gruß Peter
Hallo Peter,
komischerweise habe ich erst jetzt die Nachricht erhalten, dass Du mir in diesem Thread nicht mehr schreiben konntest.
Deswegen mal meine Antwort nochmal in diesem neuen Thread:
——————————-
Hallo Peter,
sorry, dass es immer noch nicht läuft. Aber das ist eine echt harte Nuss bei Dir! Alle Eventualitäten, die in 95% der Fälle helfen, brachten keinen Erfolg.
Ich würde trotzdem beim autofs ansetzen.
Was bringt denn
automount –version
bei Dir?
Ich habe als Ausgabe:
Linux automount version 5.0.8
Directories:
config dir: /etc/default
maps dir: /etc
modules dir: /usr/lib/arm-linux-gnueabihf/autofs
Compile options:
ENABLE_FORCED_SHUTDOWN ENABLE_IGNORE_BUSY_MOUNTS WITH_HESIOD
WITH_LDAP WITH_SASL LIBXML2_WORKAROUND
Was ich überhaupt nicht verstehe:
Du scheinst über den User pi Zugriff auf das NAS zu haben, der User fhem aber nicht.
Also scheint der Automount grundsätzlich zu funktionieren, allerdings userspezifisch.
Der User pi kann aber eine Datei in /mnt/syno/fhembackup erstellen und wieder löschen, richtig?
Meine /etc/autofs/auto.synology hat folgende Zeile:
fhembackup -fstype=nfs,rw,nouser,atime,auto,dev,exec,suid meinnas:/volume1/fhembackup
Und meine /etc/auto.master sieht so aus:
#
# Sample auto.master file
# This is an automounter map and it has the following format
# key [ -mount-options-separated-by-comma ] location
# For details of the format look at autofs(5).
#
#/misc /etc/auto.misc
#
# NOTE: mounts done from a hosts map will be mounted with the
# „nosuid“ and „nodev“ options unless the „suid“ and „dev“
# options are explicitly given.
#
#/net -hosts
#
# Include /etc/auto.master.d/*.autofs
#
+dir:/etc/auto.master.d
#
# Include central master map if it can be found using
# nsswitch sources.
#
# Note that if there are entries for /net or /misc (as
# above) in the included master map any keys that are the
# same will not be seen as the first read key seen takes
# precedence.
#
+auto.master
/mnt/syno /etc/autofs/auto.synology –ghost, –timeout=60
Vergleich bitte mal, langsam gehen mir die Ideen aus…
Du könntest natürlich mal einen zweiten User anlegen bsp. fhemtest, selbe Gruppen wie der fhem
und mal probieren, ob Du damit weiterkommst als mit dem User fhem.
Dann wäre in der Tat der User fhem verkorkst….
Gruß
Martin
Hallo Martin,
ich habe mal was anderes versucht, ich habe ein Testsystem neu aufgebaut. D.h. nur Raspbian-Stretch (nicht Lite) und FHEM installiert. Alles auf den neusten Stand gebraucht und dann deine Installation von vorne installiert. Auch nur bis zum Mount-Point.
Aber auch dort konnte ich nur mit dem User Pi auf das Verzeichnis /mnt/syno/fhembackup zugreifen, mit User fhem keine Berechtigung.
Ich habe dann ein wenig herumexperimentiert und hatte aufeinmal mit dem User fhem Zugriff auf das fhembackup Verzeichnis. (warum auch immer?)
Ich habe dann versuchsweise mal wieder die OrginalSDkarte in den Raspberry gesteckt und hatte auch jetzt dort Zugriff mit dem User fhem.
Super habe ich gedacht, Problem gelöst ( aber leider doch nicht)
Jetzt kommt ein andere Fehler :
in den Ordner sind nur die beiden Testdateien
fhem@FHEM:~$ cd /mnt/syno/fhembackup
fhem@FHEM:/mnt/syno/fhembackup$ ls -al
insgesamt 8
drwxrwxrwx 3 fhem dialout 4096 Aug 6 17:09 .
drwxr-xr-x 3 root root 0 Aug 6 16:56 ..
———- 1 fhem dialout 0 Aug 6 17:05 test1
———- 1 fhem dialout 0 Aug 6 17:05 test2
im Backupordner die beiden Backup´s
fhem@FHEM:/$ cd /opt/fhem/backup
fhem@FHEM:~/backup$ ls -al
insgesamt 8
insgesamt 86636
drwxr-xr-x 2 fhem dialout 4096 Aug 6 17:15 .
drwxr-xr-x 13 fhem dialout 4096 Jul 29 19:16 ..
-rw-r–r– 1 fhem dialout 44348104 Aug 6 17:11 FHEM-20180806_171121.tar.gz
-rw-r–r– 1 fhem dialout 44348071 Aug 6 17:15 FHEM-20180806_171510.tar.gz
-rw-r–r– 1 fhem dialout 0 Aug 6 15:55 test
-rw-r–r– 1 fhem dialout 0 Aug 6 16:55 test1
-rw-r–r– 1 fhem dialout 0 Aug 6 16:55 test2
jetzt kommt der Fehler:
fhem@FHEM:~/backup$ mv FHEM-20180806_171121.tar.gz /mnt/syno/fhembackup
mv: reguläre Datei ‚/mnt/syno/fhembackup/FHEM-20180806_171121.tar.gz‘ kann nicht angelegt werden: Die Operation ist nicht erlaubt
fhem@FHEM:~/backup$ cp FHEM-20180806_171510.tar.gz /mnt/syno/fhembackup
cp: reguläre Datei ‚/mnt/syno/fhembackup/FHEM-20180806_171510.tar.gz‘ kann nicht angelegt werden: Die Operation ist nicht erlaubt
wie du siehst sind noch alle Dateien vorhanden:
fhem@FHEM:~/backup$ ls -al
insgesamt 86636
drwxr-xr-x 2 fhem dialout 4096 Aug 6 17:15 .
drwxr-xr-x 13 fhem dialout 4096 Jul 29 19:16 ..
-rw-r–r– 1 fhem dialout 44348104 Aug 6 17:11 FHEM-20180806_171121.tar.gz
-rw-r–r– 1 fhem dialout 44348071 Aug 6 17:15 FHEM-20180806_171510.tar.gz
-rw-r–r– 1 fhem dialout 0 Aug 6 15:55 test
-rw-r–r– 1 fhem dialout 0 Aug 6 16:55 test1
-rw-r–r– 1 fhem dialout 0 Aug 6 16:55 test2
gehe ich jetzt ins fhembackup Verzeichnis sieht das so aus:
fhem@FHEM:/$ cd /mnt/syno/fhembackup
fhem@FHEM:/mnt/syno/fhembackup$ ls -al
insgesamt 8
drwxrwxrwx 3 fhem dialout 4096 Aug 6 17:23 .
drwxr-xr-x 3 root root 0 Aug 6 17:23 ..
———- 1 fhem dialout 0 Aug 6 17:23 FHEM-20180806_171121.tar.gz
———- 1 fhem dialout 0 Aug 6 17:23 FHEM-20180806_171510.tar.gz
———- 1 fhem dialout 0 Aug 6 17:05 test1
———- 1 fhem dialout 0 Aug 6 17:05 test2
d.h. er kopiert und verschiebt die Backupdateien, obwohl eine Fehlermeldung kommt.
??????
Das schlimmste ist, wenn ich in FHEM auf ausführen gehe kommen die Fehlermeldung auch und das System hängt sich komplett auf. Ich kann nur mit SSH auf den Raspberry zugreifen und ein Reboot machen.
Jetzt bin ich noch ratloser wie vorher.
Gruß Peter
Hallo ich habe ein automatisches Backup laufen. Ohne wissentlich was zu ändern schmiert mir das gesamte System neuerdings beim Erstellen des Backups ab. Im Log bekomme ich folgende Meldung:
2018.09.18 15:02:28 3: backup : Started the backup in the background, watch the log for details
Backup done
mv: cannot create regular file ‚/mnt/syno/fhembackup/FHEM-20180918_150228.tar.gz‘: Operation not permitted
2018.09.18 15:03:23 1: PERL WARNING: Use of uninitialized value in eval „string“ at (eval 459) line 33.
kann mir jemand weiter helfen?
Hallo,
dazu zwei Dinge. Erstens scheint sich mit einem der Updates auf Betriebssystemseite etwas geändert zu haben, so dass die Schleife mit dem
den Prozess für FHEM selbst gefunden hat. Dieser Tatsache habe ich Rechnung getragen und das Skript dahingehend angepasst, dass ich noch eine zusätzliche Pipe mit
angefügt habe.
In Deinem Falle scheint aber das gar nicht das Problem zu sein. Der User, unter dem FHEM läuft, meistens der User fhem, hat plötzlich keine Zugriffsrechte mehr auf das über autofs gemountete Filesystem unter /mnt/syno/fhembackup
Ich bin wegen dieses Problems mit einem anderen Leidensgenossen in Kontakt, der das selbe Problem zu haben scheint. Wir haben leider immer noch nicht herausgefunden, welche Komponente sich hier geändert hat, dass der Zugriff als User fhem nicht mehr klappt. Das einzige, was ich mittlerweile sicher sagen kann ist, dass es nicht am Skript liegt. Das funktioniert auch bei den meisten Usern, ich musste bei mir nie etwas ändern.
Allerdings scheint sich auch beim Wechsel der Betriebssystemversion von Jessie auf Stretch (Raspbian GNU/Linux 8 zu Raspbian GNU/Linux 9) etwas grundlegendes geändert zu haben. Das fängt schon bei den avahi-daemons an.
Ich kann hier nur den Tipp geben, schrittweise an das Problem heranzugehen:
– kann der User pi eine Datei unter /mnt/syno/fhembackup/ erstellen
– kann der User fhem eine Datei dort erstellen
– nein? dann Zugriffsrechte auf dem Verzeichnis mal komplett öffnen
– geht immer noch nicht? Hat sich auf dem NAS etwas geändert?
Ich hoffe, die Denkanstöße bringen Dich weiter…
Gruß
Martin
Hallo Martin, danke für die Antwort.
Dateien erstellen geht unter pi und fhem. hier meine berechtigung:
pi@raspberrypi:~ $ ls -al /mnt/syno
total 4
drwxr-xr-x 3 root root 0 Sep 18 15:35 .
drwxr-xr-x 3 root root 4096 Jul 23 15:44 ..
dr-xr-xr-x 2 root root 0 Sep 18 15:35 fhembackup
pi@raspberrypi:~ $ ls -al /mnt
total 8
drwxr-xr-x 3 root root 4096 Jul 23 15:44 .
drwxr-xr-x 21 root root 4096 Sep 18 15:30 ..
drwxr-xr-x 3 root root 0 Sep 18 15:35 syno
pi@raspberrypi:~ $ ls -al /mnt/syno/fhembackup
total 53164
drwxrwxrwx 3 fhem dialout 4096 Sep 18 21:42 .
drwxr-xr-x 3 root root 0 Sep 18 15:35 ..
———- 1 pi pi 54424266 Sep 18 15:59 FHEM-20180918_155620.tar.gz
pi@raspberrypi:~ $
auf dem nas hat sich nichts geändert
Hallo Timo,
was genau nicht (mehr) tut, kann ich bisher nicht sagen, aber mit fallen zwei Dinge auf, die anders sind als bei mir:
1.) ich habe dem Verzeichnis fhembackup in /mnt/syno 777 spendiert, also:
pi@fhem:/mnt/syno/fhembackup $ ls -al /mnt/syno/
insgesamt 8
drwxr-xr-x 3 root root 0 Aug 4 08:10 .
drwxr-xr-x 3 root root 4096 Feb 18 2017 ..
drwxrwxrwx 5 root root 4096 Sep 16 23:25 fhembackup
Mach mal als User pi
cd /mnt/snyo
sudo chmod 777 fhembackup
2.) Die Backupdatei in /mnt/syno/fhembackup gehört pi (normalerweise sollte sie dem user fhem gehören, denn darunter läuft die Backup-Funktionalität). Ausserdem hat die Datei keinerlei Rechte mehr, also 000….
Bei mir sieht das Verzeichnis /mnt/syno/fhembackup so aus:
pi@fhem:/mnt/syno/fhembackup $ ls -al
insgesamt 79267856
drwxrwxrwx 5 root root 4096 Sep 16 23:25 .
drwxr-xr-x 3 root root 0 Aug 4 08:10 ..
-rwxrwxrwx 1 1026 users 8196 Sep 7 16:42 .DS_Store
-rw-r–r– 1 fhem dialout 879417463 Sep 9 23:27 FHEM-20180909_231500.tar.gz
-rw-r–r– 1 fhem dialout 632794272 Sep 16 23:24 FHEM-20180916_231500.tar.gz
Und noch ne Frage: Hat es schon mal funktioniert? Oder ging es noch nie?
Wenn es schon mal funktioniert hat, dann hat sich entweder bei einem Update im fhem oder eher wahrscheinlich im Raspbian Linux etwas geändert.
Am Wochenende setze ich mal einen weiteren Raspi mit dem aktuellen Raspbian auf und versuche mich per autofs auf mein Synology NAS zu verbinden. Wollte ich schon lange machen und bin bisher nicht dazugekommen….
Gruß
Martin
Hallo Martin,
Ja, es hat mal einwandfrei funktioniert. Zwischenzeitlich habe ich die üblichen Updates aufgespielt, also fhem, linux etc. Ab welchem genau es nicht mehr ging, kann ich leider nicht sagen. (innerhalb der letzten 3 Wochen.)
Ich habe nun mal alles komplett neu nach deiner Anleitung oben versucht. Nach Anlegen des Dummys und anschließendem Testweise „Backup ausführen“ stürzt das ganze System ab und FHEM fährt nicht mehr hoch. Konnte dann nur noch übers Terminal die Änderungen in der fhem.cfg rückgängig machen. Soweit der jetzige Stand.
Hallo Timo,
ich habe jetzt einen Raspberry Pi 2 mit der neuesten Raspbian Linux 9 installiert, letzte fhem 5.8 Installation und alles exakt so, wie ich es in meinen Beiträgen beschrieben habe. Bei einigen Paketen musste ich etwas nachinstallieren, werde dahingehend meinen Blog aktualisieren. Allerdings hätte sich sonst ja auch kein fhem installieren und danach starten lassen, und nach einem weiteren sudo apt-get update und sudo alt-get upgrade war das System komplett aktuell.
Danach habe ich das autofs und autofs5 hochgezogen und auf meinem NAS die IP-Adresse des neuen Raspberry Pi eingetragen, damit per nfs das NAS angesprochen werden kann.
Die User pi und der User fhem hatten problemlos Zugriff auf das NAS unter /mnt/syno/fhembackup.
Ich habe dann fhem einmal hochgefahren in der Standardinstallation und dann mein Skript aus meinem Beitrag hineinkopiert und den Dummy angelegt.
Danach habe ich manuell auf „Backup ausführen“ gedrückt und ein paar Minuten gewartet. Leider friert während des Backups das fhem ein und man muss warten, bis das Backup durch ist bzw. der tar und gzip gelaufen ist und das Backupfile zunächst im FHEM-Standard unter /opt/fhem/backup erstellt hat.
Einige Sekunden später war das Backupfile unter /mnt/syno/fhembackup zu finden und das Skript durch.
Das einzige Problem ist, dass das Backup FHEM mehr oder weniger blockiert, aber das macht FHEM seit einiger Zeit schon so. Vielleicht sollte man das Backup manuell als Shellskript in den Hintergrund legen und die Priorität für das Erstellen per nice reduzieren. Aber damit würde ich mich schon ausserhalb der FHEM-Standard-Funktion fhem(„backup“) bewegen.
Fakt ist, dass bei mir das Backup einwandfrei durchlief, nichts abstürzte und das Ergebnis auf dem NAS landete.
Ich kann es bei mir leider auch auf dem zweiten System, das ich extra aufgesetzt habe bisher nicht nachvollziehen.
Wenn jemand etwas herausgefunden hat, bitte melden! Solange ich die Ursache nicht gefunden habe, kann ich auch keinen Workaround bauen….
Gruß und sorry, dass ich keine besseren Nachrichten habe…
Martin
Hey Martin, kein Problem, ich danke Dir für die Info. Ich werde in den nächsten Tagen versuchen das ganze noch einmal von Null an aufzusetzen. vielleicht habe ich auch irgendwo einen Fehler drin. Kannst Du mir sagen, wie ich bis dahin auf schnelle art und weise ein manuelles backup durchführen kann?
Hallo Timo,
willst Du nur von FHEM ein Backup erstellen oder vom ganzen Linux?
Von FHEM reicht Dir eigentlich die /opt/fhem/fhem.cfg und evtl. Dateien in /opt/fhem/FHEM (meist die 99*.pm), wenn Du Module erweitert hast oder angepasst.
Ich denke aber, Du denkst eher an das gesamte System. Das ist oft mühsam. Ich habe das immer so gemacht, dass ich in die ~/.bash_history reingeschaut habe, welche Befehle ich seit der Installation ausgeführt habe. Die Datei habe ich mir irgendwo ins NAS gespeichert, damit ich mir von dieser alten History die wichtigsten Befehle zum Aufsetzen und Installieren wieder rauskopieren kann.
Wenn es um geänderte Inhalte geht, dann würde ich diese Verzeichnisse manuell mit tar cvfz verzeichnis.tgz verzeichnis/ einpacken, aufs NAS werfen und danach mit tar xvfz verzeichnis.tgz im neuen System wieder auspacken.
Gruß
Martin
Das soll nicht gemein klingen, aber schön das ich nicht alleine zu doof bin , es hinzubekommen.
Gruß Peter
Hallo!
Ich habe auch den selben Problem, nur bei mir taucht im Logfile folgende Fehlermeldung:
PERL WARNING: Use of uninitialized value in numeric comparison () at (eval 17718) line 33.
Das wäre bei mir die Linie 33:
@mybackups = sort { eval($lastbackuptime{$a}) eval($lastbackuptime{$b}) } (@mybackups);
Leider meiner Programmierer kenntnisse sind nicht so groß um das Fehler zu korrigieren.
Vielen Dank
Und ich finde dein Modul/Post Großartig.
Viele Grüße aus Spanien 😉
Hallo,
das PERL WARNING ist nur eine Warnung, es ist nur wichtig, dass zwischen den beiden eval(..) das Kleinerzeichen, das Gleichheitszeichen und dann das Größerzeichen ohne Leerzeichen dazwischen stehen, also <=>.
Wenn es Probleme gibt, dann hängt das sicher nicht mit dieser Zeile zusammen. Was funktioniert denn genau nicht? Bleibt das Backup hängen oder kommt das Backup nicht auf dem NAS an?
Grüße nach Spanien (aus welcher Region kommst Du?)
Martin
Moin,
Ich hatte dieses Problem, das ich auch, das die Backups zwar local gemacht werden, aber nicht auf meiner Synology kopiert wurden. Was mich an der Sache sehr wunderte, das ich als „root“ und als „pi“ user zugriff auf das Verzeichniss fhembackup hatte aber halt als user „fhem“ nicht, trozu allen Vorschlagen was hier in den Kommentaren bereits Diskutiert wurde.
Meine Lösung nach 6 Stunden verzeiflung:
Hab irgendwann bei der Synology angesetzt und siehe da:
Unter Gemeinsamer Ordner –> Bearbeiten und den Reiter NFS-Berechtigung, dann den Client auswählen und die NFS-Regel bearbeiten.
Dann habe ich den „Squash“ von „Keine Zuordnung “ auf „Alle Benutzer und Admins zuordnen“ gestellt.
also eine andere einstellung wie oben in der Beschreibung aufn Bild.
Ich hoffe das andere hiermit auch erfolg haben und vielelicht noch ne bessere lösung finden.
viele Grüße
Marko
Hallo Marko,
das wäre ein Ansatz. Offensichtlich hat sich hier aber etwas im NFS-Zugriff geändert, denn diese Einstellungen hatten immer funktioniert. Mit diesen Einstellungen kann das Problem möglicherweise umgangen werden. In der Zwischenzeit habe ich aber noch etwas anderes probiert, man kann den user fhem in die sudoers aufnehmen. Dazu muss man allerdings einige Einstellungen machen. Ich werde das demnächst mal beschreiben, der Ansatz sollte das Problem mit dem Zugriff lösen können.
Gruß
Martin
Hallo Martin,
vielen Dank für deinen tollen Artikel. Es gibt einem ein sicheres Gefühl, wenn man weiß, dass das Backup nicht auf einer SD-Karte, sondern „doppelt und dreifach“ gesichert auf der Synology liegt. Dein Skript funktioniert bisher bei mir tadellos. Habe nur das folgende Problem laut Log:
019.01.24 06:21:12 1: PERL WARNING: Use of uninitialized value in numeric comparison () at (eval 175637) line 33.
2019.01.24 06:21:12 3: eval: my $NAME=’SYS_Backup‘;my $EVENT=’Ausführen‘;my $TYPE=’dummy‘;my $EVTPART0=’Ausführen‘;my $SELF=’SYS_BackupRun‘;{….
Denke das liegt daran, dass er SPORADISCH keinen Wert in “
SYS_last_Backup_size“ schreiben kann. Dein Skript habe ich 1:1 übernommen und schon mehrmals auf Übertragungsfehler kontrolliert. Kannst du mir helfen?
Viele Grüße Florian
Hallo Florian,
sorry, dass ich mich jetzt erst melde. Bin gerade vom Skifahren nach Hause gekommen.
Ich hatte damit noch kein Problem, dass er den Wert für die Größe nicht lesen kann, das scheint eher ein Timing-Problem zu sein.
Wie oft tritt das auf? Kannst Du das etwas eingrenzen?
Ich kann natürlich ins Skript einbauen, dass er die Größe nicht setzt bzw. einen Wert 0 und dann beim Vergleich entweder diese nochmal versucht zu lesen oder von der Sortier-Routine ausschließt.
Ich werde das in nächster Zeit mal dahingehend überarbeiten.
Gruß
Martin
Hallo Martin,
habe zunächst auch das Problem gehabt, dass das Backup-File nicht kopiert werden konnte. Mit dem Ansatz von Marko (s. o.) hat es auch bei mir geklappt. Dennoch wundern mich die vielen Log-Einträge:
2019.02.01 08:03:25 3: backup : Started the backup in the background, watch the log for details
Backup done
mv: Erhalten der Zugriffsrechte für „/mnt/synology/fhemBackup/FHEM-20190201_080325.tar.gz“: Die Operation ist nicht erlaubt
2019.02.01 08:03:55 1: PERL WARNING: Use of uninitialized value in eval „string“ at (eval 48808) line 33.
Dann wird der komplette Code ins Log geschrieben!
Das File kommt auf dem NAS an, das letzte Datum wird jedoch nicht in fhem geschrieben.
Hallo Marcel,
sorry, dass ich mich jetzt erst melde. Bin momentan beruflich ziemlich eingespannt.
Ich bekomme in der letzten Zeit immer wieder Rückmeldung, dass mein Skript scheitert oder Probleme auftreten, die vorher nicht aufgetreten sind und ohne eigenes Zutun nun zum Scheitern des Backups führen.
Zum einen hilft natürlich der Ansatz von Marko, allerdings nicht bei allen. Ich habe mittlerweile folgendes herausgefunden:
Ich habe dann nachgelesen und nachgelesen und bin nicht auf eine eindeutige Ursache gekommen, was dafür sorgt, warum es auf einmal nicht mehr funktioniert.
Anscheinend gibt es einen Bug im Login-Command, der über einen update hereingekommen ist. Ich konnte den Bug zwar nicht abstellen, aber ich habe herausgefunden, dass es überhaupt nur noch als root oder als sudoer möglich ist, von /opt/fhem/backup auf das NAS unter /mnt/syno/fhembackup/ zu verschieben oder zu kopieren.
Da nutzen die ganzen Zugriffsrechte auf /mnt/syno/fhembackup und darüber nichts, die sind mit 777 sowieso am Mountpount offen.
Nein, nur noch mit root-Rechten lässt sich über den automount eine Datei erstellen.
Ich hab dann folgendes gemacht, ich hab den User fhem in die sudoers aufgerufen. Du kannst dann natürlich noch die Befehle beschränken, die er darf, eigentlich braucht er nur den mv.
Ich hab also folgendes gemacht: (als user pi)
sudo usermod -G sudo fhem
dann schau in das Verzeichnis
/etc/sudoers.d
Wenn es dort eine Datei gibt 01_pi-nopasswd
dann kopier die mit
sudo cp /etc/sudoers.d/010_pi-nopasswd /etc/sudoers.d/020_fhem-nopasswd
Dann editierst Du den Inhalt auf
fhem ALL=(ALL) NOPASSWD: ALL
Nun hast Du das Recht, mit
sudo mv FHEM-20190220_231500.tar.gz /mnt/syno/fhembackup/
beispielsweise die FHEM* Datei zu bewegen.
Du musst das in dem Skript im fhem noch ändern, dass dies nur mit sudo mv geht.
Also die Zeile
`mv $longfile $destination`;
ändern in
`sudo mv $longfile $destination`;
Danach sollte es gehen. Zumindest bei mir funktioniert es jetzt….
Gruß
Martin
Hallo Martin,
da ich immer noch dabei bin das Problem zu lösen, eine kurze Frage. Kann ich jetzt deine Ausführung komplett so durch arbeiten und dann zu Schluß die hier ausgeführten Änderungen machen oder muss das zwischendurch schon passieren. So langsam kommt man irgendwie durcheinander was man jetzt wie machen soll ( soll keine Kritik sein, bitte nicht falsch verstehen)
Wie du weiß bin ich schon länger dabei es umzusetzten und habe schon sehr viel ausprobiert, deshalb wollte ich jetzt ganz von vorne anfangen und nochmal alles von vorne beginnen.
Gruß Peter
Hallo Peter,
guter Punkt, mir gefällt es ohnehin nicht mehr durch die ganzen Probleme, die im Laufe der Zeit aufgetreten sind. Wobei viele Probleme gar nicht durch das Skript selbst ausgelöst wurden, sondern von den Änderungen an den verwendeten Modulen, Betriebssystemfunktionen und Funktionalitäten des NAS.
Ich werde in meinem nächsten Urlaub den Beitrag komplett überarbeiten.
Im Grunde kannst Du aber vom ursprünglichen Beitrag ausgehen und die Änderungen einarbeiten – letztendlich reicht aber der aktuellste Eintrag. Das Skript selbst dürfte aber aktualisiert sein.
Lediglich die Änderungen an den Einstellungen des NAS und die der Rechte des Benutzers (sudoers) müssen bearbeitet werden.
Dann sollte es laufen.
Wenn es Probleme oder Unklarheiten gibt, einfach melden, aber im Augenblick komme ich nicht dazu, es komplett zu überarbeiten.
Gruß
Martin
Hallo Martin,
ich habe das ganze nochmal aufgebaut und die letzten Änderungen eingespielt. Und was soll ich sagen, die Sicherungen landen auf meine NAS, es funktioniert, suuuupppeeer.
Ich habe aber leider ein ganz kleines Problem, und zwar werden die Backup´s nicht in der richtigen Reihenfolge angezeigt.
dummy
FHEM Backup ausführen
FHEM-20190302_231500.tar.gz
FHEM-20190301_231500.tar.gz
FHEM-20190303_231500.tar.gz
FHEM-20190309_231500.tar.gz
FHEM-20190313_231500.tar.gz
FHEM-20190310_231500.tar.gz
FHEM-20190314_231500.tar.gz
FHEM-20190308_231500.tar.gz
FHEM-20190304_231500.tar.gz
FHEM-20190307_231500.tar.gz
FHEM-20190312_231500.tar.gz
FHEM-20190315_073905.tar.gz
FHEM-20190305_231500.tar.gz
FHEM-20190306_231500.tar.gz
FHEM-20190311_231500.tar.gz
Ausführen
letztes FHEM Backup Datum
11.03.2019 23:15:33
letztes FHEM Backup Größe 56064581 Bytes
woran könnte das liegen?
Gruß Peter
und nochmal vielen Dank für deine Mühe und Hilfe
Hallo Peter,
freut mich, dass es endlich klappt.
Wenn die Backups nicht in der richtigen Reihenfolge angezeigt werden, dann liegt das wohl daran, dass das Datum nicht richtig ausgelesen werden konnte.
Das liegt manchmal daran, dass das Perl-Skript nicht auf die Daten zugreifen kann.
In diesem Fall sortiere einfach über den Namen und ersetze die Sort-Zeile
@mybackups = sort { eval($lastbackuptime{$a}) <=> eval($lastbackuptime{$b}) } (@mybackups);mit
@mybackups = sort @mybackups;Gruß
Martin
Hallo Martin,
erst mal vielen Dank für die Anleitung, die sehr verständlich ist, nur bekomme ich das Backup-File nicht in den Mout-Ordner verschoben. fhem spukt mir im Log folgendes aus:
————————————————————————-
sudo: Kein TTY vorhanden und kein »askpass«-Programm angegeben
2019.03.13 09:37:55 3: set SYS_Backup : no set value specified
2019.03.13 09:45:28 2: Backup with command: tar -cf – „./CHANGED“ „./configDB.pm“ „./contrib“ „./demolog“ „./docs“ „./FHEM“ „./fhem.cfg“ „./fhem.cfg.demo“ „./fhem.pl“ „./log“ „./MAINTAINER.txt“ „./README_DEMO.txt“ „./restoreDir“ „./unused“ „./www“ |gzip > ./backup/FHEM-20190313_094528.tar.gz
2019.03.13 09:45:28 3: backup : Started the backup in the background, watch the log for details
Backup done
————————————————————————-
ich kann Test Dateien auf meiner Syno in dem Ordner erstellen und sehe diese auch auf meinen Pi in dem besagten gemouted Ordner nur wird die Backupdatei nicht verschoben.
Hast du eine Idee?
Vielen Dank und Grüße,
Joris
Hallo Joris,
das liegt höchstwahrscheinlich an den fehlenden Zugriffsrechten des Users fhem.
Sorry, dass ich mich jetzt erst melde, ich war einige Tage jetzt nicht zuhause.
Versuche mal, wie einige Posts vorher beschrieben (https://hausautomatisierung-koch.de/2017/02/19/naechtliche-sicherung-fhem-nas/#comment-225),
den User fhem in die sudoers aufzunehmen und die Zeile für das Verschieben
der Backup-Datei aufs NAS über sudo mv zu realisieren.
Dass Du von Dir erstelle Test-Dateien erstellen kannst ist klar, weil dies unter dem User pi geschieht und nicht unter dem User fhem.
Du wirst dem User fhem wie oben beschrieben erst das Recht hierfür geben müssen.
Das war nicht immer so. Erst seit einem bestimmten Update auf dem NAS gibt es Probleme mit der ursprünglich beschriebenen Lösung, die vorher fast zwei
Jahre ohne Probleme lief.
Gruß
Martin
Hallo Martin,
dank deines Kommentars vom 24. Februar 2019 um 11:40 Uhr hat nun auch der FHEM User Schreibrechte auf den NFS Mount.
Jetzt fällt mir auf, sobald ich von Hand ein Backup ausführe, ist während er das Backup zwischenspeichert unter /opt/fhem/backup FHEM nicht mehr erreichbar und ausgelastet. Die gzip Auslastung liegt dabei bei 95-100%:
pi@raspberrypi3:~ $ top
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
2591 fhem 20 0 2060 1220 956 R 100,0 0,1 7:02.89 gzip
2589 fhem 20 0 5812 2952 2612 S 3,9 0,3 0:13.46 tar
2881 pi 20 0 8240 3300 2768 R 1,6 0,3 0:02.38 top
Wenn ich die Backups ganz normale über die Weboberfläche anstoße, wie hier beschrieben https://wiki.fhem.de/wiki/Backup dann kann ich FHEM ganz normal weiterbenutzen.
Ist das ein normales Verhalten?
Hallo,
das ist mir auch schon aufgefallen und ich denke, das liegt daran, dass der tar sehr viel Ressourcen benötigt. Er wird direkt aus dem fhem.pl aufgerufen und obwohl lt. Coding im 98_backup.pm das Ganze im Hintergrund gestartet wird, hängt der Pi während der Zeit, bis er die Backup-Datei erstellt hat. Deswegen lasse ich das Backup immer nachts erstellen.
Ich rufe aber nur fhem(„backup“) als Funktion auf, das scheint anders zu sein, als wenn ich backup in der Konsole eintippe. Hab ich mir noch nicht genauer angesehen, warum das der Fall ist. Allerdings könnte man natürlich den Backup-Prozess „nicen“, also die Prozesspriorität herunterschrauben. Ich nutze ja ohnehin eine Warteschleife, bis das Backup über den Standardaufruf erledigt ist. Ich glaube, mit dem Einbau des „nice-Befehls“ direkt nach dem Starten des Backups könnte man etwas verbessern.
Vielleicht komme ich in den nächsten Tagen dazu und poste das hier.
Gruß
Martin
Hallo Martin,
vielen dank für den Artikel – bei mir klappts bisher auch nicht – aber ich habe mich noch nicht durch alle kommentare durchgearbeitet, zuletzt habe ich den vom Feb. 2019 durchgeführt, hier war in der Tat einiges zu ändern – aber getestet hab ichs noch nicht.
Meine frage wäre – ich brauche nämlich keine täglichen sicherungen – wie müsste ich das Script ändern um das 2x im Monat, meinetwegen am 10. und am 25. Tag durchzuführen?
Danke für deine Hilfe,
Florian
Hallo Florian,
sorry, dass ich jetzt erst antworte. Ich war zwei Wochen im Urlaub, bin gestern erst wiedergekommen.
Ja, die täglichen Sicherungen kannst Du dahingehend ändern, dass Du die Zeile
define job_BackupRun at *23:15:00 set SYS_Backup Ausführen
änderst auf in etwa so:
define job_BackupRun at *23:15:00 { if($mday==10 || $mday==25) { set SYS_Backup Ausführen } }
Gruß
Martin
Hallo zusammen,
für alle, die Fhem im Docker laufen haben, folgenden Hinweis.
beim Mount folgendes mit angeben: no_root_squash
Dann kann der auf dem Host gemountete Ordner im Docker Container eingebunden werden. Diesen kann man dann direkt als /opt/fhem/backup im Container mounten. So gehen die Backups direkt in den Mount. Bei dem Script zum ausführen des Backups noch den Pfad und den Teil zum verschieben der Datei entfernen( braucht man ja nicht mehr) und das ganze funktioniert.
Vielen Dank,
an die Problematik mit Docker und den Rechten hatte ich bisher noch nicht gedacht
Hallo Martin,
nachdem alles über Jahre wunderbar funktionierte habe ich nun seit gestern das Problem das mein Fhem bei dem Backup einen Fehler bringt und sich komplett aufhängt. Im Log steht folgendes:
Backup done
mv: reguläre Datei ‚/mnt/DLink/fhembackup_raspi3Bplus/FHEM-20190902_132557.tar.gz‘ kann nicht angelegt werden: Datei oder Verzeichnis nicht gefunden
mv: reguläre Datei ‚/mnt/DLink/fhembackup_raspi3Bplus/‘ kann nicht angelegt werden: Ist kein Verzeichnis
2019.09.03 07:37:57 1: ERROR evaluating my $EVENT=’Ausführen‘;my $EVTPART0=’Ausführen‘;my $SELF=’SYS_BackupRun‘;my $TYPE=’dummy‘;my $NAME=’SYS_Backup‘;{
fhem(„backup“);
sleep(5);
while(my $psoutput = `ps -ef | grep -v grep | grep FHEM`) {
sleep(10);
}
opendir DIR, „./backup“ or die $!;
my @mybackups = ();
my $lastbackupdatedatum = „“;
my $lastbackupdatesize = „“;
my %lastbackupsize;
my %lastbackuptime;
while(my $file = readdir DIR){
next if($file eq „.“ || $file eq „..“);
push(@mybackups,$file);
}
closedir DIR;
foreach my $file (sort @mybackups) {
my $longfile = „./backup/“.$file;
my $destination = „/mnt/DLink/fhembackup_raspi3Bplus/“;
`mv $longfile $destination`;
}
opendir DIR, „/mnt/DLink/fhembackup_raspi3Bplus“ or die $!;
@mybackups =();
while(my $file = readdir DIR){
next if($file eq „.“ || $file eq „..“ || $file eq „\@eaDir“);
my $mybackupfile = „/mnt/DLink/fhembackup_raspi3Bplus/“.$file;
push(@mybackups,$file);
$lastbackuptime{$mybackupfile} = (stat($mybackupfile))[9];
$lastbackupsize{$mybackupfile} = (stat($mybackupfile))[7];
}
closedir DIR;
@mybackups = sort @mybackups;
if($#mybackups > 0) {
my $mybackupfile = „/mnt/DLink/fhembackup_raspi3Bplus/“.$mybackups[$#mybackups];
my ($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst)=localtime($lastbackuptime{$mybackupfile});
$year += 1900;
$mon += 1;
$lastbackupdatedatum = sprintf(„%02d.%02d.%04d %02d:%02d:%02d“,$mday,$mon,$year,$hour,$min,$sec);
$lastbackupdatesize = $lastbackupsize{$mybackupfile}.“ Bytes“;
$mybackups[$#mybackups] = „„.$mybackups[$#mybackups].“„;
} else {
$lastbackupdatedatum = „kein Backup gefunden“;
$lastbackupdatesize = „kein Backup gefunden“;
}
@mybackups = join(„“, @mybackups );
fhem(„set SYS_Backup @mybackups“);
fhem(„set SYS_last_Backup_date $lastbackupdatedatum“);
fhem(„set SYS_last_Backup_size $lastbackupdatesize“);
fhem(„set teleBot message Fhem Backup wurde erstellt!“);
}
: No such file or directory at (eval 3479300) line 23.
Mein NAS ist aber zu 100% gemountet, wenn ich über ftp auf meinen Raspberry gehe komme ich über das Verzeichniss mnt auch auf mein NAS, so wie es schon immer war.
Kannst du mir ein wenig weiter helfen wo der Fehler liegen könnte? Wenn du weiter Informationen benötigst so frage einfach.
Danke Henri
Hallo Henri,
nachdem es ja lange Zeit funktioniert hat, muss sich aussen herum etwas geändert haben. Die Fehlermeldung läßt darauf schließen, dass auch in Deinem Falle der User fhem keinen Zugriff mehr auf das gemountete NAS-Verzeichnis hat. Wenn Du Dich über ftp anmeldest, wirst Du das wahrscheinlich mit einem anderen User drauf gehen, jedenfalls nicht mit dem User fhem. Du mußt Dich wirklich mit dem User anmelden, unter dem auch fhem läuft.
Vermutlich wirst Du beim Erzeugen einer Datei als User fhem ebenfalls keinen Zugriff mehr haben. Wenn dem so ist, dann sieh Dir mal folgenden Beitrag an:
https://hausautomatisierung-koch.de/2017/02/19/naechtliche-sicherung-fhem-nas/#comment-45
Es hatten schon mehr User das Problem, dass es plötzlich nicht mehr funktioniert hatte, unter anderem war auch ein Update auf dem NAS Schuld daran, dass es nicht mehr funktioniert hat.
Gruß
Martin
Hallo Martin,
nein daran liegt es nicht.
Ich habe jetzt noch einmal (mehrmals) das Backup manuell angestoßen, dabei geschieht folgendes….
– Das Backup wird auf der SD-Karte komplett erstellt
– Fhem stürzt ab, keine Reaktion mehr (Stunden gewartet)
jetzt habe ich „sudo reboot“ über Putty eingegeben um den Raspberry neu zu starten, da geschieht folgendes…
– Raspberry und Fhem starten neu
– Fhem überträgt das zuvor erstellte Backup von der SD-Karte auf mein NAS ohne weiteres zutun von mir
Wenn ich mich über ftp auf mein Raspberry einlogge nutze ich fhem als User.
Eventuell hast du ja noch einen Tipp…
Das einzige was ich am Tag zuvor (als das Problem kam) gemacht habe ist, ich habe meine Sonos Lautsprecher in Fhem eingebunden…, könnte es damit zusammen hängen?
Das wäre seltsam…
Danke
Henri
Hi Henri,
gut, dann können wir schon mal das Thema User und Berechtigungen ausschließen.
Mir fallen momentan zwei Dinge ein.
Zum ersten:
Mach mal im putty folgendes, wenn fhem beim Backup hängt. Der Raspi scheint ja noch zu tun, sonst könntest du ja nicht rebooten.
ps -ef | grep -v grep | grep FHEM
Wenn Du das machst, wenn fhem hängt (ich glaube nicht, dass fhem abgestürzt ist, sondert einfach nur hängt und nicht mehr reagiert), was ist die Ausgabe?
Da sollte hoffentlich nur der task laufen, der das backup macht und FHEM als Teilnamen hat. Wenn es mehrere Einträge gibt, dann haben wir ein Problem und müssten hier ansetzen.
Zweitens:
Mach mal aus dem mv einen sudo mv (mit Sudo-Rechten bewegen). Also aus diesem hier:
foreach my $file (sort @mybackups) {my $longfile = „./backup/“.$file;
my $destination = „/mnt/DLink/fhembackup_raspi3Bplus/“;
`mv $longfile $destination`;
}
dann
foreach my $file (sort @mybackups) {my $longfile = „./backup/“.$file;
my $destination = „/mnt/DLink/fhembackup_raspi3Bplus/“;
`sudo mv $longfile $destination`;
}
Zu den Sonos Lautsprechern: Direkt hat das sicher nichts damit zu tun, aber ich weiß nicht, was dabei alles installiert wird. Vielleicht läuft hier ein Job im Hintergrund – aber das ist alles nur Spekulation, ohne dass ich mich aufs System gesetzt habe…
Schau mal, ob Du weiterkommst.
Gruß
Martin
Hallo Martin,
erstmal Danke für deine schnellen Antworten und Hilfen.
Bevor ich das Update starte steht folgendes:
fhem 865 657 1 Sep05 ? 00:37:43 /usr/bin/perl ./FHEM/00_SONOS.pm 4711 0 0 startedbyfhem
während das Backup läuft steht folgendes (viel):
fhem 865 657 1 Sep05 ? 00:37:44 /usr/bin/perl ./FHEM/00_SONOS.pm 4711 0 0 startedbyfhem
fhem 19501 1 0 01:21 ? 00:00:00 sh -c (tar czf ./backup/FHEM-20190907_012126.tar.gz „./demolog“ „./www“ „./fhem.cfg.demo“ „./gassistant-fhem.cfg.previous“ „./log“ „./contrib“ „./restoreDir“ „./README_DEMO.txt“ „./MAINTAINER.txt“ „./alexa-fhem.cfg“ „./FHEM“ „./db.conf“ „./gassistant-fhem.cfg“ „./CHANGED“ „./configDB.pm“ „./unused“ „./docs“ „./fhem.cfg“ „./fhem.pl“; echo Backup done;/usr/bin/perl fhem.pl localhost:43927 ‚trigger global backup done‘)2>&1 &
fhem 19502 19501 5 01:21 ? 00:00:00 tar czf ./backup/FHEM-20190907_012126.tar.gz ./demolog ./www ./fhem.cfg.demo ./gassistant-fhem.cfg.previous ./log ./contrib ./restoreDir ./README_DEMO.txt ./MAINTAINER.txt ./alexa-fhem.cfg ./FHEM ./db.conf ./gassistant-fhem.cfg ./CHANGED ./configDB.pm ./unused ./docs ./fhem.cfg ./fhem.pl
nach dem Backup (Fhem reagiert nicht mehr):
fhem 865 657 1 Sep05 ? 00:37:45 /usr/bin/perl ./FHEM/00_SONOS.pm 4711 0 0 startedbyfhem
sieht für mich sehr nach Sonos aus, oder?
Danke
Henri
Hallo Henri,
genau, da spuckt Dir Sonos in die Suppe. Ich hatte schon mal ein ähnliches Problem und hatte irgendwann mal die Warteschleife deswegen angepasst.
Nachdem Du das ziemlich lange schon laufen hast, wirst Du den letzten grep tar nicht drin haben. Ändere die while-Schleife nach dem Backup auf
while(my $psoutput = `ps -ef | grep -v grep | grep FHEM | grep tar`) {\
sleep(10);;\
}\
Danach findet er den Eintrag von Sonos nicht mehr.
Gruß
Martin
Hallo Martin,
das hinzufügen von „grep tar“ führt leider nicht zum Erfolg.
Der Fehler bleibt weiterhin bestehen.
Naja ist Egal, liegt an Sonos kann ich nicht ändern, muss ich halt manuell daran denken immer ein Backup zu machen.
Trotz alle dem Danke für deine Hilfe…
mfg
Henri
Hallo,
ich habe versucht, die Datensicherung auf meiner WD-Cloud einzurichten.
Leider funktioniert die Einrichtung des Mountens, wie scheinbar alles unter Linux, auf Anhieb nicht (wieviel Lebenszeit ich schon mit Fehlversuchen unter Linux und FHEM zugebracht habe ??…..)
Ich habe die Konfiguration der Pfade nicht zu 100% übernommen.
Meine WD-Cloud heisst „FAMILIENCLOUD“.
Den Pafd habe ich aus dem Windows Explorer herauskopiert
———————————————————
Hier die Zeile in der „auto.synology“
fhembackup -fstype=nfs,rw,nouser,atime,auto,dev,exec,suid FAMILIENCLOUD:/raspberry/Datensicherung/FHEM_Pi
———————————————————
Hier die Zeile in der „auto.master“
/mnt/familiencloud /etc/autofs/auto.synology –ghost, –timeout=60
Leider kann ich nicht auf mein NAS zugreifen.
Bei zeigt sich unter /mnt/familiencloud ein weiteres Verzeichnis „fhembackup“, das sich nicht öffnen lässt.
Ich habe, allerdings über eine Verbindung durch die „fstab“ einen USB-Stick eingebunden, was auch funktioniert- nur die NAS will einfach nicht!
Kann mir jemand, trotz meiner unqualifizierten Angaben weiterhelfen?
Achim
Hallo,
die Angaben sind sehr präzise. Es liegt zum einen an den Einstellungen der WD-Cloud selbst als auch an der Datei auto.synology. Wie ist denn in der WD-Cloud das Verzeichnis freigegeben? Als NFS-Filesystem?
In der Synology NAS hatte ich am Anfang das Problem, dass auf bestimmte IP-Adressen eingeschränkt wurde. Ob sich das so in der WD-Cloud analog zur Synology einrichten kann, weiß ich nicht, da ich keine WD-Cloud besitze.
Noch was: Der Name FAMILIENCLOUD aus dem Windows Explorer sagt leider nichts über den IP-Namen und die nfs-Freigabe aus, denn das ist eine eigene Einstellung und kann für das smb-Protokoll separat und parallel zum nfs eingestellt werden. Windows Explorer nimmt nicht nfs, sondern smb.
Die Zeile aus der auto.synology funktioniert somit schon mal nicht.
Deswegen kann er auch das Verzeichnis nicht nach /mnt/familienclound mounten. Somit auch nicht öffnen.
Beim USB-Stick nehme ich auch an, dass dieser mit einem normalen Windows-Filesystem formatiert ist, deswegen geht das auch einfacher. NFS ist ein wenig komplexer.
Ich empfehle, dich ein wenig mit der Materie nfs auseinanderzusetzen und dann Einstellungen in der WD-Cloud vorzunehmen. Vermutlich musst Du dort mindestens die IP-Adresse des Raspberry eintragen, damit Du über nfs zugreifen darfst.
Gruß
Martin
# Wöchentliche Sicherung
Hallo vielen Dank für die Anleitung und Deine Arbeit.
Ich habe mit:
define job_BackupRun DOIF ([23:15:00|0]) (set SYS_Backup Ausführen)
die Sicherung wöchentlich realisiert, da ich pro Woche kaum Änderungen habe. Sollte ich was neues in Fhem realisiert haben, mache ich eben im Anschluss mit klick auf „Ausführen“ eine manuelle Sicherung. Man kann auch in der Synology ein Sicherungsverzeichnis Anlagen und dort einstellen wieviele Sicherungen man behalten möchte.
Mit dem at Befehl war mit wöchentliche Sicherung zu umständlich.
Hallo Martin,
hier nun mal eine positive Rückmeldung. Ich habe, deiner Anleitung folgend, heute das Backup in meinem FHEM-System integriert. Es läuft auf meinem NAS Synology DS212+ in Verbindung mit einem RPi3+.
Gruß und Danke für diese tolle Shript
Roman
Hallo Martin,
ich bekomme beim Start des Backup folgende Fehlermeldung:
mv: der Eigentümer für ‚/mnt/syno/fhembackup/FHEM-20200310_221500.tar.gz‘ konnte nicht beibehalten werden: Das Argument ist ungültig
2020.03.10 22:15:29 1: PERL WARNING: Use of uninitialized value in eval „string“ at (eval 1593) line 33.
Da meine Perl-Kentnisse leider nicht ausreichen den Fhler zu beheben möchte ich Dich bitten mal drauf zu schauen. Ansonsten klasse Tool. Danke und Gruß
Roman
Hallo Roman,
sorry, dass ich mich jetzt erst melde. Habe mir Dein Problem angesehen, ich denke, auch hier hat der Pi zu wenig Rechte, um auf die Daten des NAS zugreifen zu können.
Als Workaround empfehle ich ganz einfach, keinen mv (Verschieben der Datei), sondern ein cp (Kopieren) und dann rm (Löschen) zu machen.
Ersetze also den Block am Anfang
foreach my $file (sort @mybackups) {\
my $longfile = "./backup/".$file;;\
my $destination = "/mnt/syno/fhembackup/";;\
`sudo mv $longfile $destination`;;\
}\
durch
foreach my $file (sort @mybackups) {\
my $longfile = "./backup/".$file;;\
my $destination = "/mnt/syno/fhembackup/";;\
`sudo cp $longfile $destination`;;\
`sudo rm $longfile`;;\
}\
Probier es mal damit….
Gruß
Martin
Hallo Martin,
jetzt bin ich im Verzug. Das Kopieren ist erfolgreich. Danke schön für deine Hilfe.
Gruß
Roman
Etwas problematisch da inkonsistenzen zwischen den dateien auftreten können, da das backup auf dateiebene arbeitet.
„Besser“ für dynamische Inhalte unter Fhem wäre hier vermutlich eine Blockbasierte Sicherung, in meinem Fall läuft Fhem auf einem LVM, von diesem wird mit bordmitteln ein LVM-Snapshot erstellt und im folgenden der Snapshot weggesichert.
Ich nutze die von fhem zur Verfügung gestellte backup Funktion. fhem(„backup“); Alles was ich danach mache ist, das erstelle tgz-File umzubenennen und auf das NAS zu schieben.
Inkonsistenzen können nur zwischen mehreren Dateien auftreten, das wäre aber Sache der Backup-Funktion, die ich aufrufe. Ich habe nur 1 File, das ich sichere.
Das Modul 98_backup.pm sichert soweit ich das sehe auch nur bestimmte Inhalte in das tgz, die während der Laufzeit nicht verändert werden, wie die Config-Files.
Gleichzeitig kann auch kein Update laufen, dieses muss manuell angestossen werden. Somit können sich diese Files zur Zeit des Backups nicht ändern.
Wenn es sich um dynamische Files handeln würde, gebe ich Dir bzgl. LVM recht, dann wäre das ein Ansatz.
Ich kann nur sagen, dass ich mit dieser Lösung seit Jahren lebe und nach 2 Komplettcrashes eines Raspberries jedesmal problemlos über die Sicherung wieder herstellen konnte.
Gruß
Martin
Hallo Martin,
erst mal vielen Dank für die Anleitung. Nach einigen Stunden rumprobieren klappt jetzt soweit alles. Eine Frage hätte ich aber noch…
Mein Synology NAS ist so eingestellt, dass es nach 10 Minuten Inaktivität in den Ruhemodus geht. Somit funktioniert das verschieben auf das NAS dann teilweise nicht. Leider kann ich dort in den Energie Einstellungen auch nicht einstellen, dass es kurz vor dem verschieben erwacht.
Mein Ansatz ist nun, dass NAS ca. 1 Minuten vor der Sicherung aufzuwecken. Hast du da einen Tipp wie ich das am Besten anstellen kann (ich bin keine Linux Fachmann ;-))…
Vielen Dank vorab für deine Antwort
Uwe
Hallo Uwe,
schön, dass alles soweit klappt. Bzgl. der Synology NAS:
Solange Du das NAS nicht herunterfährst (das stellst Du unter Systemsteuerung/Hardware und Energie/Energiezeitplan ein),
sollte das Verschieben auch klappen, denn durch den Zugriff sollte sie aus dem Ruhemodus aufwachen.
Sollte das nicht klappen – bei mir geht das aber! – dann könntest Du ebenfalls in der Systemsteuerung den Aufgabenplaner einsetzen.
Wenn Du dort ein paar Minuten vor dem Skript irgendetwas startest und hinterher stoppst, dürfte das NAS nicht im Ruhemodus sein.
Eine andere Idee hätte ich jetzt auch nicht…
Viele Grüße
Martin
Hallo Martin,
ich habe meine SD-Karte auf eine SSD umgesiedelt. Seitdem läuft das Script nicht mehr bzw. der automounter. Die Bezeichnung haben sich nicht geändert und das NAS ist weiterhin erreichbar.
Der Aufruf von fstab zeigt das sich die Bezeichnung der Partition geändert haben, von /dev/mmcblk0 in PARTUUID=183c8a3a-01.
Kannst Du mir helfen?
Gruß
Roman
Vielen Dank für die tolle übersichtliche Anleitung, habe das Thema direkt für mich umgesetzt!
Eine Frage hätte ich zu deinem Backupvorgehen, wie sicherst du den Raspberry PI um? Machst du hier auch ein Backup von der Installation?
Ja, das mache ich aber manuell. Ich hatte es auch schon mal aus fhem angestoßen, allerdings hängt während dieser Zeit fhem, weil der Task zu 100% mit dem Abzug der Speicherkarte beschäftigt ist, weil der Abzug nicht im Hintergrund läuft.
Deswegen habe ich das über einen cronjob gelöst.
sudo dd if=/dev/mmcblk0 of=/media/mynas/backup/raspi_image.img bs=1M
Das mache ich wöchentlich nachts, wenn nichts los ist, um keine Inkonsistenzen zu erzeugen. Gefährlich z.B. wenn Du eine Datenbank laufen hast.
Hallo Martin,
erstmal ein dickes Lob für die tolle Ausarbeitung des Skriptes und der Anleitung.
Fehler wie Zugriffsrechte und falsche Sortierung konnte ich anhand dieser Seite lösen.