ファイル同期ツール(rsync)エラー解析：差分転送時に失われたブロック回収

【注意】 rsync の差分転送で「欠けたブロック（欠損したように見える部分）」が疑われる場合、自己判断で上書き同期や再試行を繰り返すと、元データまで巻き込んで状況が悪化することがあります。まずは現状の保全（書き込み停止・退避・検証）を優先し、復旧可否や整合性要件（監査・契約・業務影響）を含めて、株式会社情報工学研究所のような専門事業者へ相談してください。

冒頭30秒：欠損の拡大を「被害最小化」する初動と、今すぐ相談すべき判断基準

「rsync で差分転送しただけなのに、ファイルの一部が欠けたっぽい」「再実行すれば直るはず…でも怖い」。現場だと、まずこういうモヤモヤが来ます。
そして、ここでの最優先は“原因究明”よりも欠損の拡大を防ぐ（被害最小化）です。rsync の再実行は“回復の手段”にもなりますが、条件を誤ると正しい元データを上書きして確定的な損失にもなりえます。

まず、状況別に「取るべき行動」を先に置きます。迷ったらこの表に戻ってください。

“安全な初動”だけは、ここから先に進む前にやってください

ここでのゴールは「復旧作業を自力で完走する」ではなく、回収可能性と整合性を落とさずに次の判断へ進むことです。

• 書き込み停止：同期先・同期元ともに、当該ファイルへの更新を止めます（アプリ、バッチ、Cron、CIなど）。
• 退避：同期先の“壊れたかもしれないファイル”を別名にコピーして保全します（上書き禁止）。
• 最小検証：元（同期元）が確実に正であるか、サイズ・更新時刻・ハッシュで確認します。

心の会話としては、たぶんこうです。
「またログか…。今すぐ直したいのに、手が止まるのが一番つらい」
ただ、この“手を止める数分”が、のちの回収可能性を大きく左右します。

「今すぐ相談」を推奨する条件（一般論の限界が来るライン）

• 同期元・同期先のどちらが“正”か確信が持てない
• --inplace を使っていた／使った可能性がある（上書き更新により元の状態が失われる）
• I/Oエラー、異音、SMART異常、RAID劣化などストレージ側の不調が疑われる
• 法務・監査・顧客契約で「完全一致の証明」や「証跡提出」が必要

このラインを超えると、一般的な手順の紹介だけでは責任ある判断ができません。具体的な案件・契約・システム構成（NAS/RAID/クラウド、暗号化有無、バックアップ世代、復旧許容RPO/RTO）に依存するため、株式会社情報工学研究所への相談を検討してください。

相談導線：https://jouhou.main.jp/?page_id=26983
電話：0120-838-831

「差分転送なのに欠ける」理由：rsyncの前提が崩れると、整合性は簡単に揺らぐ

まず事実として、rsync は「ネットワークが不安定でも勝手に整合性を保証してくれる魔法」ではありません。rsync が得意なのは、“前提が満たされている限り”差分を効率良く運ぶことです。欠損（欠けたブロック）が疑われるときは、この前提がどこかで崩れています。

rsyncの差分転送は、こう動く（誤解しやすいポイントだけ）

rsync は一般に、受信側（同期先）にある既存ファイルを一定サイズのブロックに分け、各ブロックのチェックサム情報を送信側（同期元）へ渡します。送信側は送信元ファイルを走査して、受信側に既にあるブロックと一致する部分を見つけ、一致部分は「参照（トークン）」、一致しない部分は「生データ」として送ります。この仕組み自体はよく出来ていますが、次の条件が崩れると「一致判定」や「再開」が期待どおりに動きません。

欠損が疑われる典型パターン（脚色なしの“起こり方”）

• 転送中にファイルが更新された
  同期元が生成中・追記中（ログ、DBダンプ、動画、VMイメージ等）の状態で rsync すると、rsync が見ている「読み取り時点」と「転送完了時点」で内容が変わりえます。結果として、受信側のファイルが“部分的に古い/新しい混在”になり、欠けたように見えることがあります。
• --inplace により受信側ファイルを直接書き換えた
  通常 rsync は一時ファイルに書いてからリネームするため、失敗しても受信側の既存ファイルが保持されやすい設計です。ところが --inplace は受信側を直接更新します。中断・断線・容量枯渇が起きると、受信側のファイルが中途半端な状態で確定し、しかも“元に戻す材料”が減ります。
