Edomi Linux Backup

[saegefisch]

Wegen Deiner Infos dazu in früheren Beiträgen hatte ich das für mich auch überlegt. Aber einerseits vermute ich bei Dir eine erheblich buntere und umfangreichere IT-/Applikations/Dienste-Landschaft , bei mir ist's überschaubar. Zum anderen nutze ich zumeist Docker für meine Dienste und mit dem Auslagern der volumes liegen die relevanten/sicherungswürdigen Daten so bereits auf dem NAS (mit täglichem Backup auf 2. NAS) - in einer (impliziten) push-Lösung. Daher entschied ich mich hier bei edomi auch für ein push, weil es mir so konsistenter erscheint für meine Landschaft. Andernfalls hätte ich mich genau mit Deinen guten Argumenten auch für ein zentralen pull eines Backup-Systems entschieden. Zur Erklärung auch für andere, die sich diese Frage stellen.

Bleibt weiter die Frage: Kann man die Ausgabe eines SHELL-Befehls per Umleitung (>, >>,...) oder anderen Linux-Bordmitteln irgendwie direkt in ein edomi-Log umleiten (eigens Custom-Log oder an error anhängen)?

[Glotzkowski]

Bleibt weiter die Frage: Kann man die Ausgabe eines SHELL-Befehls per Umleitung (>, >>,...) oder anderen Linux-Bordmitteln irgendwie direkt in ein edomi-Log umleiten (eigens Custom-Log oder an error anhängen)?

Versuch es doch mal mit

[shell cmd] >> /usr/local/edomi/www/data/log/CUSTOMLOG_BACKUP-EDOMI.txt

[starwarsfan]

Hi,

also wovon ich mich auf jeden Fall in Deiner Idee verabschieden würde wäre, irgendwo ein Passwort zu hinterlegen! Bitte einen ssh-Key verwenden, den kann man dann gezielt auch wieder entfernen, wenn das notwendig ist. Bei Passwörtern ist das eher schwierig, je nachdem, wo das noch hinterlegt ist.

Und bzgl. dem Shell-Cmd könntest Du zumindest den Output ablegen, also sowas in der Art:

rsync ... | tee /usr/local/edomi/www/data/log/$(date +'%Y-%m-%d_%H%M%S')_edomi-backup.log

[jonofe]

Bei mir ist /var/edomi-backups inzwischen ein NFS Mount von meinem NAS (napp-it VM mit ZFS), d.h. EDOMI sichert die Backups direkt aufs NAS.
Das NAS wird dann mit borg-Backup (inkrementell + deduplicated + compressed) auf eine externe USB Platte gesichert.
Die Lösung ist vollständig virtualisiert, d.h. sowohl NAS als auch EDOMI laufen auf einem ESXI Hypervisor.
Zusätzlich werden alle VMs per borg-Backup gesichert und noch auf einen zweiten ESXI Backup Server repliziert. Durch regelmäßige ZFS Snapshots ist man so auch gegen Ransomware geschützt.
Auf meinem NAS läuft auch noch minIO (S3 kompatibler Object Storage), welchen ich für Windows Backup via duplicati nutze. Dies allerdings in sehr geringem Umfang, da grundsätzlich alle Daten, die zu sichern sind auf dem NAS liegen sollten.

[saegefisch]

Glotzkowski und starwarsfan : Perfekt damit geht es! Klasse!
Ich bin noch unentschlossen, ob ich lieber nur ein log (aufgeräumter, aber wächst unendlich) oder täglich ein neues haben will, die dann rollierend automatisch von edomi gelöscht werden. Daher mache ich jetzt mal ein paar Tage beides und schaue, was mir auf den 2. Blick besser gefällt. Auf jeden Fall haben mir euren Beide Antworten sehr geholfen! Wenn ich mich entschieden habe, schaue ich, ob ich da noch was mit grep oder anders schicker machen will (z.B: bei nur einem Log einen Trenner mit Datum)

Anmerkung @Yves: Das Customlog muss mit "CUSTOMLOG_" beginnen, sonst wird es nicht angezeigt in edomi.

