FHEM Forum

Hallo,

ich habe das backup.sh script in /opt/fhem/ liegen. Wenn ich dieses script via terminal auslöse, dann legt er schön ein backup ab. Aber wenn ich dies nun via FHEM steuern will, krieg ich immer eine Fehlermeldung:

So habe ich das DOIF erstellt:

([FHEM.Backup:state] eq "on") {system("sudo /opt/fhem/backup.sh &")} DOELSE

Es passiert nix. Und im Log zeigt es mir folgendes an:

2017.03.23 20:50:22 2: Backup_DOIF: {system("sudo /opt/fhem/backup.sh &")}: -1

Wir gehen davon aus, dass der lokale Systemadministrator Ihnen die
Regeln erklärt hat.  Normalerweise läuft es auf drei Regeln hinaus:

    #1) Resprektieren Sie die Privatsphäre anderer.
    #2) Denken Sie nach bevor Sie tippen.
    #3) Mit großer Macht kommt große Verantwortung.

sudo: Kein TTY vorhanden und kein »askpass«-Programm angegeben

was bedeutet das -1 hinter dem Logeintrag?

Hi,

steht doch eigentlich alles da.

Warum braucht Dein backup.sh sudo?
Was macht das?
Bloß sudo weil unter unter dem "Normaluser" kein Recht an /opt/fhem/ ?

Gruß Otto

Es wäre interessant zu sehen welche Rechte die Datei zur Zeit besitzt.

Ich würde die Dateirechte bzw. User so anpassen das FHEM diese auch ausführen darf.
Dann erspart man sich das sudo (was ja nicht zwangsläufig das Mittel der Wahl sein soll).

https://www.elektronik-kompendium.de/sites/raspberry-pi/2006091.htm (https://www.elektronik-kompendium.de/sites/raspberry-pi/2006091.htm)

Edith: Und hier war Otto schneller  ;D

danke Puschel74, chmod +x backup.sh hat glaub ich etwas geholfen.. jedoch gehts noch immer nicht..

Zitat von: Otto123 am 23 März 2017, 21:15:12
Hi,

steht doch eigentlich alles da.

Warum braucht Dein backup.sh sudo?
Was macht das?
Bloß sudo weil unter unter dem "Normaluser" kein Recht an /opt/fhem/ ?

Gruß Otto

danke für deine Antwort. Die Meldung ist für mich nicht ganz schlüssig (als Laie), deshalb habe ich mich an euch gewendet.  ich habe sudo verwendet, da mit dem code

([FHEM.Backup:state] eq "on") {system("/opt/fhem/backup.sh &")}

folgende Fehlermeldung geloggt wird:

2017.03.23 22:59:00 2: Backup_DOIF: {system("/opt/fhem/backup.sh &")}: -1
/mnt/backup bereits vorhanden
PING 10.0.1.18 (10.0.1.18) 56(84) bytes of data.
64 bytes from 10.0.1.18: icmp_seq=1 ttl=64 time=0.590 ms

--- 10.0.1.18 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.590/0.590/0.590/0.000 ms
10.0.1.18 erreichbar
/Q/backup bereits vorhanden
/Q/backup leer, Mounten starten
mountComplete: //10.0.1.18/FHEM /Q/backup cifs username=XX,password=YYY,iocharset=utf8,sec=ntlm 0 0
mountComplete: //10.0.1.18/FHEM /Q/backup cifs username=XX,password=YYY,iocharset=utf8,sec=ntlm 0 0
mountComplete: //10.0.1.18/FHEM /Q/backup cifs username=XX,password=YYY,iocharset=utf8,sec=ntlm 0 0
mountComplete: //10.0.1.18/FHEM /Q/backup cifs username=XX,password=YYY,iocharset=utf8,sec=ntlm 0 0
mountComplete: //10.0.1.18/FHEM /Q/backup cifs username=XX,password=YYY,iocharset=utf8,sec=ntlm 0 0
mountComplete: //10.0.1.18/FHEM /Q/backup cifs username=XX,password=YYY,iocharset=utf8,sec=ntlm 0 0
/etc/fstab: Eintrag bereits vorhanden: //10.0.1.18/FHEM /Q/backup cifs username=XX,password=YYY,iocharset=utf8,sec=ntlm 0 0
Mounts werden aktualisiert
mount: only root can use "--all" option
Mounten hat anscheinend nicht geklappt, skip.

da "only root can use "--all" steht, dachte ich, ich müsse sudo verwenden.. Denn vom terminal aus benutze ich auch sudo bash..

aber es geht nicht... hmm.. wo liegt wohl der Hund begraben?

Moin,

ich weiß es nicht genau, aber ich denke Du verwendest das mount falsch.
Klar ist in der Interaktion sudo immer einfach. Im Script ist es aus meiner Sicht immer schwierig und aus Sicherheitsgründen wurde ich immer versuchen es zu vermeiden.

Schau mal hier, vielleicht hilft das -> https://wiki.ubuntuusers.de/Samba_Client_cifs/

