Backup und Restore von FHEM

Backup ist immer eine gute Idee und sollte regelmäßig erfolgen. Noch viel wichtiger ist, dass man das Backup auch durch einen Restore verifiziert hat!
Viele machen Backup - aber kontrollieren?
Oder wie geht Restore?
Nachtrag 2021: Der Artikel gilt für eine externes Backup/Restore nach wie vor. Auch wenn man mit Windows 10 kein WinScp mehr benötigt, da ssh/scp direkt im System verfügbar ist.

Hinweis auf den restore Befehl: Im Wiki gibt es Beiträge wie der FHEM eigene restore Befehl verwendet werden kann. Link1  Link2

HowTo - live backup und restore einer virtuellen Maschine mit libvirt

Einleitung

Das Management User Interface libvirt steuert QEMU welches auf KVM aufsetzt. Die Basis für dieses Backup/Restore bildet die Verkettung von Diskimages.

Da hier und in der restlichen Dokumentation nichts über ein restore zu finden ist und das backup bekanntlich erst nach einem restore erfolgreich sein kann - habe ich ein kurzes HowTo geschrieben. Das ist noch nicht perfekt! 

Bitte am Ende den Abschnitt ToDo beachten!

Wem das zu sehr ins Detail geht, es gibt auf GitHub auch ein installierbares Tool welches die API von libvirt nutzt.

HowTo - FHEM Umzug von System A nach System B

Scenario: Umzug auf neues System

• System Alt: altes Linux, alte Hardware ...
• System Neu: neues Linux, neue/andere Hardware Plattform ...

Zwei verschiedenen Hardware Systeme sind etwas einfacher zu handhaben, es geht aber auch auf der gleichen Hardware (z.B. Raspberry Pi mit SD Card Wechsel oder USB-Bootstick). Ich habe alle Schritte mit einem Raspberry Pi(Raspberry OS Lite) und einer Virtuellen Maschine(debian 11 netinst) getestet. Dieses HowTo ist auch eine Ergänzung zu meinem vorjährigen Artikel.

Mit dem Raspberry Pi Imager kann man eine neue SD Card effektiv vorbereiten und das System grundlegen konfigurieren (Zahnradsymbol am rechten unteren Rand nachdem man das OS ausgewählt hat) 

Es gab von mir schon ein paar ähnliche Artikel, dieser hier soll ganz gezielt Schritt für Schritt zeigen was zu tun ist. Windows 10 hat ssh und scp eingebaut, andere Tools braucht man nicht. Wer nicht mit Windows CMD arbeiten will findet die Codezeilen für Schritt 1 am Ende auch für Linux und Powershell.

Man kann alle Schritte beliebig oft wiederholen / durchspielen und dabei lernen.

Achtung (03.2024): Das FHEM Installermodul wird leider nicht mehr gepflegt, es häufen sich die Meldungen, das mein hier gezeigtes Verfahren der Ermittlung der fehlenden Debianpakete nicht mehr funktioniert. Ich habe derzeit keine Problem Behebung!

Neues Linux System - Nacharbeit

Generell ist es relativ einfach eine bestehende FHEM Installation auf ein neues Betriebssystem/System zu setzen:

1. Backup FHEM
2. Kopie der aktuellen Backupdatei -> Server | USB Stick | per scp lokal
3. sudo halt
4. neue SD Card mit aktuellem Image (ich behalte immer die alte SD erstmal in Reserve)
5. setupBasic, setupFhem, testen
6. Backupdatei verfügbar machen -> Server | USB Stick mounten | per scp - lokal -> nach /home/pi
7. stop fhem
8. restore des Backups
9. start fhem

Sicherung / Backup

Bei mir ist beim obigen Plan mindestens die Anbindung an Dateiserver und die ssh Verbindung auf der Strecke geblieben. Schritt 1 und 8 muss man dafür noch etwas ausbauen.

Sicherung ssh Umgebung

Die notwendigen Dateien befinden sich in diesen Verzeichnissen:

