答案1
老实说,我从未听说过您正在使用的程序。
我个人更喜欢rsnapshot
(http://rsnapshot.org/) 来满足我的备份需求。Ubuntu 软件包同名。
由于它使用硬链接,第一次运行时可能会占用大量 CPU 时间,但之后就不会了。(特别是如果您在备份之间只有少数文件发生变化——大多数人都是这种情况。)同样,随着时间的推移,它不会占用太多磁盘空间。
话虽如此,我还是安排在半夜进行备份。所以除了测试配置文件时,我实际上没有机会注意到 CPU 时间。这与您是否在服务器上运行此程序无关;rsnapshot
可以在命令行上运行。或者,您可以在桌面上创建它的快捷方式。
另一个建议是只运行renice
该程序,使其以较低的优先级运行。如果您需要自动执行此操作,则需要一些简短的 bash 编程。例如,请参阅https://talk.maemo.org/showthread.php?t=36870或者直接搜索短语“automatic renice”。
我一时还不知道该怎么做,但我猜你必须这样做:
- 编写一个 bash 脚本来找出进程 ID
- 运行 renice
- 把这个脚本放在一个地方
cronjob
,让它在备份开始后立即运行,或者让它重复运行(即每小时)
我猜脚本可能看起来像这样,但是你真的需要清理它,因为它真的是我最先想到的:
#!/bin/bash
PID=`ps -ef | grep "<program name>" | grep -v "grep" | tr -s ' ' | cut -f 2 -d ' ' | head -n 1`
renice -10 ${PID}
PID 线路按顺序执行此操作:
- 获取进程列表。
- 搜索 。
- 删除同时包含 和“grep”的任何行。
- 将连续的空格替换为单个空格。
- 使用空格作为分隔符来获取第二列的值。
- 取第一行。
希望这能帮助您入门!
答案2
Ubuntu 备份又名德贾杜普用作duplicity
后端。有一个漏洞2014 年 duplicity 中修复了导致此问题的问题。但这种情况仍然会发生,因此您可以报告 duplicity 中的另一个错误。此错误仅影响一个物理核心,因此计算机在多 CPU 机器上仍应响应。否则,您可以考虑各种其他备份替代方案,或者在不使用计算机时对其进行备份。
您也可以尝试更大的块大小吗?
duplicity --max-blocksize 4096 [full/incremental] src dest
--max-blocksize number determines the number of the blocks examined for changes during the diff process. For files < 1MB the blocksize is a constant of 512. For files over 1MB the size is given by: file_blocksize = int((file_len / (2000 * 512)) * 512) return min(file_blocksize, globals.max_blocksize) where globals.max_blocksize defaults to 2048. If you specify a larger max_blocksize, your difftar files will be larger, but your sigtar files will be smaller. If you specify a smaller max_blocksize, the reverse occurs. The --max-blocksize option should be in multiples of 512.