Hello Blake, Before you spend a lot of time making patches, please read the Developers guide, then be sure you have agreement in principle on the feature design. That avoids disappointment on both sides (mine and yours).
Here are a few points that are contrary to what you write: The Copy job is intended to be used for offsite backups, and in addition, there are fields in the Media record that allow you to indicate that the volume is not available as well as the Location table that can be used to keep track of where the volumes are. The design is there even if at the moment it is not a mature feature. Most of the control for offsite storage is via external programs such as bweb. Version 3.0.1 and later do not require different pools for migration, copy, and virtual full jobs. It seems to work quite well, but since this is new as of 3.0.1, whether or not there are problems remains to be seen. Best regards, Kern On Friday 05 June 2009 21:44:54 Blake Dunlap wrote: > Disclaimer: I am a user, not an official developer. > > I've been thinking along the same lines, but have not come up with a > solution I like. > > 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. > > 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. =) > > Blake Dunlap > > > -----Original Message----- > > From: James Harper [mailto:[email protected]] > > Sent: Friday, June 05, 2009 10:58 PM > > To: [email protected] > > Subject: [Bacula-devel] The synthetic backup problem again > > > > I've had a bit more of a think about the virtual full backup problem I > > posted about previously. Basically, the problem (for me) is that the > > current implementation is designed to create a new full backup out of > > previous full+diff+inc backups, and assumes that the new backup will > > remain accessible. What I (and several others) want to do is keep the > > new virtual backup offsite. It doesn't work that way though - the first > > virtual backup is okay, but the next one wants to use the most recent > > full backup as the source, which is now offsite. > > > > So in my setup I have a pool per client, and a pool for tapes. Each > > client pool has the 'tape' pool set as the 'next pool'. I do a full > > backup at 9pm on Saturdays, and Incremental backups at 12pm, 3pm, and > > 9pm every day (except at 9pm on Saturday). Each night at 9pm virtual > > full backup is done to tape (but scheduled so that it doesn't start > > until the incrementals are finished) so that I have a single offsite > > full backup for disaster recovery purposes in the event of a total loss > > of the server room, but can still restore with fairly fine granularity > > any time for the last three weeks, and then even further back from the > > offsite tapes. > > > > The patch I have come up with says "when doing a virtual full backup, > > only consider backups _not_ in the 'next pool' as possible sources". > > This works great for me, but I understand that it will break the > > previous behaviour which other users may be relying on (although I don't > > quite understand how the existing behaviour doesn't result in a > > deadlock). > > > > I understand that the 'next pool' thing is a bit of a hack, and will > > ultimately probably go away and be replaced by a more flexible solution, > > but in the meantime I'd like to come up with a solution that could go > > into the main tree. My current idea is to create a new backup level of > > 'synthetic' (or maybe 'syntheticfull'), which uses my 'next pool > > exclusion' patch but is otherwise identical to the current 'virtualfull' > > backup level. 'L_VIRTUAL_FULL' occurs on 12 lines in the bacula sources > > so it wouldn't be too invasive as a patch. > > > > Comments? > > > > Thanks > > > > James > > > > ------------------------------------------------------------------------- > >- ---- > > 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 > > --------------------------------------------------------------------------- >--- 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 ------------------------------------------------------------------------------ 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
