tar beschleunigen?

[mschira]

Hi ich habe einen Server mit einem recht grossen Raid array (3Tb).

Ich habe cron jobs die regelmaessig backup machen sollen.

Die jobs sind recht simpel, sie bestehen aus einem tar und splitt comando:

tar -czf /dev/stdout /raid/DieDaten | split -d -b 1999m -a 3 /oldraid/dasBackup.tar.gz


Dieses commando erzeugt ein gesplittetes tar archiev mit den namen

/oldraid/dasBackup.tar.gz000
/oldraid/dasBackup.tar.gz001
/oldraid/dasBackup.tar.gz002
....
/oldraid/dasBackup.tar.gz104

und jede der dateien ist knapp kleiner als 2Gb. (bringt auch FAT32 nicht zur Verzweiflung).

Die daten werden von einem RAID array zu einer einzelnen Festplatte (/oldraid/ welches trotz des namens keines ist...) transportiert.
Das problem: das ganze ist nicht besonders schnell, 400Gb daten werden zu ca. 200 Gb Komprimiert und das ganze dauert ca. 12 h.

Hat jemand eine Idee wie das schneller geht?

Gruesse
M.

 

[mschira]

Oh ja vielleicht sollte ich anmerken so wie es jetzt ist startet das kommando einen einzelnen gzip prozess, der einen CPU core +- auslastet. kann ich tar dazu bringen alle vier cores zu nutzen?
M.

 

[Anonymous]

Das problem: das ganze ist nicht besonders schnell, 400Gb daten werden zu ca. 200 Gb Komprimiert und das ganze dauert ca. 12 h.

Hat jemand eine Idee wie das schneller geht?

Du hast so wie du das derzeit betreibst 4 Engstellen

1. Engstelle der Zugriff auf die Datein im Raid.
Wenn das Raid vernünftig angeschlossen ist, ist zumindests schon mal die Datenübertragung an sich ok. Jetzt kommt es noch auf die Dateinen auf deinem Raid an. Große Dateien überhaupt kein Problem. Aber kleine und kleinste Dateien in bremsen enorm.
Na gut, da kann man meist eh nichts machen. Ein bisschen finetuning würde noch gehen, wenn zB in dieser Zeit nicht normal mit diesem Raid weitergearbeitet wird, indem man das Filesystem kurz vor der Sicherung remountet und ihm einige Optionen mitgibt die beim auslesen der Daten nicht noch zusätzlich bremsen.

2. Engstelle die Kompression
Am besten weglassen, aus verschiedenen Gründen. Will hier nur einen einzigen nennen, kippt nur ein einziges Bit in einem deiner gesplitteten Dateien, wirst du alles was dahinter in der Sicherung kommt nie wieder herstellen können. Für alles andere gibt es Tools Howtos und Lösungen, aber in einer gezipten Sicherung ist auch nur ein einziges gekipptes Bit der Tot.
Ein weiterer Grund vielleicht noch: Angenommen du brauchst aus deinem Backup nur eine einzige Datei, wie lange brauchst du nach deinem Konzept bis du sie gefunden und wiederhergestellt hast?

3. Engstelle die CPU-Leistung und die Verteilung auf mehrere CPUs soweit vorhanden.
Wenn du die Kompression wegläßt ist das Problem schon sogut wie behoben, da die anderen Befehle keine übermäßige Rechenleistung erfordern. Die Hauptlast tritt ohne Kompression im IO auf, und hier können verschiedene Faktoren unnötig bremsen.

4. Engstelle der Zugriff auf die Sicherungsplatte. Hier gillt prinzipiell wichtig, das die Transfer- und Schreibleistung der Platte passt. Die Filegröße hier ist in diesem Fall optimal. Mit einigen Filesystemeigenschaften lässt sich noch etwas herausholen. zB kein Journal-FS, (brauchst du hier nicht), ob hier FAT32 das richtige ist ? Es findet sich bestimmt auf Dauer gesehen was schnelleres insbesondere wenn man genau weiß wieviele Dateien maximal und mit welcher festen Größe kommen, können sicherlich andere Filesysteme hier optimal an sowas angepasst werden.


