From: Les M. <les...@gm...> - 2012-09-18 16:42:38
|
On Tue, Sep 18, 2012 at 10:24 AM, Timothy J Massey <tm...@ob...> wrote: > > Fortunately, BackupPC is a "backup of the backup" right now, and is not > expected to be used for real. Yet. That's why I can take the time and try > to actually solve the problem, rather than apply band-aids. > > But that will likely end in November, if not sooner. It is more than a band-aid to have a warm-spare disk ready to pop in instead of waiting for a 3TB restore even with reasonable performance. Be sure everyone knows what they are losing. > I'm not. I've got two of these new boxes built. In both cases, they have > 2-4% wait time when doing a backup. One is a RAID-5 and one is a RAID-6. Can you test one as RAID10? Or something that doesn't make the disks wait for each other and likely count the time against the CPU? > Might it have something to do with md? Could the time that would normally > be considered wait time for BackupPC be counted as CPU time for md? That > doesn't seem logical to me, but I can say that there just isn't any wait > time on these systems. Not sure, but I am sure that raid5/6 is a bad fit for backuppc although good for capacity. > > Mine seem to track the target host disk speed more than anything else. > > The best I see is 208GB with a full time of 148 minutes. But that > > is with backuppc running as a VM on the East coast backing up a target > > in California and no particular tuning for efficiency. Compression is > > on and no checksum caching. > > That's the same settings I'm using. But that's about double the > performance I'm getting. 247GB in 340 minutes, or about 12MB/s. I see more like that when backing up slower targets - the rsync protocol probably isn't very good about overalapping the read/compare while walking the tree with the block-checksum comparison so you add up every little delay at either end. Are you sure the target has no other activity happening during the backup? -- Les Mikesell les...@gm... |