• /etc/ssh für den ssh Host / Server
• /opt/fhem/.ssh für den User fhem
• /home/pi/.ssh für den User pi. 

Ich werde zwei zusätzliche Dateien in den Backup Ordner von FHEM erstellen. Dies könnte man auch von FHEM von Zeit zu Zeit machen lassen. Neben der Datei für eine Historie mit Zeitstempel erzeuge ich noch eine ohne Zeitstempel. Damit muss man bei der Wiederherstellung nicht lang suchen.
Man kann dieses als Script auch unter FHEM ausführen, da aber Systemdateien gesichert werden, muss tar als sudo ausgeführt werden. Damit das funktioniert, muss die zuständige Datei um /bin/tar ergänzt werden.

datei=/opt/fhem/backup/ssh$(date +%Y%m%d_%H%M%S).tar.gz
sudo tar -czf $datei /etc/ssh /opt/fhem/.ssh /home/pi/.ssh
sudo cp $datei /opt/fhem/backup/ssh.tar.gz

Falls der User fhem gar kein ssh verwendet kommt ein Fehler, dann muss man die Befehle abwandeln. Da die Dateien nicht voluminös sind, kann man auf zip verzichten. Damit kann das tar Archiv leichter mit der Option -rf ergänzt werden.

sudo tar -cf $datei /etc/ssh /home/pi/.ssh
cp $datei /opt/fhem/backup/ssh.tar

Der folgende Zweizeiler wirft zwar Fehler, sichert aber die ssh Dateien für alle existierenden User.

datei=ssh$(date +%Y%m%d_%H%M%S).tar
sudo tar rf $datei /etc/ssh $(awk -F: '$3>998{print $6"/.ssh"}' /etc/passwd)

Will man einfach in FHEM die ssh Key für user fhem sichern kann man das auch dort machen: 

"datei=./backup/sshFhem$(date +%Y%m%d_%H%M%S).tar;; tar -cf $datei ./.ssh"

Und auch später wiederherstellen:

"datei=./backup/sshFhem*.tar;; tar -xf $datei ./.ssh"

Sicherung Dateiserver Umgebung

datei=/opt/fhem/backup/fsconf$(date +%Y%m%d_%H%M%S).tar.gz
sudo tar -czf $datei /etc/fstab /usr/.*credentials /etc/davfs2/secrets
cp $datei /opt/fhem/backup/fsconf.tar.gz

Hat man Scripte o.ä. zusätzlich in anderen Pfaden, kann man die natürlich einfach in dem tar Befehl ergänzen und gleich mit sichern oder eine weitere Datei nach gleichem Schema erzeugen.

Finale Sicherung des alten Systems

Damit man den finalen Status im FHEM System behält, muss man FHEM beenden und dann ein backup durchführen!

systemctl stop fhem
datei=/opt/fhem/backup/FHEM-$(date +%Y%m%d_%H%M%S).tar.gz
tar -czf $datei -C /opt/fhem --exclude ./backup ./

Wenn das Backup zu Ende ist, startet man beispielsweise das Script /opt/fhem/backupFhem.sh und kopiert alle aktuellen Dateien damit auf den Sicherungsserver.
Am Ende des Artikels habe ich noch den Hinweis auf Alternativen zum Server.

Wiederherstellung

Nachdem das neue System grundlegend installiert und getestet ist (Ergänzung Schritt 5. optional: setupDavfs) wird die Sicherung zurückgespielt.
Die Verbindung zu meinem Windows Server geht relativ simpel. Ohne Angabe des Usernamens wird der momentane User (root) verwendet. Ohne Angabe des Passwortes wird es abgefragt:

sudo su
mount -t cifs //ServerName/Freigabe /mnt
mount -t cifs -o username=UserName //ServerName/Freigabe /mnt
mount -t cifs -o username=UserName,password=Passwort //ServerName/Freigabe /mnt

Ist das Laufwerk verbunden, kann auch ohne lokale Kopie sofort mit der Wiederherstellung begonnen werden.

