From: David B. <db...@si...> - 2006-08-21 21:43:28
|
> > Daily, weekly, monthly backups to my tapelibrary. Then, once a = month, I > want > > to migrate to some tapes (special pool) for taking them offsite. If = my > site > > doesn't burn down, I still would like to make regular restores from = the > > original jobs. Well, I know that migration normally would address > something > > like D2D2T where the current implementation is perfectly matching. = But > how > > could I address my case? Or am I misunderstanding the concept ... > Yes, you make a good point, and I haven't overlooked it. What you = want is > to > make a copy rather than migrate, and this is in fact a sort of = extension > of > migration as well as the next logical step.=20 I think you'd actually want a combination of the two, plus Arno's volume = management widget: migration to consolidate the offsite copy to the = minimum number of volumes, copypool support to allow Bacula to = automatically create a duplicate set of media containing the = consolidated data, and then Arno's widget to allow you to remove one set = of the media from the library, but still track what happened to them. = Note that once you've created the consolidated copy in the = to-be-sent-offsite pool, there's nothing stopping you from migrating the = contents of those volumes back to your regular media, getting the mount = minimization and volume consolidation as a freebie in the process.=20 That would allow you to still use the onsite media copy for restores if = there is no disaster, and it gets you the bonus of minimizing the number = of tape mounts if you need to do a full restore from the offsite copy = (because the migration has consolidated the volumes down to the minimum = necessary to hold the data).=20 > However, although I have some > ideas of how to implement copy, I am not sure it is something that is > trivial > to implement. The problem is that it will take additional code to = teach > Bacula how to deal with (not get confused by) multiple copies of the = same > thing. Possibly na=EFve question: does the director or the SD write the record = that indicates where the file is on the tape? If the director, I can see = that this could get ugly. If the SD, you could implement this as a = multiplexing SD proxy between the real FD and one or more real SDs (the = real SDs see a FD-style connection from the proxy). The multiplexing SD = could assume responsibility for writing the file records, and tell the = real SDs not to do so (which would limit the necessity for write = concurrency control in the SDs). This would be relatively little impact = on the existing code (the multiplexing SD would be new, but allow reuse = of a lot of existing code).=20 The director would need to be able to tell the mux how many streams and = which SDs to connect to for each job.=20 The restore process would need to be taught to retrieve the file = location records, sort them by volume availability and mount status, = then take the first available one, preferring volumes that are already = mounted=20 If you're systematic about doing good volume management, then when you = marked the offsite archive copies as unavailable or out-of-changer, = Bacula would automatically switch to the other copies, and would only = call for the offsite ones if all the local ones were unavailable.=20 I'm not sure I explained that well. Did that make sense?=20 -- db |