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] > > It's been a while since I've dipped my toes into the BackupPC's code, but > I've done a bit of preliminary research into this, and think I've > identified the places where changes would need to be made to allow the pool > or cpool to be overridden for individual PCs -- nominally to be located at > $TopDir/pc/$host/cpool, for example. > > The idea here is would be to allow different PCs' pools to reside on > different physical filesystems for political reasons. I don't want to > disable pooling entirely since it still has features that would be > beneficial even if pooling one (or a few) PCs rather than an entire > organization. > > I haven't read this list regularly in a few years, so I thought I'd ask: > has anyone gone down this path before me? If so, did you succeed or fail? > I'd like to compare notes either way. > > [1] My specific situation is that I have multiple linux PCs with large > volumes of research data. This data is generally unique to that PC with > little duplication between PCs (at least between PCs of different research > groups). The storage to backup this data is also usually funded by > individual faculty accounts (sometimes grants) and as such should be > dedicated to that faculty's PC(s). Separate BackupPC servers (real or > virtual) is another option I have considered, but seems unnecessarily > wasteful. I read what you write and come to a different conclusion... 1. First, I don't see why separate budgets requires separate pc pools but not separate BackupPC instances. If it's merely an accounting issue, then come up with a fair metric that roughly aligns with usage. For example, charge each user based upon the relative size of their fulls to the total storage size. That seems a lot simpler and more robust then rewriting the basic code of BackupPC. If the issue were security and encryption or statutory requirements for keeping data isolated, then I could understand the need for pool separation. Otherwise, you are pursuing the wrong solution to the wrong problem. If its not even an accounting issue, but a "philosophical" one, then perhaps you should be pursuing the question on alt.philosophy.backuppc... because that is beyond the scope of this group...
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. The storage (pool and pc trees) is completely separate, the BackupPC_dump instances run separately anyway and the BackuPC_nightly processes are separate. The only "savings" is that you have a single backup daemon running which takes up only trivial processing power and maybe a few small file shared log and config files. On the other hand, you are relying on untested hacked code to perform the critical task of backups with the possibility of introducing subtle errors that may not surface until you need to do a restore and it's too late. Can you be sure you have located all the places in the code where tests are made for pool vs. cpool? Seems a waste of time and foolish to me. 3. Finally, if you want to use separate filesystems for the pools, then you also will need to have separate pc trees. And you will need to edit the backuppc startup code that attempts to test writing hard links and probably also hack how BackupPC moves and deletes 'trash'. So, now you have separate pools, separate pc trees, separate dump (and link) processes (always true), separate (i.e. non-shared) BackupPC_nightly processes, separate (i.e., non-shared) BackupPC_trashClean, etc... Seems to me like you are doing a lot of coding work and taking a huge risk of errors in order to do something that is conceptually not much different from running totally separate BackupPC instances and all just for the sake of "philosophy"... BTW, running separate instances of BackupPC need not require separate virtual machines. One could probably just make changes to the config.pl to keep separate processes from colliding... ------------------------------------------------------------------------------ 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/
