On Thu, Apr 10, 2008 at 10:48:33AM -0400, Rob Owens wrote:
> I know I'm coming into this thread way late, but I think this could be
> fairly easily managed using a master/slave setup (similar to what MythTV
> offers). BackupPC could default to being a "master", but you could
> optionally set i
I know I'm coming into this thread way late, but I think this could be
fairly easily managed using a master/slave setup (similar to what MythTV
offers). BackupPC could default to being a "master", but you could
optionally set it as "slave" and then define its master. The master
handles all th
Hello,
> Instead of trying to have 1 server that handles everything, just
> use multiple servers to do the work. I am interested in the concept of
> using some network/cluster filesystem to have multiple servers backup to
> a single SAN/NAS with the cluster filesystem.
I have this kind
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On
> Behalf Of Jean-Michel Beuken
> Sent: Saturday, January 19, 2008 1:08 PM
> To: backuppc-users@lists.sourceforge.net
> Subject: Re: [BackupPC-users] Scaling BackupPC
>
> Hello,
>
Hello,
> Instead of trying to have 1 server that handles everything, just
> use multiple servers to do the work. I am interested in the concept of
> using some network/cluster filesystem to have multiple servers backup to
> a single SAN/NAS with the cluster filesystem.
I have this kind
>iSCSI isn't going to let 2 servers access the same thing at once. Does
>GFS give better performance than NFS?
While many low-end iSCSI appliances won't allow this, and the defaults on open
source targets IET is to not permit multiple servers to access the same LUN,
you can configure it other
Timothy J. Massey wrote:
> > DRDB might help propagate the disaster in real-time. I'm not convinced
> > that is desirable.
>
> You are correct; but that's what my second idea (replication of
> individual backups) is for: *automatic* and hands-off movement of
> backup data from one place to
dan wrote:
> A database can be an order of magnitude or more
> faster than direct file access.
Certain operations can be optimized differently, especially if you
compare a loaded/cached dataset to the first access to a file but how
can you expect a database to be faster in general than the fil
Actually most modern filesystems are a lot like a database. Though the
database is another level of abstraction from the hardware, there is a ton
less overhead creating a file which is small on a single file basis but
cumulatively with thousands or millions of files makes a big difference.
This is
Les Mikesell <[EMAIL PROTECTED]> wrote on 01/17/2008 01:24:24 PM:
> Timothy J. Massey wrote:
>
> > And there's no
> > coordination between the two instances: the moment the copy is
> > finished, they're two separate pools with separate schedules, etc.
>
> Which means, of course, that if s
On 01/17 12:45 , Timothy J. Massey wrote:
> There are two separate solutions I would love to see. One is the
> ability to run BackupPC in an active/active cluster: two (or more)
> BackupPC servers with a common pool between them.
the problem here is that BackupPC is disk-I/O-limited in a lot
Timothy J. Massey wrote:
> And there's no
> coordination between the two instances: the moment the copy is
> finished, they're two separate pools with separate schedules, etc.
Which means, of course, that if something goes horribly wrong on one
(like the admin typing 'rm -rf ...' in the wro
Ski Kacoroski <[EMAIL PROTECTED]> wrote on 01/17/2008 11:40:15 AM:
> I have actually done the replication for a smaller site where BackupPC
> is backing up about 10 machines so it is only running for a few hours a
> day. When it is not running I have an rsync to a separate machine
> run. The
On Wed, 16 Jan 2008 17:14:48 -0500 "Timothy J. Massey"
<[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote on 01/16/2008
> 01:51:41 PM:
>
> Another way of doing it would be to have a way to replicate a backup
> from one server to another, where backup data could be pushed or
> pulled by the Bac
Timothy J. Massey wrote:
> [EMAIL PROTECTED] wrote on 01/16/2008
> 11:50:03 PM:
>
> > A more radical change would likely be more effective but im not sure
> > how likely it is to get implemented, and that is to store the files
> > for the backup in an SQL database
>
> At the very top of my re
[EMAIL PROTECTED] wrote on 01/16/2008
11:50:03 PM:
> A more radical change would likely be more effective but im not sure
> how likely it is to get implemented, and that is to store the files
> for the backup in an SQL database
At the very top of my reasons for selecting BackupPC are:
1) Ext
this reply is specific to:
> I think solaris or *bsd (maybe OS X soon) with zfs sounds promising for
> this with its incremental send/receive facility but I haven't tried it
> yet to see if millions of hardlinks are an issue. I'm using a hot-swap
> sata cage to raid-sync a 750 gig drive to rotate
Timothy J. Massey wrote:
> > > I am not sure a SAN/NAS with a clustered file system buys you much
> > > because each instance of BackupPC needs its own space (e.g. you cannot
> > > have multiple instances sharing the same pool space.
> >
> > Interesting concept... I bet you could if you could
[EMAIL PROTECTED] wrote on 01/16/2008
01:51:41 PM:
> Ski Kacoroski wrote:
> > I am not sure a SAN/NAS with a clustered file system buys you much
> > because each instance of BackupPC needs its own space (e.g. you cannot
> > have multiple instances sharing the same pool space.
>
> Interestin
so does backuppc care if the files in the $pool are hardlinks? if not, then
some script could traverse the seperate $TopDIR trees from each server to a
master $pool on some sort of schedule.
On Jan 16, 2008 11:51 AM, Les Mikesell <[EMAIL PROTECTED]> wrote:
> Ski Kacoroski wrote:
> > I am not sur
Ski Kacoroski wrote:
> I am not sure a SAN/NAS with a clustered file system buys you much
> because each instance of BackupPC needs its own space (e.g. you cannot
> have multiple instances sharing the same pool space.
Interesting concept... I bet you could if you could coordinate the
nightly cle
I am not sure a SAN/NAS with a clustered file system buys you much
because each instance of BackupPC needs its own space (e.g. you cannot
have multiple instances sharing the same pool space. For another
install I run, I have setup separate instances on the same server, but
in that case they you se
I was about to suggest something like Ski has.
Instead of trying to have 1 server that handles everything, just use
multiple servers to do the work. I am interested in the concept of using
some network/cluster filesystem to have multiple servers backup to a single
SAN/NAS with the clust
David,
I backup around 1500 clients to a set of (8) low end 1U x86 boxes.
Each box has a 3ware card with (4) 250G disks in a raid 5 setup. Each
box can handle 4 concurrent backups/restores at a time (at one point
when the client machines were old and failing we were doing 10 - 15
restores a week)
I have been running BackupPC with a number of clients for the past few
months. I am about to add even more clients to the degree that I think I
will have to add 2-3 additional BackupPC servers. I am curious to find
out how others are scaling BackupPC. The storage for this is a SAN, and
I have conte
25 matches
Mail list logo
