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

Я забочусь о приложении, которое генерирует большой объем данных в файле журнала (о 5G день) на сервере Red Hat. Эти выполнения процесса в течение 24 часов в течение недели, таким образом, нет никакого смысла в день, когда файл не изменяется, хотя информация, добавляемая к нему за полночь, не особенно важна, таким образом, хорошо, если я теряю скажем, несколько секунд данных в течение того периода.

Для создания "безопасных" архивов файла журнала ежедневно, я создал сценарий, который делает следующее в какой-то момент рано утром:

• делает копию файла к локальной папке
• усеките "активный" файл
• tar+compress копия
• переместите tar.gz копии к нашему пространству архива

Вот сам сценарий в случае, если там бликуют проблемы с ним:

DF=$(date +"%Y%m%d_%H%M%S")
TARGET="fixdata-logs-$DF"
cp -r ./fixdata/logs $TARGET

#Truncate the original log file
find ./fixdata/logs -name '*.log' -exec sh -c 'cat /dev/null >| {}' \;

#Zip the log files
tar -zcvf $TARGET.tar.gz $TARGET

#Delete the labelled copy
rm -rf $TARGET

#Archive files older tha 3 days
find . -type f -mtime +3 -name \*.gz -exec mv {} $ARCHIVE_DIR \;

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

Проблема, в течение этого периода, приложение часто сообщает об ошибках, который связан с системными ресурсами. Например, монитор heartbeat его очереди часто не удаются произвести регулярных heartbeat. Ясно, что эта копия-> tar.gz-> процесс перемещения вызывает действительно влияние на сервер IO, что это влияет на поведение приложения.

Как я могу уменьшить влияние этого сценария? Время к концу не важно - если решение занимает больше времени, но не вызывает ошибки приложения, то это' предпочтительное для чего-то, что быстро. Есть ли другие подходы, которые я должен рассмотреть?

Для полноты я рассмотрел следующее, но имею сомнения:

• Пропустите часть копии и tar непосредственно: Но я волнуюсь, что tar будет иметь проблемы, если файл будет изменен, в то время как это занято.
• Скопируйте в папку архива сначала и затем tar - возможно, если сжатие сделано на другом диске затем, влияние IO меньше? Я волнуюсь, что пространство архива, которое мы используем, не подходит для того, чтобы сделать дисковые операции ввода/вывода как сжатие, поскольку я не думаю, что это - традиционный диск произвольного доступа. Я также не уверен, не идет ли копия к другому физическому диску ко всем неприятностям, поскольку я думал бы, что ОС имеет некоторый умный способ сделать локальную копию, физически не читая все байты в файле. К сожалению, мои *отклоняют навыки, не помогает здесь.
• Ожидайте до выходных: к сожалению, дисковое пространство на сервере не достаточно для содержания ценности недели данных перед архивацией. Конечно, я могу попросить увеличивать его, но сначала я хочу видеть, существуют ли более нормальные решения.