In thinking about this a bit more, it seems like what you really want is a VirtualFullCopy job. I would be reasonably inclined to accept something like that (it is simple and clear) and would do a Virtual Full but mark it as a Copy job, which means that the Volumes could be offsite and would not be used in subsequent backups.
Regards, Kern On Friday 05 June 2009 20:58:18 James Harper wrote: > 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
