Edomi Linux Backup

[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]

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]

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]

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

[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.

[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.

[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

[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

[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)?

[starwarsfan]

Hallo miteinander

Nur André und Yves scheinen rsync zu nutzen.

Korrekt, das läuft jetzt schon seit vielen Jahren und seit dem Anbeginn von Edomi wird auch Edomi bei mir so gesichert. Ich verwende diese Lösung, weil ich damit auf der zu sichernden Maschine lediglich rsync installieren und ssh-Zugriff einrichten muss. Alles weitere, insbesondere die Konfiguration was gesichert werden soll, habe ich für alle Maschinen an einer zentralen Stelle (welche natürlich in Git versioniert ist).

[saegefisch]

Bisher habe ich meine edomi-Backup nur sporadisch manuell auf NAS gesichert bzw. die ganze edomi-VM wurde von proxmox täglich gesichert. Da ich nun wieder auf dedizierte HW umgezogen bin und die VM nur noch Fallback ist, möchte ich die automatisch von edomi generierten Backup-Dateien auf NAS sichern.

Gerne würde ich auf zusätzliche tools (z.B veeam) verzichten, weil ich davon ausgehe, dass Linux von Hause das nötige sehr schlank mitbringt.

• cron + cp wie hier z.B. von Micha -> schöne und sicher stabile Lösung; kleiner Nachteil aus meiner Sicht: Jeden Tag komplette Kopien übertragen
• lsyncd -> Aus meiner Sicht unglücklich, weil zum Sicherungszeitpunkt 00:00 edomi ohnehin mit vielem unter Last ist, da ist eine unmittelbare Sicherung kein Problem, aber auch nicht hilfreich
• cron + rsync oder alternativ edomi SHELL-Befehl + rsync: Damit müsste doch /var/edomi-backups schlank mit einer Freigabe auf dem NAS syncen lassen, d.h. von edomi gelöschte zu alte Backups würden auch automatisch im Ziel entfallen. Genau dafür ist das bewährte Tool ja.

Mit der SuFu scheinen die meisten andere Tools (z.B. veeam siehe oben) zu nutzen, den LBS 19000169 oder cp. Nur André und Yves scheinen rsync zu nutzen.
Ich habe mich nun auch für rsync (push von edomi aus) entschlossen (nicht wie Yves als pull vom Backup-Server aus):

Ziel: qnap-NAS (hilfreicher Blog dazu, der mir geholfen hat)

1. In Hybrid Backusp Sync-App den Dienst "Rsync-Server" aktivieren, Freigebenes Server-Konto aktivieren mit User = <rsync-user> und PW = <deinsupergeheimesPW> -> übernehmen
2. Verzeichnis anlegen in einem share, z.B. im Share "15_Daten_Server" den Ordner "edomi-backups"

edomi-Server (Terminal) testen:

export RSYNC_PASSWORD=<deinsupergeheimesPW>
rsync -trvu --modify-window=1 --delete /var/edomi-backups/* rsync://<rsync-user>@<IPdesNAS>/15_Daten_Server/edomi-backups

Hat beim ersten Versuch alles übertragen und danach bei jedem Aufruf nichts mehr - genau wie gewollt bis das nächste Backup erzeugt wird.

Jetzt muss ich nur noch schauen, ob ich das per cron mache oder per edomi-SHELL-Befehl. Per edomi-SHELL-Befehl wäre es auch Teil des Backups und mit gesichert und damit nach einem restore sofort wieder aktiv - ein klarer Vorteil. Für den Befehl beide in einer Zeile und mit KOs für PW und IP:

export RSYNC_PASSWORD={id von KO für PW};rsync -trvu --modify-window=1 --delete /var/edomi-backups/* rsync://rsync@{id von KO für IP}/15_Daten_Server/edomi-backups

Allerdings bekommt man keine Rückmeldung, weil es kein Ergebnis-KO für Type SHELL in edomi gibt. Eine Erfolgskontrolle wäre schon sehr sinnvoll, weil die Dateien im zweifel Lebensretter fü's Haus sind.

Vielleicht kann man das Ergebnis in ein KO oder per edomi auswertbares Log umlenken per ">"?

[Hennessy]

Oder curl verwenden

[Lonie]

Copy/Paste ohne die Ausgaben zu lesen Wenn wget nicht installiert ist kannst du auch nichts mit wget laden. Das hat dir die Konsole aber bereits beim Versuch angezeigt.

[Glotzkowski]

Die RPM-Datei ist sozusagen eine Installationsroutine und dies steht für Redhat Package Manager.
In der Regel wird damit ein Stück Software installiert.
In diesem Fall beschränkt sich die Installation aber auf die Installationsquelle für Veeam, dass heißt, dass bei der Installation dieses RPMs dem CentOS-System die notwendige Installationsquelle konfiguriert wird damit das System bei "yum install veeam" in allen auf dem System verfügbaren Installationsquellen auch veeam finden kann und es auf dem System installiert.
Da es sich bei dieser Software um 3rd party Software handelt, muss die Installationsquelle hinzugefügt werden und ist nicht bereits im Standard-System enthalten.

[sepplo815]

Ich versuch mir mal selbst eine Antwort zu geben.

So funktionierts:

yum -y install wget
cd /tmp
wget https://download2.veeam.com/veeam-release-el7-1.0.7-1.x86_64.rpm
rpm -ivh ./veeam-release* && yum check-update
yum install veeamy

rmp braucht ein *.rmp File erst mal um zu wissen wo die veeam Installationsdateien liegen...
Verstehe ich das richtig?

Seppl