本周早些时候我有一个“完美风暴”我的服务器上出现了一个问题：两个备份作业（系统上的每个 RAID10 阵列一个）已经运行了 18 个小时，然后我的 I/O 密集型应用程序的流量持续激增。结果就是性能慢得令人无法接受，我不得不强迫我们的管理员取消备份。（他对此很不高兴……一点也不高兴。 “如果……我不负责。”）
最终的结果是压力很大，客户不满意，而且脾气非常暴躁的斯图。
瓶颈在于磁盘利用率。一旦取消作业，一切都会正常运作。 我可以向管理员提出什么建议来减少对我的服务器的影响？
以下是一些血腥细节：
备份命令本身（我从中得到了这个ps，但我真的不知道这是什么意思。）
bpbkar -r 1209600 -ru root -dt 0 -to 0 -clnt xtx-le00 -class F_Full_on_Thursday
-sched Incr_Fri_to_Wed -st INCR -bpstart_to 300 -bpend_to 300 -read_to 300
-blks_per_buffer 127 -stream_count 8 -stream_number 8 -jobgrpid 223932 -tir -tir_plus
-use_otm -use_ofb -b svr_1259183136 -kl 28 -fso
系统
- RHEL4 64 位
- 4GB RAM（约一半由应用程序使用）
- DL380G5 带有两个附加的 SAS RAID10 分区，约 550 GB 和约 825 GB
数据
1TB
- 约 1000 万个文件
应用程序
- 工作日 09:00 至 23:00 繁忙
- I/O 密集型（99% 为读取），主要集中在几百 MB 的文件上
答案1
我不太清楚 bpbkar 的工作原理，但我会使用 rsync 将所有文件备份到异地，然后保持同步，这样会消耗很少的资源，因为只有更改的文件才会更新。当然，这意味着初始备份需要相当长的时间，但你已经说你已经“忙碌了 18 个小时”。
然后，您就可以按照自己想要的方式轻松管理另一台机器上的备份数据。
小编辑：如果您选择从磁带备份转向磁盘备份，您可能需要使用提供双重奇偶校验的 RAID6。
答案2
我们有一个系统，可以将实时服务器 rsync 到备份服务器（由廉价的 1TB SATA 磁盘构建），然后对备份服务器进行完整的磁带备份。它非常棒：
- 腰带和牙套 - 兼具两种备份的所有优点
- 大大降低了实时服务器的 IO 负载
- 如果您只需要一个或两个文件，恢复速度会更快
- 异地档案馆的全套磁带
答案3
如果您的备份需要 18 小时才能正常运行，那么降低它们的优先级可能不会解决问题（除非您想一次运行几天的备份）。我倾向于将磁盘复制机制设置到另一台机器（我自己喜欢 DRBD），然后使用 LVM 拍摄时间点快照，备份它，然后继续。因为它在单独的机器上运行，（a）它可以随心所欲地敲打而不会影响实时应用程序，并且（b）它不会与实时应用程序争夺磁盘 IO，这意味着它也可能运行得更快。
有一件事我可以肯定地说：你在同一台机器上做的任何事情都将完全破坏你的磁盘缓存——因为备份过程会从磁盘读取所有要备份的数据（即使它只是检查mtimes而不是读取和校验所有文件），仍然会有大量元数据块进入你的缓存，这些元数据块会从缓存中踢出有用的数据，并导致比原本不必要的更多的磁盘IO。
答案4
再次投票rsync。我每天使用它来备份 9TB 的非常繁忙的文件服务器。从来没有出现过问题。
如果您关心“时间点”，请创建 LVM 快照、挂载、rsync、卸载、销毁。服务器上的负载会稍微高一些，但仍然比完整复制所用时间少得多（少得多！）。
如果管理员说绝对必须，bpbkar请先对较少使用的系统执行 rsync，然后bpbkar从中运行。无需占用您的生产系统。
测试中的一个轶事：当我们接近 ext3 的 8TB 限制时，进行了一些“拔掉插头”测试来确定在复制过程中由于硬件故障损坏文件的可能性有多大。拔掉了服务器、存储盒和 SAN 接线的插头。复制了数千万个文件。
结论：
- ext3 平均每 10 次故障就会丢失一个文件。
- XFS 每次存储故障平均错误少于 5 个（服务器故障几乎为零）（这让我很惊讶！我以为 XFS 总是在硬件故障时快速而严重地失败）
- JFS 每次都会损坏数百个文件。
简而言之，rsync运行得非常好。任何错误最好归咎于您的硬件和/或文件系统。 bpbkar面对同样的故障，表现不会更好。