datei=/mnt/fhem/$(hostname)/backup/FHEM-$(date +%Y%m%d_%H%M%S).tar.gz
tar -xzf $datei -C /opt/fhem

Querverweis: Falls die Module im alten System nicht gut dokumentiert waren, hilft eventuell dieser Beitrag.

Wiederherstellung ssh

Bei meinen Systemen wurde immer nur der ecsda Key verwendet. Ich möchte nicht die neue ssh Server Gesamtkonfiguration zerstören (da ändert sich immer mal was, ich habe nicht untersucht was genau) sondern nur das wiederherstellen was gebraucht wird. Unter der Annahme: es gibt nur eine aktuelle Datei im Verzeichnis, wird damit der ecdsa Key in /etc/ssh wieder hergestellt:

datei=/mnt/fhem/$(hostname)/backup/ssh.tar.gz
tar -xzf $datei -C / --wildcards etc/ssh/ssh_host_ecdsa_*

Um die User .ssh Verzeichnisse wieder herzustellen, sollte dieser Befehl gut sein

tar -xzf $datei -C / home/pi/.ssh/ opt/fhem/.ssh/

Damit steht die ssh Umgebung wieder.

Wiederherstellung Verbindungen zum Dateiserver

Die für die Verbindung verantwortlichen Scripte sollten im /opt/fhem Verzeichnis liegen und sind damit schon Teile der Wiederherstellung. Die Datei /etc/fstab und die jeweiligen Credential Dateien liegen aber unter Umständen "verstreut" im System und sind jetzt entweder nicht vorhanden oder neu gemacht.
Zunächst die credential Datei(en) in /usr/

datei=/mnt/fhem/$(hostname)/backup/fsconf.tar.gz
tar -xzf $datei -C / --wildcards usr/.*credentials

Die davfs2/secrets will ich nur ergänzen, davfs muss schon installiert sein!

tar -xzf $datei etc/davfs2/secrets -O|grep magentacloud >> /etc/davfs2/secrets

Ich möchte gern die fstab nicht überbügeln sondern die neue Datei einfach um meine Einträge ergänzen. Existieren z.B. mehrere Mountpoints in /media/ - kann das in einer Zeile erledigt werden:

tar -xzf $datei etc/fstab -O|grep /media/ >> /etc/fstab

Jetzt müssen noch die Mountpoint erzeugt werden:

mkdir $(tar -xzf $datei etc/fstab -O|grep -o '/media/[a-Z,0-9]*'|tr '\n' ' ')

Jetzt kann man das Sicherungslaufwerk wieder trennen.

umount /mnt

Die Verbindung zu davfs2 erfordert auch noch die Gruppenmitgliedschaft in der Gruppe davfs2

usermod -aG davfs2 fhem

Die Gruppenmitgliedschaft greift erst nach erneutem Login! Also mindestens FHEM neu starten!

Alternativen zum Sicherungsserver

USB Stick
Man könnte einen USB Stick verwenden, der Raspberry Pi 3 verkraftet das Stecken im laufenden Betrieb. Bei allen anderen Typen und "zur Vorsicht" ist aber vom Stecken eines USB Sticks im laufenden Betrieb abzuraten. Zuerst schauen welches Device der Stick geworden ist und dann einfach temporär mounten:

lsblk
mount /dev/sda1 /mnt

SCP - lokale Kopie
Mit scp ist es recht simpel sich eine Kopie der Dateien lokal zum holen und diese später zurück zu spielen. Geht auch unter Windows 10 ab 1809 einfach so!

scp pi@hostname:dateiname .
scp dateiname pi@hostname:

Die Restore Befehle muss man natürlich etwas abwandeln, entweder die Variable $datei wird einfach auf die lokale Datei Homedir von pi gesetzt, oder im tar Befehl die Datei direkt angeben.

Installation nodejs, pm2 und pip

Die Installation von nodejs hatte ich ja hier schon erläutert.
Zusätzlich brauche ich "global" noch den Nodejs Prozessmanager pm2.

