Hi, 28.02.2008 15:48, Peter Much wrote: > Hello Ryan, > > sorry this got a little delayed. I copy to Your email. > > <[EMAIL PROTECTED]> aka Ryan Novosielski schrieb > mit Datum Sun, 10 Feb 2008 22:37:54 -0500 in m2n.bacula.users: > ... > It depends how You define "possible". It seems not to be currently > supported, true. But for all practical matters, a "migration" as > currently done in Bacula *is* a copy. > When you migrate a backup-job from one storage-pool to another, > you will have all the data present in the new storage pool - but > the identical data in the old storage pool is also still present > and untampered - obviousely, since that tape or disk did only > get read and not deleted. > The only thing that has changed is two values in the catalog > which mark the old job as migrated and the new job as the target > of that migration. Now if one would someway change these two values > back to default, then one would have two jobs with different > job-ids but the same content. Certainly, some piece of the Bacula > code might be incompatible with such an action - as I said, it seems > currently not supported. But there is not much work needed to get > it implemented.
Restores - currently, Bacula doesn't know how to handle restores where the needed data is available in more than one place. > So, if I were in the need of such functionality, and as the Bacula > license allows us to make modifications to it as we seem appropriate, > I would just make it working - on my own risk, on my own > responsibility. (Respectively one could hire somebody who is willing > and able to take the responsibility.) I hope you would submit it as a patch, as that would save Kern and others from doing things again in the near future :-) ... > No - I'm speaking about the problem of getting the daily amount of > data thru some drives R/W heads within 24 hours. There are sites > where *this* is the real problem, where the backup system runs > continuously on saturated network and where you calculate the number > of needed tapedrives as the amount of daily data divided by the > drive's throughput divided by 24 hours (or better 16, for practical > purposes) and such are sites where you cannot avoid concurrency. > While I would currently not suggest Bacula as a possible solution > for that kind of site, I think it a good idea to keep that scenario > in mind. I would even recommend to keep Bacula in mind if you need to handle such a scenario... I don't think we're far from being reliable enough for such a beast. > With this background, the eight jobs are just the minimum building > block necessary in order to get ever near to such a scenario: > i want at least two clients to safe onto one storage object > (because if each client must run separately then i just do not > need a network backup solution), i have long- and shortrunning > jobs that may overlap (for instance when saving away database > redo-logs, this must happen timely, even during a running > full-backup), so this makes 4. Then I have the migration jobs > that read from the disk storage object, so add another two. > And then some folks may want to restore something at any time, > so add another two. > And I have not yet found a way to design a disk storage object > in Bacula that would be able to cope with that in a reliable > manner. Just out of curiosity - which backup solutions do you know that handle this with resonable performance? I mean, the disk throughput problem is a universal one, and my (or rather, my customer's) experience is that you can build really fast disk arrays, given enough resources. > If I would get that together, then that should be the building > block for everything else, no matter how large. > > rgds, > PMc Arno -- Arno Lehmann IT-Service Lehmann www.its-lehmann.de ------------------------------------------------------------------------- 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