• 部分転送（--partial）と再開が、想定外の状態で残った
  --partial は中断時の途中ファイルを残して再開しやすくしますが、途中ファイルが「正しい途中状態」だという前提があります。ディスクフル、I/Oエラー、別プロセスによる更新、バックアップソフトの干渉などがあると、途中ファイルが壊れたまま残り、再開が“回復”ではなく“破損の上塗り”になりえます。
• 圧縮・暗号化・コンテナ化で「少しの差分」が「全体差分」になる
  gzip や暗号化済みファイル、データベースの圧縮バックアップなどは、先頭付近の小さな変化が全体に波及して、差分一致がほぼ取れなくなることがあります。これはrsyncの欠陥ではなく、データ形式の性質です。差分一致が取れないと転送量が増え、断線やディスクフルのリスクが上がり、結果として欠損が疑われやすくなります。

「欠損」に見えるが、実は“表示側の問題”のこともある

実際にはデータは揃っているのに、アプリがキャッシュやインデックスの不整合で「欠けて見せる」ケースもあります（例：メディアライブラリのDB、検索インデックス、サムネイル等）。この可能性を切るためにも、次章で述べるハッシュやチェックサムでの“事実確認”が必要になります。

ここまでの要点はシンプルです。
「rsync が悪い」ではなく、rsync が前提にしている“静的な入力”と“健全な出力先”が崩れると、整合性が揺らぐ。この現実を踏まえると、次にやるべきは“再実行”ではなく、どこが崩れたかをログと検証で特定することです。

ログがないと回収は難しい：差分の“失われ方”を特定する検証設計（dry-runとチェックサム）

欠損回収で一番つらいのは、「いま何が起きているのか」を推測で埋め始めた瞬間です。推測が入ると、次の一手（再同期・上書き・削除）が高確率で危険になります。ここでは“事実として確認できる”手順だけを書きます。

最初に確保するもの（これがないと後で詰む）

• rsync の実行コマンド（オプション含む）
• 終了コード（0以外なら要注意）と標準出力・標準エラー
• 可能なら rsync のログ（--log-file）、転送統計（--stats）
• 同期対象ファイルのサイズ・更新時刻（同期元/同期先）

心の会話で言うと、こういう抵抗が出ます。
「ログなんて取ってない…今さら何が分かるの？」
ただ、rsync は“何を更新したか”を出す機能が充実しています。次の dry-run で、かなりの事実が取れます。

安全な第一手：dry-runで“上書きの量”を可視化する

実データを変えずに差分を確認するなら、まず dry-run です。特に --itemize-changes は、変更内容を記号で表します。

rsync -a -n --itemize-changes --stats /src/ /dst/ # -n は --dry-run（実際には書き込まない） # -a は代表例（実環境の要件に合わせて調整） 

ここでのポイントは「差分が大量に出ていないか」です。欠損が疑われる1ファイルだけの問題に見えて、実はディレクトリ全体で整合が崩れていることもあります。大量の差分が出る場合、拙速な再同期は避け、まず“どの条件で崩れたか”を疑うべきです。

事実確認の要：チェックサムで「本当に欠けているか」を確定させる

表示上の不具合やアプリ側キャッシュの問題を切るには、ハッシュ（例：SHA-256）で一致/不一致を確定します。巨大ファイルでは計算コストが上がるため、優先度を付けます。

• 最優先：業務影響が大きいファイル（DBダンプ、顧客成果物、設定、鍵/証明書を除く機密）
• 次点：欠損が疑われるファイル（サイズ不一致、更新時刻不自然、アプリで開けない）

rsync 自体でも、チェックサム比較（-c / --checksum）で“内容”基準の差分判定ができます。ただし -c は全ファイル読み取りになるため負荷が高く、運用中のストレージでは注意が必要です。

rsync -a -n -c --itemize-changes /src/ /dst/ # -c はサイズ・時刻ではなく内容チェックサムで比較（負荷大） 

この段階で「本当に欠けている（内容が一致しない）」が確定したら、次に考えるのは“回収ルート”です。再実行で回収できるのか、それとも退避データやスナップショットから戻すべきか。ここを誤ると、一般論では取り返しがつかなくなります。

回収の前にやってはいけない行動（一般論として危険度が高い）

• 原因が不明なままの --delete 付き同期（消えていい保証がない）
• 欠損が疑われる同期先を“正”とみなして同期元へ戻す（逆流）
• --inplace のまま何度も再実行（中途状態が積み重なる）