Gruß Otto

Danke Otto für deine Mühe und Geduld. Ich mach mich weiter auf die Suche... ;)

Worauf ich als erstes eine Antwort suche: Was genau ist der Unterschied, wenn ich das backup-script per teminal ausführe mit

sudo bash /opt/Fhem/backup.sh

und wenn ich es per fhem mit

system("sudo /opt/fhem/backup.sh &")

Am terminal gehts bestens, auf fhem leider nicht...

Ist der fhem-code falsch?

Vielleicht liegt es daran, dass sudo auf ein Passwort wartet:
Mein Environment:
ubuntu server 16.04, fhem-user: fhem

root@SERVERFHEM:/etc/sudoers.d# cat myOverrides
fhem    ALL=(ALL) NOPASSWD: /opt/fhem/FHEM/backup.sh, /etc/init.d/homebridge, /usr/bin/nmap


Herzlichen dank supernova, das wars! Es hat nun auch bestens geklappt... dadurch verstehe ich nun auch /etc/sudoers besser... danke

Hi,
Du hast zwar jetzt die Sache mit sudo "im Griff" aber ich hatte gemeint es ist besser fhem den mount zu erleichtern.

Gruß Otto

Hallo Otto,

bitte helfe einem Laien, wie mir, was meinst du genau mit 'mount erleichtern'?
Wie sähe denn die fstab aus, die das Ausführen der backup.sh von fhem besser und sicherer macht und was ist dabei unbedingt zu beachten bzw. welche Voraussetzungen müssen dafür geschaffen werden?

Eine Sicherheitslücke in fhem möchte ich unbedingt vermeiden.

Danke,

Gernot

Hallo Gernot,

ich habe das für dich mal durchgespielt, entsprechend meinem Link. Ich habe es als User pi getan, damit Du es nachvollziehen kannst:
Ich habe einen Windows Server mit einem share \\lsk2012\images.
Ich stehe in /home/pi/
mkdir ~/images # erzeugt einen Mountpoint in /home/pi/ -> /home/pi/images
nano .smbcredentials # erzeugt eine Datein .smbcredentials in /home/pi/
username=<benutzer>
password=<passwort>
domain=lsk2012
ctrl-o ctrl-x
chmod 600 ~/.smbcredentials  # Absichern der Datei
sudo nano /etc/fstab # einen entsprechenden Eintrag in der fstab erzeugen
//lsk2012/images /home/pi/images cifs noauto,users,credentials=/home/pi/.smbcredentials 0 0
ctrl-o ctrl-x
mount ~/images # mounted ohne sudo für den User pi das Verzeichnis \\lsk2012\images nach /home/pi/images

Alle Schritte stehen so auch in dem verlinkten Wiki.
Genauso geht das für den User fhem, das HomeDir für fhem ist typischerweise /opt/fhem
Ich würde in dem Fall den Mountpoint nach /media/ legen, da ist zusätzlich noch chown fhem:dialout /media/<mountdir> notwendig.

Damit sollte der mount Befehl in deinem Backup ohne sudo funktionieren.

Gruß Otto

Hallo Otto,

