How about a "HOLD" command in bconsole to pause the scheduler and all job execution? I've had to manually cancel a number of jobs many times to prevent the execution of jobs.
/Jens > Hello, > > The bscan was never meant to put your catalog back exactly as it was. The > purpose is to allow you to use the catalog to recover files on old Volumes. > > I recommend that you revert to your previous catalog, possibly deleting the > two volumes in conflict, then do Full saves on everything (sort of starting > over). If you think you might need the files on the two extra conflicting > Volumes save those volumes, and in time of need bscan them into a fresh > database with a different name (a whole new learning experience), recover the > files, then trash the new database. > > You might want to take a look at the example in the manual for dealing with > disk storage -- I think it is titled something with Pools. The idea is that > you create a fixed set of Volumes from the beginning, then Bacula is never > allowed to create new Volumes -- it just cycles (recycles) through existing > Volumes. If you don't know exactly how many you need, you can estimate, then > always manually add new Volumes when they are needed (or monitor what is > going on and create them just-in-time). This will avoid a future repetition > of your problem of the NAS not being mounted. > > You can even phase into a new fixed Volume naming scheme by turning off the > automatic volume creation code and manually creating the new volumes, then > when the old ones are no longer needed, delete them. > > On Thursday 17 March 2005 11:58, Mike Winiberg wrote: > > Hi, > > > > We recently had a problem which I haven't been able to fully recover from, > > and would appreciate some advice about the best thing to do should > > something like this happen again: > > > > We run Bacula on Suse 9.0, using network attached storage which is mounted > > locally on /nas > > > > Due to a daytime power outage (our UPS failed FFS!) which took all our > > servers off-line at the busiest time of day, and during the panic that > > ensued, we forgot to remount the NAS before the overnight backups were run. > > > > So, we ended up with two new incremental volumes in the /nas subdir that > > were not actually on the NAS store, and Bacula was, of course, quite happy. > > > > In an attempt to recover from this, I stopped bacula, deleted the two > > 'unwanted' volumes and remounted the NAS. I then backed up the current > > catalog just in case and created a new empty catalog. I then ran bscan on > > all the volumes on the NAS to recreate the catalog so that it was in sync > > with the actual volumes we had in the backup set; which it did - after some > > time. > > > > However, when I next tried to run a backup, bacula made ten attempts to > > create a volume with an existing name and then gave up saying that I should > > use label to create a new volume for the backup to use. In other words, > > although I'd managed to recreate the catalog, bacula was trying to start > > volume numbering from the beginning again, and had not taken account of the > > volumes it had already in the catalog. Despite this, bacula was quite happy > > to let me restore from the backups it had now catalogued. I also noticed > > that all volumes had the recycle flag unset, and so wouldn't have been > > re-used, but that was fixable with update. > > > > What should I have done here? I couldn't move the 'spurious' volumes onto > > the NAS as their names clashed with existing volumes. How could I have > > either removed the erroneous jobs from the catalog, or incorporated the > > extra volumes into the backup set? > > > > To avoid keeping our backup system off-line any longer, I've restored the > > catalog with the two 'missing' backups in it so that our job schedule will > > still run, but surely there must be a way of telling bacula which volume > > number it should use next out of each pool. I couldn't find anything all > > that relevant anywhere in the docs, so here I am. > > > > > > Thanks for any help you can give. > > > > Mike Winiberg > > > > > > _____________________________________________________________________ > > This message has been checked for all known viruses by KMSinternet, powered > > by Messagelabs. > > > > > > ------------------------------------------------------- > > SF email is sponsored by - The IT Product Guide > > Read honest & candid reviews on hundreds of IT Products from real users. > > Discover which products truly live up to the hype. Start reading now. > > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > > _______________________________________________ > > Bacula-users mailing list > > [email protected] > > https://lists.sourceforge.net/lists/listinfo/bacula-users > > -- > Best regards, > > Kern > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Bacula-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/bacula-users > ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95&alloc_id396&op=click _______________________________________________ Bacula-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/bacula-users
