我的托pipe服务提供商使用名为clBackup的工具来备份我们的服务器，通过networking推送文件。 以下是我们提供给我们的一个ps输出：
top - 10:06:24 up 25 days, 3:47, 5 users, load average: 6.63, 4.79, 4.23 Tasks: 357 total, 1 running, 355 sleeping, 0 stopped, 1 zombie Cpu(s): 25.0%us, 0.6%sy, 0.0%ni, 72.5%id, 1.2%wa, 0.5%hi, 0.1%si, 0.0%st Mem: 49447692k total, 49314632k used, 133060k free, 79628k buffers Swap: 2097144k total, 288k used, 2096856k free, 40614172k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 20621 root 16 0 455m 65m 34m S 612.7 0.1 144:53.17 clBackup
由于该工具，我们正在这些服务器上托pipe的生产网站上遇到性能问题。 我们知道这一点，因为每当有人抱怨我们的网站很慢，我们检查框，我们可以看到备份程序正在运行，每当我们杀死该进程，网站再次performance良好。
显然clBackup有点擅长吞噬CPU（和内存），因为我们似乎并不是唯一遇到这些问题（ 链接1 ， 链接2 ， 链接3 ）。
我们试图让我们的托pipe服务提供商了解这个性能问题是不可接受的，并指出高CPU使用率是不正常的（超过600％），但我们收到的build议是排除一些大的目录真的不需要备份。
我们对这个回应并不满意（我们不希望花费资源来容纳我们支付的服务的备份工具，我们相信备份工具应该被devise来处理这种情况），并正在寻求帮助来自ServerFault社区的独立客观答案的forms，希望这将有助于说服我们的提供者做更多的事情。
为了使这个问题对大家有用，我们想提出一些与我们的问题有关的一般性问题，希望有经验的系统pipe理员能够回答。
问题1：从您自己的经验来看，备份使用290GB的500GB文件系统可以接受的时间是多less？
Q2：从您自己的经验来看，这种备份工具可以接受的CPU使用率是多less？
问题3：有没有人遇到与clBackup类似的问题，并重新进行过程或其他缓解措施有帮助？
是的，这是相当差 – 一个备份程序不应该吃6核心做它的工作。 我会向供应商抱怨很长时间，而且很难，并且准备离开，如果供应商没有解决问题，他们不会吮吸。
回答你的问题：
是的，我们自己遇到了同样的问题。 我们find的唯一解决办法是告诉我们的主机暂时closures它，然后我们进入一个长期的问题线程，通常会告诉我们排除目录，这实际上不是解决scheme。
对不起，我没有解决scheme，只是想让你知道你并不孤单。