BackupPC-users

Re: [BackupPC-users] hardware and configuration recommendations for speed?

2010-05-25 15:58:48
Subject: Re: [BackupPC-users] hardware and configuration recommendations for speed?
From: Frank J. Gómez <frank AT crop-circle DOT net>
To: "General list for user discussion, questions and support" <backuppc-users AT lists.sourceforge DOT net>
Date: Tue, 25 May 2010 14:59:41 -0400
Thanks for reading my whole email, Les!  My comments are inline.

On 5/25/2010 12:28 PM, Frank J. Gómez wrote:
>
> The last successful full backup of RED5 took just over 8 hours.  37,457
> files totaling just under 25 GB were backed up at a rate of 0.87
> MB/sec.  RED5 is a laptop, and it's only on the network for about 8
> hours per day, so I have to be able to do better than this.

Is that the initial or 2nd run with this batch of files?  The 3rd and
subsequent runs should be faster if you have enabled checksum caching.
Or is that a typical amount of change between backups?

It is definitely not the initial run.  The problem I've had with this particular client is that any full backup takes ages; the incremental backups work smoothly until the next full backup is scheduled.  If the laptop stays in the office long enough for the next full backup to complete, then incrementals work fine; otherwise, the client seems to get stuck (for months, sometimes) trying to complete the partial.

I don't think I have checksum caching enabled; I'll try that.

Question (perhaps an obvious one): What is the benefit of doing periodic full backups?  What would be the downside of getting the full backup once and then doing incrementals going forward?
 
Considering how cheap disks are these days, I like simple raid1 mirrors
where they are practical for the total size you need.

Could I gain any speed advantages by writing to more than one disk (striping, I guess they call it)?  It seems like more disk heads might be able to do the job faster.
 
USB is as much the bottleneck as the drive.  If you use externals, use
ESATA even if you have to add a card for it.

Yes, I meant that the fact I'm using it over USB is the bottleneck -- I don't even know if it's USB 2!  I think internal is definitely the way to go for speed.
 
> Lastly, am I wrongheaded in trying to solve this problem with BackupPC?
Backuppc's rsync will be slower than stock because it is written in
perl, not the latest flavor, and works against a compressed copy on the
server.  If speed of transfer from one or a few machines is your main
goal, you might provide server space for a full uncompressed copy where
you can rsync - then let backuppc back that up to keep its history in a
more efficient format.

That's an interesting idea.  I'd prefer to stick with a more standard approach, but failing that I'll consider this option.
 

--
  Les Mikesell
   lesmikesell AT gmail DOT com


------------------------------------------------------------------------------

_______________________________________________
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/

------------------------------------------------------------------------------

_______________________________________________
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/