Les Mikesell wrote at about 14:47:34 -0600 on Friday, March 4, 2011: > On 3/4/2011 1:56 PM, Dan Pritts wrote: > > > > On Mar 2, 2011, at 10:25 PM, David Birnbaum wrote: > > > >> Craig, > >> > >> I realize a lot's gone into your thinking for 4.0 - I was wondering if it > >> would be possible to offer some sort of "cost" parameter to the host > >> configuration. Specifically, we have local hosts (backing up via a > > > > Along similar lines, we backup a lot of VMware VMs as well as physical > > hosts. > > I expect my backup hardware could back up concurrent clients, but it would > > hammer the > > vmware storage if we did more than a couple of *those* concurrently. > > > > We can't be the only ones with this problem. > > > > In practice we just keep the concurrency down and we make it fit in our > > backup window, > > but that won't scale infinitely. > > The concurrency control really needs some kind of 'grouping' concept to > tie physical constraints together. For example, to group VM guests and > the common host, or to group remote systems sharing limited WAN > bandwidth or a router link you don't want to swamp. The idea would be > to have a setting to limit concurrency within a group while continuing > to run members outside of the group up to a different limit. Amanda had > something like that related to network segments but I've forgotten how > it was used. >
It seems like there are two factors we are trying to capture - Relative resource intensity of each client backup - Interactions between subsets of clients It seems like we may need a concept both of 'grouping' and 'resource intensity' In any case, if such changes are made, it would be worth it to think through all the common use cases so that the structure agreed upon is broad and flexible enough to capture them all. ------------------------------------------------------------------------------ What You Don't Know About Data Connectivity CAN Hurt You This paper provides an overview of data connectivity, details its effect on application quality, and explores various alternative solutions. http://p.sf.net/sfu/progress-d2d _______________________________________________ BackupPC-devel mailing list BackupPC-devel@lists.sourceforge.net List: https://lists.sourceforge.net/lists/listinfo/backuppc-devel Wiki: http://backuppc.wiki.sourceforge.net Project: http://backuppc.sourceforge.net/