export RSYNC_PASSWORD=<PW>;rsync -trvu --modify-window=1 --delete /var/edomi-backups/* rsync://rsync@<IP>/15_Daten_Server/edomi-backups | tee /usr/local/edomi/www/data/log/CUSTOMLOG_BACKUP-EDOMI_$(date +'%Y-%m-%d_%H%M%S').log | tee -a /usr/local/edomi/www/data/log/CUSTOMLOG_BACKUP-EDOMI.log

jonofe : Herzlichen Dank für Deine Lösungsdetails. Das alles rundet für mich und sicher andere das Bild sinnvoller und verlässlicher/professioneller Lösungsoptionen weiter ab.

[saegefisch]

Update: Irgendwie wollte --delete nicht funktionieren. Ursächlich war wohl bei der Quelle fälschlich das /* am Ende, richtig ist, nur das Verzeichnis anzugeben. Im Gegenzug muss aber im Ziel auch der Pfad verkürzt werden. Zudem kann man --modify-window=1 auch weglassen.

Mit folgender Änderung des rsync-Befehls (den Rest drumherum lasse ich hier mal weg) funktioniert nun auch das Wegräumen der alten Backups nach dem nächtlichen edomi-housekeeping.

rsync -trvu --delete /var/edomi-backups rsync://rsync@<IP>/15_Daten_Server/

Will man im edomi-Custom-Log mehr Details, kann man die Optionen auch ergänzen zu -trvvu oder -trvvvu, also verbose doppeln oder trippeln

[maque]

Bei mir läuft Edomi auf einem apu2e4. Ich habe /var/edomi-backups mit Automount mittels NFS auf meine QNAP gelegt. Ein Nachteil des Automount ist, dass Edomi die alten Backups nicht mehr automatisch löscht, aber damit kann ich leben. Jede Nacht um 1 Uhr fährt meine Ersatz apu2e4 hoch ohne Edomi zu aktivieren, installiert sich die vorletzte Backup und leg sich wieder schlafen. Sollte das Hauptsystem ausfallen, kann ich das die Ersatzsystem hochfahren und alles funktioniert. Der Recovery Plan wurde schon mehrfach erfolgreich getestet;-).

[saegefisch]

Danke, Matthias, für die Info zu Deinem Lösungsweg. Die Idee mit dem Ersatz-System hochfahren ohne edomi mit dem einspielen des Backups find' ich spannend.
Frage: Wie startest Du das Fallback-System ohne edomi und installierst das vorletzte Backup?

Zum Thema automount/NFS: Hatte ich in der Vergangenheit auch schon im Einsatz, fand ich ganz gelegentlich fragil/nicht immer stabil. Ich vermute, rsync wird da stabiler sein. Was sich aber noch beweisen muss... Letztlich ist's egal, wie das Gedöns auf den NAS und ggf. Backup-System kommt...Hauptsache sehr regelmäßig da...

[maque]

Das Ersatz-System hängt an einer schaltbaren Steckdose. Nachts im 0:55 Uhr läuft auf dem produktiven Edomi ein Script, dass die Steckdose kurz aus und wieder einschaltet. Dann fährt das Backup-System hoch.

Dort läuft dann ein über cron gesteuert jede Nacht das restore.sh

Damit wird der restore durchgeführt und in der edomi.ini die IP-Adresse des produktiven Edomi gegen das Backup-Edomi ausgetauscht, sowie KNX und autoBackup deaktiviert (dadurch läßt sich das System dann auch mal starten und testen). Am Ende des Scripts wird der Rechner wieder mit poweroff ausgeschaltet.

Das restore script ist im Prinzip das orginal restore - Script von Edomi.


Sollte der produktive Rechner ausfallen, habe dann noch ein script activeEdomi.sh, das KNX in der edomi.ini dann wieder aktiviert und den EDOMI Dienst beim Start enabled. Dann wird neu gestartet und der Backup-Edomi, ist der Produktive...


Ich kann die Scripte gerne bereitstellen, aber die sind nichts für Einsteiger und nur auf 2.03 mit Centos 7 getestet.

Viele Grüße
Matthias

[saegefisch]

...das wäre wohl das erste Mal in diesem Forum, dass jemand sagt: "Ach, lass mal"...

klar, sehr gerne möchte ich eine Blick auf die Scripte werfen und bewerten, ob das für mich eine gleichfalls passende Lösung ist. So wie es sich liest: Respekt, schöne und einfache Lösung ohne viel drumherum. Danke für die Beschreibung der Lösung! Könnte mir auch gefallen - und natürlich alles ohne Gewähr, d.h. jeder muss selber wissen, ob es für einen passt bzw. zu kompliziert ist. Daher: Sehr gerne mal hier die Scripte zeigen...

[maque]

Wie gesagt, alles getestet mit Centos7 und Edomi 2.03 auf einem Apu2e4.

Hier ist das Script zum nächtlichen restore auf dem Backup-System. Das läuft um 0:45

restore.sh

DIR = Das Verzeichnis, in dem die Backups liegen
INTERFACE=Hier lese ich über die Default- Route das primäre Interface
NEWIP = ist die IP-Adresse des Backup-Systems, die in die Edomi.ini eingetragen wird
FILENAME = Wird keine Datei angegeben, versucht das Script die letzte Daten von heute, oder alternativ von gestern zu installieren

DIR="/mnt/edomiBackups/"
INTERFACE=$(route | grep '^default' | grep -o '[^ ]*$')
NEWIP=$(ip -f inet a show $INTERFACE| grep inet| awk '{ print $2}' | cut -d/ -f1)
FILENAME="$1"
#Backup von heute
DAY=$(date +'%Y-%m'-%d)
#Backup von gestern
#DAY=$(date +'%Y-%m'-%d -d "1 day ago")

if [ $# == 0 ]; then
   FILENAME=$(find $DIR  -maxdepth 1 -name "$DAY*" -print0 | xargs -r -0 ls -1 -t | head -1)
fi


# Mit Ausnahme der Aenderungen in der edomi.ini, wird der restore wie im script /usr/local/edomi/main/restore.sh ausgeführt

if [ -f "$FILENAME" ]; then
   echo "Restore backupfile $FILENAME and change ip address to $NEWIP! Hit Ctrl-C to abort ..."
   echo "Restore wird in 3 Sekunden gestartet..."
   sleep 3s

   echo "EDOMI beenden... (dies kann bis zu 30 Sekunden benötigen)"
   php /usr/local/edomi/main/control.php quit

   echo "Dienste beenden..."
   service mysqld stop
   service httpd stop
   sleep 1s

   echo "Restore vorbereiten..."
   rm -rf /usr/local/edomi
   rm -f /var/lib/mysql/mysql.sock
   rm -rf /var/lib/mysql/edomiAdmin
   rm -rf /var/lib/mysql/edomiProject
   rm -rf /var/lib/mysql/edomiLive
   sleep 1s

   echo "Restore durchführen..."
   tar -xf "$FILENAME" -C /
   chmod 777 -R /usr/local/edomi
   rm -rf /usr/local/edomi/clientid.edomi

   echo "Dienste starten..."
   service mysqld start
   service httpd start

   #Anpassen der edomi.ini
   sed -i -e "s/global_serverIP='.*'/global_serverIP='$NEWIP'/"i \
      -e 's/global_autoBackup=true/global_autoBackup=false/' \
      -e 's/global_knxGatewayActive=true/global_knxGatewayActive=false/' /usr/local/edomi/edomi.ini

   echo "Restore abgeschlossen. PowerOff in 5 Sekunden..."
   sleep 5s
   poweroff
else
   echo "Syntax: restore.sh <backupfile>"
   echo "Fehler: Die Backupdatei $FILENAME wurde nicht gefunden."
fi

Das Script im das Backup-System zum Produktiv-System zu machen, sieht so aus:

echo "Das System wird in 3 Sekunden aktiv gesetzt..."
sleep 3s

echo "EDOMI beenden... (dies kann bis zu 30 Sekunden benötigen)"
php /usr/local/edomi/main/control.php quit

echo "Dienste beenden..."
service mysqld stop
service httpd stop
sleep 1s

sed -i -e 's/global_knxGatewayActive=false/global_knxGatewayActive=true/' /usr/local/edomi/edomi.ini
echo "edomi wird in 5 Sekunden gestartet..."
systemctl enable edomi
sleep 5s
reboot

[saegefisch]

Lieben Dank!

[starwarsfan]

Hi,

zunächst vielen Dank für's Teilen, interessante Idee!

Hier einige Anmerkungen zum Scripting an und für sich:

INTERFACE=`route | grep '^default' | grep -o '[^ ]*$'`

Die Backticks sind deprecated, sollten also nicht mehr verwendet werden. Das POSIX-kompatible Replacement ist "$(...)". Die Backtick-Syntax braucht man eigentlich nur noch in (stein-)alten Shell's. Details dazu siehe bspw. hier.

#Anpassen der edomi.ini
sed -i -e "s/global_serverIP='.*'/global_serverIP='$NEWIP'/"i \
-e 's/global_autoBackup=true/global_autoBackup=false/' \
-e 's/global_knxGatewayActive=true/global_knxGatewayActive=false/' /usr/local/edomi/edomi.ini

Hier kannst Du beim ersten Teil des sed-Ausdruckes alles was nach dem "=" kommt weglassen. Dann funktioniert das auch, wenn aus welchen Gründen auch immer dort nach dem "=" irgendwas anderes drin stehen sollte. Zusätzlich wäre noch machbar, auf ein vorheriges "#" zu prüfen, damit allfällige Kommentare nicht angepasst werden.

Just my two cents...

[maque]

Hi Yves,
Du hast natürlich recht, aber ich bin change resistent, da ich die backticks seit 35 Jahren nutze Ich mach nachher einen update, teste und stelle es dann hier rein, in dem ich den Code oben aktualisiere...

Matthias

[starwarsfan]

Hi Matthias

Du hast natürlich recht, aber ich bin change resistent, da ich die backticks seit 35 Jahren nutze

Kein Ding, völlig verständlich. Ich hab's mir auch erst recht spät "angewöhnt", wobei das aber mehr dadurch getrieben war, dass ich auf recht vielen verschiedenen Setups unterwegs bin und es dabei immer wieder mehr oder wenig "lustige" Suchereien gegeben hat, wo denn beim eingestellten Keyboard-Layout der Backtick zu finden ist.