Backup von Ordnern in TAR-Archiv durchführen

CPU

Lieutenant
Registriert
Jan. 2006
Beiträge
704
Hallo,

ich habe eine Freigabe, auf der ca. 150.000 Dateien (insg. rund 28 GB) lagern. Wenn ich die jetzt mit meinem "Linux-Backup-Server" gemountet habe in ein Verzeichnis kann ich mit rsync -a die Dateien in einen Ordner auf der Backup-HDD "kopieren" (mache ich bisher).
Dadurch ergibt sich jedoch das Problem, dass man diese Objekte nicht so einfach mal kopieren kann. Denn es müssen ja 150.000 Dateien angefasst werden.

Daher habe ich mir gedacht, dass man diesen Ordner einfach in den tar packen könnte um dann einen Backup-Archiv zu bekommen. Eine Datei lässt sich - auch bei 28 GB - besser handhaben.

So stelle ich mir das etwa vor:
Code:
#!/bin/bash
BACKUP_FILE_NAME="backup-$(date +%F).tar"

# Die Windowsfreigabe einhängen
mount -t smbfs -o username=<usr>,password=<pwd> //<Rechner>/<Freigabe> /mount/windows

# Backuparchiv erstellen
tar -cf $BACKUP_FILE_NAME /mount/windows/

# Windowsfreigabe aushängen
umount /mount/windows

Funktioniert das so wie im Code dargestellt??
Wie ist das mit der Geschwindigkeit/CPU-Last? Kann ich noch irgendwo etwas optimieren, dass es schneller geht? Was bewirkt es, wenn ich noch die Option -j anhänge (bzip2)? Wird es große Geschwindigkeitseinbußen haben? Wo liegt dann der Vorteil?

Gruß und Bester Dank vorab,
CPU
 
Sollte vom Prinzip her so klappen. Du musst halt ein Dateisystem auf dem Server haben, das die Dateien in voller Größe speichern kann.

Komprimieren mit bzip2 dauert meist schon etwas länger, schneller geht es mit gzip (Parameter -z). Damit ist es fast so schnell wie nur Tar.
 
Du speicherst das Archiv lokal auf deinem Linux-Client, nicht auf dem Server (= der Rechner mit der Freigabe). Die Daten müssen natürlich auch erstmal durchs Netzwerk geschaufelt werden, und das passiert unkomprimiert. Effektiver wäre eine Kompression auf dem Server mit einem schnellen Algorithmus und geringer Kompression und dann die Übertragung. Oder benutzt rsync mit -z Option.

Oder geht es dir nur darum, dass du auf dem Client eine einzige Datei hast und nicht soviele?
Wenn du irgendwann mal eine einzige Datei aus einem tar.bz2 oder .tar.gz Archiv entpacken willst, ist das ziemlich ineffizient, weil erstmal der komplette Tarball dekomprimiert werden muss. Da würde ich lieber zu .7z oder so greifen.
 
Zuletzt bearbeitet:
Du musst halt ein Dateisystem auf dem Server haben, das die Dateien in voller Größe speichern kann.
Was bedeutet das? Heißt das, dass ich z.B. kein FAT32 haben kann auf dem "Komprimierlaufwerk" (wegen 1 Datei < 4 GB)? Ich wollte ext3 nehmen.

Du speicherst das Archiv lokal auf deinem Linux-Client, nicht auf dem Server (= der Rechner mit der Freigabe).
Server ist der Rechner mit der Freigabe. Und die Daten werden auf meinem Linux-Client gesichert bzw. abgespeichert.

Effektiver wäre eine Kompression auf dem Server mit einem schnellen Algorithmus und geringer Kompression und dann die Übertragung. Oder benutzt rsync mit -z Option.
Mit einem NovellNetware 5 Server schwer zu realisieren. Daher kommt das Backup auf einen "Linux-Client".

Also klappt das so, wie ich es mir gedacht/zusammengeschrieben habe?

Gruß,
CPU
 
du solltest die exit codes von den befehlen checken. sonst läuft der script bei nem fehler einfach weiter.
 
du solltest die exit codes von den befehlen checken. sonst läuft der script bei nem fehler einfach weiter.
Wie und wo mache ich das? Könntest Du mir da ein kleines Beispiel geben?? Bitte!

Gruß,
CPU
 
Gibt verschiedene Möglichkeiten. z.B.

mount ...
if [ $? -ne 0 ]; then
echo "mount failed" >&2
exit 1
fi

oder

mount ... || ( echo "error" >&2 ; exit 1 )

speziell wenn du sowas als cronjob ausführst ist es wichtig, dass ein fehler "sichtbar" wird. cron sendet dann nämlich eine email :)
 

Ähnliche Themen

Zurück
Oben