Hello,
Jürgen Kuri wrote:
Hello,
I observed the very same phenomenon but I run a PostgreSql instead of a MySql
database.
To my knowledge - without ever having used PostgreSQL - with this
database there seems to be some sort of problems with the indexes. This
was probably discussed with Dan Langille, either on this list or on
bacula-devel.
I would restore a number of ~740.000 files backed up of one host
via a full backup and several incrementals. But the database, to
me, seems not to be the problem. The file entries from the
database were collected fast but the 'backup-dir' daemon consumed
the bigger part of time to build the virtual filesystem in the
backup server's memory. Even worse if you then - after the built
- type 'mark all' for a full restore, it takes again a lot of
time to mark all the files in the virtal file system. The result
of this action then is - this is what I observed - a very small
ASCII bootstrap file for restore purposes with the names of the
involved backup volumes the corresponding tapefiles numbers into
the backups were written.
This sounds like a design limitation. Or, in other words, might be
better to discuss on the developer list.
To me in a case of full restore it is not necessary to build a
virtal filesystem in the backup server's memory. What you need
is the information of all the involved backup volumes and the
position of the corresponding tape files. For cases like this
the pieces of information should be in the datebase (saveset
'something' -> volume name, tapefile number). This makes
especially full restores with a huge number of files
considerably faster.
this sounds quite reasonable. Time to try a full restore again, I guess,
because I *think* that a full restore didn't take very long to prepare
here. Of course, with my backup server, *everything* is slow, so I
probably didn't notice the difference.
Anyway, considering that the suggested changes might take a while to
implement there could be a workaround in case of a full restore you need
quickly: Use bextract if you've got the bootstrap file and or know which
volmes you need.
Jürgen
Is c't planning an article about bacula? In fact I was thinking about
such a project...
Arno
-----Ursprüngliche Nachricht-----
Von: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Auftrag von Arno
Lehmann
Gesendet: Dienstag, 21. Juni 2005 10:43
An: Sebastian Stark
Cc: [email protected]
Betreff: Re: [Bacula-users] how to speed up directory tree building?
Hello,
Sebastian Stark wrote:
Is there a way to speed up the creation of the directory tree when restoring
files? For some clients this takes more than an hour for us.
Our MySQL catalog has grown quite large (~5G) and I think this is the reason.
But maybe there's another way to speed this up other than splitting up the
catalog? Maybe play around with indexes?
That would seem the first step.
There are quite some messages concerning this, you could use the list
archive. If you have a good understanding of SQL and MySQL, observing
the queries and analyzing them might give some hints, too.
Arno
Thanks,
Sebastian
--
IT-Service Lehmann [EMAIL PROTECTED]
Arno Lehmann http://www.its-lehmann.de
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click
_______________________________________________
Bacula-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bacula-users