Optimierungen hängt immer von verschiedenen Faktoren ab. Das ist einmal Rechnerausbau selbst, das ist aber auch die Art der Daten und der Rechnernutzung. Dazu kommen noch deine Ansprüche an das Backup und somit das ganze Konzept deines Backups.
Prinzipiell muss man sagen, solche Sicherungszeiten sind aus verschiedenen Gründen wenn sie regelmäßig auftreten schon mal ein Zeichen das da im Konzept was überhaupt nicht passt.

Ich befürchte fast aus deine Ausführungen, du hast nur immer eine einzige Sicherung, und die überschreibst du regelmäßig komplett durch eine neue. Hast du dir schon mal überlegt was passiert wenn kurz nach Beginn der Sicherung auf deinem Rechner was total unerwartetes passiert. Dann hättest du wahrscheinlich nicht mal was vernünftiges was du recovern kannst. Und 12 Stunden sind da eine lange Zeit, zumal das Backup selbst für deinen Rechner enormer Stress ist.

Also:
1. wie oft soll das Backup laufen. Bei regelmäßig, oft oder täglich ist das ganze Konzept, so wie du es beschreibst, absolut untauglich. Hier mal schauen was andere Tools können zB rsync , oder ob man wirklich jedes mal eine Vollsicherung benötigt. Wenn sich 95% der Daten nicht ändern, dann brauch ich nicht jedes mal alles komplett zu sichern. Dann reicht mit in größeren Abständen eine Komplettsicherung und regelmäßig nur eine kleine Differenzsicherung von dem was sich geändert hat.

2. Wird auf dem Rechner in der Zwischenzeit weitergearbeitet dann ändern sich in der Zwischenzeit (mehrere Stunden) eventuell nicht nur einige wenige Dateien. Zum Schluss hättest du eventuell sogar in deinem Backup Dateien die gar nicht mehr zusammengehören.

3. Wie viele Backupstände möchtest du immer vorrätig haben, (also mindestens 1 Backup, bedeutet) das von gestern wird erst morgen und nicht schon heute überschrieben.

4. Wie schnell müssen im Notfall der gesamte Rechner wieder aus dem Backup hergestellt worden sein, bzw wie lange darf es dauern bis eine x-beliebige Datei aus dem Backup wieder hergestellt werden kann.

5. Was sind das prinzipiell und hauptsächlich für Daten oder Dateien die gesichert werden müssen. ZB. Videos, Bilder, Musik kann ich ganz anders sichern als Texte, Notizzettel und Office-Dateien, und diese wiederum ganz anders als Webseiten, Datenbanken oder das Betriebssystem.

Hast du dann ein Konzept gefunden, eventuell mit anderen Backuptools oder andern Programmen und es sind dann am Rechner irgendwelche Enpässe auffällig, die ein Backup unverhältnismäßig verzögern, dann kann man diese gezielt ansehen und eventuell optimieren. Das was du beschrieben hast kann man nicht optimieren, das muss man erst einmal komplett neu überdenken und auf den Prüfstand stellen.

robi

 

[mschira]

1. Engstelle der Zugriff auf die Datein im Raid.
Wenn das Raid vernünftig angeschlossen ist, ist zumindests schon mal die Datenübertragung an sich ok. Jetzt kommt es noch auf die Dateinen auf deinem Raid an. Große Dateien überhaupt kein Problem. Aber kleine und kleinste Dateien in bremsen enorm.
Na gut, da kann man meist eh nichts machen. Ein bisschen finetuning würde noch gehen, wenn zB in dieser Zeit nicht normal mit diesem Raid weitergearbeitet wird, indem man das Filesystem kurz vor der Sicherung remountet und ihm einige Optionen mitgibt die beim auslesen der Daten nicht noch zusätzlich bremsen.
robi

Das RAID ist ein RAID 5 und per adaptec aktiver raid karte (model habich vergessen) mit PCI-X 64 angeschlossen. Sollte also reichen. Die backup festplatte ist direct and das Motherboard angeschlossen.

