Re: [BackupPC-users] Per-PC pools

Hi Holger,

Thanks for the reply. The separate pools would be on separate raid arrays, separately funded. Many research grant funding sources have strict regulations about ensuring funds go only to support a given project, hence the separation requirement.

Part of this is in an effort to cut down on the number of backup servers I have. In the past I have recommended each group (or sometimes each grant/project) purchase its own backup server and storage. But this just leads to server proliferation.

Regarding separate BPC instances on the same hardware, the scheduling issues, need for lots of duplications of code, and likelihood of screwing something up seemed prohibitive.

After looking into the code, I think the changes would be trivial. Probably under 50 lines total. It's not necessary to have separate BackupPC_nightly and BackupPC_trashclean processes as one person opined; the existing ones simply need to be made aware of the additional locations on which to operate.

~Stephen

On Wed, Mar 13, 2013 at 10:51 AM, Holger Parplies <wbppc AT parplies DOT de> wrote:

Hi,

backuppc AT kosowsky DOT 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.

Regards,
Holger

------------------------------------------------------------------------------
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 AT lists.sourceforge DOT net
List: https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki: http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/

------------------------------------------------------------------------------
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 AT lists.sourceforge DOT net
List:    https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:    http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/