sudo su
curl -sL https://deb.nodesource.com/setup_10.x | bash -
apt-get install nodejs
npm install pm2 -g

Trotz der Sicherung des gesamten Ordners installiere ich Landroid neu. Wie so oft gibt es mittlerweile neue Versionen.

Python Pakete werden mit Hilfe von pip installiert. Beispiel: die fhem API

apt-get install python-pip
pip install fhem

ToDo
Andere Applikationen unterhalb von /opt sichern

codebox

Windows Datensicherung mit Bordmitteln auf USB Stick

Achtung!
Ich möchte davor warnen, capture-image in einem normalen Windows zu starten!
Bei den Versuchen eine andere Systemplatte einfach mit Hilfe meines Notebooks in ein Wim File zu sichern, habe ich leider die Erfahrung gemacht, dass entweder der Vorgang in vielen Stunden ohne Fortschritt oder nach einem Abbruch die zu sichernde Partition zerstört ist!
Der Befehl "dism /capture-image ..." darf meiner Meinung nach nur unter Windows PE verwendet werden!

Grundlegende Idee

• Seit der Version 1709 von Windows 10 kann man mit der Datenträgerverwaltung auch auf einem USB Stick mehr als eine Partition erzeugen.
• Der Dateiversionverlauf sichert einfach, automatisch und benutzerfreundlich die Dateien auf ein externes Laufwerk.
• Mit dism kann man ein Image des gesamten Systemlaufwerkes auf dem USB Stick (oder auf einem Netzlaufwerk) erzeugen, welches auch noch flexibel handhabbar ist.
• Mit Windows PE oder dem Windows Setup kann man jederzeit ein Notfall System starten.

Wie funktioniert Wireguard im Detail

Ich habe pivpn mit wireguard installiert und das hat einfach funktioniert. Also wirklich einfach! Jetzt bin ich etwas tiefer vorgedrungen, um zu verstehen wie man die Konfiguration lesen muss und um Konfigurationen sichern und übertragen zu können. Für pivpn gibt es eine simple Backup/Restore Beschreibung (mit Stolperstellen siehe auch).

• Wireguard unterscheidet in der Installation nicht zwischen Server und Client - nur die Konfiguration bestimmt: wer mit wem.
• Wireguard implementiert im System ein vollwertiges Netzwerkinterface mit Tunnel - quasi eine virtuelle Netzkarte mit virtuellem Kabel. Die Netzwerkadministration erfolgt mit Standard Boardmitteln.
• Die Endpunkte authentifizieren sich mit einer Public-Key-Authentifizierung.
• Soll der Endpunkt ein VPN Router sein, muss er entweder schon der Router im Netzwerk sein oder NAT aktiviert haben.

Die Konfigurationsdatei für einen Endpunkt wird normal im INI Format erstellt - bei OpenWrt ist sie in der network config integriert. 

OpenWrt kann sowohl Server als auch Client Funktionalität abbilden, ich habe mich hier zunächst auf OpenWrt Router als VPN Einwahl Server beschränkt.

Nachtrag 7.9.2022: Während ich noch immer am Artikel schreibe bringt die neue Version OpenWrt 22.03 jede Menge Änderungen und meine ganzen Scripts für Wireguard sind hinfällig!?

joomla - Webauftritt auf einen neuen Server ziehen

Wie alle PHP Web Applikationen besteht auch joomla im wesentlich aus einem Sack Dateien (ca. 10.000 gegenüber Wordpress ca. 3000 bei etwa gleicher Größe knapp 30 MB) und einer SQL Datenbank. In der Datei configuration.php steht die Datenbankanbindung drin. Als Sicherung vom alten Server benötigt man ein Backup der Dateien vom gesamten Pfad sowie ein Backup/Export/SQL Dump der Datenbank.

Umzug von FHEM

Die alte Hardware ist zu schwach, defekt oder warum auch immer - das System soll neu gemacht werden!?
Ausgangszustand:

