Hallo,
ich versuche aktuell mit einer SSH Verbindung ein Backup von ein paar
Daten vom Server vorzunehmen. Soweit so gut, ich kann mich verbinden und
auch Ordner auswählen und das Archiv wird lokal gespeichert.
Sebastian schrieb:> ich versuche aktuell mit einer SSH Verbindung ein Backup von ein paar> Daten vom Server vorzunehmen. Soweit so gut, ich kann mich verbinden und> auch Ordner auswählen und das Archiv wird lokal gespeichert.> ssh username@server-ip 'cd /srv/www/public/demo/ && tar -cf - * | gzip> -9' >/home/backup/www/backup.tgz
tar kann auch selber gzip aufrufen.
1
ssh username@server-ip 'cd /srv/www/public/demo/ && tar -czf /home/backup/www/backup.tgz *
Nur das -9 bekommt man nur mit Umweg rein. Aber dann kann man auch
gleich bzip2 oder xz verwenden. Die sind langsamer, aber komprimieren
deutlich besser.
> nun möchte ich 2 Ordner auschliessen die nicht mit einbezogen werden> sollen, wenn ich z.B. exclude hinzufüge,> ssh username@server-ip 'cd /srv/www/public/demo/ && tar -cf - * &&> --exclude=/srv/www/public/demo/sql/* | gzip -9'>>/home/backup/www/backup.tgzSebastian schrieb:> dann bekomme ich die Meldung> bash: --exclude=/srv/www/public/demo/sql/*:> No such file or directory
Das liegt daran, dass du mit deiner Kommandozeile versuchst, ein
Programm aufzurufen, das --exclude=/srv/www/public/demo/sql/* heißt. Ein
Programm mit diesem Namen gibt es natürlich nicht. Lass mal das && vor
dem --exclude weg.
Rolf M. schrieb:> tar kann auch selber gzip aufrufen.> ssh username@server-ip 'cd> /srv/www/public/demo/ && tar -czf /home/backup/www/backup.tgz *> Nur das -9 bekommt man nur mit Umweg rein. Aber dann kann man auch> gleich bzip2 oder xz verwenden. Die sind langsamer, aber komprimieren> deutlich besser.
Ups, hab jetzt erst gesehen, dass da noch die Übertragung gleich mit
dabei ist.
Also eher so:
1
ssh username@server-ip 'cd /srv/www/public/demo/ && tar -cz *' > /home/backup/www/backup.tgz
Kopier den tar Aufruf vorher als script auf das zielsystem, damit umgeht
man das Problem das die Kommandos von mehreren Shells interpretiert
werden.
scp script foo:/tmp
ssh foo chmod ugo+x /tmp/script
ssh foo /tmp/script > bla
----------------
Ansonsten musst du die Quotes quoten, also \' oder \\'
Ralf D. schrieb:> Und mit ein wenig RTFM kann man sich das ganze Shell-Geraffel sparen.ssh> username@server-ip 'tar -C /srv/www/public/demo/ -cz -f> /home/backup/www/backup.tgz --exclude=sql .'
Das ist nicht das selbe.
Ralf D. schrieb:> Macht fast das gleiche, nimmt nur eben auch eventuelle dotfiles mit.
Nein, ein ganz wesentliches Element fehlt. Aber mach dir nichts draus.
Das hab ich am Anfang auch übersehen. 😀
Sebastian schrieb:> ich versuche aktuell mit einer SSH Verbindung ein Backup von ein paar> Daten vom Server vorzunehmen. Soweit so gut, ich kann mich verbinden und> auch Ordner auswählen und das Archiv wird lokal gespeichert.
Also... äh... da fallen mir auf die Schnelle etwa drölfzig Millionen
Ideen ein, wie man das eleganter gestalten kann.
Ok, Du willst Dich von einem Client auf einen Server verbinden und dort
Deine Daten herunterladen, korrekt? Für sowas gibt es doch schon fertige
Software, rsync, SFTP, SCP und sshfs(1) fallen mir da ein, und SCMs wie
Git, Mercurial und Subversion. Und für Profis natürlich Ansible...
Man möchte übrigens schon lange nicht mehr gzip(1) benutzen. Stattdessen
gibt es pigz(1), für das Multithreading! ;-)
gzip(1) -9 braucht auch kaum jemand. Die bessere Komprimierung dauert
meistens viel länger als eine handelsübliche Netzwerkübertragung. Wenn
die langsam ist, dann doch bitte lieber xz(1) oder 7z(1) benutzen! ;-)
Ach ja: die meisten Netzwerkprotokolle -- darunter SSH, HTTP(S), ... --
können schon selbst komprimieren. Da bewirkt Deine eigene Komprimierung
eher... mehr Aufwand.
Nur so ein paar Ideen, YMMV.
> tar -cz * --exclude=sql/*
Zwei Punkte dazu:
a) Das vordere Sternchen gehört, mit einem "--" getrennt, nach hinten
(sonst werden Dateien, die mit "-" anfangen, als Option angesehen.
b) Das hintere Sternchen muß escaped werden, damit nicht das Shell
bereits versucht, es zu erweitern.
Also
tar -cz --exclude="sql/*" -- *
Sheeva P. schrieb:> lso... äh... da fallen mir auf die Schnelle etwa drölfzig Millionen> Ideen ein, wie man das eleganter gestalten kann.
Ich finde das eigentlich sehr elegant.
> Ok, Du willst Dich von einem Client auf einen Server verbinden und dort> Deine Daten herunterladen, korrekt?
Meinem Verständnis nach sucht er einen einfachen Weg, auf dem Server ein
tar.gz-Archiv zu erstellen und das auf den Client zu übertragen. Er hat
einen simplen Einzeiler, der das tut, ohne dass auf Client oder Server
dazu extra noch irgendwas konfiguriert oder installiert werden müsste.
> Für sowas gibt es doch schon fertige Software, rsync, SFTP, SCP und sshfs(1)
Damit müssten aber erst mal alle Dateien einzeln übertragen werden.
Danach müsste er dann auf der Client-Seite das Archiv erzeugen. Welchen
Vorteil hätte das? Ich sehe da auch noch das Problem, dass bei der
Übertragung ggf. nicht alle Dateiattribute 1:1 übernommen werden können
und dann verfälscht im Archiv landen.
> fallen mir da ein, und SCMs wie Git, Mercurial und Subversion. Und für> Profis natürlich Ansible...
Da wird's dann aber schwierig, ohne erst noch zusätzliche Software auf
dem Server und ggf. dem Client zu installieren. Und auch wenn ein RCS
eine tolle Sache für die Verwaltung von Quellcode ist, würde ich es
nicht unbedingt als Backup-Tool nutzen.
> Man möchte übrigens schon lange nicht mehr gzip(1) benutzen. Stattdessen> gibt es pigz(1), für das Multithreading! ;-)
Ja, pigz ist praktisch. Oder auch pbzip2.
> Ach ja: die meisten Netzwerkprotokolle -- darunter SSH, HTTP(S), ... --> können schon selbst komprimieren.
Und da kann man auch angeben, dass die Daten auf Empfänger-Seite nicht
wieder dekomprimiert werden sollen?
Rolf M. schrieb:> Ralf D. schrieb:>> Macht fast das gleiche, nimmt nur eben auch eventuelle dotfiles mit.>> Nein, ein ganz wesentliches Element fehlt. Aber mach dir nichts draus.> Das hab ich am Anfang auch übersehen. 😀
Ah ja, auf so eine Idee würde ich nicht kommen - zu viel Erfahrung mit
Netzwerkstörungen. ;-) Da ist ein Retry eines Filetransfers (der dann
inkrementell laufen kann) doch deutlich netter als das Archiv neu
generieren zu müssen.
Ändert aber nicht daran, dass man sich das Shell-Geraffel mit dem cd
sparen kann, so dass es nur ein einziger Aufruf auf der Zielseite ist.
lass doch das /* weg
Es soll doch eine Datei oder Verzeichnis angegeben werden und dieses
lautet eben
/srv/www/public/demo/sql alles was drunter liegt gehört doch dazu