ここまでで“事実”が揃ってきますが、次の章以降は失われたブロックをどう回収するか（--partial/--partial-dir、--append-verify、再取得、スナップショット、部分抽出、検証ログの残し方）に入ります。個別のシステム構成（NAS/RAID/クラウド、帯域、暗号化、ファイル形式、運用停止可否）で最適解が変わるため、終盤では「一般論の限界」と「専門家に相談すべきライン」をさらに明確化します。

伏線：--inplace / --partial / --append-verify を“回収”の味方にする条件、敵にする条件

ここから先は「欠けたブロックを回収できるか」を現実的に判断する章です。結論から言うと、rsync のオプションは“便利”というより前提条件を明示するための契約です。契約（前提）が合っていないと、回収のつもりが破壊になります。

--inplace：速いが、回収余地を削る

--inplace は、受信側（同期先）の既存ファイルを直接書き換えます。巨大ファイルで一時領域が取れないときや、追記型の運用で使われることがありますが、欠損疑いの局面ではリスクが高いです。

• 味方になる条件：受信側ファイルが確実に「捨ててもよい複製」で、かつ中断が起きない（帯域・容量・I/Oが安定）。
• 敵になる条件：中断・容量不足・I/Oエラーが起きる可能性がある／受信側ファイルが唯一のコピーに近い／監査要件がある。

なぜ危ないか。rsync の通常動作（非 --inplace）は、一時ファイル（転送中ファイル）を作り、最後にリネームで置き換えるため、途中失敗でも“元の受信ファイル”が残る余地があります。一方 --inplace は途中で止まると、受信ファイル自体が中途半端な状態で残ります。欠損に見える状態がそのまま固定されるため、後から「どこまでが正しかったか」を追う材料が減ります。

--partial / --partial-dir：中断に強いが、残骸管理が必須

--partial は、転送が途中で止まっても途中ファイルを残し、再開時に続きから進めやすくします。大容量ファイルや不安定回線で有効ですが、前提は「途中ファイルが正しい途中状態であること」です。ディスクフルやI/Oエラーが絡むと“正しい途中状態”ではなくなります。

運用上は --partial-dir を使い、途中ファイルを専用ディレクトリに隔離するのが安全側です。これにより、同期先の“本番ファイル”が汚れにくく、途中ファイルの扱い（保全・削除・再開）が明確になります。

rsync -a --partial --partial-dir=.rsync-partial --info=progress2 /src/ /dst/ 

• 味方になる条件：途中ファイル用ディレクトリが安定（容量・I/O）し、同期先の本番ファイルと分離できる。
• 敵になる条件：途中ファイルが本番ファイルと同じ場所に混ざり、運用者が「何が本番か」判断しにくい。

--append-verify：追記型ファイルの回収に強いが、前半が“同一”である必要がある

--append-verify は、受信側に既にあるファイルの先頭部分を「既存として使い」、不足分を追加しつつ、既存部分も検証します。ログやバックアップの追記型運用などで有効です。ただし、受信側の先頭部分が既に壊れている／途中で穴がある場合、期待どおりには回収できません。

rsync -a --append-verify /src/big.log /dst/big.log 

ここでの現実的な判断はこうです。

• 追記型で、受信側の先頭が正しい可能性が高い → append-verify を検討
• 受信側の先頭も疑わしい／途中穴がある → 一旦退避して作り直す方が安全

「どれを使うべきか」を決めるための整理表

この章のまとめは一つです。
「回収したい」なら、オプションは“速度”より保全と再現性を優先して選びます。次章では、欠損が疑われるファイルを“これ以上壊さない”ために、スナップショットや退避、検証の順番を確定させます。

回収の前提：コピーではなく“証拠”として保全する（スナップショット／退避／検証の順番）

欠損回収の現場で起きがちな失敗は、「正しいものを作り直す」つもりで正しいものを消すことです。これは技術力というより、時間圧と心理の問題です。だから順番を固定します。ここは脚色できません。順番を守るほど回収率が上がります。

保全の基本手順（順番が重要）

1. 書き込み停止：同期ジョブ、アプリ、バックアップ、ウイルス対策のスキャンなど、対象に触れるものを止める。
2. 同期先の退避：欠損が疑われるファイルを別名コピーし、以後そのコピーを検証対象にする（本番に触らない）。
3. 可能ならスナップショット：ZFS/Btrfs/LVM、NASのスナップショット機能があるなら、現状態を固定する。
4. 同期元の正当性確認：同期元が本当に“正”か、更新中ではないか、ハッシュ・アプリ整合性で確認する。
5. 検証ログの確保：いつ、誰が、どのコマンドで、何を確認したかを残す（監査・説明責任に直結）。