vielen Dank für deine Hilfe.
Deine Erklärung enthält viele interessante Aspekte.
(Hinweis: In deiner fstab, 3.-letzte Zeile, fehlt imo ein 'b" im Verweis auf die  .smbcredentials)

Was mich verwirrt ist, wird die Standard backup.sh für den user fhem ohne sudo dadurch ausführbar, dass es sein HomeDir - Verzeichnis ist, und, ist das nicht, - vorsichtig nachgefragt -, ein Problem in Bezug auf die Sicherheit?

lg

Gernot

Moin Gernot,

das mit dem b war in meiner Testumgebung ein Tippfehler, ich wollte es dann richtig schreiben aber hab natürlich die Zeile aus meiner fstab einfach copy&paste?  :-[
Ich habe den Fehler oben korrigiert.

Das mit Deiner Frage verstehe ich nicht. Aber ein erster Ansatz:
Dein Problem bisher ist, dass Du den "mount Befehl" (eher das Konstrukt der Einrichtung) so verwendet hast, das dieses dann Systemweit zur Verfügung steht und nicht nur für den aufrufenden User. Damit braucht es sudo.
Mit dem HomeDir hat Sicherheitstechnisch nur die Ablage der Credentials etwas zu tun. Dadurch, dass sie ersten versteckt und zweitens chmod 600 nur durch den Benutzer selbst verwendbar werden, sind sie vor anderen Usern eigentlich sicher.
In meiner Anleitung war User pi der Eigentümer. Wenn man das jetzt einfach nach fhem "delegiert" fehlt dazu noch das setzen des Eigentümers:  chown fhem /opt/fhem/.smbcredentials

Welches Problem siehst Du noch?

Gruß Otto

Hallo gernot,
du hattest das Problem gelöst, indem du den User FHEM zu den Sudoers hinzufügst. Somit hat der User FHEM ja alle Rechte erhalten die es gibt, da nach dem absenden eines Befehls mit sudo keine Sicherheitsabfrage (root Passwort) kommt, sind also alle Sicherheitsmaßnahmen ausgehebelt. Wenn du dagegen einem User über bestimmte Rechte den Zugriff auf einen Ordner oder eine Datei gewährst, dann kann er halt nur auf diesen Ordner / Datei zugreifen und sonst nix.

Wenn du also einen User zu der Gruppe Sudoers hinzufügst, ist dieser damit root gleich gesetzt und kann alle Systemeinstellungen verändern, auf alle Ordner/Dateien zugreifen und und und.

Ok, automatisierer, habe ich verstanden, der Eintrag in sudoers gibt, - auch wenn man es auf ein einzelne ausführbare Datei beschränkt -, dem user doch irgendwie, - wenn auch stark eingeschränkt -, root Rechte.

Danke, Otto, ich habe das Problem gar nicht, da mein DEV- und das LIVE-System jeweils in einer virtuellen Maschine läuft, die mit Time Machine im Hostsystem gesichert werden.
Aber ich wollte helfen, da ich erkannt habe, dass es sich um ein Rechte-Problem bei choetzu handelt. Den Sinn ein Backup in einem Unterverzeichnis von fhem abzulegen, habe ich nicht hinterfragt (ist, glaube ich, aber Voreinstellung). Du hast natürlich recht mit Allem, was du zu einem sinnvollen und sicheren Backup geschrieben hast. Deine Erläuterungen zur Einrichtung einer Samba-Freigabe und den Einstellungen zum mountpoint im HomeDir sind echt hilfreich. Nur die Nummer mit dem UserHome auf /opt/fhem, dass das wirklich typisch ist, war mir garnicht bewußt (habe ich bisher nicht).

So wie du es beschrieben hast, habe ich direkt keine Sicherheitsbedenken.

Welche größeren Sicherheitslücken siehst du denn konkret bei der kennwortfreien sudo Ausführung der Datei backup.sh oder, - was mich persönlich mehr interessiert -, von /etc/init.d/homebridge und /usr/bin/nmap. Hast du hierzu auch sicherere Alternativen?

Noch einmal Danke für die wertvollen Tips,

Gernot
 
   

Hallo Gernot,

mein Prinzip ist: nimm nicht einfach root oder Admin Konten wenn es nicht notwendig ist. Homebridge und nmap habe ich nicht im Einsatz, da kann ich adhoc nichts sagen.

Gruß Otto

Zitat von: supernova1963 am 27 März 2017, 22:22:01
Ok, automatisierer, habe ich verstanden, der Eintrag in sudoers gibt, - auch wenn man es auf ein einzelne ausführbare Datei beschränkt -, dem user doch irgendwie, - wenn auch stark eingeschränkt -, root Rechte.

Stark eingeschränkt?? du kannst als Mitglied der Gruppe sudoers alle Befehle durch voranstellen von 'sudo' mit root-Rechten ausführen - !!!ohne Passwortabfrage!!!. Somit gibt es keine Einschränkungen mehr, der Benutzer hat alle Macht über das System...
Daher soll man Standartnutzer nicht zu sudoers packen, sonder einem Standartnutzer (FHEM) durch hinzufügen von einzelnen Gruppen nur so viel Systemrechte geben wie er haben muss um zu funktionieren und nicht mehr! so viel wie nötig - so wenig wie möglich!

Und wenn man einen einzelden Befehl durch sudo erlaubt, sollte man gucken, das nicht ein normaler User den "Befehl" austauschen kann.

Sonst macht man es einigen Leuten ziemlich einfach
: Befehl durch etwasd "böses" austauschen
: per sudo starten lassen (oder bei cron/automatismen warten, bis Befehl gestartet wird)

Gibt mittlerweile sogar schon automatische Tools, die so etwas können ...

@wernieman: Korrekt, keine Schreibrechte für "normale User" wie fhem auf den spezifizierten ausführbaren Dateien!!!

@automatisierer: Ich glaube es liegt ein Missverständnis vor, mit dem von mir geposteten Eintrag erhält der user fhem nur für die spezifizierten ausführbaren Dateien das Recht den sudo Befehl ohne Passwort zu nutzen. Für alles andere wird das sudo Passwort verlangt!

Jo, da hast du wohl recht, dass hatte ich mal schlicht weg überlesen - sorry.

Kein Problem, aufgrund dieser Diskussion habe ich zumindest noch einmal alles überprüft,

Gernot

Hallo Otto

frage zu deinem Skript. Dieses habe ich nun schon eine zeitlang erfolgreich im Einsatz. Funktioniert soweit perfekt.

Meine Frage dazu: Könnte man das skript auch insofern abändern, dass es nicht nur von /opt/fhem ein Backup macht, sondern von der gesamten SD Karte, nämlich von /dev/mmcblk0

Ich habe versucht, dies in deinem Skript zu ändern, aber es geht wie nicht. Das Backup ist 129bytes gross.. ;)

So, habe ich es angepasst..

#!/bin/bash

mountIp="10.0......"
mountDir="Raspi1"
mountUser="pi"
mountPass="xyxyxy"
mountSubDir=""
localMountPoint="/Q/backup"

#optional
backupsMax="10"
localBackupDir="/mnt/backup"
###################################

perl /opt/fhem/fhem.pl 7072 "setreading Raspi1.Backup info backup starting now"

if [ ! -e "$localBackupDir" ]
then
echo "$localBackupDir wird erstellt"
mkdir -p "$localBackupDir"
else
echo "$localBackupDir bereits vorhanden"
fi

tar --exclude=backup -cvzf "/$localBackupDir/$(date +%y%m%d_%H%M%S)_Raspi1_backup.tar.gz" "/dev/mmcblk0" &>/dev/null

if ! ping -c 1 $mountIp
then
echo "$mountIp nicht erreichbar, stop"
perl /opt/fhem/fhem.pl 7072 "set Raspi1.Backup error"
perl /opt/fhem/fhem.pl 7072 "setreading Raspi1.Backup info $mountIp not found"
exit
else
echo "$mountIp erreichbar"
fi

localIp=$(hostname -I|sed 's/\([0-9.]*\).*/\1/')

if [ ! -e "$localMountPoint" ]
then
echo "$localMountPoint wird erstellt"
mkdir -p "$localMountPoint"
else
echo "$localMountPoint bereits vorhanden"
fi

if [ "$(ls -A $localMountPoint)" ]
then
echo "$localMountPoint nicht leer, kein Mounten notwendig"
else
echo "$localMountPoint leer, Mounten starten"
vorhanden="0"
while read line
do
mountComplete="//$mountIp/$mountDir $localMountPoint cifs username=$mountUser,password=$mountPass,iocharset=utf8,sec=ntlm 0 0"
echo "mountComplete: $mountComplete"
if [ `echo "$line" | grep -c "$mountComplete"` != 0 ]
then
echo "/etc/fstab: Eintrag bereits vorhanden: $mountComplete"
vorhanden="1"
break
fi
done < "/etc/fstab"
if [ "$vorhanden" != "1" ]
then
echo "/etc/fstab: Eintrag wird ergänzt: $mountComplete"
echo "$mountComplete" >> "/etc/fstab"
fi
echo "Mounts werden aktualisiert"
mount -a
sleep 3
fi

if [ "$(ls -A $localMountPoint)" ]
then
if [ ! -e "$localMountPoint/$mountSubDir/$localIp" ]
then
mkdir -p "$localMountPoint/$mountSubDir/$localIp"
else
echo "$localMountPoint/$mountSubDir/$localIp existiert bereits"
fi
find "$localBackupDir" -name '*Raspi1_backup.tar.gz' | while read file
do
fileSize="0"
fileSizeMB=$(du -h $file)
fileSizeMB=${fileSizeMB%%M*}
filename=${file##*/}
echo "$filename ($fileSizeMB MB) wird in den Backupordner verschoben"
if [[ "$pushoverToken" != "" && "pushoverUser" != "" ]]
then
curl -s -F "token=$pushoverToken" -F "user=$pushoverUser" -F "title=Raspi1 $localIp" -F "message=Backup mit $fileSizeMB MB wird erstellt" https://api.pushover.net/1/messages.json
fi
#mv "$file" "$localMountPoint/$mountSubDir/$localIp/$filename"
cp "$file" "$localMountPoint/$mountSubDir/$localIp/$filename"
rm "$file"
perl /opt/fhem/fhem.pl 7072 "set Raspi1.Backup off"
perl /opt/fhem/fhem.pl 7072 "setreading Raspi1.Backup backup $filename"
perl /opt/fhem/fhem.pl 7072 "setreading Raspi1.Backup backupMB $fileSizeMB"
perl /opt/fhem/fhem.pl 7072 "setreading Raspi1.Backup info backup done"
done
else
echo "Mounten hat anscheinend nicht geklappt, skip."
exit
fi

#Löschen alter Backups
if [[ "$backupsMax" != "" && "$backupsMax" != "0" ]]
then
perl /opt/fhem/fhem.pl 7072 "setreading Raspi1.Backup backupFilesMax $backupsMax"
backupsCurrent=`ls -A "$localMountPoint/$mountSubDir/$localIp" | grep -c "_Raspi1_backup.tar.gz"`
backupsDelete=$(($backupsCurrent-$backupsMax))
if [ "$backupsDelete" -gt "0" ]
then
echo "$backupsCurrent Backups vorhanden - nur $backupsMax aktuelle Backups werden vorgehalten - $backupsDelete Backups werden gelöscht"
ls -d "/$localMountPoint/$mountSubDir/$localIp/"* | grep "_Raspi1_backup.tar.gz" | head -$backupsDelete | xargs rm
else
echo "$backupsCurrent Backups vorhanden - bis $backupsMax aktuelle Backups werden vorgehalten"
fi
else
perl /opt/fhem/fhem.pl 7072 "setreading Raspi1.Backup backupFilesMax no limit"
fi

backupsCurrent=`ls -A "$localMountPoint/$mountSubDir/$localIp" | grep -c "_Raspi1_backup.tar.gz"`
perl /opt/fhem/fhem.pl 7072 "setreading Raspi1.Backup backupFiles $backupsCurrent"


echo "Mount wieder unmounten"
umount "$localMountPoint"

Sorry es Dir so direkt zu sagen, aber eine Direkte Sicherung von /dev/... mit einem tar ist NICHT möglich!

Danke für die schnelle und direkte Antwort. Wie löst ihr diese Situation?

Ich möchte einmal die Woche eine SD Karte Sicherung auf mein NAS sichern. Am liebsten per FHEM gesteuert.

zumindest unter Stretch mit Desktop gibt es ein Programm "SD card copier"
dieses erstellt lauffähige Klone der Boot-SD.

Wenn es dieses auch als Kommandozeile gibt könnte man zwei Micro-SD Karten über USB anstecken und zeitgeplant jeweils eine überschreiben.
ich mach das zur Zeit 1 x die Woche manuell. Hat auch den Vorteil dass kein SD Karten Leser dauerhaft im USB steckt.
USB Leser könnten ja auch durch spannungs-Spitzen getötet werden...

Pi runterfahren, SD Karte entnehmen und über einen Cardreader ein Image erstellen.

Bei mir läuft täglich ein inkrementelles Backup der SD Karte und wöchentlich ein komplettes. Unabhängig von FHEM per cron. Ich kann das Skript heute abend mal raussuchen (oder du fragst Google)


Kurz, weil mobil...

herzlichen Dank für die Antworten.

Ich mache z.Z. die Variante von CoolTux.. Das ist die manuelle Variante. Ich möchte es aber automatisieren, da ich nicht immer daran denke.
Die Lösung von Frank_Huber ist eine gute Alternative, aber eben auch ziemlich manuell ;)

KernSani, sehr gerne! Google frage ich dann, wenn ich dein Skript nicht umsetzen kann. Bin mal gespannt.

Danke nochmals.

Um es noch mal und noch mal und noch mal zu sagen. Wer sich auch nur Ansatzweise mit Linux, dessen Filesysteme und den generellen Aufbau eines -nixsystemes aus kennt, weiß das man von einem laufenden System keine 1 zu 1 Sicherung machen sollte.

• Datenbanken puffern Daten im Ram zwischen welche dann nicht mehr vorhanden sind, inkonsistenz drohen.
• Moderne Filesysteme verwenden Journaling und speichern kleine Marker zwischen. Auch diese können bei einem 1 zu 1 Kopie verloren gehen und somit ist das Filesystem korrupt (kaputt)

Für Leute die sich damit auskennen und nur für diese gibt es die Möglichkeit mittels dem tar Befehl eine komplett Kopie des System zu machen unter Berücksichtigung der Linuxgegebenheiten /dev /proc /sys und so weiter.
Danach erstellt man sich einen Plan und Hilfsmittel für ein Desaster Recovery mit entsprechenden Werkzeugen.
Somit wird aus einem minimalen System welches in 5 Minuten aufgesetzt ist und nach 10 min auf dem aktuellsten Stand ist durch ein Desaster Recovery innerhalb einer Stunde ein voll funktionstüchtiges System mit allen Services.

Wichtig. ALLE Services müssen vor einem Backup runter gefahren werden. Also auch ein FHEM. Einmal im Jahr wechsel ich bei meinen 3 Systemen Proforma die SD Karte. So ein Teil kostet unter 10 Euro pro Karte, das sollte ja wohl drin sein.



Grüße

auch eine Möglichkeit mir zu sagen " DU hast keine AHNUNG".. ;) Aber du hast absolut recht. Dein Post überzeugt mich und ich verstehe nun, wieso ich dies vermutlich auch in Zukunft händisch machen sollte...  Ich wechsle übrigens auch 1mal pro Jahr die SD Karte... ;)

