目前我们遇到一个大问题：我们需要为我们的客户镜像一个文件系统。 这通常不是一个真正的问题，但这里是：
在这个文件系统上有一个文件夹，有数百万个硬链接（是的！百万！）。 rsync需要超过4天才能build立文件列表。
我们使用以下rsync选项：
rsync -Havz --progress serverA:/data/cms /data/
有没有人有一个想法如何加快这个rsync，或使用替代？ 我们不能使用dd因为目标磁盘比源小。
更新：由于原始文件系统是ext3我们将尝试dump和restore 。 我会保持你up2date
我们现在使用了ext * dump。 运作良好，恢复方面甚至不必分机*。
我们通过卸载设备并使用dump vf - /dev/vg0/opt | gzip -c > /mnt/backup/ext3dump.gz来完成离线备份 dump vf - /dev/vg0/opt | gzip -c > /mnt/backup/ext3dump.gz 。
这里最后一行你可以看到大小，时间，速度和最后的inode数字：
DUMP: dumping regular inode 47169535 DUMP: dumping regular inode 47169536 DUMP: Volume 1 completed at: Wed Jun 29 05:42:57 2011 DUMP: Volume 1 54393520 blocks (53118.67MB) DUMP: Volume 1 took 4:16:43 DUMP: Volume 1 transfer rate: 3531 kB/s DUMP: 54393520 blocks (53118.67MB) DUMP: finished in 15403 seconds, throughput 3531 kBytes/sec DUMP: Date of this level dump: Wed Jun 29 01:24:29 2011 DUMP: Date this dump completed: Wed Jun 29 05:42:57 2011 DUMP: Average transfer rate: 3531 kB/s DUMP: DUMP IS DONE
您需要将双方升级到rsync 3.从更改日志：
- A new incremental-recursion algorithm is now used when rsync is talking to another 3.x version. This starts the transfer going more quickly (before all the files have been found), and requires much less memory. See the --recursive option in the manpage for some restrictions.
自从rsync 3.0.0发布以来已经有2年多的时间了，但不幸的是，大多数企业发行版都是基于比这更早的代码，这意味着你可能使用的是rsync 2.6。
作为参考（如果有其他人有这个问题），如果你已经运行rsync 3，那么你正在使用与增量recursion不兼容的选项。 从手册页：
Some options require rsync to know the full file list, so these options disable the incremental recursion mode. These include: --delete-before, --delete-after, --prune-empty-dirs, and --delay-updates.
而且，再次， 双方必须运行rsync 3才能支持增量recursion。
您可以使用LVM并创build卷的快照，然后rsync将快照作为备份。
或者，您可以将其与其他答案结合使用， 并在快照卷上使用dump ，以避免必须使原始卷脱机。