Hi Mark: Thanks for the response. :-)
At 18:17 25.2.2008, [EMAIL PROTECTED] wrote: >=> The problem: >=> >=> When the first incremental backup is run, Bacula promotes it to a >=> full as expected since there is no prior full. However, this backup > >Right, that's normal. Correct. No surprise there. >=> is roughly 1TB being compressed and written to an NFS share at >=> approx. 1.5MB/s. Thus, the full backup takes over 48 hours to >=> complete. While that is running, the Bacula scheduler kicks-in on > >Ick. Yes. Unfortunately, that was the only storage available. The 1TB RAID is full :-( Still, the throughput is not bad given that jumbo frames are not enabled and gzip compression is running at level 9. >=> the next day and the day after, queueing-up those day's >=> backups. However, because the full that those backups depend on is >=> still running and has not been committed to the catalog, those jobs >=> are likewise promoted to fulls. When the initial backup completes, > >Double ick. What version of Bacula are you running? I'm far from >certain about >this, and I'm not running a current version myself, but I believe that Kern >talked about fixing this in a future version, and that fix may be in the >current release. 2.2.8. It sounds very much like the "Redundant Run in Schedule" thread will resolve this. Kern has clearly put some thought into this problem. > => it is immediately followed by 2 more full backups which exceeds the >=> space available. Although this can be worked around by temporarily >=> disabling the incremental schedules, it is not ideal since the >=> problem will only occur again when the 50-day retention period is exceeded. > >Huh? > >If you've got a 50 day retention period for full backups, then after >the first >one, there should be a "full" in existence, meaning that subsequent >incrementals will not get promoted to fulls. Of course, this doesn't >alleviate >the problem with the monthly full taking more than 24hrs to run, and having >simultaneous full and incremental backups running (which is the issue that I >think has been fixed). Correct. I made an error there since I was also considering a case where there would only be one full in existence. Thus, when the previous full expired and the the next one ran, the same problem would occur. You are right that in my example above, there would always be 2 fulls in the system. >=> Is it possible for Bacula to determine whether or not an incremental >=> job should be promoted to a full at the time the job starts running >=> rather than at the time the job gets queued by the scheduler? That > >It sounds like the problem may be with your retention period...are you sure >that it's not less than 30 days? It eventually will be for this NAS volume once we configure an LTO2 autoloader for offsite backups. Right now, the NAS has the only backup storage but once tapes are deployed, it will only be needed for short-term recoveries. >=> would solve my problem since any incremental jobs that were queued >=> while their dependent full was still running would not get promoted >=> to fulls themselves. > >I sympathize...really! Thanks! I'm confident things are under control though. :-) It is impressive watching the network throughput when Bacula is running.... >=> I suspect this is a corner-case since backups, even fulls, that take >=> longer than 24 hours (let alone 48 hours) are rare. > >Unfortunately, not as much of a corner case as you think. I've got 4 >jobs that >take over 24hrs for full backups, and a 5th that's so close that any >additional >load on that disk system or the network during backups pushes the job over >24hrs. That's good to know. I know some other folks (not Bacula users) who regularly back-up 1 PetaByte. It doesn't sound like Bacula needs many changes to deal with this issue effectively though. Best regards, Peter Buschman >=> >=> --PLB >=> > > > >---- >Mark Bergman [EMAIL PROTECTED] 215-662-7310 >System Administrator Section of Biomedical Image Analysis >Department of Radiology University of Pennsylvania > PGP Key at: https://www.rad.upenn.edu/sbia/bergman > > > >The information contained in this e-mail message is intended only >for the personal and confidential use of the recipient(s) named >above. If the reader of this message is not the intended recipient >or an agent responsible for delivering it to the intended recipient, >you are hereby notified that you have received this document in >error and that any review, dissemination, distribution, or copying >of this message is strictly prohibited. If you have received this >communication in error, please notify us immediately by e-mail, and >delete the original message. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
