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: 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). > >1. It requires a database change. 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 :-) 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, 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 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
