Windows Serverをファイルサーバーとして運用していると、
「ファイルを間違えて削除してしまった」
「Excelファイルを上書きしてしまったので、昨日の状態に戻したい」
といった問い合わせを受けることがあります。
そんなときに役立つのが、Windowsの**「以前のバージョン」**です。
対象フォルダーを右クリックして、
プロパティ → 以前のバージョン
を開くと、過去の状態が表示されることがあります。
これは主にWindowsのVSS（Volume Shadow Copy Service）によるシャドウコピーを利用した機能です。
今回はWindows Serverをファイルサーバーとして運用する場合の「以前のバージョン」の仕組みや確認方法、シャドウコピーの容量、注意点について解説します。
「以前のバージョン」とは？
「以前のバージョン」は、ファイルやフォルダーを過去の状態に戻したり、過去のデータを取り出したりするためのWindowsの機能です。
ファイルサーバーでシャドウコピーを設定している場合、ユーザーが誤ってファイルを削除したときでも、過去のスナップショットにファイルが残っていれば復元できる可能性があります。
例えば、
9:00 正常なファイルが存在
12:00 シャドウコピー作成
15:00 ユーザーがファイルを削除
という状況であれば、12:00のシャドウコピーからファイルを取り出せる可能性があります。
ファイルサーバーを運用していると非常に便利な機能です。
削除したファイルを「以前のバージョン」から探す
削除したファイルそのものは存在しないため、通常はそのファイルが保存されていた親フォルダーから確認します。
対象フォルダーを右クリックして、
プロパティ → 以前のバージョン
を開きます。
利用可能なスナップショットがあれば、日時の異なるフォルダーが一覧表示されます。
削除前と思われる日時を選択して「開く」を選びます。
過去のフォルダーの中に目的のファイルが存在していれば、そこから現在の場所などへコピーします。
いきなり「復元」を押さない
個人的におすすめしたいのは、最初から「復元」を実行するのではなく、まず**「開く」から中身を確認すること**です。
復元操作によって現在のファイルやフォルダーに影響を与えることを避けるためです。
例えば目的のファイルが、
\\SERVER\share\営業部\資料.xlsx
だった場合、以前のバージョンから目的のファイルを見つけたら、まず別の場所へコピーします。
C:\Temp\restore\
など、一時的な場所へ取り出して、
- 本当に目的のファイルか
- ファイルが開けるか
- 必要な日付の内容か
を確認してから元の場所へ戻す方が安全です。
「以前のバージョン」が表示されない場合
プロパティを開いても以前のバージョンが表示されない場合があります。
その場合は、サーバー側でシャドウコピーが設定されているか確認します。
Windows Serverでは対象ボリュームのシャドウコピー設定を確認できます。
対象ドライブの設定から、
シャドウコピー
を確認します。
ここで、
- シャドウコピーが有効になっているか
- どのボリュームが対象か
- スケジュール
- 使用する記憶域
- 使用量
などを確認します。
シャドウコピーの容量に注意
「以前のバージョンを有効にしているから、昔のファイルもずっと残っている」
と思ってしまいがちですが、そうではありません。
シャドウコピーには保存領域があります。
この領域が不足すると、古いシャドウコピーから削除されていきます。
現在のVSSの状態を確認するときには、管理者権限のコマンドプロンプトから次のコマンドも利用できます。
vssadmin list shadowstorage
環境によっては、次のような情報を確認できます。
Used Shadow Copy Storage space
Allocated Shadow Copy Storage space
Maximum Shadow Copy Storage space
日本語環境では日本語で表示される場合があります。
特に確認したいのが最大シャドウコピー記憶域です。
ここが小さいと、ファイル更新の多いサーバーでは古いシャドウコピーが早く消えてしまう可能性があります。
現在残っているシャドウコピーを確認する
次のコマンドも利用できます。
vssadmin list shadows
現在システムから認識されているシャドウコピーを確認できます。
「以前のバージョンから数日前までしか戻れない」
という場合には、実際にどの程度シャドウコピーが残っているのか確認してみるとよいでしょう。
シャドウコピーはバックアップではない
ここは非常に重要です。
シャドウコピーは便利ですが、シャドウコピーだけをバックアップの代わりにするのは危険です。
例えば、
- ディスク自体が故障した
- ボリュームが破損した
- シャドウコピー領域が失われた
- 古いシャドウコピーが容量不足で削除された
- サーバーそのものが利用できなくなった
といった場合には、シャドウコピーから復旧できない可能性があります。
そのため、
シャドウコピー ＋ 別のバックアップ
という考え方が重要になります。
Windows Serverであれば、Windows Serverバックアップを利用している環境も多いでしょう。
Windows Serverバックアップの世代を確認する
Windows Serverバックアップを使用している場合は、
wbadmin get versions
で利用可能なバックアップを確認できます。
「以前のバージョン」に目的のファイルが無かった場合でも、さらに古いWindows Serverバックアップに残っている可能性があります。
そのため、削除ファイルの復元では、
① 現在のフォルダー
↓
② 以前のバージョン
↓
③ Windows Serverバックアップ
という順番で確認すると分かりやすいと思います。
実際に削除ファイルを探してみた結果
今回、実際にユーザーから、
「誤って削除したファイルを復元できないか」
という依頼がありました。
最初に「以前のバージョン」を確認しました。
複数の世代が残っていたため、古い世代まで遡りましたが、目的のファイルはありませんでした。
そこで、
wbadmin get versions
を実行してWindows Serverバックアップの世代も確認しました。
Windows Serverバックアップ自体は存在していました。
しかし、こちらにも目的のファイルは残っていませんでした。
つまり、
シャドウコピーとバックアップの両方が存在していても、削除された時期によってはファイルを復元できない
ということです。
なぜファイルが残っていなかったのか？
例えば、次のようなケースが考えられます。
8月1日 ファイル作成
8月10日 ファイル削除
9月1日 現在残っている最古のシャドウコピー
この場合、9月1日以降のシャドウコピーをいくら確認してもファイルはありません。
Windows Serverバックアップについても同様です。
現在残っている最古のバックアップより前にファイルが削除されていれば、そのバックアップからは復元できません。
また、ファイルを作成してから次のバックアップやスナップショットが取得される前に削除した場合、そもそも一度も保存されていない可能性もあります。
「何世代あるか」より「何日前まで戻れるか」
バックアップ運用では、
「10世代保存している」
といった世代数を確認することがあります。
しかしファイルサーバーでは、何日前まで戻れるのかも重要です。
例えば1日に複数回シャドウコピーを作成している場合、20世代残っていたとしても、それほど長期間は遡れない可能性があります。
逆に更新量が少なく、十分なシャドウコピー領域が確保されていれば、より長期間残る場合もあります。
そのため実際に、
vssadmin list shadows
や「以前のバージョン」を確認して、
現在の環境では実際に何日前まで戻れるのか
を把握しておくことをおすすめします。
ファイルサーバー管理者が確認しておきたいこと
ファイルサーバーを管理している場合は、障害が発生する前に次の点を確認しておくと安心です。
- シャドウコピーが有効になっているか
- スナップショットの作成スケジュール
- シャドウコピーの最大記憶域
- 実際に何日前まで以前のバージョンが残っているか
- Windows Serverバックアップの保持期間
- バックアップ対象に必要なボリュームが含まれているか
- テスト用ファイルを実際に復元できるか
特に最後の復元テストは重要です。
バックアップ処理が毎日「成功」していても、本当に必要なファイルを復元できるかは別の話だからです。
まとめ
Windows Serverの「以前のバージョン」は、誤って削除したファイルや上書きしてしまったファイルを復元するときに非常に便利な機能です。
確認するときは対象フォルダーを右クリックして、
プロパティ → 以前のバージョン
を開きます。
VSSの状態を詳しく確認したい場合は、
vssadmin list shadows
現在のシャドウコピー記憶域を確認したい場合は、
vssadmin list shadowstorage
も利用できます。
ただし、シャドウコピーには保存容量の上限があり、古いデータがいつまでも残るわけではありません。
また、シャドウコピーはバックアップそのものではありません。
今回実際に削除ファイルの復元を試したところ、「以前のバージョン」とWindows Serverバックアップの両方を確認しても、目的のファイルを見つけることができませんでした。
バックアップでは、
「取得に成功しているか」だけではなく、「必要な時点まで遡って実際に復元できるか」
まで確認しておくことが重要です。
コメント