サーバー移行や再配置の直後、昨日まで普通に開けていた成果物が突然開かなくなった――そんな“最悪の朝”を最短でリカバリするための実践記事です。Azure・Hyper‑V・VMware いずれの環境でも使える「まず止める」「安全に複製してから直す」「戻せる設計にする」を軸に、現場で役立つ手順・コマンド・チェックリストをまとめました。
目次
Windows Server 再割り当て後に発生したファイル破損｜事象の背景
再割り当て（再配置／移行／ディスク再接続）直後に、作業中に生成・変換していたドキュメントやバイナリが壊れて開けなくなるケースがあります。今回の想定は次のとおりです。
- VM 内で ChatGPT‑4 を用いて翻訳・リライトを自動処理していたところ、完了直後に対象ファイルが開けなくなった。
- API 利用料金はすでに発生。丸一日分の成果を可能な限り復旧したい。
先に結論：最初の 10 分でやるべきこと
- 直ちにディスクへの書き込みを止める（対象ボリュームでの新規保存・移動・巨大なログ出力を停止）。
- 現在状態のスナップショット／クローンを取得し、解析・復元は必ず複製側で実施する。
- VSS（以前のバージョン）を即確認。該当時点が見つかればコピーで救出し、原本は触らない。
この 3 ステップだけで、復旧確率と復旧後の整合性が大きく変わります。
スナップショット／クローン取得の実践手順
Azure（管理ディスク）
- 対象 VM を割り当て解除（停止・割り当て解除）。
- ディスク ブレードからスナップショットを作成。
- スナップショットから新規ディスクを作成し、一時 VM にアタッチ。
- 一時 VM 側で対象ボリュームを読み取り専用でマウントし、調査・復旧を実施。
Azure CLI の例（概念）
az snapshot create -g <rg> -n snap-yyyymmdd --source <disk-id>
az disk create -g <rg> -n disk-from-snap --source snap-yyyymmdd
az vm disk attach -g <rg> --vm-name rescue-vm --name disk-from-snap --new
Hyper‑V（オンプレ／IaaS）
- 対象 VM を停止。
- VHD(X) をファイルコピーでバックアップ、またはチェックポイント（Production）を取得。
- 別の検証用 VM に VHD(X) を追加ディスクとして接続して調査。
VMware vSphere
- 対象 VM のパワーオフ、もしくは静止点を確保。
- 仮想ディスクのスナップショットを作成（必要ならメモリを含めない）。
- 仮想ディスクを別 VM にマウント（Hot‑Add）し、読み取り中心で調査。
VSS（以前のバージョン）で戻せるかを最優先チェック
Windows Server では、ボリューム シャドウ コピー（VSS）が有効なら自動的に復元ポイントを保持している場合があります。
- 対象ファイル／フォルダーを右クリック →「プロパティ」→「以前のバージョン」。
- 開ける最新時点があれば、コピーで退避（置換はリスク）。まず別パスへ救出。
VSS の状態確認コマンド
vssadmin list shadows
vssadmin list shadowstorage
注意：VSS の保存領域が不足すると古いスナップショットが破棄されます。将来に備え、VSS 領域は計画的に確保しましょう。
ファイルシステムの論理エラー修復（複製側で）
軽度の破損であれば、NTFS のインデックスや不整合を直すだけで開けることがあります。ただし原本では実行しないのが鉄則です。
推奨フロー
- まず読み取り専用チェック：
chkdsk <ドライブ>: /scan - 問題が検出されたら、複製ディスクで修復実行：
chkdsk <ドライブ>: /f - システム ファイルも疑わしい場合（OS ボリュームに限定）：
sfc /scannow DISM /Online /Cleanup-Image /RestoreHealth
補足：アプリ生成ファイルの壊れは「アプリの書式破損」であることも多く、OS 側の修復で直らない場合は後述のアプリ固有ワークアラウンド（ZIP 内部の XML 修復やヘッダー再生成など）を試します。
サードパーティ製データ復旧ツールの安全な使い方
使うのは複製ディスク／スナップショットから作ったイメージに限ります。原本走査は取り返しのつかない上書きを誘発します。
- Recuva：軽度の削除復旧・既存ファイルのスキャンに手軽。
- EaseUS Data Recovery：UI が分かりやすく、誤削除・フォーマット・RAW 化に強い。
- R‑Studio：パーティション喪失・複雑な壊れに強いプロフェッショナル向け。
理想は、まずセクタレベルのディスクイメージ（E01 / RAW）を取得してから解析すること。書き戻しは絶対に行わず、救出ファイルは別ディスクに書く運用を徹底します。
Azure バックアップ／スナップショットがある場合の正式手順
Recovery Services Vault で保護中の VM
- Vault →「バックアップ項目」から対象 VM を選択。
- 「復元」で時点を指定し、新規 VM で復元またはディスクで復元を選択。
- 復元リソースから一時 VM に接続し、必要ファイルをコピーで救出。
管理ディスクの独立スナップショットがある場合
- スナップショット → 新規ディスクを作成。
- 一時 VM にアタッチして読み取りでマウント。
- 対象ファイルを別ストレージ（Azure Files / OneDrive / 外部 NAS 等）へ退避。
バックアップやスナップショットが無い場合の現実的な選択肢
VM もディスクも削除済みでクラウド側に復元点が無い場合、クラウド内部の物理レイヤーからの復旧はほぼ不可能です。手元のローカルコピー・メール添付・チャット添付・一時フォルダー・バッチの中間生成物など、二次痕跡を徹底的に洗い出しましょう。また、アプリが作成した作業用テンポラリ（例：~$xxx.docx、.tmp、AppData\Local\Temp、%TEMP%）から救える場合があります。
アプリ固有の“壊れファイル”ワークアラウンド集
| 種類 | 症状 | 試すべき手順 |
|---|---|---|
| Office系（.docx/.xlsx/.pptx） | 開けない／内容が消える | 拡張子を .zip に変更して展開→word/document.xml 等を XML リンターで整形→再圧縮。 「開いて修復」を試し、修復後は別名保存。 |
| ビューアでエラー | qpdf/gs で再線形化、構文修復を試行。復旧後は別名保存。 | |
| 画像（.png/.jpg） | プレビュー不可 | ヘッダーを別正常ファイルから移植（高度）。exiftool でメタ再構築。サムネイルキャッシュからの抽出を試行。 |
| テキスト/コード | 文字化け・途中切れ | エンコーディング自動判別をオフ→UTF‑8/BOM 有無を切替。改行コード修正。差分から不足を補完。 |
根本原因の典型と切り分け
「再割り当て直後に壊れた」場合、次の要因が重なっていることが多いです。
- I/O の不整合：移行中や割り当て変更直後に大きな書き込みが重なり、キャッシュ未フラッシュのままディスクが切り離し・再接続された。
- 未完了の VSS スナップショット：VSS Writer が失敗し、アプリ整合性のない状態でコピーが行われた。
- ウイルス対策やバックアップエージェントのファイルロック：処理の衝突でファイルが半端状態に。
- ファイルシステムエラー（NTFS ジャーナルの不整合）：電源断・強制停止・ストレージ遅延で発生。
- ReFS・重複排除・記憶域スペースの構成変更：最適化直後のトリムやメタデータ更新と業務バッチが重なる。
イベントログでの確認ポイント
# ディスク/NTFS/StorPort
イベント ビューアー → Windows ログ → システム
ソース: disk, ntfs, storvsc, storport, volsnap, vss
# VSS 関連
アプリケーション ログ → ソース: VSS
# チャネル ログ（詳細）
アプリケーションとサービス ログ → Microsoft → Windows → NTFS / VHDMP / Hyper-V-* 即時にできる“被害最小化”オペレーション
- 対象ボリュームの読み取り専用化：ディスク管理または
diskpartで属性を ReadOnly に。 - ログの退避：アプリ／OS ログを別ボリュームへエクスポート。時系列を確定。
- 影響範囲の固定：影響ファイル一覧をインベントリ化（拡張子・更新日時・サイズ）。
# 例：直近24時間に変更された対象拡張子を列挙
Get-ChildItem E:\ -Recurse -Include *.docx,*.xlsx,*.pdf |
Where-Object { $_.LastWriteTime -gt (Get-Date).AddDays(-1) } |
Select-Object FullName,Length,LastWriteTime |
Export-Csv .\changed_files.csv -NoTypeInformation -Encoding UTF8
再発防止の運用ベストプラクティス（必須）
| 項目 | 推奨内容 | 効果 |
|---|---|---|
| Azure バックアップ | Recovery Services Vault を作成し、日次バックアップ＋保持期間をポリシー設定。定期的に復元リハーサルを実施。 | 誤削除・破損に数クリックで対応（VM 全体／ファイル単位）。 |
| ソフトデリート | Vault とストレージ口座の Soft Delete をオン。 | バックアップやスナップショットの誤削除を 14–90 日間ガード。 |
| 定期スナップショット | アプリ更新・OS パッチ・大規模バッチ前に必ず取得。自動化推奨。 | 短時間でポイントインタイム復元。 |
| 成果物の外部保存 | ChatGPT 生成結果を Git / OneDrive / SharePoint 等に逐次エクスポート。Pull Request ベースで差分管理。 | 作業途中のバージョン管理と多重バックアップ。 |
| 構成のコード化 | Azure Policy / Bicep / Terraform でバックアップ構成・タグ付けを IaC 化。 | 新規 VM 展開時の付け忘れ防止。 |
| I/O 静止点 | スナップショット前にアプリを一時停止、バッファをフラッシュ。可能ならアプリ整合スナップショット。 | 壊れファイルの発生率を劇的に低減。 |
ChatGPT（API）利用料金とデータ保護の考え方
- API 課金はリクエスト処理の完了時点で確定するため、ファイル破損自体を理由に減額・払い戻しは通常不可。
- 損失を最小化するには、出力を即時に安全な場所へ書き出す（クラウドストレージ／オブジェクトストレージ）。
- プロンプト・応答ログを保存し、会話履歴から再生成可能な形で残す。
# 例：生成直後に二重保存（ローカル＋クラウド）
$path = "D:\work\result-$(Get-Date -f yyyyMMdd-HHmmss).md"
$result | Out-File $path -Encoding UTF8
Copy-Item $path "\\fileshare\project\ai-output\" -Force
“安全に直す”ための復旧プレイブック（詳細版）
- インシデント宣言：関係者に通知し、対象ボリュームを ReadOnly。「変更凍結」を明確化。
- スナップショット/クローン取得：プラットフォーム標準機能で現状保存。作業はクローン側のみ。
- VSS 確認：「以前のバージョン」からコピー救出（最優先）。
- 論理修復：
chkdsk /scan→ 問題ありなら/f（複製側）。 - アプリ固有修復：Office＝ZIP 再構築、PDF＝構文修復など。
- サードパーティ復旧：ディスクイメージ化→スキャン→別ディスクへ救出。
- 検証：ウイルス対策・バックアップエージェントの例外設定、I/O 競合の被疑点を是正。
- 再発防止：バックアップ／スナップショットの自動化、手順の標準化、演習。
プラットフォーム別：スナップショット前の“静止化”チェック
| 項目 | 確認内容 | 対策 |
|---|---|---|
| アプリ書き込み | 大量バッチ・一括変換・DB のフラッシュ未完 | アプリ一時停止／キューを排出してからスナップショット。 |
| VSS Writer | 失敗／タイムアウト | vssadmin list writers で状態確認。失敗があればサービス再起動後に再取得。 |
| ウイルス対策 | ファイルロック | 除外パスの設定（作業フォルダー、VHDX、バックアップ一時領域）。 |
| ストレージ遅延 | 高い待ち時間 | ピーク帯の回避、QoS 設定、I/O 平準化。 |
よくある失敗と回避・注意の赤シール
- 原本ディスクで復旧ツールを走らせる：最悪の一手。復旧率が急落します。
- 「上書き保存」で修復を試す：まず別名保存が鉄則。
- 検証せずに運用復帰：復旧後はファイル オープン可否・ハッシュ・件数の突合を実施。
検証と可観測性：直して終わりにしない
- ハッシュ検証：救出前後の整合を
Get-FileHashで突合。 - 差分レポート：壊れ／救出できた／再生成したファイルの棚卸し。
- 監査証跡：いつ・誰が・どの時点を使って復旧したかを記録。
# 例：救出済みフォルダーのハッシュ一覧
Get-ChildItem "E:\recovered" -Recurse |
Get-FileHash -Algorithm SHA256 |
Export-Csv .\recovered_hashes.csv -NoTypeInformation -Encoding UTF8
RPO/RTO を満たすバックアップ設計の要点
- RPO（どこまでのデータを失えるか）：生成バッチが 1 時間単位なら、1 時間ごとのスナップショット＋日次バックアップ。
- RTO（どれくらいで復旧すべきか）：数十分以内なら、ディスク単位復元とファイル復元の併用を設計。
- 3‑2‑1 ルール：3 コピー・2 媒体・1 はオフサイト（クラウドバックアップ）。
運用の自動化サンプル（概念）
タグ Backup=Daily のディスクに対して毎深夜スナップショットを取得し、保持は 7 世代、重要タグは 30 世代にする、といったルールは IaC で表現します。
# 擬似例：PowerShell/Az でタグに基づきスナップショット作成
Get-AzDisk -ResourceGroupName rg-app | Where-Object {
$_.Tags["Backup"] -eq "Daily"
} | ForEach-Object {
New-AzSnapshot -ResourceGroupName rg-app -SnapshotName "auto-$($_.Name)-$(Get-Date -f yyyyMMddHHmm)" `
-Snapshot (New-AzSnapshotConfig -Location $_.Location -CreateOption Copy -SourceResourceId $_.Id)
}
インシデント対応の“時系列テンプレ”
- T0：障害検知、対象ボリューム凍結、作業中断。
- T0+10m：スナップショット／クローン取得。
- T0+30m：VSS から即時救出（該当あれば）。
- T0+1h：論理修復・アプリ修復の検証（複製側）。
- T0+3h：サードパーティ復旧スキャン（必要時）。
- T0+同日：暫定復旧リリース、恒久対策のオーナー割当。
チェックリスト（実務でそのまま使える）
| カテゴリ | 確認 | 状態 |
|---|---|---|
| 緊急対応 | 対象ボリュームの書き込み停止／ReadOnly 化 | [ ] |
| 保全 | スナップショット／クローン取得（ID を控える） | [ ] |
| 迅速復旧 | VSS「以前のバージョン」からコピー救出 | [ ] |
| 修復 | chkdsk /scan → /f（複製側） | [ ] |
| 解析 | イベントログの抽出（disk/ntfs/vss/volsnap） | [ ] |
| 恒久策 | Azure Backup ポリシー適用／Soft Delete 有効化 | [ ] |
| 運用 | スナップショット前の静止化手順を標準化 | [ ] |
| 品質 | 復旧後のハッシュ／件数／差分レポート | [ ] |
ケース別・最短リカバリの意思決定表
| 状況 | 最優先アクション | 次の一手 |
|---|---|---|
| VSS がある | 対象ファイルを該当時点からコピー | 差分再生成（ChatGPT ログから） |
| Azure バックアップがある | ファイル復元／ディスク復元 | 検証後に本番へ差替え |
| スナップショットのみ | 新規ディスク化し救出 | 不足分は再生成 |
| 何も無い | テンポラリや二次痕跡から救出 | 復旧ツールでイメージ走査 |
ChatGPT ワークロードの“壊れにくい”運用設計
- 出力のトランザクション化：一時ファイルに書き込み → ハッシュ計算 → 完了後に本番名へ atomic rename。
- 世代管理：ファイル名に ISO8601 タイムスタンプを付けて世代を作成。
- 永続化の二重化：ローカルとクラウドへ二重保存。失敗時はリトライ。
- ログの完全保存：プロンプト・レスポンスを JSONL で保管。再生成時の再現性を担保。
# 例：安全な書き込み（擬似）
$tmp = "D:\out\file.tmp"
$dst = "D:\out\file.docx"
Set-Content $tmp $result -Encoding Byte
$hash = (Get-FileHash $tmp -Algorithm SHA256).Hash
Rename-Item $tmp $dst
Add-Content "D:\out\manifest.csv" "$dst,$hash,$(Get-Date -f o)"
トラブル収束後に必ずやる後片付け
- 原因の一次仮説と反証可能なログを添えた簡易レポート化。
- 自動化 Pull Request（バックアップ設定・除外設定）。
- 復元リハーサルの定期ジョブ（四半期に 1 回など）。
まとめ：復旧の鉄則と、壊れない仕組み
復旧の成否は「止める→保全→複製側で直す→戻せる設計」に尽きます。今回のように Windows Server の再割り当て直後にファイルが壊れたとしても、VSS・スナップショット・Azure バックアップの三段構えがあれば、“ほぼ即日”で業務の最小限再開が現実的です。将来に向けては、スナップショット前の静止化・出力のトランザクション化・二重保存・IaC 化を標準運用に組み込み、同様のトラブルを限りなくゼロに近づけましょう。
付録：よくある質問（FAQ）
Q. chkdsk /f は安全ですか？
A. 複製ディスクに対してのみ実行してください。原本での修復は上書きを伴い、あとから高度な復旧が効かなくなる恐れがあります。
Q. VSS が空でした。望みはありますか？
A. テンポラリやキャッシュ、メール／Teams などの添付、ブラウザーのダウンロード履歴など“二次痕跡”を探しましょう。無ければディスクイメージ化→復旧ツールの出番です。
Q. Azure バックアップは毎日で十分？
A. 1 日の間に大量生成があるなら、日次に加えて時間単位のスナップショットを併用してください。RPO に合わせて設計します。
Q. ChatGPT の API コストは戻りますか？
A. 通常は戻りません。だからこそログ保存と再生成設計が重要です。
復旧コマンドと参照ポイント（クイックリファレンス）
# 以前のバージョン（GUI）
右クリック → プロパティ → 以前のバージョン
# VSS 状態
vssadmin list writers
vssadmin list shadows
# ファイルシステム
chkdsk E: /scan
chkdsk E: /f
# システムファイル（OS ボリューム）
sfc /scannow
DISM /Online /Cleanup-Image /RestoreHealth
# ハッシュ検証
Get-FileHash -Algorithm SHA256
# 直近変更リスト
Get-ChildItem E:\ -Recurse | Where-Object { $_.LastWriteTime -gt (Get-Date).AddHours(-12) }
コメント