Backup

Announcing Azure Network Watcher – Network Performance Monitoring and Diagnostics Service for Azure | Blog | Microsoft Azure 1 user Have you ever felt the need to diagnose a critical problem and you needed access to packet data from a virtual machine? What if you c… [azure.microsoft.com ](http://b.hatena.ne.jp/ebibibi/?url=https%3A%2F%2Fazure.microsoft.com%2F) - テクノロジー - あとで読む - [](http://b.hatena.ne.jp/ebibibi/)ebibibi w, b, azure 16 clicks 2017/03/23 - System Center Configuration Manager エージェントと Microsoft Intune (MDM) による管理の共存について – Japan System Center Support Team Blog 1 user みなさま、こんにちは。System Center サポート チームです。 Windows 10 の展開に伴い、タブレットなどのモバイル デバイスに搭載された Windows 10 端末の管理をご検討いただく中で、System Center Configuration… ...

今週後半は暖かい日が続きましたね。春一番が吹いた地域もあったようです。 さて、今週のトピックスです。 - 3分でわかる Azure Managed Diskのしくみ 8 users 3分でわかる Azure Managed Diskのしくみ 1. FD A FD B 2. FD A FD B 3. https://docs.microsoft.com/ja-jp/azure/storage/storage-managed-disks-overv… [www.slideshare.net ](http://b.hatena.ne.jp/ebibibi/?url=http%3A%2F%2Fwww.slideshare.net%2F) - テクノロジー - あとで読む - [](http://b.hatena.ne.jp/ebibibi/)ebibibi w, azure, b 34 clicks 2017/02/15 - なぜWindowsの標準ドライバーはすべて「2006年6月21日」のまま更新されないのか？ - GIGAZINE 71 users Windows純正のドライバーのタイムスタンプはすべて「2006年6月21日」に統一されています。Windowsマニアでもなかなか知らなさそうなトリビアの理由をMicrosoftのエンジニアが明かしています。 Why are all Windows drivers … [gigazine.net ](http://b.hatena.ne.jp/ebibibi/?url=http%3A%2F%2Fgigazine.net%2F) - テクノロジー - あとで読む ...

SCDPMによるハイブリッドクラウド保護のe-bookが出てきます。マイクロソフトのFree ebookシリーズは無料なのにやけにクオリティが高いので必ず読んだほうが良いシリーズですが、今回もですね！ Free ebook: Microsoft System Center Data Protection for the Hybrid Cloud - Microsoft Press - Site Home - MSDN Blogs 読まなきゃいけない本が溜まっていく一方…という方も多いとは思いますが…。

Exchange Server 2010のDAGのトランザクションログがDPM 2012でバックアップを実施しても消えない…という話を受けて、調査してみました。 調べた所以下のブログに非常に良い情報がありました。 - [Exchange 2010: Log Truncation and Checkpoint At Log Creation in a Database Availability Group - Tim McMichael - Site Home - TechNet Blogs](http://blogs.technet.com/b/timmcmic/archive/2012/03/12/exchange-2010-log-truncation-and-checkpoint-at-log-creation-in-a-database-availability-group.aspx) Exchange Server 2010 SP1以降挙動が変わっており、要点は以下とのことです。 - ログファイルを消しているのはバックアップソフトウェアではなくて、ExchangeのReplicationサービス - トランザクションログが作成されたタイミングのチェックポイントがログファイルに埋め込まれている - DAGのコピーノード毎にどこまでログの切り詰めをしていいか報告される - 一番わかい番号までログのきりつめを行えると判断されるが、実際には”checkpoint depth”の分だけは消さずに残しておく - 切り詰めされるのはきちんと増分バックアップされているファイルのみ - “Checkpoint at log creation time”はeseutil /ml <ログファイル名>”で確認できる 要は、きちんとバックアップが成功していても、チェックポイントとして100程度、実際のファイル数としてはそれ以上のログファイルが残っているのが正常だ、ということです。 今回の検証環境では200ファイル程度ログファイルが残っており、確かに最新のログと最古のログとでチェックポイントとして100の違いがありました。

先日DPMのバックアップロジックについて改めて確認しました。まだ把握しきれていないのですが、私はかなり誤解をしていたようです。「15分おきに同期される」というイメージが強く何から何まで…とは言わなくても大部分がそういう管理をされているのかと思い込んでいたのですが実際に調べてみると全然違いました。(※まだ確認中なので誤解が含まれている可能性が高いです。ご注意ください。) 現時点の私の理解は以下です。 - 15分おきに同期をする。それはディスクのミラーリングが同期的にやられているのに対して、非同期で時間差を持ってやっているイメージ。つまり、極端な言い方をすると「遅い」。 - 回復可能なポイントの作成は別途スケジュールされて行われる。これはVSSを使っている。同期をどれだけ頻繁にやっても結局回復ポイントを作らなければリストア可能なポイントは増えない。 - 高速完全バックアップをしないと同期対象にならず、したがってリストアもできない。 新規に作成されたファイルがリストア可能になるのは高速完全バックアップが行われたあと。 - **ファイルのバックアップはこのような感じだが、他の「アプリケーション」っていうのは色々あるしロジックも個別に全部異なる。** 例えばSQL Server15分おきの同期のタイミングでログを取得する、DB本体との同期は行わない。これによって任意のタイミングにリストア可能になる(=ファイルの回復ポイントとの依存関係も無い)。 - **下手に「15分おきに同期されます」という説明を注釈をつけずに行うと嘘になる。** ここまで理解して以下のバックアップ設定の意味がわかるようになりました。 あとは、個別の「アプリケーション」についてそれぞれどのような挙動になっているのかを見ていく必要があるようです。以下は一例ですがDPMやバックアップ対象のバージョンによってこのロジック自体も変更になっている(改善されている)ようですので注意が必要なようです。 - [DPM 2012] DPM 2012 SP1 における Hyper-V バックアップのロードマップ - Japan System Center Support Team Blog - Site Home - TechNet Blogs [http://blogs.technet.com/b/systemcenterjp/archive/2012/06/20/3504815.aspx](http://blogs.technet.com/b/systemcenterjp/archive/2012/06/20/3504815.aspx) CSV 1.0、すなわち Windows Server 2008 R2 の CSV 環境ですと、VM のバックアップは高速完全バックアップ、つまり前回のバックアップからの差分のみの転送が出来ず、毎回、VHD ファイルを全て読み出し・比較するという事が必要であり、それに伴ってバックアップ速度は非常に遅かったのですが、CSV 2.0 ではこれに対しての改善が図られています。 また、勉強する上では以下の記事がかなりデザイン周り含めて参考になりましたので紹介しておきます。 - DPM Protection Group Design Considerations - AuTechHeads Blogs [http://www.autechheads.com/blogs/entryid/252/dpm-protection-group-design-considerations](http://www.autechheads.com/blogs/entryid/252/dpm-protection-group-design-considerations) DPMも色々と奥が深いですね。 ...

SystemCenter関連の記事は以下のブログに移行しました。 - [System Center Blog](http://ebi.dyndns.biz/systemcenter/) この記事は以下の記事に移行しました。 - [DPMのバックアップロジック | System Center Blog](http://ebi.dyndns.biz/systemcenter/2013/05/08/dpm%E3%81%AE%E3%83%90%E3%83%83%E3%82%AF%E3%82%A2%E3%83%83%E3%83%97%E3%83%AD%E3%82%B8%E3%83%83%E3%82%AF/)

※今回は番外編です。メーカーの保障も私の保証もありません(笑)。 バックアップソフトウェアって、リストアソフトウェアじゃないよね 私が思うに、「バックアップソフトウェア」は、あくまでも「バックアップ」用であって、「リストア」用ではないです。メーカーの出しているマニュアルの手順どおりに操作を行っても「バックアップしたとおりには戻らない」「導入している製品ごとに個別にリストア手順を確立する必要がある」というのが当たり前です。フルバックアップしたものをフルリストアしても動かないなんてひどいじゃないですか。 一方、素敵にバックアップが取得できて、素敵に戻ってくれるのがディスクイメージングツールです。そもそも別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時間もあればロールバック含めて完了するでしょう?戻らない可能性なんてほぼ無いでしょう?準備も必要ないでしょう? というわけで、今回は無責任なことを言って終わりにします。あまり真に受けないでください。