心の会話としてはこうなります。
「スナップショットなんて今さら…」「退避してる間に復旧できたのに」
でも、ここでの退避とスナップショットは、“戻れる場所”を作る行為です。戻れない状態での試行錯誤は、一般に危険です。

スナップショットが無い環境での“代替”

スナップショット機能が無い場合でも、代替はあります。ただし作業コストが上がるため、業務影響と相談して決めます。

• 対象ディレクトリを別ボリュームへコピー（容量が許せば最も単純）
• 重要ファイルだけを優先退避（全体は無理でも“要”だけ固定する）
• クラウドの場合はバージョニング（S3等）やスナップショット相当機能の有無を確認

ここで重要なのは「どのレベルで整合性が必要か」です。ファイル単体の整合性で足りるのか、ディレクトリ全体の整合性が必要なのか、アプリのトランザクション整合性が必要なのか。これは一般論では決められません。システム構成と業務要件で変わります。

依頼判断：一般論の限界が見えるポイント

• NAS/RAID が絡み、冗長性劣化やディスクエラーが疑われる
• クラスタ・分散FS・オブジェクトストレージなど、整合性が多層
• 監査・契約で「いつの時点の整合か」を説明する必要がある

ここに当てはまるなら、欠損回収は“rsyncの話”を超えます。具体的な案件・契約・システム構成に踏み込んで判断する必要があるため、株式会社情報工学研究所への相談を検討してください。
相談導線：https://jouhou.main.jp/?page_id=26983 ／ 電話：0120-838-831

次章では、いよいよ「失われたブロック」を現実的に回収するための手順（rsyncの再取得、部分抽出、検証）に入ります。ここからは“何を正として、どこから取り直すか”が主題です。

具体手順：欠けたブロックを回収する3ルート（再取得／スナップショット復元／部分抽出）

「欠けたブロックを回収」と言っても、実務上のルートは大きく3つです。どれが最適かは、同期元が健全か、スナップショットがあるか、業務停止が可能かで決まります。ここでは“事実確認に基づいて選ぶ”ための手順にします。

ルートA：同期元が正 → rsyncで安全に再取得する（上書きしない）

同期元が正で、欠損が同期先のみの問題なら、原理的には再取得で直せます。ただし、いきなり本番ファイルを上書きしないのが基本です。まず“別名”に取得して照合します。

# 例：欠損が疑われる1ファイルを別名に取得（上書き回避の発想） rsync -a --progress /src/path/file.bin /dst/path/file.bin.recovered 

取得後にハッシュで一致を確認し、問題なければ切り替えます。これなら「途中でまた失敗した」場合でも、元の（欠損疑い）ファイルを保持できます。

ルートB：スナップショットがある → 欠損前の時点へ戻す（最短で確実）

スナップショットがある環境では、欠損回収は“rsyncで頑張る”より、欠損前時点へ戻すのが最短で確実なことが多いです。ただし、戻す範囲（単一ファイル／ディレクトリ／ボリューム）と、戻した後の再同期設計が必要です。

• 戻す前に、現在状態を別スナップショットで固定（戻しの戻し）
• 戻した後、rsync のオプションを見直して再発防止（後章）

スナップショット復元は、環境によって操作が異なります。ここも一般論の限界があり、NASベンダ・FS設計・運用要件で判断が変わります。

ルートC：同期元が完全には信用できない／部分だけ回収したい → 部分抽出と比較で詰める

同期元も更新中だった可能性がある、あるいは同期先で一部だけ壊れたかもしれない。こういうときは「どの範囲が一致していて、どこから崩れたか」を確定し、必要最小限の回収を狙います。

実務では、次のような比較が行われます。

• サイズの差分（どれくらい欠けた可能性があるか）
• ハッシュの比較（全体一致／不一致）
• 部分ハッシュ（先頭/末尾/固定オフセットの比較）

ただし、ここから先は対象ファイル形式によって手段が分かれます。例えばDBダンプ、ログ、バイナリ、圧縮ファイルでは「部分抽出しても意味があるか」が違うからです。個別案件のファイル種別と業務要件を踏まえて設計する必要があり、無理に一般化すると誤誘導になります。

ここまでの小まとめ：回収は“最短で確実なルート”を選ぶ