Leon,

ich war anfangs auch skeptisch. bin zwar unter Linux eher der Amateur, aber vom Grunde her auch ITler. :-)

Aber das Raspbian Tool tut seinen Dienst! hab ich schon mehrfach getestet und zum neu aufsetzen meiner 4 Instanzen hab ich auch die Karten geklont.

Zitat von https://www.raspberrypi.org/blog/another-update-raspbian/:

ZitatSD card copier

One query which comes up a lot on the forums is about the best way to back up your Pi. People also want to know how to migrate their Raspbian install to a new SD card which is larger or smaller than the one they are using at the moment. This has been difficult with the command-line tools that we've recommended in the past, so there is now a new application to help with this, and you'll find it in the menu under 'Accessories'.

sdcc

The SD Card Copier application will copy Raspbian from one card to another – that's pretty much all it does – but there are several useful things that you can do as a result. To use it, you will need a USB SD card writer.

To take a common example: what if you want to back up your existing Raspbian installation? Put a blank SD card in your USB card writer and plug it into your Pi, and then launch SD Card Copier. In the 'Copy From Device' box, select "Internal SD Card", and then select the USB card writer in the 'Copy To Device' box (where it will probably be the only device listed). Press 'Start', watch the messages on the screen and wait – in ten or fifteen minutes, you should have a clone of your current installation on the new SD card. You can test it by putting the newly-copied card into the Pi's SD card slot and booting it; it should boot and look exactly the same as your original installation, with all your data and applications intact.

