On Wed, 8 Aug 2007, Arno Lehmann wrote: > Hi, > > 08.08.2007 05:22,, Robert LeBlanc wrote:: >> >> >> On 8/7/07 5:32 PM, "Charles Sprickman" <[EMAIL PROTECTED]> wrote: >> >>> Hi all, >>> >>> I'm having some trouble figuring out how to "catch up" when someone has >>> forgotten to put a tape in or if I manually schedule a job that requires a >>> different pool than what is in the tape. >>> >>> I think a real-world example is in order. My fulls are on the first >>> weekend of the month, diffs each subsequent weekend, then incrementals on >>> weekdays. No one is in the office sat/sun to change tapes. >>> >>> This past weekend I mistakenly asked for a tape from the weekly pool to be >>> inserted. Unfortunately, I had forgotten this was a new month. So on >>> Sunday afternoon when bacula was going to do a run, it wanted to do a Full >>> and it wanted a tape from the Monthly pool. No one was around, so the >>> jobs did not start. >>> >>> Monday I asked for someone to put in the next Monthly tape, but then that >>> night bacula wanted a Daily. >>> >>> This is where I get confused. If a job fails simply due to the wrong >>> tape, how do I make bacula re-run the job and run it to the appropriate >>> pool? If I let this slide, is bacula simply going to wait until the first >>> weekend in September to do a full run? I'd really like to get one in >>> ASAP. >> >> I've just run the jobs manually and modified the job to be the right level >> and the right pool. Kind of a pain sometimes when a lot of jobs fail (we >> have almost 30 clients). I would be interested in a batch restart too. > > Usually, Bacula simply waits until it can run the stalled jobs. There > is a hard-coded maximum wait time, though, and a high number of > failing mounts will also end the job with an error.
Thanks for the info... I was able to work my way around possible network problem (thanks to this list) by adjusting the retry interval and the number of retries. I am quite happy that the manual is very complete, but I still have trouble with digging up the the info I need. I'm also still thinking about stuff in terms of how Amanda did it, and that screws me up. Anyhow, it looks like increasing these parameters from the defaults would help: Max Start Delay = <time> The time specifies the maximum delay between the scheduled time and the actual start time for the Job. Max Wait Time = <time> The time specifies the maximum allowed time that a job may block waiting for a resource (such as waiting for a tape to be mounted) > What this means is that, unless you configured things like maximum > wait or run times or automatic polling / mounting, you can load the > right tape and Bacula will run the jobs that are held. I'm going to give that a try before I completely re-think a new schedule. > If you configured Bacula to fail stalled jobs after some time, the > automatic rescheduling and "Rerun Failed Levels" can help a lot in > your scenario. If you can't run full backups during the week, it's > better to simply skip missed jobs IMO. I may try that as well if the above gets too complicated. Although the "Rerun Failed Levels" looks like it can land me in more trouble with my current setup where each level has it's own pool - meaning the operator may think that a Daily tape is needed, when actually a Monthly tape is needed. >>> This sort of mishandling of tapes will likely not be a one-time occurence, >>> plus there's issues of people going on vacation and similar where there >>> will be no operator on site to swap tapes. How do other people deal with >>> this? What happens to these failed jobs in the catalog? Should they be >>> deleted? Is there a way to reschedule them all? > > There are no means to retry a bunch of failed jobs, but it would be > possible by scripting some console commands... like get a list of all > failed jobs, take the highest backup level for each job, and feed the > commands to run these jobs to bconsole. > > The better solution, IMO, is to define your backup procedure in a way > that prevents these scenarios. Necessary tape changes during the > weekend are a problem best solved by investing into an autochanger, > though. Even with amanda I was wanting an autochanger, but I don't see that on the horizon here. > If that's not an option, I prefer to have the days that require tape > changing to be Tuesdays and Wednesdays - experience tells me that > these are the days where it's least likely that no operator is present. This is an incredibly simple idea that made me slap my forehead. I was really set on doing Fulls on the weekend for no good reason. Simply moving those to mid-week could solve this whole mess. > Of course, having a single sheet of instructions for your operators is > helpful, so they can easily look up which tapes (from which pool) to > load on which day, and so on. Working on a wiki page for them... > I have a more or less sophisticated perl script that decides which > tapes need to be unloaded and inserted and which can be used to > produce clear instructions for the operators, but it's only really > usable for autochangers. And it's still missing some important features... How is your script polling for upcoming jobs? Just calling bconsole and doing a "dir status" and then parsing out the "Scheduled Jobs" list? > Anyway, my personal impression is that these problems are typically > ones that should be tackled by writing the necessary operations > manual. All attempts I know to solve these issues by complex > configurations tend to break in some cases, and require intervention > by an administrator anyway. > >>> Another thing that I have not figured out is how to see what bacula thinks >>> it's next run will be (what hosts, what level, what pool). I'd like to >>> know this for troubleshooting purposes as well as to try and script >>> something to give people an advance warning about what tape should be in >>> the drive each night. >> >> You can do a status on the director and it will tell you all that info in >> the top portion of the screen except the pool (it does tell you the tape it >> thinks it will use which can change if the tape fills up) >> >>> And lastly, any plans to have the spool act like it does in Amanda? >>> Meaning that if you have the space and you don't have the right tape in, >>> bacula will spool all the jobs until the right tape ends up in the drive. >>> Or perhaps it is possible in some way that I'm not seeing. >> >> That is a cool feature that would be pretty nifty. We have a changer so it's >> not as big a del, but it sounds like a great feature > > I would recommend to investigate if migration is the right approach > for you, then - set up a disk to disk to tape backup. I see another thread on that right after this one. I'll read up on it. Although I am very fond of an automatic feature where if a tape is not available and you've got a big drive all jobs just spool there and then get sucked off the drive once the correct Volume becomes available. That's another piece of "Amandathink" I've taken with me... > In the first pass, backup from your clients to the disk based volumes, > and then migrate these backups to tape later. The migration can be > done during the work hours, so that an operator can easily change > tapes or ask for help. > > In this case, you'd need the disk space to hold all or most of your > backups, though. Got it! >>> Any help is appreciated, we're very happy so far with bacula but for this >>> little issue of our sneakernet changer not being 100% reliable. :) > > Well, my usual advice is to get most of your backups run automatically > without intervention, and don't use too much time and effort to get > the remaining problems solved by Bacula but rather by educating your > operators :-) I am also considering just using fewer tapes. But that requires a good sit-down with all involved to weigh the risks of putting too much stuff on a single tape. Thanks so much for the assistance, it's very much appreciated. Charles > Arno > >>> Thanks, >>> >>> Charles >>> >>> ------------------------------------------------------------------------- >>> This SF.net email is sponsored by: Splunk Inc. >>> Still grepping through log files to find problems? Stop. >>> Now Search log events and configuration files using AJAX and a browser. >>> Download your FREE copy of Splunk now >> http://get.splunk.com/ >>> _______________________________________________ >>> Bacula-users mailing list >>> Bacula-users@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/bacula-users >>> >> >> >> Robert LeBlanc >> College of Life Sciences Computer Support >> Brigham Young University >> [EMAIL PROTECTED] >> (801)422-1882 >> >> >> >> ------------------------------------------------------------------------- >> This SF.net email is sponsored by: Splunk Inc. >> Still grepping through log files to find problems? Stop. >> Now Search log events and configuration files using AJAX and a browser. >> Download your FREE copy of Splunk now >> http://get.splunk.com/ >> _______________________________________________ >> Bacula-users mailing list >> Bacula-users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/bacula-users > > -- > Arno Lehmann > IT-Service Lehmann > www.its-lehmann.de > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > Bacula-users mailing list > Bacula-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bacula-users > ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
