Резервные копии Ubuntu потребляют 100% процессорного времени

Честно, я никогда не слышал о программе, которую Вы используете.

я лично предпочитаю rsnapshot ( http://rsnapshot.org/ ) для моих резервных потребностей. Пакет Ubuntu является тем же именем.

, Так как это использует hardlinks, в первый раз, это работает, может использовать много процессорного времени, но впоследствии, это не будет. (Особенно, если у Вас есть немного файлов, которые изменяются между резервными копиями - который имеет место для большинства людей.) Аналогично, это не будет использовать много дискового пространства со временем.

Однако я планирую резервные копии в середине ночи. Таким образом кроме того, когда я тестирую конфигурационный файл, у меня действительно нет шанса заметить процессорное время. Это не связано с тем, выполняете ли Вы это на сервере; rsnapshot может быть выполнен на командной строке. Или, можно создать ярлык на рабочем столе к нему.

Другое предложение ко всего renice программа так, чтобы это работало в более низком приоритете. Если необходимо сделать это автоматически, то некоторое короткое программирование удара будет необходимо. Посмотрите, например, https://talk.maemo.org/showthread.php? t=36870 или просто ищет фразу "автоматический renice".

Первое, что пришло на ум, я не знаю, как сделать это, но мое предположение - то, что Вы имели бы к:

• пишут сценарий удара, который узнает идентификатор
• процесса, выполненные 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 делает это в порядке:

1. Получает список процессов.
2. Поиски.
3. Удаляет любую строку, которая имеет обоих и "grep".
4. Замена последовательные пробелы в одиночный пробел.
5. Захват значения второго столбца, использующие пространство как разделитель.
6. Проводят первую строку.

Hope это помогает запустить Вас!

Резервное копирование Ubuntu иначе использование DejaDup duplicity как бэкенд. Был ошибка в двуличности в 2014, которая была зафиксирована, который вызвал это. Это все еще происходит, хотя, таким образом, Вы могли сообщить о другой ошибке в двуличности. Эта ошибка только влияет на одно физическое ядро, таким образом, компьютер должен все еще быть быстро реагирующим на машинах мульти-ЦП. Иначе можно рассмотреть различные другие резервные альтернативы или иметь компьютерное резервное копирование, когда Вы не используете его.

Вы могли также попробовать больший blocksize?

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.