You can run directly from the backup, but if you want to recover your original card from your backup, simply reverse the process – boot your Pi from the backup card, put the card to which you want to restore into the SD card writer, and repeat the process above.

The program does not restrict you to only copying to a card the same size as the source; you can copy to a larger card if you are running out of space on your existing one, or even to a smaller card (as long as it has enough space to store all your files – the program will warn you if there isn't enough space). It has been designed to work with Raspbian and NOOBS images; it may work with other OSes or custom card formats, but this can't be guaranteed.

The only restriction is that you cannot write to the internal SD card reader, as that would overwrite the OS you are actually running, which would cause bad things to happen.

Please also bear in mind that everything on the destination card will be overwritten by this program, so do make sure you've got nothing you want to keep on the destination card before you hit Start!

Was beim RasPi meistens funktioniert, da durch wenig ram sehr wenig gecacht wird.

Nur meine Erfahrung als Administrator: Genau wenn man es braucht, hat man den Fall: Es funzt nicht ....

Nicht ohne Grund gibt es für BarMetal-Recovery (sehr) Teure Produkte im Backup Bereich ....

Meine Empfehlung (privat):
Alle Daten für eine Neuinstallation bereit haben (/etc, fhem etc) und im Notfall eine Neuinstallation und Config aus dem Backup.
Wenn man eine Installationsanleitung sich gemacht hat (Ich weiß, vergisst man meistens), hat man auch schon ein sehr gutes Backup ;o)

