1

Я использую 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" / 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 высасывает много ЦП и памяти.

1 ответ1

0

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

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

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