回収は根性論ではありません。
同期元が正なら「別名で再取得→照合」。
スナップショットがあるなら「時点復元」。
どちらも不確実なら「比較して最小範囲に絞る」。
この判断を誤ると、欠損を“確定損失”にしてしまいます。

次章では、欠損が起き続ける背景（ファイル更新、ブロック境界、暗号化/圧縮、ネットワーク）を踏まえて、rsync運用を“回収できる設計”に作り直します。

再発防止の核心：rsyncを「回収できる同期」にする運用設計（更新中ファイル・巨大ファイル・暗号化の扱い）

欠損が疑われるケースの多くは、rsync の機能不足ではなく「入力が静的である」「出力先が健全である」という前提が崩れたことが原因です。再発防止は、オプションの小手先より運用の前提条件を“崩れにくくする”ことが本質になります。現場の感覚としてはこうです。
「結局、rsync を責めても戻らない。じゃあ次に同じ事故を起こさない形にするしかない」

1) まず“更新中ファイル”を同期対象から外す（最重要）

ログ、DBダンプ、VMイメージ、アップロード途中のメディアなど、同期中に内容が変わり得るファイルは、差分一致の前提を壊します。対策は「更新中のまま同期しない」に尽きます。実務では次のように設計します。

• 生成→確定→リネーム：生成は一時名で行い、完了後に確定名へ原子的に切り替える（例：file.tmp → file.bin）。
• ロック/フラグ：生成中を示すフラグファイルを置き、rsync はそれを見て除外する。
• 時間窓：夜間バッチ等、更新が止まる時間帯に同期する（RPO/RTOと要相談）。

2) 巨大ファイルは“方式”を変える（rsync万能論をやめる）

巨大な単一ファイル（数十GB〜TB）では、少しの変更が全体差分になったり、転送中断の影響が大きくなります。ここでの選択肢は「rsyncで頑張る」だけではありません。

ここは一般論の限界が出ます。ファイル形式（圧縮・暗号化・DB）、ストレージ（NAS/RAID/クラウド）、許容停止時間（メンテ窓）で最適解が変わるためです。だからこそ、設計段階で株式会社情報工学研究所のような専門家に相談して“回収できる運用”を先に作る価値があります。

3) 圧縮・暗号化データは「差分一致が期待できない」前提で設計する

暗号化済みファイルや圧縮済みアーカイブは、少しの変更が全体に波及しやすく、rsyncの差分効率が落ちます。効率が落ちると転送が長くなり、中断・ディスクフル・タイムアウトのリスクが上がります。対策は次の方向性になります。

• “固めてから送る”のではなく、固める前の素材を同期し、受信側で固める（可能な運用なら）。
• どうしても固める必要があるなら、世代管理（バージョニング/スナップショット）を厚くして、失敗時に戻れるようにする。

この章の結論は、「rsyncを強くする」ではなく、rsyncが強く働ける前提（静的入力・健全出力・戻れる世代）を作ることです。次章では、その前提を“工程”として固定化し、誰がやっても同じ結論にたどり着けるログ・証跡・検証の仕組みに落とします。

相談導線：https://jouhou.main.jp/?page_id=26983
電話：0120-838-831

“同期”と“検証”を分ける：差分転送の事故を「ノイズカット」する二段階パイプライン（証跡・合否判定・ロールバック）

現場でいちばん苦しいのは、障害が起きたあとに上司や関係部門へ説明するときです。
「たぶん同期は終わってます」では通りません。
「直った気がします」も危険です。
だから、rsync運用を“作業”ではなくパイプラインにして、同期と検証を分離します。これが結果的に事故の温度を下げ、場を整えます。

二段階パイプラインの全体像

1. 同期（転送）：まずは壊さない前提でデータを運ぶ（本番を直接更新しない）
2. 検証（合否判定）：ハッシュ・チェックサム・件数・メタデータで一致を確認し、合格なら切り替える

ポイントは「同期が成功した＝正しい」ではなく、検証に合格した＝正しいへ定義を変えることです。

ステージング方式：本番を直接更新しない

欠損事故の多くは「本番ディレクトリを直接rsyncした」ことから始まります。対策として、同期先にステージング領域（検証用）を用意し、検証に合格したら切り替えます。

• 同期先：/data/live（本番）と /data/stage（検証用）を分ける
• rsync は基本 /data/stage に入れる
• 検証合格後に、切り替え（運用に合わせてリネーム・マウント切替・シンボリックリンク切替など）

これだけで「再実行で本番を上書きして悪化する」確率が大きく下がります。

