私は rsync を使用して、SSH 経由でローカル ネットワーク上の NAS にバックアップしています。しかし、rsync を実行すると、特定のファイルで停止してしまうことがわかりました。rsync は完全にフリーズし、それ以上のファイルの転送を拒否します。その後、SIGKILL を強制的に実行する必要があります。これにより、rsync ジョブ全体が再起動され、前回実行したときに停止したのと同じファイルで停止してしまいます。
さまざまな修正方法を試しましたが、今のところどれもうまくいきません。当初は、ローカル システム (OS Extended FS を搭載した OS X 10.11.3 と、バックアップ用の ext4 ドライブを搭載した Ubuntu Linux 14.04.1 を実行している NAS) 間の不正な文字の問題が原因で発生していると考えていました。rsync がファイルで停止する場合、通常はファイル名またはパスに 9/10 回「&」が含まれていることに気付きました。
lsofしかし、サーバーとサーバー上のrsync プロセスを見ると、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 は CPU とメモリを大量に消費するため、Crashplan を捨てて Amazon Glacier にバックアップ サービスとして切り替えるべきかどうか疑問に思っています。
答え1
rsync がハングする原因はわかりません。そのディレクトリ ツリー全体に通常のコピーを実行して、なんらかの I/O エラーが発生していないかどうかを確認してください。ファイル システム チェックを実行するのも悪くありません。
Amazon Glacier については、はい、使用できます。Duplicity はバックアップ先として S3 をサポートしており、S3 のライフサイクル ルールを使用すると、ファイルを Glacier に自動的に移動できます (S3 Web コンソールで設定)。署名ファイルとマニフェスト ファイルは S3 に保存する必要があります (そうしないと、Duplicity はそれらを取得できません)。ただし、ボリューム ファイルは、バックアップされたファイルを抽出する必要がある場合にのみ必要であり、Glacier に安全に保存できます。ライフサイクル ルールには既知のプレフィックスが必要ですが、これは Duplicity のデフォルトの動作ではないため、パラメーター設定を確認してください。