https://marius.bloggt-in-braunschweig.de/2025/04/23/teil-1-wie-man-partitionen-neue-alte-uuids-gibt/

Ihr hat den ersten Teil gelesen und wollt mehr erfahren? Syncen wir doch mal einen ganzen Server.

Teil 2: einen ganzen Server Rsyncen

Ihr habt sicher schon mal etwas von einem Clusterfilesystem gehört. Dabei mounten man auf zwei Servern ein gemeinsames Filesystem, daß sich dann über das Netzwerk abgleicht, in dem alle Blöcke mit Änderungen einzeln von A nach B transportiert werden, das GlusterFS macht(e) sowas z.b.  Problem hier,  das geht nur für ganze Mountpoints, also Verzeichnisse oder Partitionen. Wer Teil 1 gelesen hat, weiß das in dem aktuellen Fall so ein ClusterFS nicht geht, weil es Abweichungen im Netzwerk gibt, die dann jedes mal überschrieben würden.

Natürlich gibt es auch andere ClusterFilesysteme die nach Dateien , statt Blöcken gehen, und da kann man dann Dateien excluden, aber in dem Fall haben wir einen Liveserver den wir nicht stoppen dürfen um dem „umzuformatieren“, so daß er so ein ClusterFS benutzen kann, dazu sind da auch zu viele Daten drauf um den „mal eben“ umzukopieren.

Zum Glück brauchen wir das nicht, weil wir Rsync nehmen können.

Ok, Ich habe gelogen, wir syncen gar nicht den ganzen Server 😉

Wir Syncen /etc/ /home/ /var/lib/mysql und alle anderen Plätze wo Userdaten liegen. Das Prinzip erläutere ich mal bei /etc/ und wo man da aufpassen muß. Das hier führen wir auf dem Hotstand-By-Server aus:

rsync -a –delete -v -e „ssh -C -i /root/.ssh/synckey“ root@$ZIELSERVER:/etc –exclude=/etc/sysconfig –exclude=/etc/fstab –exclude=/etc/systemd –exclude=/etc/iproute2 –exclude=/etc/cron.d /

Wir verbinden uns also zum Live-System und syncen ZU UNS!  Nennen wir das mal PULL-Verfahren. Das würde auch in die andere Richtung gehen, dann wäre ein PUSH-Verfahren. Liegt bei Euch was Ihr machen möchtet. Eines möchte ich aber zu bedenken geben:

Wenn man schon einen anderen Server hinstellt, dann so, daß wenn der aktive Server gehackt wird, der Hacker nicht auf den Reserveserver drauf kommt. Ein PULL hat also einen gewissen Vorteil. Der nicht ausgelastete Reserveserver kann auch das Datenbackup machen und so den Liveserver entlasten. Denkt über solche Sachen vorher nach, es lohnt sich 😉

Der Rsync erklärt

rsync -a –delete -v -e „ssh -C -i /root/.ssh/synckey“

„-a –delete -v „ archiviert und löscht Daten rekursiv auf dem Empfängerserver, wo mit der Hotstand-By im Sync bleibt mit allen Änderungen auf dem Quellserver, aber auf dem Quellserver nichts verändert wird. Das ist ganz wichtig, weil ein Master-Master-Setup beim Sync birgt richtig Potenzial für Datenverluste.

Damit sich unser Rsync überhaupt auf den anderen Server verbinden kann ohne das wir ein Passwort eingeben müssen, nehmen wir einen passwortlosen sshkey ‚-e „ssh -C -i /root/.ssh/synckey“ ‚ , denn einen SSH-Agenten gibt es dort nicht, bzw. der würde es auch nicht sicherer machen, weil der KeyStore nie ablaufen darf, sonst geht der Sync nicht mehr. Wer will da schon jeden Tag rein und den KeyStore verlängern?

Zuerst geben wir an, was wir syncen wollen, also /etc/ , dann die ganzen Excludes, die wir NICHT syncen wollen, dann wohin es gesynct werden muß -> „/“:

root@$ZIELSERVER:/etc –exclude=/etc/sysconfig –exclude=/etc/fstab –exclude=/etc/systemd –exclude=/etc/iproute2 –exclude=/etc/cron.d /

Tip: Wieso „/“ als Ziel? Weil /etc/ in / liegt! Würde man hier /etc als Ziel angeben, dann ergäbe das /etc/etc .

In /etc/sysconfig sind z.b. die Netzwerkkonfigurationen, in /etc/systemd können z.b. lokale Anpassungen im Hotstand-By sein, so daß die nicht gelöscht werden dürfen, nur weil es die auf dem Quellserver nicht gibt. IProute2 ist ein Sonderfall, auf den wir im nächsten Teil eingehen werden und im cron vom Quellserver laufen Dinge die nicht auf dem Hotstand-By laufen sollen.

Kleines Konfigproblem

Wir haben jede Menge Konfigurationsdateien von Netzwerkbasierten Diensten wie Apache HTTPD, Proftp usw. gesynct, die aber alle auf dem Quellserver konfiguriert wurden, sprich: die IPs da drin stimmen nicht! Das können wir aber leicht nach dem Sync beheben. Ein unvollständiges Beispiel:

$ replace „1.2.3.4“ „5.68.7.85“ — /etc/sysconfig/iptables /etc/sysconfig/network-scripts/ifcfg-* /etc/sysconfig/network /etc/httpd/conf/httpd.conf /etc/httpd/conf.d/ssl.conf /etc/named/* /etc/hosts

Da Ihr clever wart und Eure Dienste auf dem Reserveserver erst gestartet habt, nachdem Ihr den IP Replace gemacht habt, brauchen die Dienst deswegen nicht nach jedem Sync neu gestartet werden. Die laufen ja schon auf der richtigen IP.

Jetzt hatte ich eingangs gesagt, einiges wie Netzwerkkonfiguration soll nicht gesynct werden, kann man aber machen, wenn man die IPs / Macs usw. passend ersetzt. Und deswegen sollte das auch ein PULL sein, weil der Hotstand-By weiß, welche IPs er hat, der Quellserver muß das nicht wissen und muß es dann auch nicht fixen, wozu er mehr als nur Rsync Zugang bräuchte.

Wenn man / syncen will

Wenn man wirklich dumme Sachen machen will:

rsync -a –delete -v -e „ssh -C -i /root/.ssh/synckey“ root@$ZIELSERVER:/ –exclude=/{dev,proc,run,sys,tmp} /

dann klammert wenigstens /dev /proc /sys und /run aus, wenn Euch schon nicht anders zu helfen ist 😉  Denkt dran, das bei dem Sync jeder CRON, egal ob per crond oder systemd, sofort gelöscht wird. Ein nachträglicher Fix oder weiteren Sync wird es nicht geben, wenn Ihr die nicht auch excluded!  Außerdem denkt dran, Ihr synct auch die Syncbefehle, libs und /bin usw.. das kann böse ins Auge gehen, deswegen sagte ich, daß das eine Dummheit wäre. Wenn so ein Sync während es Updates passiert, ist das Update weg und nur noch halb vorhanden oder nur halb gesynct. Tut es nicht, wenn es nicht absolut sein muß, oder tut es in ein Unterverzeichnis.