ログと証跡：rsyncは“出力フォーマット設計”が肝

運用で必要なのは、あとから「何が変わったか」を再現できるログです。代表的には次の出力を揃えます。

• dry-runログ：実行前に差分量を把握する（--dry-run、--itemize-changes）
• 実行ログ：いつ、どこからどこへ、何を転送したか（--log-file など）
• 統計：転送量・速度・ファイル数（--stats）

さらに、障害対応で効くのは「人が読むログ」だけでなく「機械が判定できるログ」です。差分が一定以上なら中断する、終了コードが0以外なら切り替えない、といったガードを入れます。

“合否判定”を作る：一致確認の粒度を決める

検証の強度は、業務要件とコストで決めます。全部を最強にすると運用負荷が跳ね上がるため、段階設計が現実的です。

ここで重要なのは、検証レベルの選択そのものが個別案件（契約・システム構成・業務）に依存する点です。一般論だけで「レベル3にすべき」と言うのは無責任になりがちです。どの粒度で、どの範囲を、どの頻度で検証するかは、現場と経営の折衝も含む設計になります。

“戻せる設計”を仕込む：世代保持と切り替え条件

欠損が疑われたとき、最後に効くのは「戻せる」ことです。スナップショットやバージョニングが理想ですが、最低限でも次を持ちます。

• 切り替えは検証合格後のみ
• 切り替え前の状態を一定期間保持（世代管理）
• 問題が出たら“即ロールバック”できる手順を文書化

この章のまとめは、「rsyncを実行する」ではなく、同期→検証→切り替え→ロールバックまでを一連の仕組みにすることです。これができると、欠損事故のたびに夜間対応が増えるのではなく、むしろ“事故の温度を下げる”方向へ持っていけます。

そして、この仕組み作りは、あなたの環境（NAS/RAID/クラウド、運用停止可否、監査要件、予算）で最適解が変わります。一般論のテンプレだけでは設計しきれないため、具体的に悩んでいる案件があるなら、株式会社情報工学研究所への相談を検討してください。
相談導線：https://jouhou.main.jp/?page_id=26983 ／ 電話：0120-838-831

実務テンプレ：安全側のrsyncコマンド設計（やらない判断を含めた“歯止め”の作り方）

ここまでの話を「明日からの運用」に落とす章です。現場の本音はだいたいこうです。
「理屈は分かった。じゃあ、何をどう実行すれば“欠損の疑い”で夜間に追い込まれないの？」

答えは、rsyncコマンドそのものより、壊しにくい流れ（ステージング、ログ、検証、切り替え、ロールバック）を先に作ることです。ここでは“安全側に倒す”ための代表テンプレを提示します。あなたの環境で最適化する際は、後半の「一般論の限界」に戻ってください。

テンプレ0：まず dry-run（実行前に差分と削除を見える化）

本番を触る前に、差分量と削除対象が想定どおりかを確認します。特に削除を伴う同期は、最初に“見える化”しないと事故の温度が上がります。

rsync -a -n --itemize-changes --stats /src/ /dst/ 

• -n（dry-run）で実書き込みを避ける
• --itemize-changesで何が変わるかを記号で出す
• --statsで規模感（件数・転送量）を把握

テンプレ1：ステージングへ同期（本番を直接更新しない）

欠損疑いの“拡大”を抑え込む最も効く作法は、本番に直接rsyncしないことです。まずステージングへ入れて検証し、合格したら切り替えます。

# 例：/dst_stage に同期（/dst_live は本番） rsync -a --info=progress2 --stats --log-file=/var/log/rsync_job.log \ --partial --partial-dir=.rsync-partial \ /src/ /dst_stage/ 

ここでの狙いは、「失敗しても本番が汚れにくい」ことです。回線断やディスクフルが起きても、ダメージコントロールがしやすくなります。

テンプレ2：削除を伴うときの“歯止め”（削除は最後・遅延・別管理）

「同期元から消えたものは同期先でも消す」は運用上必要なことがあります。ただし、欠損疑い局面で削除を軽率に入れると、回収可能性を落とします。削除の設計は“慎重側”が基本です。

• 最初は削除なしで回し、差分を安定させる
• 削除が必要なら、dry-runで削除対象を確認してから
• 可能なら削除を遅延させ、検証後に確定させる

# 例：削除を伴う場合もまず dry-run で確認 rsync -a -n --delete --itemize-changes --stats /src/ /dst_stage/ 

