我正在备份一个Linux盒子到通过NFS挂载的NAS。 我正在使用rsync（作为http://www.mikerubel.org/computers/rsync_snapshots/与硬链接的scheme的一部分）。 这是我ssh进入machine_being_backed_up，启动我的rsync命令，备份文件大约一个小时左右，然后冻结服务器（例如，需要物理重新启动，这是非常不方便的，需要时间重新启动）最后的错误（实际名称匿名）：
some/path/file1.gz rsync: read errors mapping "/home/some/path/file1.gz": Input/output error (5) some/path/file2.gz rsync: read errors mapping "/home/some/path/file2.gz": Input/output error (5) some/path/file3.gz 这很可能表明我正在尝试备份的机器上的硬盘驱动器有一些错误的扇区，对不对？ 或者，NFS连接速度太慢，或者在安装我的NFS驱动器（使用rw，soft，intr选项安装）时select了错误的选项，可能会出现这种错误？ 有没有办法使这些input/输出错误只是跳过/失败的文件，而不是冻结系统（所以我不必经过镇去重新启动服务器）？
更新：我昨天打开了SMART，昨天进行了短暂和长期的自测，报告没有错误（昨天我不能提到这一点，因为长时间的testing在7p左右完成，计算机在午夜左右崩溃，所以我可以login，直到今天上午，当我可以 – 站点重启）。
此外，我试图rsync的问题文件到同一驱动器上的另一个分区，并没有得到任何错误。 我现在正在试图直接rsync到NAS（而不是使用NFS挂载NAS）。
更新（10月3日）：我已经将硬盘移动到另一台机器，并且已经有2个星期没有错误。 在旧机器中，每天都有这种types的错误。 我猜测主板或内存错误在其他机器（没有足够的时间来完全诊断和查明问题）。
物理冻结机器的事实强烈表明这是硬件错误的症状。 我不希望坏扇区导致机器挂起，所以它可能不太容易诊断。
要查看是否是磁盘是问题，请尝试在本地读取受影响的文件（通过SSHlogin并使用cat /home/path.to.file > /dev/null ），但如果这起作用，则不一定意味着磁盘表面是好的（它可能是边界线，有时可读其他不）。 如果您尚未运行SMART监视工具，并观察扇区重新映射数量增加的情况 – 这将表明磁盘表面不处于顶端形状（重新映射的几个扇区在现代大型驱动器中并不罕见，但是许多指示一个严重的问题）。
这可能是文件系统损坏，但我不希望这完全挂起机器 – 或者如果它是如此糟糕的文件系统驱动程序崩溃，我希望在控制台上的内核恐慌消息，而不是机器停止。 你可以使用fsck来检查这个，但是要确保你现在可以读的所有东西都是备份的，以防万一这样的修复会让事情变得更糟（这很less见，但是我已经看到了，特别是如果你是使用一个实验性的文件系统或一个testing版，而不是一个经过testing的版本）。
另一件要检查的硬件冻结是CPU和RAM是好的。 他们可能是错误和过热 – 不是太多，以致于在正常运行中造成问题，是由rsync运行一段时间推动某些东西在边缘上施加的额外负载。 如果出现问题，运行内存testing和CPU“烧入”testing可能会突出显示。 你的I / O控制器也可能以同样的方式成为一个嫌疑犯，虽然我不知道你将如何去testing。
这听起来像你在源机上的文件系统或硬盘有问题，而且它不在rsync的控制之下。 尝试这个：
$ cp /home/some/path/file1.gz /home/some/path/file1_bak.gz ...
并再次运行rsync （与新文件），看看它是否工作。 如果没有，请查看--exclude或--exclude-from选项来备份所有剩余的数据，然后用SMART检查硬盘状态，必要时运行fsck 。
在Raspbian GNU / Linux 8.0（jessie）下使用rsync和NTFS复制大型（多MB）时遇到同样的问题，并得到相同的错误信息。 在Windows下，磁盘已经运行了几分钟。 我推断这个问题可能与软件有关。