• Raspberry Pi2, 
• Raspbian Wheezy, 
• Probleme mit der SSL Lib beim https Zugriff (SSL Version SSLv2 not supported), ist mit jessie behoben.

Zielzustand:

• Raspberry Pi3
• Raspbian Jessie Lite

Geht relativ einfach, wenn man einige Vorbereitungen trifft. Der grobe Fahrplan sieht so aus:

1. Auf neuer Hardware ein neues System installieren.
2. Alle benötigten Tools und Module (debian Pakete) nachinstallieren.
3. FHEM als Grundlage installieren, eventuell Details testen (z.B. SSL).
4. Backup und shutdown aktuelles FHEM System auf Pi2
5. Transfer der Backupdatei auf Pi3
6. Restore und Start von FHEM auf dem Pi3
7. Test ob System einwandfrei läuft, wenn ja alles gut, wenn nein eventuell erstmal Restart FHEM auf Pi2 und in Ruhe untersuchen -> nochmal ab Schritt 4 bis alles läuft.

Schritt 1-3 

habe ich hier ausführlich beschrieben, das dauert je nach dem was man im Schritt 2 alles benötigt alles in allem keine 20 min. Dieser Artikel wird von mir laufend aktualisiert. Zu dem Wissen zu gelangen was man alles benötigt, kann allerdings wesentlich länger dauern, wenn man sich nichts aufgeschrieben hat. Im Zweifelsfall sollte man ein Paket/Tool mehr als eines zu wenig installieren. Die empfohlene Liste auf debian.fhem.de ist sicher ein guter Kompromiss.  Ich habe angefangen eine Liste zu erstellen, welches FHEM Modul welche cpan Module bzw. debian Pakete benötigt. Die werde ich noch veröffentlichen.

Schritt 4 und 6 

kann man nach seinen persönlichen Vorlieben gestalten. Normalerweise sollte das in wenigen Minuten abgeschlossen sein.
In der Regel sollte alles was FHEM betrifft in diesem Pfad liegen /opt/fhem/. Dieser Pfad muss auf das neue System und muss die richtigen Berechtigungen erhalten. Ich habe das hier schon mal im Detail beschrieben und es genauso gemacht:

Pi2 in der FHEM Oberfläche 

backup
warten bis backup fertig -> Log oder Eventmonitor
shutdown

• mit winscp die aktuelle Sicherung ins zentrale Sicherungs-Share auf den Server kopieren
• und in  einer zweiten Sitzung gleich wieder auf den Pi3 ins /home/pi/ Verzeichnis kopieren

Pi3 als User Pi im putty Terminal

sudo systemctl stop fhem
sudo tar -xvzf /home/pi/FHEM-201xxxxx_xxxxxx.tar.gz -C /opt/fhem/
sudo systemctl start fhem

Schritt 7

• FHEM Web erreichbar?
• Log File kontrollieren!!!

Wenn bis hier grobe Fehler vorhanden sind am Besten erstmal den Pi3 wieder beenden und alles auf dem Pi2 wieder starten. In Ruhe Fehler suchen.

• Schalter betätigen
• Sonderfunktionen kontrollieren (Sound und Sprachausgabe usw)

Nützliche Hinweise und Befehle

Umfangreiche Manipulation müssen nicht zeileweise mit sudo gemacht werden, sudo su schaltet den sudo Modus ein bis zum exit.

Es kann immer mal passieren, dass die Rechte im fhem Verzeichnis falsch sind. Dies kann man relativ einfach beheben in dem man den Eigentümer aller Dateien setzt:

sudo chown -R fhem:dialout /opt/fhem/

Manchmal muss die Rechte einzelner Dateien setzen, z.B. ausführbar machen:

sudo chmod +x /home/pi/shutdown.py

In besonderen Fällen muss das UID Bit gesetzt werden:

chmod u+s /usr/bin/dfu-programmer

Oder ganz brutal, einfach Rechte auf Alles:

