I once had a problem like that with restores. It turned out to be wrong
permissions on /tmp on the client (755, instead of 1777). Nothing noted
in logs.

Probably not related, but worth having documented somewhere.

Tyler

On Mon, 2011-02-14 at 00:39 -0500, Jeffrey J. Kosowsky wrote:
> My incremental backups seem to be taking FOREVER now.
> I am backing up my server onto a SOHO NAS device.
> Incrementals used to to take about 30 minutes.
> Now it has been running for 16 hours and it is only partially through
> (though not stuck). 
> 
> I don't think it's a network bandwidth/transfer speed issue since
> NewFileList shows that only 1068 new files have been accumulated in 16
> hours (and there are no super long or multimedia files -- it really
> has just been backing up mostly my /usr partition). 
> 
> In fact, the total size of the partition is 13GB so the speed is only about
> 220KB/sec even if all files were transferred completely. Even with
> BackupPC running, I can get raw UDP network transfer speeds of
> 11MB/sec between the server and the NAS. And the NFS transfer speeds
> to copy a file using dd is about 5.5MB/sec. These speeds are 50 and 25
> times the speed it would take to copy over the entire partition yet
> BackupPC is still running...
> 
> Also BackupPC is consuming minimal processor resources (and nothing
> else is much running either on the server or the NAS). Also minimal
> swap space is being used.
> 
> 
> And since BackupPC itself is running on the server so for an incremental
> there shouldn't be much need for bandwidth over the NAS link anyway
> (especially since I have rsync checksum caching).
> 
> So what should I be checking as possible causes of such a dramatic
> slowdown of incremental backups?
> 
> 
> 
> ------------------------------------------------------------------------------
> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
> Pinpoint memory and threading errors before they happen.
> Find and fix more than 250 security defects in the development cycle.
> Locate bottlenecks in serial and parallel code that limit performance.
> http://p.sf.net/sfu/intel-dev2devfeb
> _______________________________________________
> 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/
> 

-- 
"Never underestimate the bandwidth of a station wagon full of tapes
hurtling down the highway.
   -- Andrew S. Tanenbaum


------------------------------------------------------------------------------
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
_______________________________________________
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/