ソースがVSSのイベントID12292および13のエラー

構築完了後に引き渡してもらったOSでVSSがソースのエラーが大量に出ていました。 ひっきりなしという状態ですね。(イベントログくらいちゃんと確認しましょう…。) 出ていたのは主に以下の2つのエラーです。 ログの名前: Application ソース: VSS 日付: 2013/06/27 17:02:32 イベント ID: 12292 タスクのカテゴリ: なし レベル: エラー キーワード: クラシック ユーザー: N/A コンピューター: S12HVS1.jbs.local 説明: ボリューム シャドウ コピー サービス エラー: CLSID {463948d2-035d-4d1d-9bfc-473fece07dab} でシャドウ コピー プロバイダー COM クラスの作成中にエラーが発生しました [0x80070005, アクセスが拒否されました。 ]。 操作: ハードウェア プロバイダーのインスタンスを作成しています このプロバイダーの呼び出し可能インターフェイスを取得します このコンテキストをサポートするすべてのプロバイダーのインターフェイスの一覧を作成します シャドウ コピーを照会します コンテキスト: プロバイダー ID: {3f900f90-00e9-440e-873a-96ca5eb079e5} プロバイダー ID: {3f900f90-00e9-440e-873a-96ca5eb079e5} クラス ID: {463948d2-035d-4d1d-9bfc-473fece07dab} スナップショット コンテキスト: -1 スナップショット コンテキスト: -1 実行コンテキスト: Coordinator イベント XML: 12292 2 ...

April 8, 2014 · 2 min · 胡田昌彦

[番外編]究極のバックアップ方法

