Re: nützliche Befehle

Datumsansicht Baumansicht Betreffansicht Attachement-Sicht

From: Michael Lestinsky (michael.lestinsky_at_energis-ision.com)
Date: 13. Sep 2001


Am 13.09.'01 schrieb Raphael H. Becker:
> Lange Zeit spaeter habe ich mal rausgefunden, dass man in jede pipe (das
> "|") auch ein ssh-Befehl einbauen kann, der remote einen anderen Befehl
> ausfuehrt und diesem stdin uebergibt; kopieren eines Verzeichnisses von
> tower1 ueber das Netzwerk auf tower2 in ein Unterverzeichnis sieht
> demnach so aus:

Ich mache meine Backups mittlerweile so:

(sh-Teil-Skript)

fsdump () {
    FILE="${SPOOL}/$2.${LEVEL}-dump.gz"
    dump -${LEVEL}au -h 0 -f - $1 2>/dev/null | \
        ssh -c blowfish -l $USER $HOST "buffer -p 70 | gzip > ${FILE}"
    if [ $? != 0 ]; then
      exit $?
    fi
}

fsdump / root
fsdump /usr/local usr_local

Ich lasse die Kompression hier auf dem Zielrechner erledigen, da sich
dies aus Performance-Gruenden als besser zeigte. Andersherum sieht es so
aus:

Hier findet die Kompression vor der "SSH-Pipe" statt, da hier SSH auf
dem Zielrechner zuviel Last erzeugt und ein gzip zuviel Rechenzeit
wegfressen wuerde. Ausserdem reduziert dies die Last, die verschluesselt
werden muss.

fsdump () {
    FILE="${SPOOL}/$2.${LEVEL}-dump.gz"
    dump -${LEVEL}au -h 0 -f - $1 2>/dev/null | buffer -p 70 | gzip | \
        ssh -c blowfish -l $USER $HOST "cat > ${FILE} ; chflags nodump ${FILE}"
        # ^^^^^^^^^^^^^^^^^^^^^^
    if [ $? != 0 ]; then
      exit $?
    fi
}

Wobei hier der Zielrechner ein OpenBSD ist. Ich weiss nicht, ob das
nodump-Flag hier rekursiv ausgewertet wird, daher setze ich es nach der
Uebertragung einfach fuer diese Datei (unterstrichener Teil).
Linuxseitig muss ich dies nicht tun, da hier das nodump-Flag in einem
Verzeichnis rekursiv an alle Dateien darin uebergeben wird. Dort habe
ich also nur einmalig das nodump-Flag auf ${SPOOL} gesetzt.
Dies war wichtig um das im Thread "Resonanzkatastrophe" angesprochene
Problem zu loesen.

Besonders beachte man auch das "buffer" vor dem "gzip", wodurch der
Transfer um ca. 500kB beschleunigt wurde, da dump, gzip und ssh so
(zumindest zu einem gewissen Grad) voneinander entkoppelt wurden.

So schafe ich derzeit Transferraten um 2500kB/sec.

Ich weiss, ein Bandlaufwerk waere besser... Aber mir geht es nicht um
langfristige Archivierung, sondern um 1. Desaster-Recovery (Platten-Crash...)
und 2. Operator-Fault (etwa rm -r im falschen Verzeichnis...).

Es empfiehlt sich natuerlich zu testen ob das eigene Konstrukt zum
erstellen der Backups tatsaechlich funktioniert. Insbesondere sollte man
also testen, ob die Restore-Funktionen diese Files wieder einlesen koennen.

Bye
Michael


Datumsansicht Baumansicht Betreffansicht Attachement-Sicht

Dieses Archiv wurde generiert von hypermail 2.1.2 : 11. Mar 2002 CET