> > I have thought about this one, but the problem is the > > differentials/incrementals will still be based on it. Which causes > problems if > > say you only want to keep those jobs for 3 weeks, but the on site > backups can > > be kept for much longer. > > I only use Incrementals so it isn't a problem, but yes, for > Differentials it would be a problem.
The first incremental after a full is still going to need the full available to do any restores, and subsequent incremental are based on the previous, etc. > > > > > This is just a symptom though of the bigger issue where Bacula is not > designed > > at the moment with the concept of offsite backups in mind. Hacks > accomplish > > it, but it requires a good bit of workaround (duplicate jobs, > duplicate > > filesets, etc) > > > > The best I have come up with is an option to have the name of a job be > changed > > upon completion via scripting or similar, and ensure that all tree > logic > > restricts by job name (Most of it does, but there are a few places you > have to > > tweak in code to accomplish this). > > > > I am in the process of implementing the above, but not there yet, > mostly > > because I am stalled waiting for SAN access so that I may do full > backups to > > disk instead of the juggle imposed due to the requirement of different > pools / > > storage devices (yet not supporting separate SD's). > > > > Let me know if you want to collaborate on patches. =) > > > > I think bacula needs the concept of a 'source pool' for a job. You'd > need to be able to list multiple pools for it to be useful though. One > idea I had was to be able to tag pools with one or more arbitrary tags. > Some examples of a tag might be 'Onsite', 'Offsite', 'Archive', 'Tape', > and 'Disk'. You'd then be able to specify a list of pools and/or tags > for a Job (and override in the schedule). Eg: > > (snip) > > So only Pools tagged with Onsite would be selected as the base job for > the Incrementals and Differentials. Sources= would maybe allow you to > specify both Source Tags and Pool resources. > > This could be further extended to doing restores too. You can already > specify a Pool I think, but being able to specify a Tag would limit the > source media to only (say) Onsite pools. > > Next Pool would go away, maybe. > > Obviously the user is quite free to engineer an unworkable configuration > (eg Level=VirtualFull Source=Onsite Pool=Full-Disk) which could cause > bacula to try and read and write from different media on the same > storage device and deadlock, but I don't think that alone is reason to > shoot down this idea (I'm sure there will be plenty of those :) > > Comments? > > James > I've had similar thoughts (though not to this extent until now) and would love to see this, it would greatly simplify management and design of systems like mine and some of the ones I have deployed for customers which have to use offsite pools with differing retentions and do not want local backups based on them, while still allowing the new features to work well like virtual fulls and not requiring a lot of duplication which can lead to errors. Feature request time (Yes I realize this is a rather complicated one, and would be a while off)? -Blake ------------------------------------------------------------------------------ OpenSolaris 2009.06 is a cutting edge operating system for enterprises looking to deploy the next generation of Solaris that includes the latest innovations from Sun and the OpenSource community. Download a copy and enjoy capabilities such as Networking, Storage and Virtualization. Go to: http://p.sf.net/sfu/opensolaris-get _______________________________________________ Bacula-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/bacula-devel
