Holger Parplies wrote at about 15:51:19 +0100 on Wednesday, March 13, 2013: > Hi, > > backu...@kosowsky.org wrote on 2013-03-13 10:11:17 -0400 [Re: > [BackupPC-users] Per-PC pools]: > > Stephen Joyce wrote at about 07:52:11 -0400 on Wednesday, March 13, 2013: > > > I'm in a situation where I find myself desiring per-pc pools.[1] > > > [...] > > > > I read what you write and come to a different conclusion... > > I'm not saying I don't, but there's one thing you don't mention: > > > [...] > > 2. Second, why go to the trouble of rewriting deeply embedded code to > > separate pools within a single BackupPC daemon process rather than > > just running separate instances of BackupPC? Once the pools are > > separate, there is truly de minimus savings to run one vs. multiple > > BackupPC instances. > > True, but the one thing you *don't* get with independent daemon processes is > coordinated scheduling. There are good reasons to limit concurrent backups. > With independent storage units that may be less important, but there *can* be > other reasons for wanting a global decision process (i.e. which backup should > be run first, how many concurrently ...). Depending on your infrastructure, > that could either mean using separate servers, modifying the code as you > suggested, pooling the money and keeping a single instance, or just running > several instances because you don't need coordinated scheduling. In fact, you > might even need coordination per group rather than globally, which would be > much easier with independent instances. > > Another point that springs to mind is that all might benefit from a common > pool on a faster storage system (more spindles, faster RAID level). While > total backup time over all systems might be the same, each individual backup > might complete faster. You might just get more out of your money by pooling > resources. >
I agree with your comment on scheduling... though that would be a manageable issue unless he were supporting large numbers of independent users/pools. Given his use case referencing faculty with separate filesystems, I assumed that the overall number of distinct instances would be relatively small. For a small such number, just reduce the max processes per instance and/or adjust the blackout periods. Since the rate limiting step on most modern systems is file access and not computational power and since the OP was talking about separate filesystems (presumably on separately paid for hardware), the number of concurrent processes is probably not even an issue. This seems a lot less risky than mucking with the code especially since the notion of pool location is scattered throughout the code... ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar _______________________________________________ BackupPC-users mailing list BackupPC-users@lists.sourceforge.net List: https://lists.sourceforge.net/lists/listinfo/backuppc-users Wiki: http://backuppc.wiki.sourceforge.net Project: http://backuppc.sourceforge.net/