サーバーバックアップに関する既知の問題と解決方法(ja-JP)
このドキュメントは、Windows Home Server 2011 Essentials、Windows Home Server 2011、Windows Storage Server 2008 R2 Essentialsのサーバーバックアップ機能に関して報告されている問題と解決方法をまとめたものです。
このドキュメントは、http://social.technet.microsoft.com/wiki/contents/articles/11872.server-backup-known-issues-and-resolutions-en-us.aspxを意訳しています。正確な内容は原文を参照願います。
RmMedaDataへのアクセスが拒否される
事象:
バックアップ履歴にサーバーバックアップが完了せず失敗した旨が表示されます。イベントビューアーのアプリケーション、Windowsログ配下にイベントID 547 のログが記録されています。このイベントログの情報のなかに、以下のフォーマットでサーバーバックアップのログファイルのパスが表示されています。
The backup operation that started at '2012-03-31T07:00:05.748719600Z' has encountered errors for the volume(s) 'F:'. Log of files not successfully backed up 'C:\Windows\Logs\WindowsServerBackup\Backup_Error-31-03-2012_02-00-05.log'.
上記のファイルパスを参照し、サーバーバックアップのログを開くと、以下のような情報が記録されています:
Error in backup of F:\Extend\RmMetadata\TxfLog\ during write: Error [0x80070005] Access is denied.
Error in backup of F:\Extend\RmMetadata\TxfLog\TxfLog.blf during write: Error [0x80070005] Access is denied.
原因:
これはサーバーバックアップで(ボリューム全体ではなく、フォルダーを指定することで)ファイルレベルでのバックアップを構成されたNTFSフォーマットドライブでのみ発生します。$RmMetaDataは他のプロセスからアクセスできない、NTFSの内部データです。
解決方法:
この問題について、2つの対処方法があります。
- 問題が発生したボリュームについて、サーバーバックアップのポリシーでボリューム全体をバックアップするよう構成し、ブロックレベルでのバックアップに変更することができます。
- ファイルレベルのバックアップを行う際に、これらの問題となるファイルを除外するようレジストリーキーを設定することができます。これらのファイルはNTFSファイルシステムでのみ利用されており、無視しても問題は発生しません。
- レジストリエディターを開き、以下のキーに移動します。
HKLM\SYSTEM\CurrentControlSet\Control\BackupRestore\FilesNotToBackup - FilesNotToBackup配下に、IgnoreNTFSという名前で複数行文字列値を追加し、値に \Extend\ /S を入力します。
- サーバーを再起動します。
- レジストリエディターを開き、以下のキーに移動します。
VSS がシャドウコピーの作成に失敗する
事象:
バックアップ履歴に、サーバーバックアップが完了しなかった、または成功しなかった旨が表示されます。イベントビューアーのアプリケーション、Windowsログ配下にイベントID 519 のログが記録されています。このイベントログの情報のなかに、以下のフォーマットでサーバーバックアップのログファイルのパスが表示されています。
The backup operation that started at '2012-04-08T07:00:03.915482900Z' has failed to back up volume(s) 'E:'. Please review the event details for a solution, and then rerun the backup operation once the issue is resolved.
また、イベントビューアーのシステム、Windowsログ配下に次のようなイベントID 36 のログが記録されています。
The shadow copies of volume E: were aborted because the shadow copy storage could not grow due to a user imposed limit.
これらの2つのイベントログは、同一のボリュームが障害の原因であることを示しています。
原因:
バックアップにあたり、サーバーバックアップのためにバックアップ元となるディスクにシャドウコピーを作成する必要があります。シャドウコピーの作成には空きスペースが必要です。ディスク領域が不足しているか、シャドウコピーの最大サイズの制限に該当する場合、シャドウコピーの作成に失敗します。
解決方法:
バックアップ元となるディスクの空き容量をチェックしてください。空き領域が少ない(ボリュームサイズ全体の10%以下)場合、
- 不要なデータを削除する
- 他のボリュームにデータを移動する
- 既存のシャドウコピーデータを削除する
等で、空き領域を確保してください。
バックアップ元となるディスクに10%以上の空き領域がある場合、シャドウコピーの最大サイズの値をより大きな値に更新してください。
注意:シャドウコピーの最大サイズを”制限なし”に設定した場合、システムは当該ボリュームに保存されている各ファイルについて最大64のコピーを保存します。これによりファイルバージョンの管理をより確実に行える一方で、大量のディスクスペースを消費します。最大サイズを”制限なし”に設定する前に、十分な空き領域があることを確認するか、または他のボリュームにシャドウコピーデータを配置してください。
シャドウコピーデータの管理について詳細な情報は、http://technet.microsoft.com/ja-jp/library/cc771305を参照してください。
バックアップがExchange Server と競合する
Exchange Serverがインストールされたボリュームをバックアップする場合、Exchangeのバックアップと復元を構成する方法に関するTechNetのドキュメントを参照してください。
http://technet.microsoft.com/en-us/library/dd876851.aspx
出荷状態へのリセットがエラーコード 0x80042431 で失敗する
事象:
出荷状態へのリセットを実行中にServerrecovery.exeがサーバー側でクラッシュし、エラーコード 0x80042431 がクライアントに通知されます。
原因:
出荷状態へのリセットの間、ディスクの状態がオフライン、ボリュームの状態が失敗と表示されます。これはハードディスクを接続または取り外ししたり、スロットの場所を変更した場合に発生します。
対処方法:
以下のステップはサーバーにモニター、キーボード、マウスを接続する必要がある場合があります。以下の手順でディスクを消去することができます。
ディスクの消去は対象となるディスクの全てのデータを削除することに注意してください。消去コマンドを実行する前に、ディスク内のデータがバックアップされていることを確認してください。
コンソールウィンドウを起動するため、Alt+F10を押下してください。
コマンドプロンプトに、diskpart と入力しエンターを押下します。
List disk と入力し、エンターを押下します。
- 状態がオフラインになっているディスクがあった場合、”Select disk X”と入力してエンターを押下し、ディスクを選択します。(Xにはlist diskで表示されている番号を入力します)
- “online disk”と入力してエンターを押下します。
“list volume”と入力してエンターを押下します。
A) ステータスに”失敗”と表示されるボリュームがあった場合、”Select volume X”と入力してエンターを押下し、ボリュームを選択します。
B) “detail volume”と入力してエンターを押下し、ディスク番号を調べます。
C) “select disk Y”と入力してエンターを押下し、ディスクを選択します。(YにはBで調べたディスク番号を入力します)
D) “clean”と入力してエンターを押下し、ディスクを消去します。正常でないステータスのディスクがなくなるまで、ステップ3と4の手順を繰り返します。
“exit”と入力してエンターを押下し、diskpartを抜けます。
サーバーの出荷状態へのリセットを継続します。
別のバックアップが進行中です
事象:
バックアップ履歴に、サーバーバックアップが成功せず失敗した旨が表示されます。イベントビューアーのアプリケーション、Windowsログ配下にイベントID 518 のログが記録されています。
イベントログに以下のようなエラーが記録されています。
The backup operation that started at '2012-03-31T17:00:07.104757000Z' has failed because another backup or recovery operation is in progress. Please stop the conflicting operation, and then rerun the backup operation.
原因:
サーバーバックアップは、バックアップポリシーでスケジュールされた時刻に開始されます。その際に、他のサーバーバックアップ/リカバリーのプロセスが存在していた場合、新たなプロセスは失敗します。
これは仕様で、この問題を無視して頂いて構いません。実行されているバックアップ/リカバリーのプロセスが終了すれば、新しいバックアッププロセスは問題なく実行されます。
サーバーバックアップに関する補足
- サーバーのバックアップが失敗する場合の一般的な回避策は、サーバーのバックアップポリシーを再構成することです。これにより、ボリュームGUIDの変更など環境の変化によって引き起こされる問題を解決することができます。
- バックアップパフォーマンスについて、以下に注意してください。
A) ブロックレベルバックアップはファイルレベルのバックアップよりも高いパフォーマンスが望めます。ブロックレベルバックアップとはバックアップポリシーの構成時に、ボリューム全体をバックアップするよう選択することを指します。
B) バックアップが失敗した場合、次回のバックアップはより時間がかかります。次回のバックアップでは完全バックアップが行われ、既存のバックアップの整理もしようとします。従って、バックアップに失敗した後のバックアップでは通常より時間がかかります。 - バックアップ領域の管理のため、バックアップディスクに10%以上の空き領域がない場合ダッシュボードでアラートが表示されます。実際には、新しいバックアップを保存するのに十分な空き容量がない場合、サーバーバックアップは自動的に古いバックアップを削除します。ダッシュボードにアラートが表示されますが、古いバックアップを保存しておく必要がない場合、このアラートを無視しても構いません。詳細な情報は、http://blogs.technet.com/b/filecab/archive/2011/03/14/windows-server-backup-automatic-disk-usage-management.aspxを参照してください。