sudo chmod 777 /etc/systemd/system/pishutdown.service

Ein paar Beispiele für User und Gruppen Mitgliedschaften:

useradd -m test
passwd test
gpasswd -a test users
gpasswd -a pi pulse-access
gpasswd -d pi audio
gpasswd -d test audio
groups test
getent group test
cat /etc/group

Samba Freigabe für Sonos einrichten:

sudo mkdir /mnt/SonosSpeak
sudo chmod 777 /mnt/SonosSpeak/
sudo nano /etc/samba/smb.conf

am Ende folgendes einfügen:

[SonosSpeak] comment = Audio-Files for SonosPlayer to Speak
read only = false
path = /mnt/SonosSpeak
guest ok = yes

anschließen den Service neu starten

sudo systemctl restart smbd.service

Zusatzinfo

Das Verhalten/der Syntax in der smb.conf hat sich offenbar bei Jessie etwas geändert! Nutzt man die Originale smb.conf von Raspbian muss man nur den Abschnitt des Shares (siehe oben) einfügen.
Die Anonyme Zugriff auf Shares wird durch die Standard Einstellung im Abschnitt
   [global]
   security = user
   map to guest = bad user
ermöglicht. Die erste Zeile ist die Standardeinstellung und ist in der smb.conf nicht extra gesetzt. Die zweite Zeile steht so in der Original smb.conf schon drin.

Dockerfile - Image für den Container selbst bauen

Das hier ist mehr ein persönliche Machbarkeitsstudie und soll kein Ansatz für ein dauerhaft gepflegtes Dockerimage werden. Ich wollte wissen wie es geht und den Vorgang verstehen. herausgekommen ist erstmal ein kurzes Beispiel und ein minimales FHEM Image.

Kurz vornweg: Hier ein Script welches die gesamte docker Umgebung und das FHEM Image baut. Damit hat man auf einem Intel PC in weniger als 2 min (Pi3 ca. 6 min) ein funktionierendes FHEM. 

Wireguard - verbundene Netzwerke

Einfach eine vor konfigurierte Box in das Netzwerk des Freundes oder Kunden stecken und dann ruhig und sicher dieses Netzwerk von der Ferne überwachen und administrieren können - das war die Idee. Eine Box, die der andere jederzeit entfernen und auch wieder stecken kann. Man muss im anderen Netzwerk nichts weiter tun

• keine Manipulation im Netzwerk, 
• keine Portfreigabe,
• kein Router / Fritzbox VPN-Verbindung einrichten. 

Schnell, transparent und einfach soll es auch noch sein! IPv4 und IPv6 sollen funktionieren.

Es braucht nicht viel: Hardware: einen Raspberry Pi als Client und eine debian Maschine (virtuell oder physisch) im eigenen Netzwerk. Software: wireguard, PiVPN, etwas gewusst wie. 

Hinweis: Das hier primär verwendete PiVPN wird nicht mehr weiterentwickelt. Ich habe hier einen neuen Artikel erstellt, der auf zusätzliche Tools verzichtet.

FHEM auf neues System umziehen

Eigentlich ist der Weg einfach:

1. Neues System installieren (Perl Module dokumentiert?)
2. Altes System beenden und sichern
3. Restore der Sicherung, Test und Start neues System

Die Downtime beim finalen Umzug soll möglichst gering sein. Punkt 3 kann, vor allem auch zur Übung, mehrfach durchlaufen werden. 

Hinweis: Es gibt zu diesem Thema auch eine aktualisierte Schritt für Schritt Anleitung.

Am Setup eines Raspberry hat sich seit 2019 bei mir nichts geändert. Aber ich habe ein paar neue Ideen getestet. Es ist gut wenn man ein Testsystem oder die neue Hardware bereits zur Vorbereitung hat! 

Will man es auf gleicher Hardware vorbereiten, sollte man sich meinen Artikel BootStick für den RaspberryPi anschauen. 

OpenWrt - sysupgrade ohne Bedenken

