我目前使用传统的 rsync+cp -al 方法来创建我们服务器树的增量/快照备份。备份将通过四个 eSATA 连接（每个连接四个磁盘）发送到一对连接到备份机器（一台具有 16 GB RAM 的 Sandy Bridge 机器，运行 CentOS 5.5）的八磁盘塔上。每个磁盘都是一个常规的 2 TB 磁盘，因此我们有 32 TB 的磁盘空间连接到备份机器。我们用这个在服务器上备份了大约 20 TB 的数据。
问题是，每次每日备份都要花费超过 24 小时，而真正耗费时间的并不是实际的 rsync，而是在备份机器上本地执行树的 cp -al 所花费的时间。仅制作树的影子副本就需要超过 12 个小时，据我所知，性能积压在磁盘上（顶部显示 cp 使用了大量 RAM，但 CPU 并不多，并且大部分时间处于不间断睡眠状态）
我们将服务器数据分成四个主要卷（和一些次要卷），每个备份都并行运行（cron 中有一些偏移量，以尝试先完成某些磁盘的 cp）。备份驱动器上有两个卷，每个卷都是 16 TB 的条带化 LVM 卷。
所以显然我需要提高性能，因为它目前无法使用。
第一个问题是：当 CentOS 6 发布并支持 btrfs 时，使用 btrfs 对子卷进行快照是否会大幅提高性能？
第二个问题是：有没有办法，使用 ext3 或 CentOS 5 或 6 中支持的其他东西，来“鼓励”它将目录/inode 放在卷的一部分（可能是通过 LVM 位于 SSD 上的部分），而将文件放在另一部分？这大概可以解决问题，但我不知道如何以这样的方式提示 ext3。
答案1
您可以尝试使用--link-dest和相关选项，而不是使用rsync。cp -al请参阅手册页和类似这样的教程了解详情。
您可以通过关闭 ext3 的日志来获得额外的速度，但是我不建议这样做，因为如果更新期间出现问题，它会增加备份损坏的可能性。
如果您的备份包含具有许多文件的目录，那么您可能会发现重新格式化为 ext4 或使用带有 ext3 的 dir_index 选项可能会改善情况 - 但在这两种情况下，您可能都需要重新格式化才能看到全部好处，因为仅使用新选项重新挂载文件系统不会转换任何现有结构。
答案2
考虑使用rdiff-备份而不是 rsync+cp。它会自动处理文件的旧副本，因此您不需要 cp。
来自 rdiff-backup 页面：
“目标目录最终是源目录的副本，但额外的反向差异存储在该目标目录的特殊子目录中，因此您仍然可以恢复一段时间前丢失的文件。”