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
