volle Bandbreite ausnutzen

[blackm]

Hi,

ich hab mir gerade mal ein backup Script geschrieben. Es werden ein paar tar balls erzeugt die ich dann per ftp auf einen anderen Rechner schiebe.
Irgendwie ist das mit dem ftp aber ein bischen langsam (< 5 MB/s bei einer 100 Mbit Leitung).
Deswegen hab ich mir ueberlegt das ich ja auch die tar balls direkt auf einen tcp Socket schreiben kann (also nicht er auf die Platte) und dann direkt auf den anderen Rechner uebertrage. Problem ist nur das ich sowas noch nie geschrieben hab, deswegen interessiert mich ob das die gewuenschte performance bringt (in perl geschrieben).

by, Martin

[abi]

hast du mal über den Einsatz von rsync nachgedacht?

[tylerD]

Also IMHO hat ftp schon recht wenig Overhead, der je großer die Files im Verhältniss immer kleiner wird. Deshalb wirst du wohl nicht viel Zeit gewinnen können, da du ja auch erst noch einen Server schreiben mußt usw.

Vielleicht solltest du einfach mal nachschauen ob es eventuell ander Gründe (DMA für Festplatten, Prozessorauslastung usw) für die Geschwindigkeit gibt.

cu

[pdreker]

rsync ist auf jeden Fall eleganter...

Aber um Blackm's Idee 'mal auszubauen: netcat ist die Lösung...
Auf dem Zielrechner:

Code: Alles auswählen

nc -l -p 12345 > Datei.tar.gz

und auf dem Quellrechner

Code: Alles auswählen

tar cvzf - /verzeichnis | nc zielhost 12345

Patrick

[tylerD]

Aber um Blackm's Idee 'mal auszubauen: netcat ist die Lösung...
Auf dem Zielrechner:

Code: Alles auswählen

nc -l -p 12345 > Datei.tar.gz

und auf dem Quellrechner

Code: Alles auswählen

tar cvzf - /verzeichnis | nc zielhost 12345

Und ich depp hätt mich wieder hingesetzt und sowas selbst gecodet warum einfach wenns auch schwer geht?

cu

[blackm]

Vielleicht solltest du einfach mal nachschauen ob es eventuell ander Gründe (DMA für Festplatten, Prozessorauslastung usw) für die Geschwindigkeit gibt.

Also der proftp ist schon der Grund warum der Celeron 433 zu 100 % ausgelastet ist.
Ich hatte es auch mal testweise per nfs versucht, war schneller als ftp aber ist zu uncool (das kann ja jeder *g*).

@try: Ne, hatte ich noch nicht drueber nachgedacht, liegt aber wahrscheinlich daran das ich nicht weis was das eigentlich ist

@Patrick: Ja, so in der richtung hatte ich mir das vorgestellt

Code: Alles auswählen

blackm@client:~$ apt-cache search netcat
[...]
netcat - TCP/IP swiss army knife
[...]

Nette Beschreibung

@tylerD: Ich haette wahrscheinlich das gleiche gemacht! Ein Hoch auf Patrick

by, Martin

EDIT: netcat rockt! Geht viel schneller und die Festplatte ist nun die geschrindigkeitsbestimmende Komponente.

[blackm]

Also ich hab nun was hinbekommen, was funktioniert.

Code: Alles auswählen

#! /bin/sh

HOST=client.home

# is remote host reachable?
if ! ping -c 1 -i 1 $HOST >/dev/null 2>&1
then
    exit 1
fi

# create lock file on remote host
ssh backup@$HOST touch /tmp/backup_in_process

# tar the filesystem
ssh backup@client.home rm -f /var/backups/etc.tar
ssh -f backup@client.home "netcat -l -p 12345 > /var/backups/etc.tar "
sleep 5
cd /etc && tar -cf - ./ | netcat $HOST 12345 -q 5
sleep 2

ssh backup@client.home rm -f /var/backups/root.tar
ssh -f backup@client.home "netcat -l -p 12345 > /var/backups/root.tar"
sleep 5
cd /root && tar -cf - ./ | netcat $HOST 12345 -q 1
sleep 2

ssh backup@client.home rm -f /var/backups/home.tar
ssh -f backup@client.home "netcat -l -p 12345 > /var/backups/home.tar"
sleep 5
cd /home && tar -cf - ./ | netcat $HOST 12345 -q 1
sleep 5

ssh backup@client.home rm -f /var/backups/var.tar
ssh -f backup@client.home "netcat -l -p 12345 > /var/backups/var.tar"
sleep 5
cd /var && tar -cf - ./backups ./cache ./dhcp ./lib ./local ./lock ./log ./mail ./nfs-tv ./opt ./run ./spool ./state ./vhost ./www | netcat $HOST 12345 -q 1
sleep 5

#change owner and permissions on remote host
ssh backup@$HOST chmod 400 /var/backups/etc.tar /var/backups/root.tar /var/backups/home.tar /var/backups/var.tar
ssh backup@$HOST chown backup:backup /var/backups/etc.tar /var/backups/root.tar /var/backups/home.tar /var/backups/var.tar

# remove lock file on remote host
ssh backup@$HOST rm -f /tmp/backup_in_process

Auf gzip hab ich wegen dem lahmen Server (433 Mhz) verzichtet.

by, Martin