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