1

Я использую время для резервного копирования моей установки Linux. Он служит расширенной оболочкой для команды rsync .

Сегодня я попытался добавить /var /log в список папок для резервного копирования, и это вызвало серьезные проблемы с производительностью. Задание, похоже, зависло в конкретном файле, и загрузка ЦП родительского процесса rsync достигает 100%. Затем я использовал lsof чтобы увидеть, какой файл вызвал проблему, и, похоже, это каталог /var/log .

Я провел поиск в Google и несколько экспериментов с различными опциями rsync и обнаружил, что --checksum является нарушителем. Без параметра инкрементное резервное копирование завершается правильно в считанные минуты. При этом процесс застревает, когда rsync пытается синхронизировать постоянно меняющийся файл журнала. Это имеет смысл, но мне все еще кажется, что это ошибка.

Я правильно использую опцию? Есть ли обходной путь для этого?

2 ответа2

1

Возможно, вы захотите выполнить ротацию журнала перед синхронизацией. Пропустите активные файлы и просто сделайте резервную копию архивов. Вы даже можете сделать rsync постротационным действием после обычного поворота логов.

0

Имейте в виду, что контрольная сумма существует только для проверки того, что передача файла успешно завершена .. средство, чтобы убедиться, что файл не поврежден, если хотите.

Возможно, это не тот ответ, который вы ищете, но --checksum будет медленным. Обойти это невозможно. Если бы я был тобой, я бы создал быстрый скрипт bash, чтобы сжать все твои журналы, прежде чем ты запустишь резервное копирование.

Достаточно чего-то быстрого:

#!/bin/sh
for file in /path/to/log/dir/*;
do;
zip `basename $file`.zip *;
rm -f "$file";
done;

Затем запустите вашу резервную копию. Это в любом случае спасет rsync от создания контрольных сумм, возможно, огромных файлов журнала.

Будь милым ... Я знаю, что это не тот ответ, который вы искали.

Удачи

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .