Martin Schmiderer schrieb:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Am Freitag, 4. Juli 2003 13:50 schrieb J. Kochhann:

...

Hallo Liste !

Ich habe 2 Linux Server. Einen mit DAT-Streamer, einen ohne. Ich möchte auf dem Server ohne Streamer ein tar-archive erzeugen, welches aber aus Platzgründen nicht erst lokal, sonder direkt auf dem Server mit dem Streamer landen soll ???

In etwa so:

tar -cvzf 192.168.4.200:~/backup/meinarchiv.tar /etc

Leider funktioniert aber die Angabe der IP-Nr. nicht. Wer kann mir weiter helfen ???

...

Danke Jörg Hi *,

was Du suchst ist tar cpf - | rsh host "(cd directory && tar xvf - )"

Oder per NFS ;-)

On 4 Jul 2003 at 14:44, Daniel Bauer wrote:

On 4 Jul 2003 at 13:50, J. Kochhann wrote:

...

Hallo Liste !

Ich habe 2 Linux Server. Einen mit DAT-Streamer, einen ohne. Ich möchte auf dem Server ohne Streamer ein tar-archive erzeugen, welches aber aus Platzgründen nicht erst lokal, sonder direkt auf dem Server mit dem Streamer landen soll ???

In etwa so:

tar -cvzf 192.168.4.200:~/backup/meinarchiv.tar /etc

Leider funktioniert aber die Angabe der IP-Nr. nicht. Wer kann mir weiter helfen ???

Hallo Jörg,

Du kannst das mit tar selbst lösen:

z.B. tar --rsh-command=/usr/bin/ssh -Mcvf server:/dev/st0 /home

Noch eine Anmerkung dazu: rmt muß auf dem Server mit Band vorhanden sein. Ich habe dazu einen Link nach /etc/rmt machen müssen, Original habe ich unter /sbin/rmt gefunden. Bis denne Daniel

On Fri, Jul 04, 2003 at 04:54:18PM +0200, Al Bogner wrote:

Brauche ich in diesem Fall --rsh-command=/usr/bin/ssh ? Wie sollte dann die Syntax aussehen?

Das sind alles GNU-ismen. Ohne GNU-Tools macht man das so: export RSH=ssh (oder rsh, wenn man kein ssh hat) tar cvf - /zu/sicherndes/verzeichnis | $RSH user@host.mit.tape "dd of=/dev/st0" Hier schreibt tar mit "-f -" das Tape-Archive nach stdout, und stdout wird per Pipeline über das Netz auf host.mit.tape gesendet. Dort wird das Tape-Archive zum stdin von dd, das es dann auf das Band schreibt. Hinweise: - Es ist schneller "buffer -o ..." statt "dd" zu verwenden, wenn man die Möglichkeit hat. - DDS-Tapes schreiben schneller, wenn man variable Blocksize verwendet. Dazu "mt -f /dev/nst0 setblk 0" setzen. Kristian

* Al Bogner schrieb am Freitag, 2003-07-04:

client erstellt eine tgz-Datei von den Homeverzeichnissen von server, wobei server eine Datei authorized_keys mit Schlüssel von client hat.

Es ist IMHO nicht übermäßig sinnvoll, den Client die Wahl treffen zu lassen, was er vom Server holen möchte -- besser wäre es, auf dem Server eine Liste der zu sichernden Verzeichnisse zu führen und ein Skript auszuführen, das genau diese Verzeichnisse sichert. Etwa so: (Server /etc/backupdirs) /etc /home (Server /root/bin/remotebackup) #!/bin/sh tar -czf - `cat /etc/backupdirs` (Client /home/user/bin/serverbackup) #!/bin/sh ssh root@server /root/bin/remotebackup > serverbackup.tar.gz Das hat zur Folge, daß auf dem Server der tar-Befehl ausgeführt wird und die Daten in die Standardausgabe geschrieben werden, die ssh an den Client weiterleitet, wo sie dann in eine Datei umgeleitet werden. Diese Lösung hat aber ein klaffendes Sicherheitsloch, weil der Benutzer, als der das Backup läuft, eine interaktive Shell auf dem Server als derjenige Benutzer bekommen kann, als der er sich via SSH anmeldet -- in diesem Fall root, was aus backuptechnischen Gründen wohl in den meisten Fällen so sein wird. Besser ist es, ein neues SSH-Schlüsselpaar ohne Passphrase anzulegen, das nur für die Anmeldung zum Sichern benutzt wird und dann in authorized_keys ganz am Anfang der Zeile mit dem öffentlichen Schlüssel folgendes zu schreiben: command="/root/bin/remotebackup",no-pty,no-port-forwarding Diese Option bewirkt, daß bei der Anmeldung mit diesem Schlüssel immer dieser Befehl ausgeführt wird, ganz gleich, was der Client für Wünsche äußert. Auf diese Weise kann zwar der Backupbenutzer auf dem Client immer noch an alle Daten kommen, die in den zu sichernden Verzeichnissen liegen, aber immerhin kann er den Server nicht mehr sabotieren. Zudem wird noch das Port-Forwarding unterbunden, damit der Client den Server auch nicht während der Laufzeit des Backupskriptes als Ausgangspunkt für Angriffe auf andere Systeme benutzen oder auf irgendwelche Dienste auf dem Server zugreifen kann. Zum Durchführen des Backups reicht dann ein: ssh -T root@server > serverbackup.tar.gz Die Option -T bestätigt auch von der Client-Seite aus, daß der Server keine tty zuzuweisen braucht. Gebe ich das nicht an, bekomme ich bei Textausgaben vom Server den Treppenstufeneffekt. Trotz aller Sicherheit gegen Manipulation des Servers ist so ein DoS-Angriff auf den Server bzw. seine Netzwerkanbindung möglich, indem man einfach zehn Backups gleichzeitig startet. Das noch zu vermeiden, soll dem Leser überlassen bleiben. Und natürlich muß der private Schlüssel gut geschützt werden. -- Christian Ullrich Registrierter Linux-User #125183 "Remember: 'I am a person. I have a right to the ball.'"