Mehrere Server via ssh/rsync sichern
Hallo Liste. Ich möchte gerne mehrere Server auf einen Backup-Server sichern, und zwar einmal täglich per rsync/ssh. Dabei stelle ich mir folgende Verzeichnisstruktur auf dem Backup-Server vor: /backup/srv1/... /backup/srv2/... Dabei sollen auch Verzeichnisse wie /etc und /var mitgesichert werden. Das Problem ist nun, daß viele Dateien in /etc root gehören. Das bedeutet mithin, daß ich dem per rsync einliefernden Rechner ebenfalls root-Rechte einräumen muß, damit alles in /etc und damit in /backup/srv1/etc... mitgesichert bzw. geändert werden kann. Sprich: der Aufruf von rsync muß etwa so lauten: rsync -a -e ssh /etc root@backuphost:/backup/srv1 Aber ich will natürlich andererseits nicht, daß srv1 root-Rechte erlangt, wenn er sich auf dem Backup-Server einloggt. Wie kann ich das Dilemma lösen? So etwas wie tar würde mir zwar die Problematik lösen. Das Problem ist aber, daß es sich um mehrere hundert GB an Daten handelt, von denen sich von Sicherungslauf zu Sicherungslauf nur ein paar MB ändern. Bei tar müßte ich aber jedesmal alles übertragen. Freue mich auf Denkanstöße! -- Andre Tann
Quoting Andre Tann
Hallo Liste.
Ich möchte gerne mehrere Server auf einen Backup-Server sichern, und zwar einmal täglich per rsync/ssh. Dabei stelle ich mir folgende Verzeichnisstruktur auf dem Backup-Server vor:
/backup/srv1/... /backup/srv2/...
Dabei sollen auch Verzeichnisse wie /etc und /var mitgesichert werden. Das Problem ist nun, daß viele Dateien in /etc root gehören. Das bedeutet mithin, daß ich dem per rsync einliefernden Rechner ebenfalls root-Rechte einräumen muß, damit alles in /etc und damit in /backup/srv1/etc... mitgesichert bzw. geändert werden kann. Sprich: der Aufruf von rsync muß etwa so lauten:
rsync -a -e ssh /etc root@backuphost:/backup/srv1
Aber ich will natürlich andererseits nicht, daß srv1 root-Rechte erlangt, wenn er sich auf dem Backup-Server einloggt.
Wie kann ich das Dilemma lösen?
entweder die Daten vom Client per cron-Job auf den Backup-Server pushen. /backup muß ja nicht root gehören. Oder in der authorized_keys auf dem Client mit COMMAND=... arbeiten, z.B. so: command="rsync --rsh="ssh -i /root/.ssh/backupserver.key" -avz / root@backupserver:daten/" ssh-rsa <public key> (alles in einer Zeile) Ich mache hier sowohl als auch. Die Daten werden per cron von den Clients gepackt und als tar.gz auf den Server geschoben, auf dem Server gibts dafür nen User "backups", der für jeden Client eine entsprechende Zeile in der authorized_keys hat und die Backups ins $HOME kriegt. So hat keiner auf dem Serer rootrechte und es gibt keinen Extra-Login auf den Clients. -- Erhard Schwenk Akkordeonjugend Baden-Württemberg - http://www.akkordeonjugend.de APAYA running System - http://www.apaya.net
Erhard Schwenk, Montag, 4. September 2006 15:32:
entweder die Daten vom Client per cron-Job auf den Backup-Server pushen.
Ja, genau so will ich es machen. Aber das betrifft das Problem ja nicht, denn:
/backup muß ja nicht root gehören.
Nein, muß es nicht. Aber /backup/etc... gehört root. D.h. wenn ich so hineinschreiben will, daß der Eigentümer der Datei erhalten bleibt, dann muß ich mit root-Rechten arbeiten. Dabei spielt es keine Rolle, ob die Clients per cron auf den Server einliefern, oder ob (was in meinem Falle nicht ginge) der Server per cron von den Clients saugt.
Oder in der authorized_keys auf dem Client mit COMMAND=... arbeiten, z.B. so:
command="rsync --rsh="ssh -i /root/.ssh/backupserver.key" -avz / root@backupserver:daten/" ssh-rsa <public key>
Wo kann man denn da genauer nachlesen? man authorized_keys gibts jedenfalls nicht...
Ich mache hier sowohl als auch. Die Daten werden per cron von den Clients gepackt und als tar.gz auf den Server geschoben
Das bedeutet, daß Du das Problem dadurch umschiffst, daß Du vorher mit tar packst. Dann bleiben Dir natürlich die Eigentümer der Dateien erhalten. Aber was, wenn die .tar.gz hunderte von GB groß ist? Dann überträgst Du doch lauter unnötiges Volumen, wenn sich nur wenige MB geändert haben. -- Andre Tann
Am Montag, 4. September 2006 15:45 schrieb Andre Tann:
Erhard Schwenk, Montag, 4. September 2006 15:32:
entweder die Daten vom Client per cron-Job auf den Backup-Server pushen.
Ja, genau so will ich es machen. Aber das betrifft das Problem ja
nicht, denn:
/backup muß ja nicht root gehören.
Nein, muß es nicht. Aber /backup/etc... gehört root. D.h. wenn ich so hineinschreiben will, daß der Eigentümer der Datei erhalten bleibt, dann muß ich mit root-Rechten arbeiten.
Dabei spielt es keine Rolle, ob die Clients per cron auf den Server einliefern, oder ob (was in meinem Falle nicht ginge) der Server per cron von den Clients saugt.
Oder in der authorized_keys auf dem Client mit COMMAND=... arbeiten, z.B. so:
command="rsync --rsh="ssh -i /root/.ssh/backupserver.key" -avz / root@backupserver:daten/" ssh-rsa <public key>
Wo kann man denn da genauer nachlesen? man authorized_keys gibts jedenfalls nicht...
man sshd im Abschnitt AUTHORIZED_KEYS FILE FORMAT Jürgen -- Dr.rer.nat. Juergen Vollmer, Viktoriastrasse 15, D-76133 Karlsruhe Tel: +49(721) 92 04 87 1 Fax: +49(721) 92 04 87 2 Juergen.Vollmer@informatik-vollmer.de www.informatik-vollmer.de Internet-Telefonie: www.skype.com Benutzer: juergen.vollmer
Quoting Andre Tann
Erhard Schwenk, Montag, 4. September 2006 15:32:
entweder die Daten vom Client per cron-Job auf den Backup-Server pushen.
Ja, genau so will ich es machen. Aber das betrifft das Problem ja nicht, denn:
/backup muß ja nicht root gehören.
Nein, muß es nicht. Aber /backup/etc... gehört root. D.h. wenn ich so hineinschreiben will, daß der Eigentümer der Datei erhalten bleibt, dann muß ich mit root-Rechten arbeiten.
Ah ok ich sehe was Du meinst. Mehrere Lösungsmöglichkeiten: - Du verwendest Netzwerkweit identische UIDs und GIDs, am besten über ein zentral verwaltetes Directory (z.B. LDAP oder NIS/YP oder pam_mysql). Dann ist das Problem schlicht egal, weil ja jeder überall nur an seine Daten kommt. Es bleibt allerdings die Notwendigkeit, die Daten im Backup-Prozeß als root zu schreiben. In dem Fall würde ich zu "Server holt sich die Daten von den Clients" tendieren, so daß die Clients auf keinen Fall einen Root-Zugriff auf den Server kriegen. - Du sicherst die Rechte in eine extra Datei (oder extra Dateien) und schiebst dann alles mit backup.users 600 (bzw. 700 bei Directories) auf den Server. Beim Restore kannst Du dann mit einem Skript die Rechte anhand des gesicherten File wiederherstellen. Diese Vorgehensweise funktioniert auch mit Posix-ACLs ganz gut. - Du archivierst die Daten auf dem Server in eine afio- oder tar.gz-Datei.
Oder in der authorized_keys auf dem Client mit COMMAND=... arbeiten, z.B. so:
command="rsync --rsh="ssh -i /root/.ssh/backupserver.key" -avz / root@backupserver:daten/" ssh-rsa <public key>
Wo kann man denn da genauer nachlesen? man authorized_keys gibts jedenfalls nicht...
man sshd; man ssh
Das bedeutet, daß Du das Problem dadurch umschiffst, daß Du vorher mit tar packst. Dann bleiben Dir natürlich die Eigentümer der Dateien erhalten. Aber was, wenn die .tar.gz hunderte von GB groß ist? Dann überträgst Du doch lauter unnötiges Volumen, wenn sich nur wenige MB geändert haben.
rsync sollte da eigentlich nur die Differenz üebrtragen. Problematisch bleibt aber zugegeben, daß das Archiv auf dem Client jedesmal komplett zusammengerechnet werden muß, um selbige zu bestimmen (man kann es allerdings zumindest über nen FIFO an rsync schieben, so daß es keinen Plattenplatz belegt). Wenn rsync mit tar.gz nicht so recht funktionieren will, kann man es auch noch mit afio probieren, das packt Dateiweise, was für rsync evtl. besser zu durchschauen ist und auch robustere Archive erzeugt, die nicht wegen einem Bitkipper am Anfang komplett unbrauchbar werden. Das Packen auf dem Client hat hier durchaus Vorteile - meistens idlen die zur Backup-Zeit eh nur rum und haben endlos CPU-Zeit übrig, während der Backup-Server mit dem Packen von GBs an Daten von zig Clients evtl. überfordert sein könnte. -- Erhard Schwenk Akkordeonjugend Baden-Württemberg - http://www.akkordeonjugend.de APAYA running System - http://www.apaya.net
Hallo Erhard, Erhard Schwenk, Montag, 4. September 2006 16:21:
- Du sicherst die Rechte in eine extra Datei (oder extra Dateien) und schiebst dann alles mit backup.users 600 (bzw. 700 bei Directories) auf den Server. Beim Restore kannst Du dann mit einem Skript die Rechte anhand des gesicherten File wiederherstellen. Diese Vorgehensweise funktioniert auch mit Posix-ACLs ganz gut.
Dies Variante könnte ganz gut passen. Dazu zwei Fragen: - wie kann man denn auf einfache Weise sämtliche Rechte und Besitzverhältnisse an den Dateien und Verzeichnissen eines ganzen Baums in eine Datei sichern? Und wie wiederherstellen? - wie kann ich allen Dateien einen bestimmten user und eine bestimmte Rechtemaske überstülpen (also backup:users 0600 wie in Deinem Beispiel)? -- Andre Tann
Andre Tann, Dienstag, 5. September 2006 23:13:
- wie kann man denn auf einfache Weise sämtliche Rechte und Besitzverhältnisse an den Dateien und Verzeichnissen eines ganzen Baums in eine Datei sichern? Und wie wiederherstellen?
Ergänzung: ich habe mir mal stat angesehen. Wäre so etwas eine gute Idee? find /etc -exec stat -t "{}" \; > rechte.lst Was ich noch nicht herausfinden konnte ist, wie ich nach einer Wiederherstellung der Dateien die Rechte aus rechte.lst auslese und den Dateien/Verzeichnissen überstülpe. -- Andre Tann
Hallo, Am Die, 05 Sep 2006, Andre Tann schrieb:
Andre Tann, Dienstag, 5. September 2006 23:13:
- wie kann man denn auf einfache Weise sämtliche Rechte und Besitzverhältnisse an den Dateien und Verzeichnissen eines ganzen Baums in eine Datei sichern? Und wie wiederherstellen?
Ergänzung: ich habe mir mal stat angesehen. Wäre so etwas eine gute Idee?
find /etc -exec stat -t "{}" \; > rechte.lst
Was ich noch nicht herausfinden konnte ist, wie ich nach einer Wiederherstellung der Dateien die Rechte aus rechte.lst auslese und den Dateien/Verzeichnissen überstülpe.
find /etc/ -print0 | xargs -0 stat -c "chown %u.%g '%n'; chmod %a '%n';" Ggfs. musst du das noch um lsattr / ACLs erweitern, und zwar so, dass du ebenso passenden Aufrufe von 'chattr' bzw. 'setfacl' generierst, z.B.: lsattr -R | awk ' $1 !~ /:$|^-*$/ { gsub("-","",$1); print "chattr ", gensub("([^-])","+\\1","g",$1), q $2 q; }' q="'" Das mit dem "q" ist deshalb, weil es sonst unuebersichtlich zu quoten ist: print "chattr ", gensub("([^-])","+\\1","g",$1), "'"'"'"$2"'"'"'"; ^^^^^^^^^^^^^^^^ *lol* Aufpassen muss man aber (in beiden Faellen) wg. Dateinamen, die ein ' enthalten, da bin ich aber schon zu muede zu. Zum Wiederherstellen dann einfach sh rechte.lst aufrufen :) -dnh -- They backflip over bullets and grab onto helicopters falling from the sky in an apparent effort to inspire Isaac Newton's enraged corpse to reanimate and hunt them down. -- Mr. Cranky on "Charlie's Angels: Full Throttle"
David Haller, Mittwoch, 6. September 2006 00:14:
find /etc/ -print0 | xargs -0 stat -c "chown %u.%g '%n'; chmod %a '%n';"
Das ist elegant... Man schreibt das Restore-Skript schon beim auslesen...
Zum Wiederherstellen dann einfach
sh rechte.lst
Und sh stört sich nicht daran, daß das Zeilenende nur durch Null-Charakters dargestellt wird? -- Andre Tann
Hallo, Am Mit, 06 Sep 2006, Andre Tann schrieb:
David Haller, Mittwoch, 6. September 2006 00:14:
find /etc/ -print0 | xargs -0 stat -c "chown %u.%g '%n'; chmod %a '%n';"
Das ist elegant... Man schreibt das Restore-Skript schon beim auslesen...
Jip. :)
Zum Wiederherstellen dann einfach
sh rechte.lst
Und sh stört sich nicht daran, daß das Zeilenende nur durch Null-Charakters dargestellt wird?
Die futtert schon das xargs -0 weg ;) Wie gesagt, mit ' im Dateinamen gibt's Probleme, mal schauen, ob mir morgen noch was dazu einfaellt. -dnh --
Womit erstellt ihr so eure Homepages? mit vim *g*. Wobei es Leute gibt, die tatsächlich behaupten, das soll auch mit diesem Betriebssystem - wie heißt es doch gleich - *äh* Emacs gehen. [> Bernd Stäglich und Philipp Zacharias in suse-linux]
Am Montag, 4. September 2006 15:03 schrieb Andre Tann:
rsync -a -e ssh /etc root@backuphost:/backup/srv1
Aber ich will natürlich andererseits nicht, daß srv1 root-Rechte erlangt, wenn er sich auf dem Backup-Server einloggt.
So etwas wie tar würde mir zwar die Problematik lösen. Das Problem ist aber, daß es sich um mehrere hundert GB an Daten handelt, von denen sich von Sicherungslauf zu Sicherungslauf nur ein paar MB ändern. Bei tar müßte ich aber jedesmal alles übertragen.
nö wieso, es gibt doch die --newer oder auch --incremental Optionen bei tar.
Freue mich auf Denkanstöße!
Dier Verzeichnisse per NFS mounten, aber ok da geht natürlich der Vorteil von rsync verloren, da ja alles über die Leitung geht. PS: rsnapshot automatisiert das ganze Procedere etwas. Ist aber ssh + rsync Bye Jürgen -- Dr.rer.nat. Juergen Vollmer, Viktoriastrasse 15, D-76133 Karlsruhe Tel: +49(721) 92 04 87 1 Fax: +49(721) 92 04 87 2 Juergen.Vollmer@informatik-vollmer.de www.informatik-vollmer.de Internet-Telefonie: www.skype.com Benutzer: juergen.vollmer
2006/9/4, Andre Tann
werden. Das Problem ist nun, daß viele Dateien in /etc root gehören. Das bedeutet mithin, daß ich dem per rsync einliefernden Rechner ebenfalls root-Rechte einräumen muß, damit alles in /etc
http://troy.jdmz.net/rsnapshot/ http://www.jdmz.net/ssh/ Ich nehm stattdessen einen non-root-Account, der sudo macht. Gruß Martin
Hallo, Am Montag 04 September 2006 15:03 schrieb Andre Tann:
Hallo Liste.
Ich möchte gerne mehrere Server auf einen Backup-Server sichern, und zwar einmal täglich per rsync/ssh. Dabei stelle ich mir folgende Verzeichnisstruktur auf dem Backup-Server vor:
/backup/srv1/... /backup/srv2/...
Anforderung kommt mir bekannt vor :-)
Freue mich auf Denkanstöße!
-- Andre Tann
Wie wär's mit: http://suse-linux-faq.koehntopp.de/q/q-backup-rsync.html in Verbindung mit: http://www.linux-magazin.de/Artikel/ausgabe/2004/09/backups/backups.html Das Ganze gut durchgerührt und angepasst kommt bei mir ein Sicherungsscript raus, das etwa so aussieht: #!/bin/bash cd /root/bin logger backup_all.daily.sh started export PATH=.:$PATH backup_rsync.sh <rechner-1> backup_rsync.sh <rechner-2> backup_rsync.sh <rechner-3> backup_rotate.daily.sh <rechner-1> backup_rotate.daily.sh <rechner-2> backup_rotate.daily.sh <rechner-3> logger backup_all.daily.sh stoped #stop Vom Sicherungsrechner aus werden jeweils ssh-tunnel zu den zu sichernden Rechnern aufgebaut (dort in authorized_keys comannd=...). Dort jeweils eine /etc/rsync-excludes definieren, damit nicht jeder Mis.. wollte sagen nichts unnötiges gesichert wird. Es muss natürlich auf jedem zu sichernden Rechner ein sauber konfigurierter ssh-service laufen (Das wird bei mir eh permanent überwacht) damit die sicherung auf funktioniert. Das rsync-en (kann man das wirklich so schreiben?) geht ziemlich flott. Danach das 'rotieren' der täglichen (oder wöchentlichen, monatlichen ...) Sicherungen dauert deutlich länger, läuft aber auch nur auf dem Sicherungsrechner! Viel Spass -- MfG Rolf Masfelder EMail: rolf.masfelder@nector.de
Hallo, Am Mon, 04 Sep 2006, Rolf Masfelder schrieb: [..]
Das Ganze gut durchgerührt und angepasst kommt bei mir ein Sicherungsscript raus, das etwa so aussieht:
#!/bin/bash
cd /root/bin [..] export PATH=.:$PATH
Besser: export PATH="/root/bin:$PATH" Sonst habe die weiteren Prozesse "." im Pfad, egal in welchem Verzeichnis. -dnh -- At 17, if you don't think _Lord of The Rings_ is the greatest contribution to literature there's something wrong with your head. If you still think that at 50, there's definitely something wrong with your head. -- Terry Pratchett
Hallo Andre, hallo Leute, (sorry für die späte Antwort!) Am Montag, 4. September 2006 15:03 schrieb Andre Tann:
Ich möchte gerne mehrere Server auf einen Backup-Server sichern, und zwar einmal täglich per rsync/ssh. [...] Aber ich will natürlich andererseits nicht, daß srv1 root-Rechte erlangt, wenn er sich auf dem Backup-Server einloggt.
Evtl. wäre AppArmor eine Lösung: Du kannst damit rsync (oder ein Script, das rsync aufruft) einschränken und ihm nur Schreibzugriffe in /backup verpassen - trotz root-Rechten. Das Script sollte natürlich als command= in authorized_keys fest verdrahtet sein ;-) Gruß Christian Boltz PS: In suse-security gab es mal einen Key, um AppArmor der 10.0 von seinen Beschränkungen zu befreien. Könnte ich bei Bedarf raussuchen - obwohl ich eher zur 10.1 rate ;-) PPS: Zufallssig ;-)) -- Bevor es Mißverständnisse gibt: Ja, ich bin willenloser Lustsklave der Göttin "Versionitis", und für ein 'ß' hinter der Versionsnummer tue ich _alles_ [Ratti in suse-linux]
participants (7)
-
Andre Tann -
Christian Boltz -
David Haller -
Dr. Jürgen Vollmer -
Erhard Schwenk -
Martin Schröder -
Rolf Masfelder