2. Engstelle die Kompression
Am besten weglassen, aus verschiedenen Gründen. Will hier nur einen einzigen nennen, kippt nur ein einziges Bit in einem deiner gesplitteten Dateien, wirst du alles was dahinter in der Sicherung kommt nie wieder herstellen können. Für alles andere gibt es Tools Howtos und Lösungen, aber in einer gezipten Sicherung ist auch nur ein einziges gekipptes Bit der Tot.
Ein weiterer Grund vielleicht noch: Angenommen du brauchst aus deinem Backup nur eine einzige Datei, wie lange brauchst du nach deinem Konzept bis du sie gefunden und wiederhergestellt hast?
robi

Ja compression ist ein problem. Leider habe ich nicht genug platz auf der zweiten platte (ist eine 740Gb platte) und (auch auf den Tapes ) um das zu vermeiden.
Einmal in Monat wird das verzeichnis mit den Backups auf Band gezogen, daher brauch ich unter 2Gb dateien (da das auf Windows basierende andere System sonst hustet...).
Insofern ist also schon noch mal eine weitere - mehrfache - Sicherung da.

Eine einzelne Datei herauszubekommen geht. Habe ich schon mal gemacht. Dauert lange (ca. 12 h) aber am ende....

Ich habe am anfang mal SimpleBackup ( http://sourceforge.net/projects/sbackup/ ) fuer incrementelle sicherung ausprobiert, aber das hat nicht funktioniert.
Warum auch immer aber es hat irgendwelche dateien incrementell gesichert, dateien die seit Jahren unangetastet sind, dafuer ewig gebraucht (16h) und ueberhaupt.
Ganz komisch.

Ich habe auch versuch kDar auf meinem System zu benutzen aber das hat nicht geklappt da kDar sich nicht mit SuSE 10.3 vertraegt.

Vielleicht ein anderes kompressionsverfahren?

3. Engstelle die CPU-Leistung und die Verteilung auf mehrere CPUs soweit vorhanden.
Wenn du die Kompression wegläßt ist das Problem schon sogut wie behoben, da die anderen Befehle keine übermäßige Rechenleistung erfordern. Die Hauptlast tritt ohne Kompression im IO auf, und hier können verschiedene Faktoren unnötig bremsen.
robi

siehe oben ich muss komprimieren, nur wie verteile ich das auf mehrere CPUs. tar -z gzip ist leider nicht multithread. (was eigentlich ein Hammer ist...)

ich kan naturlich nicht sagen wie fix es ohne kompression ginge. Vielleicht mal ausprobieren...

4. Engstelle der Zugriff auf die Sicherungsplatte. Hier gillt prinzipiell wichtig, das die Transfer- und Schreibleistung der Platte passt. Die Filegröße hier ist in diesem Fall optimal. Mit einigen Filesystemeigenschaften lässt sich noch etwas herausholen. zB kein Journal-FS, (brauchst du hier nicht), ob hier FAT32 das richtige ist ? Es findet sich bestimmt auf Dauer gesehen was schnelleres insbesondere wenn man genau weiß wieviele Dateien maximal und mit welcher festen Größe kommen, können sicherlich andere Filesysteme hier optimal an sowas angepasst werden.
robi

Die fur das RAID benutze ich XFS und fuer die Backupplatte ext3. Waere ext2 schneller?

Ich befürchte fast aus deine Ausführungen, du hast nur immer eine einzige Sicherung, und die überschreibst du regelmäßig komplett durch eine neue. Hast du dir schon mal überlegt was passiert wenn kurz nach Beginn der Sicherung auf deinem Rechner was total unerwartetes passiert. Dann hättest du wahrscheinlich nicht mal was vernünftiges was du recovern kannst. Und 12 Stunden sind da eine lange Zeit, zumal das Backup selbst für deinen Rechner enormer Stress ist.
robi

Wie gesagt zunaechst mal stimmt das, das lokale Backup auf dem Rechner wird immer wieder ueberschrieben, aber einmal im Monat wird das Backup auf Tape gezogen und in den Schrank gelegt. Ein recovery vom Band wuerde ca 2-3 tage dauern, aber es sollte eigentlich nie noetig werden...


Also:

1. wie oft soll das Backup laufen. Bei regelmäßig, oft oder täglich ist das ganze Konzept, so wie du es beschreibst, absolut untauglich. Hier mal schauen was andere Tools können zB rsync , oder ob man wirklich jedes mal eine Vollsicherung benötigt. Wenn sich 95% der Daten nicht ändern, dann brauch ich nicht jedes mal alles komplett zu sichern. Dann reicht mit in größeren Abständen eine Komplettsicherung und regelmäßig nur eine kleine Differenzsicherung von dem was sich geändert hat.
robi

naja schon so ein zweimal die Woche. Und ja ca. 99% der daten aendern sich nicht. incrementell waere da schon gut. Auf der anderen Seite ist der Stress fuer den Computer hoch aber wenn er ueber Nacht lauft nicht so schlimm. Und dann auch wieder nicht SOOOOO hoch. Wenn nachts noch was anderes lauft dann sind das grosse rechenaufgaben, die relative wenig datenzugriff haben und eher CPU lastig sind.

2. Wird auf dem Rechner in der Zwischenzeit weitergearbeitet dann ändern sich in der Zwischenzeit (mehrere Stunden) eventuell nicht nur einige wenige Dateien. Zum Schluss hättest du eventuell sogar in deinem Backup Dateien die gar nicht mehr zusammengehören.
robi

kaum ein problem.

 

[ixo]

Löst das vielleicht Deine Probleme?

Gruß, ixo

 

[Anonymous]

Löst das vielleicht Deine Probleme?

Ich denke mal im Moment nicht wirklich. Es sind eventuelle noch 10% Reservern mit allerlei Tricks in dem was er macht, aber solange er auf die Kompression angewiesen ist bleibt es extrem langsam.

Die Kompression muss am besten irgendwie weg, dafür einmal im Monat ein Komplettsicherung am besten gleich aufs Band, (wenn das aber so lange dauert wie er sagt, dann ist dort wohl auch noch der Wurm drin. Wiki mal lesen )
und täglich dann nur noch die Diffenzsicherung zur letzten Bandsicherung. auf die Platte. Mit welchem Programm oder Tool ist vom Prinzip fast egal, (abhängig auch von eventuellen zusätzlichen Filerechten die mitgesichert werden müssten, aber das würde ja tar jetzt auch noch nicht machen).
Ob nun fertige Backuptools, die nicht immer einfach zu konfigurieren sind, und von denen man im Zweifesfall nie weiß wie sie es wirklich genau machen, oder mit den Standard-Tools von Linux und ein bisschen Scripterei rundherum, ist wohl Geschmackssache oder Philosophie.

Dann reichen wahrscheinlich 2 Sätze Bänder (oder bei modernen Laufwerken auch nur 2 Bänder), und die Platte in der Kapazität von jetzt für ein Volumen um für bis zu 2 Monaten lückenlos jeden Tagesstand der Daten für diesen Server wiederherzustellen. Die Sicherungszeiten würden abgesehen von der monatlichen Vollsicherung wohl auf geschätzte maximal eine Stunde reduziert, Die Datenwiederherstellung etwas aufweniger, da erst vom Band eingelesen und dann noch von der Platte aktualisiert werden müsste. Kommt natürlich auch aufs Bandlaufwerk an, aber wenn man nicht mehr unbedingt auf zB. DLT oder DAT angewiesen ist sondern zB mit LTO arbeiten kann, hat man in 12 Stunden und nur einem Laufwerk aber minimum 3 Rechner mit dieser Datenmenge (zZ 400GB) wiederhergestellt.


robi

 

[ixo]

Es sind eventuelle noch 10% Reservern mit allerlei Tricks

Naja, alle Cores, die Deine Kiste hat, werden bei der ersten Sicherung parallel arbeiten, d.h.bei 2 doppelt so schnell, bei 4 vier Mal so schnell. Die folgenden Sicherungen sind dann locker 10x (bis 100x) so schnell (hängt von Deinen Daten ab). Es ist trotz Kompression schnell (die man übrigens abschalten kann). Ab der zweiten Sicherungen werden nur noch die neuen Daten (parallel zur sonstigen Sicherung nochmals parallel auf allen cores) komprimiert.
Übrigens kannst Du mit dem Tool auch große Image-Dateien (z.B. von VMware Xen o.ä.) schnell und platzsparend sichern, falls Du soetwas auch in Deinen Dateien hast.

Die Kompression muss am besten irgendwie weg, dafür einmal im Monat ein Komplettsicherung am besten gleich aufs Band

Die Kompression bremst mit dem Tool so gut wie gar nicht. Jede Sicherung ist über die Hardlinks als Resultat trotzdem eine Komplettsicherung. Das einmal mit Monat (was meiner Ansicht nach zu selten ist) zu machen ist dann natürlich nicht nötig. Ob Du ein Band benutzen willst, musst Du grundsätzlich entscheiden - schneller dürfte es damit i.A. nicht werden (außer Du schreibst parallel auf Bänder etc, dann wird es aber sehr teuer).

von denen man im Zweifesfall nie weiß wie sie es wirklich genau machen

Generell hast Du da Recht, wichtig ist m.E., dass man auch ohne Tool problemlos an seine Daten wieder herankommen kann. Das ist bei dem von mir verlinkten der Fall.

Mschira, Du muss es natürlich selbst wissen, ich kann Dir bei Deinem Problem nur empfehlen, es mit dem Tool 'mal (z.B. für einen kleineren Bereich) auszuprobieren.

Gruß, ixo

 

[mschira]

Hm ihr schlagt also storebackup vor? Das macht ein komplettes discimage wenn ich das richtig sehe?
Da muss ich erst mal ein bischen hineinlesen glaub ich. Ich brauche halt kein komplettes image von dem RAID. Einen grossen Teil der Daten will ich gar nicht sichern (sind nicht meine, sind immer nur kurz da und auch redundant, sozusagen im transit).
Die zu sichernde Datenmenge ist im augenblick ca. 1Tb.

Das andere was ich gefunden habe ist rsync kann man das mit tar kombinieren? Kann rsyc auch alte dateine speichern? i.e. wenn ich eine Datei im Orginal loesche was passiert mit der Kopie?

Ich koennte natuerlich auch einefach eine 1.5Tb Platte kaufen... Kostet nicht mehr die welt. Wuerde das problem mit dem platz erst mal loesen, i.e man braeuchte keine Kompression mehr.
M.

 

[jengelh]

tar --use=pbzip2 -cf blafasel.tar.bz2 ${deine_daten}

 

[ixo]

Hm ihr schlagt also storebackup vor? Das macht ein komplettes discimage wenn ich das richtig sehe?
Da muss ich erst mal ein bischen hineinlesen glaub ich. Ich brauche halt kein komplettes image von dem RAID. Einen grossen Teil der Daten will ich gar nicht sichern (sind nicht meine, sind immer nur kurz da und auch redundant, sozusagen im transit).
Die zu sichernde Datenmenge ist im augenblick ca. 1Tb.

storeBackup sichert einzelne Dateien (auf Wunsch komprimiert), und das sehr kompakt, da Doubletten, Namensänderungen etc. erkannt werden. Es ist (seit v3) außerdem auch in der Lage Image Dateien oder ganze Device-Images mittels Deduplikation effizient zu sichern (siehe auch hier).
Dateien ausschließen kannst Du auch sehr flexibel (ich kenne nichts, was an die Möglichkeiten heranreicht).

Das andere was ich gefunden habe ist rsync kann man das mit tar kombinieren? Kann rsyc auch alte dateine speichern? i.e. wenn ich eine Datei im Orginal loesche was passiert mit der Kopie?

Dann benötigst Du den Platz 3x. (Abzüglich Kompression von tar)
Rsync kann übrigens rudimentär ähnlich verwendet werden wie storeBackup. Die Stärke von rsync ist das Synchronisieren über eine (schlappe) Leitung.

Ich koennte natuerlich auch einefach eine 1.5Tb Platte kaufen... Kostet nicht mehr die welt. Wuerde das problem mit dem platz erst mal loesen, i.e man braeuchte keine Kompression mehr.

Sollte wahrscheinlich nicht nötig sein.

Gruß ixo.