Rsync висит на файлах с клиента на сетевой сервер NAS через SSH

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

Я пробовал различные исправления, но до сих пор никто не работал. Первоначально я думал, что это происходит из-за некоторых проблем с символами между моей локальной системой (OS X 10.11.3 с OS Extended FS и моим NAS под управлением Ubuntu Linux 14.04.1 с диском ext4 для резервного копирования). Я заметил, что когда rsync застревает в файле, в котором он обычно находится, имя файла или путь обычно имеют '& amp;' в нем 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" / user@192.168.0.21:/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 высасывает много ЦП и памяти.

— juliushibert
источник

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

— Mitch Lindgren

@MitchLindgren Я не нашел решения этой проблемы. В конце концов я перешел на другую систему резервного копирования. Я подозреваю, что проблема могла заключаться в том, что некоторые вещи работали против моей настройки. Т.е. недопустимые символы в именах файлов. Низкое энергопотребление процессора и шины ввода-вывода на устройстве резервного копирования. И я копировал из локальной файловой системы HFS + в удаленную файловую систему ext3. Я надеюсь, что вы сможете найти работоспособное решение.

— juliushibert

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

Что касается Amazon Glacier, да, вы можете использовать это. Duplicity поддерживает S3 в качестве места назначения резервного копирования, а правила жизненного цикла S3 позволяют автоматически перемещать файлы в Glacier (настраивается через веб-консоль S3). Вам необходимо хранить файлы подписи и манифеста в S3 (иначе двуличие не сможет их извлечь), но файлы томов нужны только в том случае, если вам нужно извлечь файлы резервных копий, чтобы их можно было безопасно хранить в Glacier. Правила жизненного цикла требуют известного префикса, который не является поведением двойственности по умолчанию, поэтому обязательно проверьте настройки параметров.

— ams
источник