削除の振る舞いは要件（保持期間、監査、誤削除の許容）で変わります。一般論で「deleteを使え／使うな」と断言するのは危険です。ここは個別案件の判断領域です。

テンプレ3：巨大ファイル・不安定回線の“現実解”（途中ファイル隔離＋再開）

中断が避けられない環境では、途中状態を管理できるようにしておくことが重要です。

rsync -a --info=progress2 --stats \ --partial --partial-dir=.rsync-partial \ /src/ /dst_stage/ 

注意点は1つだけ。途中ファイルが“正しい途中状態”であることが前提です。ディスクフルやI/Oエラーが絡むなら、途中ファイルを鵜呑みにせず、退避・作り直しも視野に入れます。

テンプレ4：検証（合否判定）を“作業”ではなく工程にする

rsyncの終了コードが0でも、それだけで「正しい」とは限りません。だから、同期→検証→切り替えを固定します。検証の強度は、あなたの業務要件で選びます。

そして合格したら切り替えます。切り替え方法（リネーム、リンク切替、マウント切替）は環境次第です。ここは“仕組み”の設計領域なので、一般論だけで決めるのは危険です。

困ったときの“やらない判断”チェック（これがあると空気を落ち着かせられる）

• 同期元が更新中の可能性がある → まず同期対象の作り方（確定→リネーム）を直す
• 同期先ストレージにI/O不安がある → rsyncを回す前にストレージ健全性を優先
• 削除を伴う同期で差分が想定外に大きい → いったん止めて原因特定
• 監査・契約で完全一致の説明が必要 → 検証工程と証跡の設計を先に固める

この章のまとめです。
rsyncの運用は「コマンド」ではなく、止める基準・検証・戻し方まで含めた設計です。次章では、この“設計の限界点”を明確にし、一般論でできる範囲と、個別案件で専門家に相談すべき範囲を自然に切り分けます。

帰結：差分転送は魔法じゃない—「一般論の限界」を越えたら専門家に委ねるのが最短ルート

ここまで読んで、「rsyncの欠損回収」は結局こういう話だった、と腹落ちするポイントがあります。
差分転送は“速く運ぶ技術”であって、“正しさを自動保証する仕組み”ではない。
だから、欠損の疑いが出た瞬間に必要なのは、根性で再実行することではなく、被害最小化（拡大抑え込み）→事実確認→回収ルート選択→再発防止設計の順番です。

「一般論」で言えるのは、ここまで

本記事で提示したのは、以下の“どの環境でも概ね成立しやすい”原則です。

• 欠損の疑いが出たら、まず書き込み停止と退避で“戻れる状態”を作る
• dry-runやログで差分を見える化し、推測で動かない
• 本番を直接更新せず、ステージング→検証→切り替えに寄せる
• 巨大ファイル・更新中ファイル・暗号化/圧縮は、差分一致の前提が崩れやすいと理解して設計する

「一般論の限界」が来る場所（ここから先は個別案件）

一方で、次の領域に入ると“正しい答え”は環境・契約・業務要件で変わります。ここを一般論で断言すると、誤った誘導になり得ます。

• NAS/RAID/分散FS/クラウドなど多層ストレージで、整合性の責任範囲が複雑
• 監査・契約で「どの時点の整合か」「証跡は何か」を説明する必要がある
• アプリ整合性（DB、インデックス、トランザクション）まで含めて“正”を定義しないといけない
• 業務停止が難しく、RPO/RTOと現実コストの折り合いを付ける必要がある

この領域では、rsyncの知識だけでは不十分です。システム構成、運用、契約、監査、復旧優先順位まで含めて判断しなければなりません。
だから、読者が具体的な案件・契約・システム構成で悩んだとき、最短ルートになりやすいのは、株式会社情報工学研究所のような専門家に相談し、前提整理と回収方針を一緒に固めることです。

「また新しい相談先増やすの、正直しんどい」—そう感じるのは自然です。
でも、欠損回収は“判断を誤ると取り返しがつかない”性質があります。一般論で粘って時間を失うより、早い段階で状況を棚卸しし、壊さず回収できる手順に乗せる方が、結果的に運用負荷も説明コストも下がります。

相談導線：https://jouhou.main.jp/?page_id=26983
電話：0120-838-831

この後、付録として「現在のプログラム言語各種」で、ファイル生成・同期・検証を実装する際に起きがちな落とし穴（原子的更新、fsync、部分書き込み、ハッシュ、例外処理）を整理します。rsync運用を支える周辺実装の品質が、結局“欠損の疑い”の発生率を左右するためです。

