ディープスキャンに踏み切る前に、システムの保護や企業バックアップがスナップショットを残していないか確認してください。エクスプローラーで親フォルダを右クリック → 「以前のバージョンの復元」——項目があれば、ディスクを掘らずにツリー全体を数秒で取り戻せることがあります。
シャドウコピーは時間経過に沿ったブロック単位の変更を追跡します。毎晩のフルバックアップではありません。保持は復元ポイント用に構成したディスク予算に依存します。忙しい CAD ワークステーションは、軽負荷の事務用 PC よりスナップショットを早くローテーションすることがあります。
「以前のバージョン」が届かない場合
- SSD の空きを節約するためシステムの保護を無効にしている。
- 外付けドライブは既定で保護から除外されている。
- クライアント側のシャドウをリダイレクトまたは無効にする企業ポリシー。
スナップショットは保証されません。無効化されたり、空きのためにトリムされたり、外付けでは存在しないことがあります。一覧が空なら次は Recuva で問題ありません——表示されたときだけシャドウを安い勝ちとして扱ってください。
安全に復元する
シャドウから戻したファイルは、その場で編集する前に別ディスクへコピーしてください。保護されたボリューム上で古い版を直接開いても、復旧と競合する書き込みを起こし得ます。エクスプローラーの「コピー…」で自分が管理するステージングフォルダへ。
バージョンを調べている間も、そのボリュームへの新しい重い書き込みは避けてください。バックグラウンドの再利用とのレースは続きます。ポリシーが厳しい PC では、ストレージセンスと Defender が一時的なシャドウデータを予想より早く消すことがあるため、サポートも読んでください。
シャドウコピーはあるのにタイムスタンプが妙なときは、チケット管理や git 履歴と突き合わせ、実際に「最後に良好だった」のがどの版か特定します。ユーザーが新しい版だと思って古いスナップショットを戻すことがあります。
スナップショットが救った日は、振り返りをスケジュールしてください。なぜ Recuva が最後の砦だったのか。バックアップジョブを更新し、四半期ごとにリストアをテストして、次のインシデントはより健全な前提から始めます。
ボリューム シャドウ コピー サービス——管理者が見るもの
管理者はベンダーツールや vssadmin でシャドウストレージを調べることがあります。一般向け復旧に CLI はめったに要りませんが、シャドウ領域が有限であることを知ると、「先月は動いたのに今日は失敗する」の理由がディスク一杯で説明できます。
以前のバージョン、ファイル履歴、クラウドの巻き戻し
ファイル履歴は有効化されていればライブラリやデスクトップを対象にします。OneDrive と SharePoint は独自のごみ箱とバージョン数を持ちます。プレースホルダとしてしかローカルに存在しなかったファイルのために PC 全体をディープスキャンする前に、プロバイダ固有の復元を試してください。
シャドウを静かに潰すアプリ
- 大きな連続書き込みを行うデータベースサーバーはシャドウの差分を素早く消費する。
- デフラグや一部の最適化ツールは空き領域を統合する過程で古いシャドウをトリムすることがある。
- デュアルブートの Linux が NTFS パーティションをリサイズすると以前の復元メタデータが無効になることがある——リサイズ前にリリースノートを読む。
エンドユーザーへの説明
スクリーンショットでパスを一つ示す。「親フォルダを右クリック → 以前のバージョンの復元」。ごみ箱だけ試すユーザーは、シャドウが二クリックで済むチケットを無駄に消費します。
シャドウが空でもデータが重要なとき
それは Recuva やイメージ化の合図であり、罪悪感ではありません。シャドウを確認したことをログに残し、次のエンジニアが同じ 30 分を繰り返さないようにします。メタデータは消えたがハードウェアは安定しているときはディープスキャンの記事と併用してください。