OK, at our next restore, I will send an outpu. We have a 300 meg bandwidth down and up, so that isn't the problem. Possibly the amount of files is the problem. Dan Langille wrote: > On Oct 8, 2008, at 4:15 PM, Joe Mannuzza wrote: > >> >> Dan Langille wrote: >>> >>> On Oct 8, 2008, at 3:57 PM, Joe Mannuzza wrote: >>> >>>> Dan Langille wrote: >>>>> >>>>> On Oct 8, 2008, at 1:11 PM, Joe Mannuzza wrote: >>>>> >>>>>> Dan Langille wrote: >>>>>>> >>>>>>> On Oct 2, 2008, at 1:54 PM, Joe Mannuzza wrote: >>>>>>>> >>>>>>>> Has anyone had issues doing a restore of large sets of data via >>>>>>>> bacula? >>>>>>>> Specifically, has anyone also noticed the process taxing the CPU? >>>>>>> >>>>>>> >>>>>>> Can you be more specific regarding these processes? >>>>>>> >>>>>>> At what stage of the backup does the CPU get taxed? >>>>>>> >>>>>>> It is normal for the tree building phase to require lots of CPU >>>>>>> >>>>> >>>>>> Dan, >>>>>> >>>>>> Thanks for the response. I am unsure at what stage it gets >>>>>> bogged down. Is there a way to check after the fact? >>>>> >>>>> Not that I can think of. >>>>> >>>>>> Also, there were many backups going on at the same time of the >>>>>> failure- around 40. Server info: 2 Xeon 5150 @2.66 gigs, 3 gigs >>>>>> of RAM. >>>>> >>>>> Is that normal? Do you usually run 40 concurrent backups? >>> >>> >>> >>>> We don't always have that many going, but from 5:00 Pm to 8:00 or >>>> 9:00 ish we can have up to 45. We don't have any problems with our >>>> backups unless a restore is running at the same time. >>> >>> So you're asking if doing a restore while there are 45 backup jobs >>> are running might tax the CPU. The answer is yes. >>> >>> How much this will tax the CPU depends upon too many factors to >>> discuss in this scope. >>> >>>> Is it possible that the de-compression that the Bacula server is >>>> performing is putting too much load on the CPU (combined with the >>>> backups)? >>> >>> Decompression? By bacula-dir? There is no decompression done there >>> AFAIK. Sometimes bacula-fd can do decompression if you are using >>> software decompression. > > >> One of the problems we run into is when we try to restore a server >> with a large amount of HDD space used (well, just around 40 gigs >> total for 2 disks), it takes all day to complete and goes into the >> night when the backups are being completed. By all day I mean from >> 9:00 am until 8:00 PM. Should a restore of that size take so long? >> Is there a way to speed up restores so that they don't take all day? >> If we wanted to restore a system with 100 gig used HDD space, what >> could we do to speed up the process, if anything? We don't have >> backups running from 8 AM to 5 PM except for a few stragglers from >> the night before (4 at the most, not an issue for us). > > Please remember to cc the mailing list. > > I am not following the above. Let's keep it simple. > > The length of time it takes to restore data depends on many things: > > - how fast your hard drives are > - how much the system is being used at the time > - how fast your network is (for sending data from bacula-sd to > bacual-fd where it is restored) > - are these many small files or many large files? Writing 10GB of > data in 10 files takes far less time than writing the same amount of > data in 100,000 files. > > Those are the just the things I can think of now. > > If you can paste us the output of one of these jobs, that will give us > some context. > > --Dan Langille > http://langille.org/ > > > > >
------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
