☰

毎日のバックアップ中にrsyncでIOエラーが発生しました

tag-icon • tag-icon rsync linux-kernel
毎日のバックアップ中にrsyncでIOエラーが発生しました

私はサンプルの NAS サーバー (QNAP TS-210) を持っていますが、Linux は非常に限定的にオンボードされています (ただし、Optware/IPKG で少し強化されています)。私は Linux 初心者です。インターネットで調べた結果、NAS ハード ドライブと外部 USB ドライブ間でファイルを同期するために rsync を使用し、このスクリプトを定期的に実行するために CRON を使用する独自のバックアップ スクリプトを作成することができました。

数日前まではすべて順調でした。バックアップ スクリプトによって生成された電子メールに、バックアップされている多数のリソース (フォルダー) に関する情報が含まれるようになりました。まったく同じスクリプトを SSH 経由で実行すると、「 」に続いて「 」IO error encountered -- skipping file deletionというエラー行が多数表示されました。cannot send file with empty name in...rsync error: some files/attrs were not transferred (see previous errors)

私がバックアップしているコンテンツの 100% は Windows からのものです (NAS は自分のコンピューターのバックアップにのみ使用しています)。このシステムでは、空の名前のファイルを作成できません。この問題は数日間だけ発生しており、数週間以上 (休暇中) バックアップを変更していませんでした。したがって、これは Linux (NAS に搭載) の問題であるに違いありません。

質問は、空の名前のファイルが表示される原因は何でしょうか? どうすればそれらを取り除くことができますか ( cdrsync レポートに記載されているフォルダーに移動して を実行するとls -ls、「空の名前のファイル」のようなものは表示されません)。そうすれば、次の rsync パスではそのようなエラーは発生しません。最後に、今後そのようなファイルが表示されないようにするにはどうすればよいでしょうか?

答え1

これはrsyncのせいではないと思います。関連するコードがrsyncのflist.cソースから読みます:

1729         for (errno = 0, di = readdir(d); di; errno = 0, di = readdir(d)) {
1730                 unsigned name_len;
1731                 char *dname = d_name(di);
...
1746                 if (dname[0] == '\0') {
1747                         io_error |= IOERR_GENERAL;
1748                         rprintf(FERROR_XFER,
1749                                 "cannot send file with empty name in %s\n",
1750                                 full_fname(fbuf));

実際、そのコード行はrsync開発者によって追加されたものです2007年8月にこの場合に特に言えることは：

If readdir() gives us an empty name, reject it.

言い換えれば、readdir()カーネル関数自体（ディレクトリ内のファイルのリストを返す関数）が空の文字列を含むエントリを返したということです。ルール上、このようなことは決して起こらないはずです。オープングループ仕様:

The readdir() function shall not return directory entries containing empty names.

それは何らかの一時的な問題だったようです。なぜなら、lsそのディレクトリで を実行した時点では問題はなくなっていたからです ( も使用されていたはずですがreaddir()、問題はなくなっていました)。

あなたの質問に対する答えは次のとおりです:

  1. 原因はファイルシステムの破損のようです。カーネル ドライバーのバグからハードウェア障害まで、あらゆる原因が考えられます。rsync しているディレクトリがシンボリックリンク経由でアクセスされているか、またはネットワーク境界を越えていて問題が発生しているかどうかも確認する価値があるかもしれません。

  2. これらを取り除くには、通常のファイルシステム修復チェックリスト（fsck など）を実行します。

  3. 今後これを回避するには、スクリプトに事前に再帰リストを強制するように指示できると思いますが、すでに注目されているので (休暇から戻ったので)、監視し、再度発生した場合はボックスにアクセスするのが正しい対応のようです。

これが役に立つことを願っています。頑張ってください!

関連情報