P.S: Mein Backup /etc und fhem.cfg hat mir privta schon "den Arsch" gerettet ... die Familie kann böse sein, wenn diverse "Dienste" nicht gehen ...

Der SD Klon sollte auch nicht das einzige Backup sein.
Das zuverlässigste und sicherste ist zweifelsfrei wie von Leon geschrieben das herunterfahren, SD Karte raus und manuell klonen.
Dabei ist aber das System ne "Weile" offline. Das will man sicherlich nicht jede Woche machen.

meine "Strategie"
- FHEM Backup auf Fileserver jede Nacht.
- einmal wöchentlich der "online SD Klon"
- unregelmäßig so alle 3 bis 6 Monate den offline Klon.

Und wenn nach knapp 2 Jahren das System streikt kann man ja auch überlegen ob man nicht auf aktuellem Raspbian wieder aufsetzt und nur das FHEM Backup zurückholt.
Eine gute Doku der installierten Debian Pakete und FHEM Module ist dabei unersetzlich.

P.S. und Backup bitte Versionieren ... also mehr als eine "Version"

Guten Morgen,

ich komme auf oben stehendes Thema zurück. Ursprünglich hat das backup.sh geklappt. Nachdem ich aber versucht habe, das selbe für die ganze SD Karte zu machen, hat es mir irgendwie etwas geändert, was ich nicht wollte. Nun kommt beim täglich backup von FHEM folgende Meldung:

10.0.1.18 erreichbar
/Q/backup bereits vorhanden
/Q/backup leer, Mounten starten
mountComplete: //10.0.1.18/FHEM /Q/backup cifs username=pi,password=xx,iocharset=utf8,sec=ntlm 0 0
mountComplete: //10.0.1.18/FHEM /Q/backup cifs username=pi,password=xx,iocharset=utf8,sec=ntlm 0 0
mountComplete: //10.0.1.18/FHEM /Q/backup cifs username=pi,password=xx,iocharset=utf8,sec=ntlm 0 0
mountComplete: //10.0.1.18/FHEM /Q/backup cifs username=pi,password=xx,iocharset=utf8,sec=ntlm 0 0
mountComplete: //10.0.1.18/FHEM /Q/backup cifs username=pi,password=xx,iocharset=utf8,sec=ntlm 0 0
mountComplete: //10.0.1.18/FHEM /Q/backup cifs username=pi,password=xx,iocharset=utf8,sec=ntlm 0 0
/etc/fstab: Eintrag bereits vorhanden: //10.0.1.18/FHEM /Q/backup cifs username=pi,password=xx,iocharset=utf8,sec=ntlm 0 0
Mounts werden aktualisiert
mount error(22): Invalid argument
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)
Mounten hat anscheinend nicht geklappt, skip.

