我们目前有一个大问题:我们需要为我们的一个客户镜像一个文件系统。这通常并不是什么问题,但在这里:
在这个文件系统上有一个文件夹有数百万的硬链接(是的!)数以百万计)。rsync只需要4天以上才能构建文件列表。
我们使用以下rsync选项:
rsync -Havz --progress serverA:/data/cms /data/有没有人知道如何加速这个rsync,或者使用其他的方法?我们不能使用dd,因为目标磁盘比源小。
更新:由于原始文件系统是ext3,我们将尝试dump和restore。我会留下你的up2date
发布于 2011-06-29 04:25:20
我们现在用的是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发布于 2011-07-01 15:10:09
您需要将双方升级到rsync 3。从changelog:
- 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已经发布了两年多了,但不幸的是,大多数企业发行版都是基于比这更早的代码,这意味着您可能正在使用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才能支持增量递归。
发布于 2011-06-28 14:29:28
您可以使用LVM并获取卷的快照,然后rsync作为备份。
或者,您可以将它与另一个答案结合起来,并在快照卷上使用dump,以避免将原始卷脱机。
https://serverfault.com/questions/284782
复制相似问题