> > Since migration is a significant new > > feature, it strikes me as a very good opportunity to start heading in > > that direction. > Yes, that is a good point that I probably did not consider enough.
Well, it's not like you don't have anything else to do...8-) > Yes, on second thought we probably could do Migration a bit differently. > However, unless one wants to overly complicate the existing complicated > code, > it would either be all or nothing -- that is either accept all possible > existing ways of setting the storage device, or do it only from the Pool. > If > it is done only from the Pool, then modification from the command line > would > be out, and all flexibility would be lost. Though it is possible, I find > adding even more code to restrict devices only for Migration to be a bit > of > overkill. Maybe I am wrong ... OK. I was thinking of allowing the specification as syntactically valid, but ignoring them (with a message in the job log to that effect), but if it's a real PITA than a great big fat "Don't Do It This Way. Here be Dragons!" warning in the docs is probably sufficient. Or at least allows "I told you not to do that!" as a valid support response. 8-) I think the change in the default setup would probably be complimentary, and would settle a lot of this; much of the overriding going on is legacy stuff where we would be doing something very different going forward. > Migration has been the hardest project I have worked on in Bacula, and it > is > sort of limping along, but I am not really very happy about it. At the > moment I don't see any way to improve it, but I am unhappy because it is > rather complicated -- try figuring out what happens when Pools, SQL > statements, and Regexes are involved to determine what gets migrated -- it > is > a brain buster. What worries me more though is that the current > implementation is not very scalable. I mentioned this some months ago -- > I > shudder to think of what will happen when some poor guy fires off a > Migration > job that spawns 1000 child jobs :-) As I think you said, it will be > interesting to see how Bacula stands up to the stress test. :-) If it's any consolation, it took 200 engineers at IBM almost 8 years to get this far in DFSMS for z/OS. We're way ahead by that measurement...8-) > I'm a bit tired of working on it, but at the same time would really like > to > see it working well, and even more, I would really like to see about > adding a > copy feature, and even more than that a "consolidation" feature (or what > some > people call a synthetic Full backup -- I think) where the current state of > the system will be created from existing backups, but written to one set > of > tapes ... Migration *is* hard. Copypool management will be comparatively easy; you've build a lot of the hard stuff along the way. Wrt the "synthetic backup", think about it as a migration job where the migration selection criteria is "most recent files from all jobs prior to <date>", and NextPool= your tape pool. I think you're going to end up creating a new job entity for the new backup, though. Now that DVDs work (crossing my fingers), the next big question IMHO is how to produce multiple copies of backup tapes at the same time, and handle restore from the most convenient copy if more than one exists. That should keep you busy for your next vacation...8-) > > On the other hand, it boils down to: > > Initial setup of Bacula: > > [snip] > > Implementing migration (or replacing the current spooling code): > > [snip] > Put that way, it all sounds simple enough, but it assumes you understand > the > concept of a pool, which I have noticed from reading the email lists is > not > so easy for most users. As soon as I get the paper I'm working on out the door, I'll give this a go. > > It might be interesting to think about making a change to the default > > configuration that gets initially installed with the .debs or .rpms to > > configure a disk changer and disk pool by default, and then use the > > enabling-migration process above to add tape capability. That would make > > the Bacula installation immediately useable on install (and with > > disk-based backup becoming commonplace, this would be a very handy > > thing, particularly when the Windows daemons become mainstream), and > > propagate the changes forward w/o breaking the world for the existing > > users. One could easily write a tool to do the definition steps for the > > tape enablement. > > This isn't such a bad idea. All the pieces are already there except the > Migration job. I'll think about it, though it would be nice if someone > else > took on this task since I still have a huge amount of documentation work > to > do. I'll take a crack at it in the cookbook. That would take it out of the mainline release process (and hopefully let you work on something else). ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
