Bacula mit MySQL extrem langsam

[aPollO2k11]

Mal eine Frage zum Verständnis: Nach meinen Informationen wird 'Spooling' ausschließlich dazu verwendet, den Datenfluss zu einem Bandlaufwerk möglichst konstant zu halten, um langwierige Stop-Start-Prozesse auf diesem Laufwerk zu vermeiden.

Demnach dürfte dieses Feature für Scenarien mit einem festplatten-basierten Storage bedeutungslos bzw. sogar schädlich sein, oder?
TNX

Ich hatte es auch ohne spooling versucht, da war das Backup aber ziemlich langsam, was warscheinlich an dem lahmen MySQL lag. Ich hab es mit SQLite und PostgreSQL nicht noch einmal ohne Spooling versucht. Wieso sollte es "schädlich" sein? Die Datei-Attribute werden halt erst einmal "gesammelt" und dann mit einem rutsch in den Katalog gespeichert statt ständig zwischen Sicherung der Datei und schreiben der Attribute hin und her zu springen.

[gehrke]

Mal eine Frage zum Verständnis: Nach meinen Informationen wird 'Spooling' ausschließlich dazu verwendet, den Datenfluss zu einem Bandlaufwerk möglichst konstant zu halten, um langwierige Stop-Start-Prozesse auf diesem Laufwerk zu vermeiden.

Die Frage war ernst gemeint - es ging mir nicht darum, jemanden zu kritisieren. Vielleicht gibt es ja Seiteneffekte, die ich nicht kenne...

Bin noch nicht so sattelfest mit bacula und habe das Thema nachgelesen (weil ich ebenfalls Performance-Probleme habe). Im gleichnamigen Buch von Philipp Storz taucht das Thema Data Spooling tatsächlich nur im Kontext von 'Tapelibrary' auf und wird nur mit den Eigenheiten von Bandlaufwerken begründet.

Demnach dürfte dieses Feature für Scenarien mit einem festplatten-basierten Storage bedeutungslos bzw. sogar schädlich sein, oder?

Wieso sollte es "schädlich" sein?

Wenn es im Falle von Disk-Storage nutzlos ist, dann erhöht es sinnlos die Komplexität. Der Autor weißt auch explizit darauf hin, dass das Spool-Verzeichnis selbst aus dem Backup excluded werden muss, andernfalls drohen Endlosschleifen.

[heisenberg]

Das hat mich auch neugierig gemacht, warum das bacula mit MySQL so langsam ist. Ich würde mich wundern wenn's an mysql liegt. Ich habe eher den Verdacht, dass bacula das Laden der Daten in mysql so erledigt, dass dies nicht auf schnellstmögliche Weise passiert. Auch Wenn das ein paar Millionen Records sind, darf das nicht so lange dauern.

Bzgl. der Vorschläge hier statt MySQL lieber Postgres zu verwenden, habe ich von den Schreibern hier keinerlei Gründe dafür gelesen.

Allerdings sind auf der Seite von Bacula Benchmarkergebnisse zu sehen, die Postgres und MySQL einander gegenüberstellen. Postfix wird dort als ca. 6 Mal schneller dargestellt. Könnte sich also durchaus lohnen.

[hec_tech]

Eventuell ist die Datenbankanbindung schlecht umgesetzt für MySQL müsste man sich mal anschaun wäre hier interessant bareos mit bacula zu vergleichen.

Wobei ich gelesen habe dass im bareos da irgend ein Patch drinnen ist der die Geschwindigkeit massiv erhöht eventuell hat der auch damit zu tun.

[gehrke]

Wobei doch in der Datenbank (welche auch immer) eigentlich nur die Meta-Daten (AKA Catalog) geschrieben werden. In meinem konkreten Fall bin ich mir ziemlich sicher, dass die Performance der Datenbank im Vergleich zum Lesen, Entschlüsseln, Transport, Verschlüsseln und Speichern der Daten im TB-Bereich überhaupt nicht ins Gewicht fällt. Aber ich kann mich ja irren, deshalb frage ich...

[hec_tech]

Da habe ich ganz andere Erfahrungen zwar nicht mit Bacula/Bareos aber mit BackupExec und NetApp.
Da geht es um ein paar hundert TB und wir sehen extreme Unterschiede zwischen den Jobs je nach Anzahl der Files von denen die Metadaten geholt werden müssen.
Die Jobs haben hier bei der Geschwindkeit Unterschiede vom Faktor 10 also hängt es definitiv mit den Metadaten und der Geschwindigkeit zusammen.

Für ein Backup von ein paar großen Files macht es nicht viel Unterschied aber bei vielen kleinen Dateien wird es leider extrem. Oft braucht man auch mehrere Tape Drives um langsame und schnelle Jobs zu trennen.
Wird aber alles erst ab einer gewissen Größe und Laufzeit der Jobs notwendig.