Es gibt ein (für mich) neues Feature bei OpenWrt: Attended SysUpgrade

Das vereinfacht den Vorgang ein neues Image einzuspielen erheblich, man hat quasi keine Nacharbeit mehr! 

Nachdem ich mich mal wieder mit hotplug und opkg-extras beschäftigt habe, entdeckte ich in dem Wiki Artikel ganz zum Schluss den entsprechenden Hinweis. 

Damit braucht man jetzt nur noch zwei Dinge beim sysupgrade: 

1. eine angepasstes Backup Archiv Configuration
• Pfade bzw. Dateien eintragen und mit "Open list" prüfen ob alle wichtigen Dateien im Archiv enthalten sind.
• Obwohl das sysUpgrade genau diese Dateien von sich aus behält (Keep Settings...), sollte man immer ein Archiv separat erzeugen und herunterladen!
2. Das installierte luci-app-attendedsysupgrade Package.

Im Menü System einfach Attended Sysupgrade auswählen, der Rest ist selbsterklärend. Im Reiter Configuration kann man den Advanced Mode einschalten. Damit kann man die Pakete verifizieren und eventuell noch etwas ändern. Man kann auch ein angepasstes Image der bereits installierten Version herunterladen. 

Hinweis: Am Ende bleibt irgendwie die UI hängen, man kann diese schließen und sich nach dem Neustart neu verbinden.

Ich habe z.B. um folgende Dateien/Pfade ergänzt:

/etc/wireguard/
/etc/adblock/ad*list
/root/speedtest
/root/.config

Hatte man hotplug-extras installiert, kann man die installierten Scripts wieder entfernen (auch oben in der Liste):

rm /etc/hotplug.d/iface/90-online
rm /etc/hotplug.d/online/10-sleep
rm /etc/hotplug.d/online/50-opkg-restore

Fehlt noch was?

Eine weitere FHEM Instanz auf gleicher Hardware

Ein kleines HowTo für eine zweite FHEM Instanz.

1. Variante: Codeshare

Es gibt bei dieser Variante keine separaten Pfade - alles läuft in einem Pfad!
Lediglich eine neue fhem.cfg wird verwendet. Ein Update wirkt sich auf alle Instanzen aus!
Nur 3 Zeilen für die FHEM Kommandozeile - Achtung! Einzeln ausführen! FHEM startet über die Raw Definition mehrere Prozesse, da wäre die neue cfg noch nicht da wenn der sed Befehl losläuft:

• Die erste Zeile holt eine Standard fhem.cfg vom SVN und speichert sie als fhem2.cfg. Die Original fhem.cfg wird nicht überschrieben!
• Die zweite Zeile modifiziert diese fhem2.cfg:
• Port 8093 statt 8083
• ändert Namen für Logfile und Statefile sowie eventTypes, damit läuft diese Instanz zunächst unabhängig.
• initialUsbCheck wird deaktiviert 
• Die dritte Zeile startet diese neue Instanz, sie ist unter http://<hostname>:8093 erreichbar.

"wget -qO fhem2.cfg https://svn.fhem.de/fhem/trunk/fhem/fhem.cfg"
"sed -i -e 's/\/fhem/\/fhem2/;;s/\/eventTypes/\/eventTypes2/;;s/8083/8093/;;$aattr initialUsbCheck disable 1' fhem2.cfg"
"perl /opt/fhem/fhem.pl /opt/fhem/fhem2.cfg"

Achtung: Obwohl die Konfiguration separat ist, verwendet sie den gleichen Pfad wie die erste Instanz. Update, gleiche Namen innerhalb von Definitionen (Logdateien usw.) wirken sich auf beide Instanzen aus!

Ein shutdown der zweiten Instanz beendet diese, ein shutdown der ersten Instanz beendet beide Instanzen!

Mit einem notify in der ersten Instanz, kann man die zweite Instanz automatisch nach dem Start der ersten Instanz starten:

define n_StartFhem2 notify global:INITIALIZED "perl /opt/fhem/fhem.pl /opt/fhem/fhem2.cfg"