Mount error (22). Wenn ich das Google kommt vieles, aber alles irgendwie chinesisch für mich.. Was meint ihr?

Lg c

Zitat/etc/fstab: Eintrag bereits vorhanden: //10.0.1.18/FHEM /Q/backup cifs username=pi,password=xx,iocharset=utf8,sec=ntlm 0 0

Bearbeitest Du Deine fstab??

hallo wernieman, danke.

was meinst du mit bearbeiten? geändert? Ja, habe ich gemacht mit "sudo nano etc/fstab  und dann die entsprechende Zeile wieder rausgelöscht, nachdem ich sie manuell reingemacht habe..

Hmm, hab ich (wieder) Scheiss gemacht? ;)

lg c

was ist denn genau gemountet?
mount

Problem hatte ich auch. Du musst in der fstab folgendes ändern:

//192.168.100.20/backup /Q/backup cifs username=xxxxx,password=xxxxx,iocharset=utf8,sec=ntlm 0 0

in
//192.168.100.20/backup /Q/backup cifs username=xxxxx,password=xxxxx,iocharset=utf8,sec=ntlmssp 0 0

Zitat von: Wernieman am 24 April 2018, 13:22:22
was ist denn genau gemountet?

Code Auswählen Erweitern

mount

ich mounte mein NAS... Es hat vor meinen Manipulationen wunderbar geklappt..

@Matze66: Das probier ich heute Abend aus. Danke.

Oder einfach den "eigentlich) nicht nötigen Parameter "sec=ntlmssp"  rausnehmen

Guten Morgen

Das backup hat geklappt, aber es gibt immer noch die Fehlermeldung . Hmm, woher kommt das wohl?

/etc/fstab: Eintrag bereits vorhanden: //10.0.1.18/FHEM /Q/backup cifs username=pi,password=xx,iocharset=utf8
Mounts werden aktualisiert
mount error(22): Invalid argument
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)
/Q/backup//10.0.1.34 existiert bereits
180425_010000_fhem_backup.tar.gz (35 MB) wird in den Backupordner verschoben
11 Backups vorhanden - nur 10 aktuelle Backups werden vorgehalten - 1 Backups werden gelöscht
Mount wieder unmounten

Guck mal mit
mount
ob an dem Mountpoint schon etwas gemountet ist ...

Hallo Wernieman
danke für deine Geduld.. ;)

Wenn ich mount eingebe kommt eine lange liste, jedoch nirgends etwas von /Q/backup oder 10.0.1.18... Brauchst du die ganze Liste?

mount | grep Q

Kannst Du nicht sinvollere Namen als "Q" verwenden?

Unix braucht keine Laufwerksbuchstaben, da sollte man dann lieber sinvolle Mountpoint-Namen verwenden.

Hat er von meintechblog, die haben es mal so benannt ;)

Und schon vom Namen weiß man dann, das sie eher von Windows als von Linux Ahnung haben ..... *grummel*

mount | grep Q

hat nix rausgespuckt...

meinst du es liegt an Q ? Bevor ich versuche das zu ändern (mit meinem Mac ;), will ich nur sicher gehen, dass es daran liegen könnte.. Danke.

Es liegt sicher nicht am Buchstaben, sondern an anderer Stelle. Vielleicht fragst du mal im Blog an, immerhin haben die das Script geschrieben :)

Nein ... nur die Fehlermeldung, die Du gepostet hast, sagt aus, das es schon ein mount gibt ....

- Funktioniert es denn als root?
- Kann denn fhem das sudo?

Hallo zusammen,

nun habe ich auch Probleme mit meinen Backup.sh script.

2019.02.13 09:11:19 5: Triggering FHEMBackupOn
2019.02.13 09:11:19 4: FHEMBackupOn exec {system ("sudo -u root /opt/fhem/FHEM/backup.sh &")}
2019.02.13 09:11:19 3: FHEMBackupOn return value: -1
/backup bereits vorhanden
2019.02.13 09:11:40 2: AttrTemplates: got 53 entries
PING 192.168.20.2 (192.168.20.2) 56(84) bytes of data.
64 bytes from 192.168.20.2: icmp_seq=1 ttl=64 time=0.475 ms

