I have a Linux box that I use as a file server. I have a monthly cron job that tars up the contents of the data drive and then copies it via scp to another machine for safe keeping. The resulting tarball is around 300GB in size, and it normally takes about a day and a half to complete the copy (over an 802.11g Wi-Fi connection).
Today I noticed that my backup job hadn't completed yet, and it's been running for 3 days. Checking the destination machine, I could see that only about a third of the data has been copied so far, and it appears to be growing at a rate of < 300KB/sec.
Using iperf
between the two machines, I can see that my network throughput is around 20Mbits/sec, which is about what I expect over an 802.11g connection.
Using dd if=srcfile of=/dev/null
on the source machine, I can read about 45MB/sec from the source drive (an external USB drive).
using dd if=/dev/zero of=/destdrive/tmp.dat
on the destination machine, I can write about 30MB/sec to the destination drive (internal SATA drive). Seems kind of slow for a SATA drive, but not unreasonably slow (and certainly not 300KB/sec slow).
So I seem to have ruled out network throughput and drive throughput at both ends, so where else can I look to find the source of the bottleneck?
iperf
, which shows a 20Mbps throughput - about what you'd expect over an 802.11g link. – Jeff Loughlin Nov 23 '16 at 14:25smartctl -a /dev/sd[X]
to see if you have any pending or offline uncorrectable sectors, or if you have any read failures. – Spooler Nov 23 '16 at 14:51