On Wed, Mar 19, 2014 at 1:48 PM, Timothy J Massey <tmassey AT obscorp DOT com>
wrote:
>
> > Let's say that the storage is not a problem for me and I can have as
> > many TB or PT as I need. However the main assumption is that every
> > box has got a separate "disk" to be backed up to. So now I faced the
> > problem with BackupPC which does use pool or cpool to store files
> > within :/. I don't need any compression or deduplication. Is there
> > any way to backup files directly to pc/HOST/ instead ?
>
>
> I am going to give a flat "no" to this. You may be able to break things
> within BackupPC to accomplish this (never run the link, for example), but you
> are *breaking* things. Don't do that if you expect *anyone* to be able to
> help you.
I don't know about that - people on the list report fairly often that
they are using too much disk space and it turns out that links have
been failing for one reason or another - but they still have working
backups.
> > I'm not going to backup couple of hundreds servers using one
> > BackupPC instance of course but I want to back up at least 100
> > servers per BackupPC instance.
> >
> > Is there something you could advise me ?
>
> Sure: use virtualization. Create your huge datastore (or multiple
> datastores) and create a VM for each unit that needs its own pool. Each VM
> will get its own (virtual) disk. Each will be, for better or worse,
> completely separate from each other.
Interesting concept, but it seems like it would add a horrible amount
of overhead in terms of setup and maintenance - even just tracking
which VM does which backup. Although - maybe it would mesh with
whatever is driving the idea of keeping the backups separate. If the
issue is political/security isolation you could give admin access to
someone on their isolated VM. You'd have scheduling issues that a
single server would sort out, though.
> There are other things that you'll have to worry about, no matter whether
> it's a single instance or multiple VM's. The screamingly obvious one is disk
> performance. I've found that running more than one BackupPC job at a time
> destroys performance, even on servers with 3-4 disks, using both hardware and
> software RAID. I have one server with 6 disks that does OK with a couple of
> jobs, but not nearly as fast as one at a time. I have one server with 12
> disks: that one has so much disk performance that I'm bottlenecked at the
> other end, so I can do 3 or so jobs simultaneously. You're talking
> "hundreds". So disk performance will really, really matter here. Your
> question will be more like, "How many *shelfs* of disks?" rather than, "How
> many disks?"
Throwing RAM at a disk performance problem usually helps. As does not
using raid5.
> Another issue will be network bandwidth. Unless you're running a
> well-designed 10GbE network, forget backing up "hundreds" (your number) of
> servers in a timely fashion.
That's going to depend on rate-of-change more than anything else if
you use rsync. You should only need to xfer the differences after the
first run - although you need to remember that is the difference
against the last full run. But, I agree that there's a point where
you should just add another backup server.
--
Les Mikesell
lesmikesell AT gmail DOT com
------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech
_______________________________________________
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/
|