--- 192.168.20.2 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.475/0.475/0.475/0.000 ms
192.168.20.2 erreichbar
/mnt/fhemBU bereits vorhanden
/mnt/fhemBU leer, Mounten starten
mountComplete: //192.168.20.2/home /mnt/fhemBU cifs username=name,password=pw,iocharset=utf8,sec=ntlmssp 0 0
mountComplete: //192.168.20.2/home /mnt/fhemBU cifs username=name,password=pw,iocharset=utf8,sec=ntlmssp 0 0
mountComplete: //192.168.20.2/home /mnt/fhemBU cifs username=name,password=pw,iocharset=utf8,sec=ntlmssp 0 0
mountComplete: //192.168.20.2/home /mnt/fhemBU cifs username=name,password=pw,iocharset=utf8,sec=ntlmssp 0 0
mountComplete: //192.168.20.2/home /mnt/fhemBU cifs username=name,password=pw,iocharset=utf8,sec=ntlmssp 0 0
mountComplete: //192.168.20.2/home /mnt/fhemBU cifs username=name,password=pw,iocharset=utf8,sec=ntlmssp 0 0
mountComplete: //192.168.20.2/home /mnt/fhemBU cifs username=name,password=pw,iocharset=utf8,sec=ntlmssp 0 0
mountComplete: //192.168.20.2/home /mnt/fhemBU cifs username=name,password=pw,iocharset=utf8,sec=ntlmssp 0 0
mountComplete: //192.168.20.2/home /mnt/fhemBU cifs username=name,password=pw,iocharset=utf8,sec=ntlmssp 0 0
mountComplete: //192.168.20.2/home /mnt/fhemBU cifs username=name,password=pw,iocharset=utf8,sec=ntlmssp 0 0
mountComplete: //192.168.20.2/home /mnt/fhemBU cifs username=name,password=pw,iocharset=utf8,sec=ntlmssp 0 0
mountComplete: //192.168.20.2/home /mnt/fhemBU cifs username=name,password=pw,iocharset=utf8,sec=ntlmssp 0 0
/etc/fstab: Eintrag wird ergänzt: //192.168.20.2/home /mnt/fhemBU cifs username=name,password=pw,iocharset=utf8,sec=ntlmssp 0 0
Mounts werden aktualisiert
mount error(95): Operation not supported
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)
mount error(95): Operation not supported
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)
Mounten hat anscheinend nicht geklappt, skip.

Hatte diesen Thread und ein paar andere dazu gefunden nur leider keine Lösung.

mountIp="192.168.20.2"
mountDir="home"
mountUser="name"
mountPass="pw1"
mytelnetPW="pw2"
mountSubDir="RaspiBU"
localMountPoint="/mnt/fhemBU"

in meiner fstab sehe ich auch:
//192.168.20.2/home /mnt/fhemBU cifs username=name,password=pw1,iocharset=utf8,sec=ntlmssp 0 0

Leider aber legt er sich immer hin und macht den Job nicht zuende :\

EDIT: Nochmal angepasst wegen eines sehr dummen Fehlers! Deswegen ist mein Post nun unter dem von Wernieman.

Wie testet man das am besten?
- Ich glaube FHEM kann sudo. ~80% sicher...

geh mal in die Konsole und setze "mount -a" ab.
Dann prüfe ob der Share verbunden ist.

Worauf läuft der Share?

Das Share Verzeichnis liegt auf meinem NAS (Synology). Habe diverse Jobs, die dort hingehen und auch diverse Applikationen darauf. Also ich kann nur klar sagen, Synology sind in meinen Augen die besten Home NAS Systeme. Nun denn...soviel dazu.

sudo mount -a ergibt:

pi@Raspi:/etc $ sudo mount -a
mount error(95): Operation not supported
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)


Nach google ist das ein Rechte Problem. Aber mit pi und sudo? Hmmm

Benutzername / Passwort stimmen für die NAS?

oder evtl die mount Parameter? ",sec=ntlmssp 0 0" könnte auch falsch sein.
schau mal hier: https://forum.ubuntuusers.de/topic/synology-nas-beim-start-mounten/

Benutzer u PW sind korrekt. Beim ersten Test lief das ohne Probleme. Da sah ich aber das er in Q mountet und das fand ich bescheiden.
Naja aber egal ob Q oder nun in /mnt/fhemBU, geht es nicht mehr.

Den Parameter sec=ntlmssp oder sec=ntlm oder ganz weg, bringt keine Verbesserung. Aktuell hab ich den ganz rauß genommen.

Existiert den der Mountpoint?
ls -lha /mnt/fhemBU

Und was steht in den Logfiles?
cat /var/log/kern.log
cat /var/log/syslog

ls -lha /mnt/fhemBU = MountPoint ist da und sieht aus wie es aussehen soll.
cat /var/log/syslog = Hier hab ich auch noch einen toten Dienst gefunden. Hat nix damit zu tun aber gut zu wissen!


Problem gefunden....

Hab in diversen Foren gelesen das zum einen sec=ntlmssp weg soll und man beim mount noch vers=1/2.0 eintragen soll. Ich habe mal 2 genommen, da die neuer ist.
Jetzt geht es durch.

Der Befehl ist mir neu "ls -lha /mnt/fhemBU" - Aber der kommt auch erst mal in meine Liste. Guter Befehl zum prüfen!

Sorry aber ein "ls" sollte man als "Basic" Wissen. Ist "vergleichbar" mit dem Windows "Dir".

Die Parameter:
l : Langes Auflisten (also Größe, User etc.)
h : "Human readeble"
a : Zeig alles (auch die . Dateien)


ansonsten siehe Hilfe, also man
man ls

ls kenne ich aber dieses Konstrukt war mir unbekannt.