目前我们有一个大问题:我们需要为我们的一位客户镜像一个文件系统。这通常不是什么大问题,但这里是:
在这个文件系统上,有一个文件夹有数百万个硬链接(是的!数百万!)。rsync
仅构建文件列表就需要 4 天以上的时间。
我们使用以下rsync
选项:
rsync -Havz --progress serverA:/data/cms /data/
有人知道如何加速这个 rsync 吗,或者使用其他方法吗?我们无法使用,dd
因为目标磁盘比源磁盘小。
更新:
由于原始文件系统是ext3
我们将尝试dump
。restore
我会让你保持最新状态
答案1
您需要将双方都升级到 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,那么您使用的选项与增量递归不兼容。从手册页中:
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 才能支持增量递归。
答案2
我们现在使用了 ext* dump。效果很好,而且恢复端甚至不必是 ext*。
我们已经完成了离线备份,通过卸载设备并使用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
答案3
您可以使用 LVM 并对卷进行快照,然后将快照 rsync 作为备份。
或者,你可以将它与其他答案结合起来使用dump
在快照卷上,以避免使原始卷脱机。