※今回は番外編です。メーカーの保障も私の保証もありません(笑)。 バックアップソフトウェアって、リストアソフトウェアじゃないよね 私が思うに、「バックアップソフトウェア」は、あくまでも「バックアップ」用であって、「リストア」用ではないです。メーカーの出しているマニュアルの手順どおりに操作を行っても「バックアップしたとおりには戻らない」「導入している製品ごとに個別にリストア手順を確立する必要がある」というのが当たり前です。フルバックアップしたものをフルリストアしても動かないなんてひどいじゃないですか。 一方、素敵にバックアップが取得できて、素敵に戻ってくれるのがディスクイメージングツールです。そもそも別OSで立ち上げて、ディスクイメージを取っているわけですから戻らないわけが無いんですけどね。でも、これだと、サーバーに必ずダウンタイムを作らなくてはいけないし、自動化もかなり難しいので、実運用に乗せるのは特殊なケースを除いてかなり厳しいでしょう。 イメージングツールの良い面と日々のバックアップツールの良い面を併せ持つすばらしいソリューションであるはずだった、オンラインでディスクイメージを取得するバックアップ製品。うまく動く場合にはいいのですが、はっきり言ってあちこちからトラブルの話ばかり聞こえてきます。しかもよくあるのはスナップショットドライバのバグでBSoDが発生するような致命的なものばかり。 究極のバックアップ方法 そんな中、私が知る限り必ず完璧に環境を戻してくれる素敵な手法があります。それは、「RAID1」です。 「『RAID1』ってHDDの冗長化の手法じゃなかったっけ?」というのは正しい反応なのですが、私が言っているのもそれです。同じ内容のディスクがあるわけですから、それがバックアップになっているのです。たとえば以下のようなときに使えます。 - 「あ、今の状態を取っておきたいな」と思ったらオンラインのまま(あるいはオフラインにしてから)1本引き抜く(バックアップ)。その後、別の新しいディスクを刺しておけばまた同期される。 - 「もしもうまくいかなかったらすぐに元に戻したいな」と思ったら、オンラインのまま(あるいはオフラインにしてから)1本引き抜く(バックアップ)。その後作業がうまくいけば抜いておいたディスクをそのまま指せばいいし、もしも作業がうまくいかなかったら一度オフラインにして、とっておいたディスクだけを刺して起動し、その後もう1本のディスクを指せばいい。 バックアップとずれますが以下のようなHDDコピー機としての使い方も。 - 同じハードウェア構成のサーバーを複数台構築するときに。1台を構築し、1本HDDを抜いて、新しいHDDを刺して、同期して、1本抜いて・・・を繰り返せばあっという間に複製完了 「いきなり引き抜いたら駄目なんじゃ?」と思う人もいるかもしれませんが、はっきり言っていきなりBSoDで落ちたときと同じレベルですし、昨今はきちんとファイルシステムレベルでジャーナル機能を持っているのでおいそれとおかしくはなりません。気になるならメモリの内容をフラッシュさせてから抜くなり、安全にやりたかったらオフラインで抜けば心配事は何もありません。 「単一で稼動するサーバーならそれでいいかもしれないけど、複数台で連携して稼動するようなシステムではだめだろう」と思う人もいるかもしれません。それは正しい指摘だとは思いますが、それでは世の中にあふれているバックアップソフトがそこまできちんと整合性を取ってバックアップ取得~リストアしてくれるでしょうか?・・・同じことだと思います。それに、どうしても完全に安全にやりたければ、関連するシステムを全部シャットダウンしたうえで、オフラインの状態でHDDを引っこ抜けばいいんです。この芸当はオンラインでバックアップを取得するソリューションでは不可能です。オフラインのイメージングツールでも同じことはできますが、やろうとおもったらRAIDのドライバが・・・とか色々面倒です。ディスク引っこ抜くのは一瞬です(笑)。 「OS部分はそれでいいかもしれないけど、データが外部ストレージにあるような場合はどうするんだ」と思う人がいるかもしれませんが、まさにデータ部分に対してこの手法を用いているのがディスクのクローニングの技術です。なぜ外部ストレージにあるデータにはディスクでのコピーを許容するのに、OS部分にはそれを使わないんですかね?矛盾して無いでしょうか? ・・・。 オンラインでディスクの同期を停止してもデーターの整合性がとられるようにVSSなどの技術があるわけなので、それとこれとは話が違うじゃないかと思うと思いますが、それは正解です(笑)。 冗談はともかく真面目な話 冗談はともかくとしても、私は真面目な話としてこのRAID1を使ったバックアップを、ロールバック案としてきちんと検討、採用していいのではないかと考えています。 たとえば、Active Directoryのスキーマ拡張作業。普通に作業をするだけなら10分で終わる作業です。CD or DVDを入れてコマンド一発です。ですが、マイクロソフトが「スキーマ拡張作業で何か問題が発生したときにはフォレスト全体に悪影響が及び復旧に多大な時間がかかる可能性があるから・・・」とかなんとか脅かして、“ベストプラクティス"としてまだるっこしい手順を大々的に宣伝してしまったものだからみんなビビッて10分の作業のために何時間も、何日も、準備をふくめて何ヶ月もかけるケースすらあります。(たとえばこの辺とかMicrosoft での構造化された Active Directory スキーマ管理) もちろん、それだけの危険性がある根拠があるのであれば(たとえば、勝手にスキーマを拡張しまくっていて本当にバッティングの恐れがある、とか)わかるのですが、スキーマはだれも自分たちではいじっていないし、ADとExchangeが入っているだけ・・・というような場合には問題が起きる可能性なんてありえないんです。だって全く同じことが世界中で行われていて、問題ないんですから。 なのに、まずステージングサイトを用意して、スキーママスタをステージングサイトに移動して、そこでまずアウトバウンドの複製をとめて・・・だの何だのやり始めてしまうのは全く持ってナンセンス。だと思うのです。まずやってみて、駄目だったら戻せばいいじゃないかと言いたいのです。 そうすると、「リストア手順の確立」とか、「復旧時間が」とかそういうまためんどくさい話になります。DCの場合には複製も考慮しないといけないので、さらにめんどくさい。 で、こんなときこそ私はこのRAID1でのバックアップをロールバック手段として使えばいいんじゃないかと思うのです。 - 全DCシャットダウン~HDD1本抜く - DC起動 - スキーマ拡張 - テスト - (テストOKなら)抜いてあったHDDをオンラインのまま指す - (テストNGなら)全DCシャットダウン~抜いてあったHDDを刺して起動 これでいいじゃないですか。これならDCの数にもよりますけど1時間もあればロールバック含めて完了するでしょう?戻らない可能性なんてほぼ無いでしょう?準備も必要ないでしょう? というわけで、今回は無責任なことを言って終わりにします。あまり真に受けないでください。

February 17, 2009 · 1 min · 胡田昌彦