BackupPC-users

Re: [BackupPC-users] Backing up many small files

2013-02-05 11:01:01
Subject: Re: [BackupPC-users] Backing up many small files
From: "Sorin Srbu" <sorin.srbu AT orgfarm.uu DOT se>
To: "'General list for user discussion, questions and support'" <backuppc-users AT lists.sourceforge DOT net>
Date: Tue, 5 Feb 2013 16:59:43 +0100
> -----Original Message-----
> From: Adam Goryachev [mailto:mailinglists AT websitemanagers.com DOT au]
> Sent: Tuesday, February 05, 2013 1:09 PM
> To: backuppc-users AT lists.sourceforge DOT net
> Subject: Re: [BackupPC-users] Backing up many small files
>
> On 05/02/13 21:11, Sorin Srbu wrote:
> >> Have you done at least two FULL backups since you enabled the
> >> checksum-seed option? If not, stop now, and wait until you have.
> >
> > I have eighteen full backups online for this particular machine.
>
> Note I said number of full backups since you changed that option, not
> just number of fulls. There is a difference!

I'm not sure I understand the distinction. I set the checksum-flag a while 
back (a few years I think) and since then at least eighteen full backups have 
been made.


> > As for the single drive, I can't do much about that. It's an instrument
> > computer and not really allowed to change the config or the service
> > support-people won't be too happy about it.
>
> Understood, sometimes you just don't get a choice.... In any case, you
> do need to check this anyway to find out if it is in fact the
> bottleneck. If it is, then there is no point looking or changing
> anything else, if not, then you will need to keep looking.

Only a single-drive, and an approx nine years old at that. Not to top-notch. 
I'd say this is a bottle-neck as well.

> You can keep an eye on the /sys/block/sda/stat file, in particular watch
> the activetime value (10th value). If this is increasing at the nearly
> the same rate as wall clock time, then it means your drive is basically
> 100% busy, and therefore the bottleneck. If it is much slower than wall
> clock time, then your bottleneck is elsewhere... Again, you want to
> watch this during a backup, both during the first stage while the client
> is building the list of files to backup, and again while the 200M data
> is being transferred.

Thanks for the hint. Will look this up tomorrow.


> >> 3) Check disk performance on the backup server
> > Any best practices here?
> Yes, get as many drives as possible, make each drive as fast as possible, 
> and combine with a hardware raid card with a Battery Back Up
> write cache. IMHO, also only use RAID level 0, 1 or 10 (ie, no checksum 
> based raid levels like 5 or 6).
> In reality, you make do with what you have. BTW, you might also look into 
> changing the filesystem format from ext3
> to something more modern which will probably perform better. Personally, I 
> use reiserfs, but only because I built this system back when > it was the 
> best performing filesystem, wouldn't suggest it now for a new system due to 
> it's seemingly un-maintained status... Though it > has proved reliable for 
> me.

Ah, yes. Ext3 and more drives. This is what RHEL4 supports out-of-the-box 
basically. As the computer also came preconfigured from the instrument-company 
with the two drives I didn't have much choice in changing it for something 
more modern, like ext4, available in RHEL6. 8-/


> > Is this the (GUI) Edit Config/Backup settings/CompressLevel=3 you're 
> > referring to?
>
> Yes, set this to 0 to disable compression, but you might need to delete
> all existing backups to really see the effect it will have. (Existing
> unchanged files will still be stored compressed, only new files will be
> stored uncompressed. You will still need to uncompress an old file if it
> is updated, but after the first update it will be stored uncompressed.
> Also, you will still uncompress a file to do a full comparison (of a
> small percentage of files). (Watch CPU consumption on the backup
> server, if CPU is busy, then compression is an issue, remember compression 
> will
> only use a single core even if you have a multi-core CPU).

Set to no compression, will see about deleting old compressed stuff tomorrow.


> This is not relevant, I meant to watch what the bandwidth usage was
> during a backup. BTW, 7MB/s is fine for a 10Mbps connection, but if you
> really have a 100Mbps network, you should see at least 80MB/s transfer
> speeds. Try testing with iperf if you want to generate your own load.
> BTW, slower speed with the client compared to the server may point to
> CPU or network driver issues on the client (ie, old crappy network
> card, or slow cpu, etc).

Aha, misunderstood. Sorry.


> So is this 3 x 500G drives?
> Try a "hdparm -tT /dev/sd[ab] /dev/hdb" to compare the speeds of them
> (while there are no running backups). Maybe you could replace the PATA
> drive now with a SATA if you have a spare around? Also might be able to
> increase to the 4 x 500G drives you thought you had.... Though none of
> this will help if the problem is somewhere up ab

Speeds seem to be pretty much the same.

user@BPC-server ~/ [0]# hdparm -tT /dev/sd[ab] /dev/hdb

/dev/sda:
 Timing cached reads:   3016 MB in  2.00 seconds = 1508.16 MB/sec
 Timing buffered disk reads:  214 MB in  3.00 seconds =  71.30 MB/sec

/dev/sdb:
 Timing cached reads:   3008 MB in  2.00 seconds = 1504.85 MB/sec
 Timing buffered disk reads:  216 MB in  3.01 seconds =  71.83 MB/sec

/dev/hdb:
 Timing cached reads:   3012 MB in  2.00 seconds = 1506.73 MB/sec
 Timing buffered disk reads:  218 MB in  3.02 seconds =  72.13 MB/sec


> No problem... just pointing it out :) You never know what other people
> do or don't know.

People keep telling me that about raid0 and how not to use it, but I insist 
there are uses for it even today and even for backups. ;-)


> If the problem is server side, it may be worthwhile to wipe the data and
> use a smaller chunk size on the RAID, format with a different
> filesystem, and start the backups again. Just remember, don't bother
> timing anything until after the second full backup has finished.

Yeah, I've been thinking along those lines as well with eh CentOS 6, ext4 and 
more disk drives, but so far as the backup server is just a "casual" server it 
hasn't come up high enough on the to-do list.

-- 
/Sorin

Attachment: smime.p7s
Description: S/MIME cryptographic signature

------------------------------------------------------------------------------
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013 
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
_______________________________________________
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/