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

Я использую предустановленное программное обеспечение Ubuntu для резервного копирования, с Ubuntu 16.04 для рабочего стола (но, возможно, та же проблема была и в более старой Ubuntu).

Каждый раз, когда он запускается (один раз в день), он потребляет 100% процессора в течение нескольких минут. Так как я думал, что программное обеспечение для резервного копирования должно быть тихим и невидимым, это довольно раздражает.

Было бы хорошо, если бы это занимало в четыре или пять раз больше времени, которое требуется сейчас для выполнения своих задач, но потребляло бы меньше ресурсов процессора и было бы более тихо.

Есть ли тихий режим для программы резервного копирования или лучшая альтернативная программа резервного копирования для Ubuntu?

2 ответа

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

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

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

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

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

Сверху головы, я не знаю, как это сделать, но я думаю, что вам придется:

  • написать скрипт bash, который узнает идентификатор процесса
  • беги ренись на нем
  • положить этот скрипт в 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. Возьми первую строчку.

Надеюсь, это поможет вам начать!

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

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

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.
Другие вопросы по тегам