Hello, I observed the very same phenomenon but I run a PostgreSql instead of a MySql database.
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. 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. Jürgen -----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_id=7477&alloc_id=16492&op=click _______________________________________________ Bacula-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/bacula-users ------------------------------------------------------- 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
