Hi, 22.09.2009 01:12, Blake Dunlap wrote: > Resurrecting this a bit, just curious if anything has been thought > off / changed, plus some ideas... > >> On Monday 08 June 2009 02:18:58 James Harper wrote: >>>> 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. >>> Perfect. >> Yes, but unfortunately I spoke too soon. >> >>> Would you want a new level called VirtualFullCopy, or an >>> additional flag somewhere? >> We should think about this some more. Perhaps we could come up >> with a way to mark a Job offsite rather than as a Copy. >> Something like that would fit much better with the current >> direction we are taking. It might be something like your >> proposed Pool flag, but that is problematic from several stand >> points:
Hmm... I prepared something, years ago :-) There's the Location concept. The tables / column are already in the catalog. The idea was to have Locations defined with a cost. My initial idea was that a cost of 0 would indicate a volume is easily available - like in the autochanger or on the shelf. Higher cost would indicate more effort fetching media. So, if you had two sets of backups, one on volumes in a location with cost=10 and one with cost=20, the ones from the location with cost=10 would be requested. If you move your volumes around, you just update the cost accordingly. I - obviously - never got around to finish that as the customer for whom I invented that stuff is no longer a customer :-( > I like this idea, it's pretty much the goal we want, just trying to > find differing ways to see it done. The reason the Pool option > appeals to me over this, is you can turn on a single pool in the > restore in theory, and have access to your "pool" of offsite > backups, or even less speedy alternate site backups (possible tiers > of capabilities of speed / accessibility). The idea outlined above works with finer granularity than per pool. >> 1. It requires a database change. The Location concept doesn't - it just needs the right tools to manage, and small changes to Baculas volume selection (i.e., go for sets of media with lowest overall cost). > Agreed, having a pool not considered for normal (virtual) backup > functions would need an additional binary flag. Like an archive > flag or similar definition. > >> 2. It assumes (I think) that the Pool is used for only one type >> of Volume, which is not currently the case, and if we made it so, >> it would vastly complicate life for small users who use only the >> Default Pool. > > I would disagree here, I don't see this being anything but an add > on for those that would use it, defaulting to non intrusive all > onsite local backups unless configured otherwise. > >> Some way of using current DB fields would be preferable -- or >> simply do a Virtual Full then a Copy job :-) Sure, copy, change the location - and wait for Bacula to support that concept :-) > But this requires the virtual full job to be created, and then > copied, and here is the important point, it still acts as a copy > job, so you either must have a matching local original backup, That problem remains - I suppose it would be best to base the virtual full on jobs that are available at low cost. > or > the copy will be promoted to the viable version, and we're right > back where we started. This is not desirable in my case at least, > and I believe others as well, as it would be very nice to be able > to have an offsite current full backup, while the local backups are > still based on an old full, and periodic differential / incremental > backups to vastly conserve space, while having a viable recent > complete offsite backup that is restorable as well. I believe with the implementation of the Location / cost concept that would be possible. Hope this gets someone interested in finishing Location support ;-) Arno > I guess the > other option would be to have a completely separate offsite backup > rotation, with copies of all differential/incremental backups, but > that would greatly increase the required churn, when this feature > could easily fill the role with much more efficiently with a few > minor conceptual tweaks. > > Copy jobs definitely have their place, especially for clone based > backups requiring auditing, but that shouldn't discount the > viability of an alternate solution for those of us looking more for > storage efficiency than compliance. > > For reference, it would save me hundreds/thousands of GB of storage > per week, not to mention the much lower network usage / backup > times each week currently running the completely separate full only > backup sets currently in place to provide the non virtual version > of this feature. As it stands now, I have to choose, either to have > synthetic full backups each week, and keep copies locally, or I can > have completely separate "offsite" backups each week, but they must > be done in full separately, with cloned filesets, etc (not fun to > maintain at all). > >> >> Kern > > -Blake > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry® Developer Conference in > SF, CA is the only developer event you need to attend this year. > Jumpstart your developing skills, take BlackBerry mobile > applications to market and stay ahead of the curve. Join us from > November 9-12, 2009. Register now! > http://p.sf.net/sfu/devconf > _______________________________________________ Bacula-devel > mailing list [email protected] > https://lists.sourceforge.net/lists/listinfo/bacula-devel > -- Arno Lehmann IT-Service Lehmann Sandstr. 6, 49080 Osnabrück www.its-lehmann.de ------------------------------------------------------------------------------ Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________ Bacula-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/bacula-devel
