Резервные копии 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 делает это в следующем порядке:
- Получает список процессов.
- Ищет.
- Удаляет все строки, которые имеют оба и "grep".
- Замените последовательные пробелы в один пробел.
- Захватите значения второго столбца, используя пробел в качестве разделителя.
- Возьми первую строчку.
Надеюсь, это поможет вам начать!
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.