Backup der IP-Symcon Konfiguration
Wie schon in einem anderen Beitrag geschrieben, hatte ich selbst schon das Thema, dass nach einem Neustart die gesamte Konfiguration weg war. Deshalb kann man wohl nicht oft genug Sicherungen machen.
Auf dem Server sind diese auch mit 3 einfachen Befehlen erledigt:
/etc/init.d/symcon stop // IP-Symcon stoppen
zip -r ~/backup.zip "/var/lib/symcon" // IP-Symcon Ordner sichern
/etc/init.d/symcon start // IP-Symcon wieder starten
Ich habe dafür ein kleines Bash-Skript geschrieben, welches mir mit nur einem Befehl erlaubt, diese Schritte durchzuführen. Vor allem, dass mir die backup.zip Dateien nicht bei jeder Ausführung überschrieben werden.
#!/bin/bash # Create a backup ZIP from IP-Symcon config. # @author Roland Meier today=`date +"%Y%m%d_%H%M"` file_name="/root/backup_"$today".zip"
/etc/init.d/symcon stop echo "Symcon Service stopped..."
zip -r $file_name "/var/lib/symcon" echo \"$file_name\" "created..."
/etc/init.d/symcon start echo "Symcon Service started..."
Als erstes wird das aktuelle Datum sowie Uhrzeit in Stunden und Minuten ermittelt. Diese werden direkt in den Dateinamen gepackt, also z.B. backup_20170917_1008.zip.
Danach wird der Symcon Dienst beendet und auch als "gestoppt" angezeigt.
Nun wird der IP-Symcon Ordner mit dem zuvor ermitteltem Dateinamen gesichert.
Zuletzt wird der IP-Symcon Dienst wieder gestartet und angezeigt.
Das Skipt backup.txt Skript könnt ihr hier herunterladen.
Speichert es z.B. in euren Benutzer-Ordner, nun müsst ihr sie nur noch umbenennen und ausführbar machen:
mv backup.txt backup.sh
chmod +x backup.sh
Ausgeführt werden kann eine Sicherung dann mit:
sh backup.sh
Mit einem Cronjob könnt ihr auch regelmäßig dafür sorgen, dass automatisch ein Backup angelegt wird, z.B.
*/10 * * * * root /root/backup.sh // Skript alle 10 Minuten ausführen
0 * * * * root /root/backup.sh // Skript jede Stunde ausführen
0 4 0 0 0 root /root/backup.sh // Skript täglich um 4 Uhr ausführen
Hier liegt das Skript im Root Ordner... Ihr braucht natürlich nur eine Zeile davon.
Beachtet bitte, dass es einige Zeit benötigt, bis das Backup erstellt ist und für diese Zeit der Dienst offline ist. Wenn alle 10 Minuten die Clients die Meldung bringen, dass der Dienst nicht online ist, ist das eher nervig.
Ich persönlich werde das Skript 1x täglich laufen lassen, sofern ich mal vieles am Stück verändere, werde ich mit genannten Befehl ein manuelles Backup anlegen.
Wiederherstellen einer IP-Symcon Konfiguration
Der Wiederherstell-Prozess hatte mich etwas geärgert, sehr lange wollte einfach die ursprüngliche Konfiguration des C2 nicht im XU4 Arbeiten. Dummerweise probierte ich ständig mit einer alten Config herum, welche einfach noch nicht mehr Inhalt hatte. Die neue Richtige war dann doch 12MB groß.
Auf dem Server sind auch hierfür nur 3 Befehle nötig:
/etc/init.d/symcon stop // IP-Symcon stoppen
unzip ~/backup.zip -d "/var/lib/symcon" // IP-Symcon Ordner aus der backup.zip entpacken
/etc/init.d/symcon start // IP-Symcon wieder starten
Auch hierfür habe ich ein kleines Bash-Skript geschrieben, welches mir diese Schritte mit nur einem Befehl abnimmt.
#!/bin/bash
# Restore the IP-Symcon config from a backup ZIP.
# @author Roland Meier
file_name="/root/backup.zip"
if [ -e $file_name ]
then
echo "A backup.zip found..."
/etc/init.d/symcon stop
echo "Symcon Service stopped..."
unzip $file_name -d "/"
echo \"$file_name\" "restored..."
/etc/init.d/symcon start
echo "Symcon Service started..."
else
echo "No backup.zip found..."
fi
Im Gegensatz zum Backup Skript sind hier jedoch ein paar Dinge zu beachten:
- In meinem Fall arbeite ich direkt im ROOT. Ihr müsst hier also das Verzeichnis angeben, wo euer Backup liegt.
- Das Skript erwartet den Dateinamen backup.zip. Ist diese nicht vorhanden, wird das angezeigt und das Skript ist beendet.
Ihr müsst also gezielt eure Backup Datei in backup.zip umbenennen, bevor ihr es wiederherstellen könnt.
Passt das alles, wird der Symcon Dienst beendet und als "gestoppt" angezeigt.
Dann wird der IP-Symcon Ordner mit den Daten aus der backup.zip entpackt. Eventuelle Nachfragen hatte ich bestätigt z.B. mit A = alle überschreiben.
Hinweis! Das überschreibt eure momentane IP-Symcon Konfiguration mit dem Inhalt des Backups!!!
Zuletzt wird der IP-Symcon Dienst wieder gestartet und angezeigt.
Das restore.txt Skript könnt ihr hier herunterladen.
Speichert es z.B. in euren Benutzer-Ordner, umbenennen und ausführbar machen:
mv restore.txt restore.sh
chmod +x restore.sh
Dann könnt ihr es auch schon verwenden:
sh restore.sh
Aktualisieren der IP Adressen auf dem neuen Gerät
Das Webinterface ist nun über die IP-Adresse des Odroid XU4 Servers mit gleichem Port erreichbar. Meine bisherigen Geräten waren abgesehen der beiden LED-Stripes auch schon ansteuerbar.
Beim Versuch, die LED Lampen zu steuern erschien die Meldung, dass die Instanz nicht aktiv sei.
Hier musste natürlich erstmal der Wine Starter wie im Beitrag IP-Symcon auf Odroid Server & Verwaltungskonsole unter Linux Kubuntu beschrieben bezüglich der neuen IP-Adresse aktualisiert werden.
Auch hier wird dann erstmal die Lizenz wieder eingebunden sowie der Fernzugriff.
Im Objektbau waren dann die beiden UDP Sockets der DMX Gateways mit einem rotem Ausrufezeichen versehen.
Ein Doppelklick darauf zeigt, dass es den Empfänger-Host nicht gibt, klar, hier war ja die IP des alten C2 hinterlegt, dieser Host ist aber nun neu.
Einfach aus dem Dropdown Feld den einen aktuellen Wert wählen, Übernehmen und schon klappt die LED Steuerung wieder.
Nun hatte ich ganz lustige Effekte, dass meine LED-Stripes plötzlich zu blinken begannen.
Ursache war recht schnell gefunden, der alte Odroid-C2 mit dem IP-Symcon. Während der neue XU4 den LEDs z.B. Rot 100% geschickt hat, schickte der C2 0%.
Lösung war, den IP-Symcon Dienst auf dem C2 einfach zu beenden z.B. mit:
/etc/init.d/symcon stop
oder einfach abstecken.
Zuletzt noch im IPSStudio die neue Verbindung eintragen sowie natürlich auch in sämtlichen IPSView Programmen.
