On Tuesday 21 June 2005 13:23, Jürgen Kuri wrote: > Is c't planning an article about bacula? In fact I was thinking about > such a project... > > This is a misunderstanding I am in fact not the author of the mentioned > computer magazine. > > -----Ursprüngliche Nachricht----- > Von: Arno Lehmann [mailto:[EMAIL PROTECTED] > Gesendet: Dienstag, 21. Juni 2005 13:07 > An: Jürgen Kuri > Cc: Sebastian Stark; [email protected] > Betreff: Re: AW: [Bacula-users] how to speed up directory tree building? > > > 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. restore all avoids the "mark *" delay, which is due to reading the Catalog for each hard linked file. By the way, I would prefer that the default be that all files are marked at the beginning. This avoids the above problem (no extra time at all). However, the users rather strongly regected this and prefer the default to be that no files are marked. "unmark *" is very fast in all cases; as pointed out above, the convers is not at all true. > > 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. If you consider how a full restore is done, you will understand that a "virtual filesystem" image is necessary if you want to optimize the resore to restore only the last incremental or differential copy of a particular file. If you don't mind overwriting the same file with the Full backup image, then every Incremenatal and Differential image that was saved, then yes, a restore can be done without the in memory image. For version 1.37, this is actually proposed to the user if *all* the File entries in the catalog have been pruned -- obviously, the Job entries in the catalog must still be there. I probably should consider making the above an option in itself. > > > 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 -- Best regards, Kern ("> /\ V_V ------------------------------------------------------- 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
