Mehrere Befehle in .sh ausführen

[Zerdux]

Hey,
Ich würde gerne in einer .sh - Datei mehrere Befehler per Cronjob hintereinander ausführen.
Zunächst sollen Ordner in einer tar.gz gepackt werden.
Anschließend soll automatisch im Hintergrund die tar.gz an einem anderen Server mittels ssh hochgeladen werden.
Danach soll auf dem Start-Server die tar.gz gelöscht werden.

Meine .sh sieht aktuell so aus:

Code: Alles auswählen

#!/bin/bash

tar cfvz /bUP/serverbackup_`date +"%F"`.tar.gz / &
sleep 36000
sshpass -p 'PASSWORD' scp -r /bUP/* backupmaster@XXX.XXX.XXX.XX:/home/backupmaster/bUP &
sleep 36000
rm /bUP/serverbackup_`date +"%F"`.tar.gz

Leider hab ich es bisher nur zum Packen der Ordner geschafft.
Einzeln in der Konsole ausgeführt funktionieren die Funktionen einwandfrei.
Als .sh ausgeführt macht er nach dem packen nicht weiter.
Die letzte Nachricht die beim "Testlauf" der .sh ausgeführt wird ist:

tar: Beende mit Fehlerstatus aufgrund vorheriger Fehler

Bin im Sachen Bashes noch neu unterwegs und kenn mich daher nicht so gut mit der Thematik aus.
Die Sleep-Funktion soll bewirken dass der Server 10 Stunden wartet, bis er mit der nächsten Aufgabe weiter macht. Nicht dass mitten im Packen das Archiv schon geuploadet wird obwohl es noch nicht vollständig ist und nicht schon beim Upload gelöscht wird und dann am Zielserver mit Datenverlust ankommt.

Das schlaue Internet konnte mir auch nicht weiterhelfen. Borgbackup überträgt gar keine Infos an den anderen Server desweiteren wollte ich eigentlich schon die Möglichkeit haben die .tar.gz gelegentlich herunterzuladen um sie nochmals auf einer Festplatte zu sichern.

[MSfree]

Laß die "&"-Zeichen am Zeilenende weg, dann kannst du dir die sleeps sparen.

Die "&"-Zeichen bewirken, daß ein Befehl in den Hintergrund geschickt wird und der nächste Befehl (parallel) abgearbeitet wird. In deinem Fall schickt du tar in den Hintergrund und läßt sleep parallel dazu 10 Stunden (=36000 Sekunden) warten. Das ist nicht nur unzuverlässig, wenn ein Befehl mal länger als 10h braucht, in den meisten Fällen wartet die das Skript zu Tode, obwohl der Hintergrundprozeß längst fertig ist.

So

Code: Alles auswählen

tar cfvz /bUP/serverbackup_`date +"%F"`.tar.gz /
sshpass -p 'PASSWORD' scp -r /bUP/* backupmaster@XXX.XXX.XXX.XX:/home/backupmaster/bUP
rm /bUP/serverbackup_`date +"%F"`.tar.gz

würdem alle Befehle schön hintereinander abgearbeitet und zwar unmittelbar sofort, sobald eine fertig wird.

[uname]

Du kannst noch die (testweise) Eingabe einer Taste zwischen den Befehlen einbauen. Dann könntest du zwischendurch in einem weiteren Terminal schauen, ob die Datei auch tatsächlich da ist

Code: Alles auswählen

read "Taste drücken"

Du solltest in der zweitgenannten Zeile (Übertragung) die Parameter so setzen, dass nur die erzeugte Datei auch übertragen wird. Wahrscheinlich würde ich eher "rsync über ssh" bemühen. Den Namen der Datei würde ich in einer Variable speichern.

[MSfree]

Achso, nochwas:

Code: Alles auswählen

tar cfvz /bUP/serverbackup_`date +"%F"`.tar.gz / 

Das willst du nicht wirklich. Du generierst dann auch ein Backup von einigen virtuellen Dateisystemen wie /proc, /sys und /run, die nicht nur teilweise extrem große Dateien beinhalten, wie z.B. /proc/kcore, die werden sowieso nach jedem Boot frisch erzeugt.

Du möchtest also lieber

Code: Alles auswählen

tar cfvz /bUP/serverbackup_`date +"%F"`.tar.gz --exclude /proc --exclude /sys --exclude /run /

verwenden.

[uname]

Die Frage ist auch ob man mit dem Backup beim Restore überhaupt was anfangen kann. So backupst du zwar alle Programme wie z. B. /bin/false, jedoch weißt gar nicht welche Pakete wie z. B. im Fall von /bin/false das Paket coreutils installiert waren.

Bist du in der Lage aufgrund deines Backups ein Restore durchzuführen? Hast du das mal probiert? Wenn du sowieso neu installierst brauchst du z. B. /usr oder /bin gar nicht sichern, da du bei Neuinstallation alles automatisch wieder auf die Platte müllst. Wichtig wäre dann vor allen /etc, /home und /root und eine Liste der installierten Pakete.

[pferdefreund]

Also ich sichere immer alles ausser /proc und /sys und hatte beim Restore - selbst auf eine andere Partition noch nie Probleme.
Bootloader anpassen - und gut ist. Da ja /var mitgesichert wird, weiß das restorete system selbstverständlich, was installiert ist.
Von meinen Monatsbackups (je nachdem, was ich ausser Musik-hören an der Kiste mache), mache ich normalerweise immer einen Restore auf eine 2. Partition, mache nen neuen Lilo und habe immer ein Notfallsystem parat. Auf die Art mache ich auch immer eine Systemkopie vom Produktiv-System und übe in der Kopie erst mal den dist-upgrade. Wenn OK, einfach im Bootloader die Kopie zum Produktivsystem machen und das Spiel beginnt von neuem.
Was ein Backupscript angeht - richtig einfach jeden Befehl in eine extra Zeile und gut ist.
Eventuell im Scriptcopf #!/bin/bash -e - und das Ding stoppt sofort, wenn was dumm gelaufen ist, mit einer Fehlermeldung.
Cron sollte dich dann per interner Mail darüber informieren.
Am Ende eventuell noch ein
echo "Backup gelaufen" | mail -s "Backup OK" deinuser@localhost und du bekommst sogar ne Mail, wenn das Backup durch ist.

[heisenberg]

Code: Alles auswählen

tar cfvz /bUP/serverbackup_`date +"%F"`.tar.gz --exclude /proc --exclude /sys --exclude /run /

Noch eine kleine Änderung:

tar cfvz /bUP/serverbackup_`date +"%F"`.tar.gz --exclude /proc/"*" --exclude /sys/"*" --exclude /run/"*" --exclude=/dev/"*"

Die abschließenden Slashes mit den Sternen, damit die Verzeichnisse selbst gesichert werden, jedoch keine Inhalte davon, damit Sie bei der Wiederherstellung leer erzeugt werden. Und /dev würde ich auch nicht mitsichern. Wird ja afaik automatisch erzeugt. Die Sterne sind in Anführungszeichen, damit sie nicht durch die Shell interpretiert werden.

Ansonsten wäre ein --preserve-permissions (Erhalte die Rechte) und --numeric-owner (Sonst wird der Eigentümername verwendet. Das kann zu Problemen im Zusammenhang mit einer Wiederherstellung über ein Rettungssystem führen) noch zu empfehlen.

Reihenfolge der Optionen

Code: Alles auswählen

tar cfvz /bUP/serverbackup_`date +"%F"`.tar.gz /

Das bedeutet, dass Du das Verzeichnis / und /bUP/serverbackup_`date +"%F"`.tar.gz in die Datei vz sichern möchtest. Hinter der Option f muss unmittelbar der Dateiname stehen. Das, was Du willst, ist wohl eher:

Code: Alles auswählen

tar cvzf /bUP/serverbackup_`date +"%F"`.tar.gz /

Ich verwende sonst lieber die Standardschreibweise für Optionen, auch wenn tar es hier in der traditionellen Schreibweise anders unterstützt:

Code: Alles auswählen

tar -cvzf /bUP/serverbackup_`date +"%F"`.tar.gz /

[tobo]

Reihenfolge der Optionen

Code: Alles auswählen

tar cfvz /bUP/serverbackup_`date +"%F"`.tar.gz /

Das bedeutet, dass Du das Verzeichnis / und /bUP/serverbackup_`date +"%F"`.tar.gz in die Datei vz sichern möchtest. Hinter der Option f muss unmittelbar der Dateiname stehen. Das, was Du willst, ist wohl eher:

Code: Alles auswählen

tar cvzf /bUP/serverbackup_`date +"%F"`.tar.gz /

Werden die Optionen in der traditionellen BSD-Variante ohne Bindestrich übergeben, dann gibt die Reihenfolge der Optionen im Optionsblock, welche ein Argument benötigen, gleichzeitig auch die Reihenfolge der darauf folgenden Argumente vor. Ist - wie im Beispiel - nur eine Option vorhanden, die ein Argument benötigt, dann ist es egal, an welcher Stelle diese Option im Optionsblock steht.

Code: Alles auswählen

tar cfvI a.tar gzip /etc  ##richtig
tar cvIf a.tar gzip /etc  ##falsch

[Meillo]

Tolle Beitraege in diesem Thread! Danke! Es macht richtig Spass hier mitzulesen.

[Rosendoktor]

Statt der ganzen --exclude Parameter nimmt man meist besser die --one-file-system Option. Das beschränkt tar in diesem Fall auf das / Dateisystem, alle anderen eingehängten Dateisysteme bleiben außen vor, wie virtuelle (/dev, /sys, /proc,), temporäre (/tmp, /var/tmp, /run) sowie alles was ggf. unter /mnt oder/media gemountet ist.