Damit läuft auch ein restart ohne Probleme: beide Instanzen werden nacheinander neu gestartet.
Beide Instanzen verwenden unterschiedliche Prozessorthreads/CPUs.

2. Variante: Rettungsweste

Wenn FHEM nicht mehr startet muss man Fehler suchen. Dazu ist es eigentlich nicht schlecht, mal eben "schnell" zu prüfen: Läuft es generell "ohne alles", was sagt das Log?
Der Ausgangszustand ist hier: FHEM läuft nicht! Wir bewegen uns im Terminal!

Erstmal prüfen, ob FHEM wirklich nicht läuft.

ps -aux|grep fhem

Prinzipiell passiert mit diesen Zeilen, das Gleiche wie in Variante 1, außer:

• Nur der Name für den Statefile wird geändert, damit der Inhalt des originalen Statefile erhalten bleibt. 
• Der Logfilename bleibt erhalten, man startet zwar ein  FHEM mit leerer cfg, hat aber den originalen Logfile im Zugriff.

n=3
cd /opt/fhem
sudo wget -qO fhem$n.cfg https://svn.fhem.de/fhem/trunk/fhem/fhem.cfg
sudo sed -i "s/\/fhem.save/\/fhem$n.save/;\$aattr initialUsbCheck disable 1" fhem$n.cfg
# oder auch das Port ändern
# sudo sed -i -e "s/8083/8093/" fhem$n.cfg
sudo chown fhem: fhem$n.cfg 
sudo perl fhem.pl fhem$n.cfg

Damit sieht/kann man:

• ob FHEM startet (keine Problem mit dem Betriebssystem),
• wie gewohnt das Logfile lesen. 
• restore machen
• diese Instanz ganz normal mit shutdown beenden

3. Variante: Völlig separat

In dieser Variante wird folgendes eingerichtet:

• neues Port, 
• der existierende /opt/fhem Pfad wird ohne die aktuellen Daten in einen neuen Pfad /opt/fhemN kopiert, 
• neuer zweiter FHEM Service, 
• neue leere fhem.cfg wird verwendet.

Ein installiertes FHEM  mit Systemd ist Voraussetzung!

Das Script / die Befehle alle im sudo Kontext (sudo su) ausführen!

#!/bin/bash
# Nummer und Port vergeben
n=4
fPort=8103

# aktiven Pfad kopieren, aktuelle Daten ausschließen
rsync -av --exclude={'log/*','restoreDir/*','cache','backup'} /opt/fhem/ /opt/fhem$n/

# fhem Service kopieren, anpassen und anlegen
cp /etc/systemd/system/fhem.service /etc/systemd/system/fhem$n.service
sed -i -e "s/\/fhem/\/fhem$n/" /etc/systemd/system/fhem$n.service
systemctl daemon-reload
systemctl enable fhem$n

# Leere cfg holen und anpassen
wget -qO /opt/fhem$n/fhem.cfg https://svn.fhem.de/fhem/trunk/fhem/fhem.cfg
sed -i -e "s/8083/$fPort/;\$aattr initialUsbCheck disable 1" /opt/fhem$n/fhem.cfg

#Besitzer setzen
chown -R fhem: /opt/fhem$n/

# Service starten
systemctl start fhem$n

Achtung, das kopiert und modifiziert die Version von fhem.cfg und fhem.service vom Entwicklungsstand heute! Wenn sich in Zukunft etwas ändert, muss dieser Code angepasst werden!

Will man alles wieder entfernen:
Bitte Vorsicht!

# zur Sicherheit nochmal n setzen
n=4

# Entferne den Dienst
systemctl stop fhem$n
systemctl disable fhem$n
systemctl daemon-reload
systemctl reset-failed
echo 'Mit y oder Y bestätigen'
rm -i /etc/systemd/system/fhem$n.service

#Entferne den Pfad
echo 'Mit y oder Y bestätigen'
rm -I -R /opt/fhem$n