Я использую rsync для резервного копирования на NAS в моей локальной сети через SSH. Однако при запуске rsync я обнаруживаю, что он зависает на определенных файлах. Rsync полностью зависает и отказывается передавать какие-либо дальнейшие файлы. Затем мне приходится принудительно подавать SIGKILL, что приводит к перезапуску всего задания rsync и зависанию на том же файле, который вызвал его зависание в прошлый раз, когда я его запускал.
Я пробовал разные исправления, но пока ни одно не сработало. Сначала я думал, что это происходит из-за какой-то проблемы с недопустимыми символами между моей локальной системой (OS X 10.11.3 с OS Extended FS и моим NAS под управлением Ubuntu Linux 14.04.1 с диском ext4 для резервного копирования). Я заметил, что когда rsync застревает на файле, который у него обычно есть, имя файла или путь обычно содержат '&' в 9/10 случаях.
Однако после наблюдения за процессами rsync с сервером lsofи htopна нем, похоже, что rsync (в большинстве случаев, но не всегда) падает примерно в тот же момент, когда зависает файл rsync с клиента. Я заметил, что даже когда rsync зависает на стороне клиента, я все равно получаю вывод, показывающий, lsofчто файлы на стороне сервера доступны.
Это команда rsync, которую я использую.
/usr/bin/rsync --bwlimit=1000 --verbose --rsync-path="sudo rsync" --archive --recursive --numeric-ids --human-readable --partial --progress --relative --itemize-changes --stats --files-from=/Users/user/Dropbox/Flex/Scripts/mac/rysnc-backup-to-cp/config/backup_files --exclude-from=/Users/user/Dropbox/Flex/Scripts/mac/rysnc-backup-to-cp/config/exclude -e "ssh -q -p 22 -i /Users/enwhat/.ssh/user" / [email protected]:/media/Backup/_Backup/Machine/
Пример того, где rsync обычно зависает:
<f+++++++ Volumes/Data/Users/user1/Pictures/2013_12_iPhone_Archive/IMG_6993.m4v 17.33M 63% 994.25kB/s 0:00:10
или
<f+++++++ Volumes/Data/Users/user1/Documents/docs/Work/_Sort from USB backup drive/Drive/JOB/CD Album/AAA1834__Album&flyer_15_Years/2-Design/1-D-Visuals/stage 05/AAA_album_12_c.psd 96.40M 50% 1.55MB/s 0:01:00
Я пробовал удалять --verbose --rsync-path="sudo rsync” --delete-duringвсе по отдельности. Когда я удаляю эти флаги аргументов, процесс rsync добирается до указанного файла и зависает.
Есть ли здесь что-то еще или вполне вероятно, что недопустимый символ в имени файла вызывает проблему между типами FS?
Я думал, что Crashplan, работающий на сервере, мог потреблять слишком много ресурсов и вызывать сбой rsync. Но когда я останавливаю службу CrashPlan на сервере, ресурсы освобождаются, но rsync все равно падает на тех же файлах. Это примечание и выходит за рамки вопроса, но я задаюсь вопросом, стоит ли мне отказаться от Crashplan и перейти на Amazon Glacier в качестве резервного сервиса, поскольку Crashplan поглощает много ресурсов ЦП и памяти.
решение1
Я не знаю, почему rsync может зависать. Вы можете попробовать запустить обычную копию по этому дереву каталогов и посмотреть, нет ли у вас какой-либо ошибки ввода-вывода. Запуск проверки файловой системы был бы неплохой идеей.
Что касается Amazon Glacier, да, вы можете использовать его. Duplicity поддерживает S3 в качестве места назначения резервных копий, а правила жизненного цикла S3 позволяют автоматически перемещать файлы в Glacier (настраивается через веб-консоль S3). Вам необходимо сохранить файлы подписи и манифеста в S3 (иначе Duplicity не сможет их извлечь), но файлы тома нужны только в том случае, если вам нужно извлечь файлы резервных копий, чтобы их можно было безопасно сохранить в Glacier. Правила жизненного цикла требуют известного префикса, что не является поведением Duplicity по умолчанию, поэтому обязательно проверьте настройки параметров.