付録：現在のプログラム言語各種で“欠損疑い”を生みにくくする注意点（原子的更新・fsync・検証）

ここは「rsync以前」の話です。同期対象ファイルの作り方や、検証の実装が雑だと、差分転送は簡単に前提を失います。特に重要なのは次の3点です。

• 原子的更新：生成中ファイルを直接本番名で書かず、完了後にリネームで切り替える
• 永続化の保証：必要なら flush / fsync（ファイルだけでなくディレクトリも）を意識する
• 検証可能性：ハッシュ、サイズ、件数、ログで“事実確認”できる材料を残す

C / C++

• 部分書き込み（writeが全量を書かない）を前提にリトライループを組む
• 原子的更新は「一時ファイルへ書く→fsync→rename」。必要に応じてディレクトリもfsync
• バッファリング（stdio）を使う場合は fflush と fsync の役割を分けて理解する

Go

• 原子的更新は「一時ファイル→Sync→Close→Rename」。同一ファイルシステム内のRenameが前提
• ファイルだけでなくディレクトリの同期（fsync相当）を検討する（要件次第）
• 巨大ファイル処理では、エラー伝播と途中状態（中断時の後始末）を明確にする

Python

• 書き込み後は flush と os.fsync を区別して使う（必要な要件のときだけfsync）
• 一時ファイル利用（tempfile等）→最後に os.replace（原子的置換）で切り替える
• ハッシュ計算はストリーム処理で（巨大ファイルを丸ごとメモリに載せない）

Java / JVM系（Kotlin含む）

• FileOutputStream/BufferedOutputStream のflushと、永続化（FileChannel.force）の違いを意識する
• 原子的更新は「一時ファイル→close→Files.move（ATOMIC_MOVE可能なら）」
• 例外時に一時ファイルが残る前提で、清掃方針（残す/消す）を運用に合わせる

JavaScript / Node.js

• fs.writeFile は内部で置換するわけではないため、原子的更新が必要なら一時ファイル→renameを明示する
• 非同期I/Oの失敗（例外/Promise拒否）を握りつぶすと、欠損や途中状態の温床になる
• ストリーム処理（createReadStream/createWriteStream）はerror/closeの取り扱いを厳密にする

Rust

• write_all を使って部分書き込みを吸収しつつ、sync_all/sync_data（要件次第）で永続化を意識する
• 一時ファイル→rename の原則を守り、失敗時に一時ファイルが残る設計に備える
• Resultの伝播を徹底し、途中で落ちたときに“壊れた出力”が本番にならないようにする

.NET（C# / F#）

• FileStream の Flush(true) 等、永続化の意味を理解して使う（要件があるときだけ）
• 原子的更新は一時ファイル→置換（プラットフォーム依存の差を考慮）
• 例外時の後始末（ファイルハンドル解放、部分ファイルの扱い）を明確にする

PHP

• file_put_contents の LOCK_EX は万能ではない。原子的更新が必要なら一時ファイル→renameを検討
• エラー抑制（@）で失敗を隠すと、欠損や途中ファイルを見逃す
• 巨大ファイル処理はメモリ制限とストリームI/Oを前提にする

Ruby

• 一時ファイル→renameの原則。例外時に一時ファイルが残る運用も想定する
• IOのflushと永続化（fsync相当）の必要性を要件で判断する

Shell（bash等）

• set -euo pipefail で失敗を早期に検知し、途中状態で“成功扱い”しない
• コマンドの終了コードとログを残す（rsyncは特に重要）
• 削除を伴う処理は dry-run や対象列挙で事前確認を必須にする

PowerShell

• $ErrorActionPreference や -ErrorAction Stop を活用し、失敗を“成功”として流さない
• ログ出力（Transcript等）で証跡を残し、差分や削除の事前確認を組み込む

付録の結論はシンプルです。
同期の事故は、rsync単体ではなく「ファイルの作り方」「失敗の扱い」「検証の仕組み」で発生率が大きく変わります。
そして、ここもまた一般論だけでは最適化しきれません。業務要件（停止可否、監査、契約、RPO/RTO）とシステム構成（NAS/RAID/クラウド/暗号化）を踏まえ、どこまで強い整合性を求めるかを設計する必要があります。

具体的な案件・契約・システム構成で悩んでいるなら、株式会社情報工学研究所への相談・依頼を検討してください。
相談導線：https://jouhou.main.jp/?page_id=26983 ／ 電話：0120-838-831