Я использую zip, чтобы сделать регулярное резервное копирование локального каталога на удаленную машину. Они не верят в вещи как rsync здесь, таким образом, лучше, чтобы я мог сделать (?). Вот сценарий, который я использую
echo $(date)>>~/backuplog.txt;
if [[ -e /Volumes/backup/ ]];
then
cd /Volumes/Non-RAID_Storage/;
for file in projects/*;
do nice -n 10 zip -vru9 /Volumes/backup/nonRaidStorage.backup.zip "$file" 2>&1 | grep -v "zip info: local extra (21 bytes)">>~/backuplog.txt;
done;
else
echo "backup volume not mounted">>~/backuplog.txt;
fi
Это все хорошо работает, за исключением того, что zip никогда не использует много ЦП, таким образом, это, кажется, занимает больше времени, чем это должно. Это никогда, кажется, не добирается выше 5%. Я пытался делать это хорошими-20, но это не имело никакого значения. Это - просто сужение трубы скоростей сети или скоростей диска процесс, или я делаю что-то не так?
Вы, вероятно, найдете это zip
проводит большую часть его времени, ожидая ввода-вывода (читающий файлы и пишущий сжатые версии), который является, почему он не использует столько ЦП, сколько Вы ожидаете. Предоставление процесса дополнительного приоритета через nice
не имеет никакого эффекта на это, поскольку задача не может больше использовать процессорное время, если бы это не питаемые данные на уровне, который потребовал бы его к.
В соответствии с Linux Вы видите эту ситуацию как высокий %age, поскольку "IO Ожидают" время в выводе от top
и подобные утилиты, то же может быть верным для OSX.
Причины в течение времени ожидания IO могли включать:
Если Вы хотите использовать "запасные" циклы ЦП и не можете сделать так путем сокращения задержек IO, Вы могли попытаться использовать 7zip вместо этого - это использует намного больше процессорного времени на блок данных, но достигает лучшего сжатия, чем zip некоторым полем слишком во многих случаях, уменьшая размер Ваших резервных копий. Будет ли это быстрее (потому что 7zip приводит к отправке меньшего количества данных по сети), или медленнее (потому что дополнительная вычислительная сложность означает Вас, ЦП может стать узким местом не диски/файловые системы/сеть), зависит от Ваших машин точная спецификация.
Еще одна вещь, некоторый процесс отчета об инструментах использует на ядро и некоторые на ЦП (и некоторые так или иначе в зависимости от настроек), и zip обычно является потоковым процессом. Таким образом, если у Вас есть четырехъядерный ЦП, что 5% вряд ли не будут "5% ЦП" или приблизительно 20% одного ядра (хотя это может возвращаться между ядрами, если это является единственным, распараллелил его, не будет работать больше чем на одном ни в какой данный момент).
"хороший-n 10" заставляет рассматриваемую программу быть еще "более хорошей" при помощи более низкого приоритета. Возможно, Вы имели в виду "хороший-n-10" или "хороший - 10", который делает программу менее "хорошей", и таким образом используйте больше ЦП.
вот мой сценарий как есть, если кому-либо интересно. Очевидно, существует несколько трудно кодированных путей в здесь, таким образом, Вы не можете просто выполнить его как есть. Это сохраняет журнал своих операций и использует рычание для уведомления Вас относительно любых ошибок. Если у Вас нет рычания / не хотят устанавливать его, просто комментировать / удаляют любую из строк с growlnotify в них.
Одно из других изменений, которые я внес, должно было скопировать удаленный архив zip в локальный диск прежде, чем добавить файлы. То, что происходило, было то, что zip копировала архив в локальный временный файл, внося изменения и затем кладя обратно временный файл к удаленному диску, для каждого файла/папки в высокоуровневом каталоге. Таким образом, теперь это только делает тяжелую сеть, поднимающуюся однажды. Я - вид размышления, что я должен смотреть на tar для такого рода вещи..
localBaseDirectory=/Volumes/Non-RAID_Storage/;
backedUpDirectory=projects;
backupVolume=/Volumes/video-prod/Backup;
backupFile=$backupVolume/Non-RAID_Storage_backup.zip;
zipTempfile=/Volumes/B_media
localBackupTempFile=/Volumes/A_Media/backuptemp.zip;
log=~/backuplog.txt;
temp=/var/tmp/backupError.txt;
##############################################
/usr/local/bin/growlnotify -m "backing up $backedUpDirectory on $localBaseDirectory" 2>&1 >/Dev/Null #need this redirect because growl chucks errors when run by cron;
echo $(date) > $log
if [[ -e $backupVolume ]];
then
if [[ -e $backupFile ]];
then cp $backupFile $localBackupTempFile;
mv $backupFile "$backupFile-old";
echo "copied old backup to $backupFile-old">>$log;
fi;
cd $localBaseDirectory 2>$temp;
if [[ -s $temp ]];
#notify if there was an error cding to this directory. -s is true if the file exists and is not zero sized
then cat $temp | /usr/local/bin/growlnotify -s;
cat $temp >> $log;
fi;
for file in $backedUpDirectory/*;
do
/usr/local/bin/growlnotify -m "backing up $file" 2>&1 >/Dev/Null;
#zip using verbose, recursive, update (ie don't overwrite files unless they're older), highest level compression
#zip creates a lot of garbage errors when being verbose eo send errors to a temp file, and stdout to the log file
nice -n 10 zip -vru9 -b $zipTempfile $localBackupTempFile "$file" 2>$temp |grep "adding:">>$log;
#add just the important errors to the log
cat $temp 2>/dev/null|grep "error:">>$log;
done;
echo "done adding to local zip file - moving to $backupFile">>$log;
#move the local version to the remote backup file
mv $localBackupTempFile $backupFile 2>>$log;
echo "$(date) - backed up Non-RAID_storage">>$log
/usr/local/bin/growlnotify -m "backed up $backedUpDirectory on $localBaseDirectory" 2>&1 >/Dev/Null;
else
/usr/local/bin/growlnotify -s -m "Backup volume not mounted" 2>&1 >/Dev/Null;
echo "backup volume not mounted" >> $log;
fi;