サーバーのバックアップ5

by manamana 24. February 2009 06:10

前回の「完全」バックアップは納得のいかないものでした。
そこで、パフォーマンス設定の構成を 「常に増分バックアップを実行する」にしておきました。

当然のように増分バックアップが繰り返されていったわけですが、
昨日(=一週間後)またしても「完全」バックアップが実行されたのです・・・

まとめると
・パフォーマンス設定の構成は(GUI上からは)機能していない
・一週間毎に完全バックアップが実行されるが、その他は増分バックアップ

ディスクの使用量は相変わらず微増でして、とても3回完全バックアップをしたとは思えません。
もしかすると、バックアップ結果にもVSSが反映されていて、
同一のファイルがあれば記録しないとかいう感じなのかもしれません。
このあたりは良くできていると感じています。

謎は深まります 

Tags:

Server

サーバーのバックアップ4

by manamana 16. February 2009 22:29

訂正の訂正・・・というか、意味不明です。
"Windows Server バックアップ" が完全バックアップを始めています。

先日、完全バックアップと増分バックアップが TrueImage のそれと異なると書きました。
バックアップの運用を始めて一週間ですが、順調に増分データを作っていました。
しかし、本日のバックアップは「完全」バックアップで、またしてもシステムがハング状態となったのです。

オプションは「常に完全バックアップを実行する」に設定しているので、正しい動きではあります。
しかし、この一週間の増分データは一体何だったんでしょうか?
ヘルプを読み返しましたが、肝心の「パフォーマンス設定の構成...」に関する記述がない~

元々、完全バックアップで運用するつもりだったので、時間が掛かったりするのはOKです。
でも、意図しない動きをは大変困ります。
これは問い合わせをした方がいいのかも? 


追記:
先ほどバックアップが終了しました。
現在バックアップ対象となっているドライブC: D: は約250GBほど利用しています。
今回、完全バックアップが二度行われているので、250GB ほど追加で消費されるはず・・・
しかし、HDDの消費量は全体で263GBであり、殆ど増えていません!!
これは、WSB の動作原理が私の理解とは大きく異なっていることを示します。

WSB は、VSSと密接にリンクしています。
VSS はデータそのものの情報というより、データの変更履歴情報といった性格なので、
完全バックアップといっても、驚くほどデータの圧縮がされるのかもしれません。
ちょっと修行してきます。 

Tags:

Server

サーバーのバックアップ3

by manamana 10. February 2009 09:20

Windows Server バックアップ(=WSB)に対して大きな誤解をしていました。

WSBの場合、パフォーマンスの最適化オプションとして
  ・常に完全バックアップを実行する
   バックアップの速度は遅くなりますが、全体的なパフォーマンスに影響はありません。
  ・常に増分バックアップを実行する
   バックアップの速度は速くなりますが、シャドウコピーが後に残るため、ボリュームのパ
   フォーマンスが低下する場合があります。ハードディスクを多用するアプリケーション
   があるサーバーにはお勧めしません。 
  ・カスタム
   完全バックアップと増分バックアップのどちらを実行するかをボリュームごとに指定でき
   ます。
の3つを選択できます。

True Image にも「完全バックアップ」や「増分バックアップ」という用語があり、
  完全バックアップ=>指定したボリュームの完全なコピーイメージ
  増分バックアップ=>完全バックアップ以降の増分データイメージ
となり、完全バックアップで出来上がるイメージファイルがバックアップの基本な訳です。

しかし、WSBの場合、True Image の「完全バックアップ」に対応するそれは、
一回目のバックアップで出来上がる VHD ファイルであり、
二回目以降のバックアップは、True Image の「増分バックアップ」に対応するのです。
私はこの辺を混合していたのでした・・・

では、WSB の完全バックアップや、増分バックアップというのは何かといえば、
バックアップ作業に先んじて作られる、シャドウコピーファイルの扱いの違いで、
  完全バックアップ=>シャドウコピーファイルを作り直す
  増分バックアップ=>シャドウコピーファイルを作り置きしておく
という違いなわけです。

WSBの一回目のバックアップは、システムファイルも含めた完全なバックアップで、
非常に時間がかかる&システム負荷がかかる作業です。
しかし、二回目以降は(True Imageでいう)増分バックアップとなり、
短時間&システム負荷は軽めとなります。 
当初、WSBでの運用は苦しいかも?と思っていましたが、
初回さえ乗り切ればそれほど心配する事なくバックアップが進んでいくのでした。

WSBはOSを含めたシステムの復旧ができるハズです。
そのうち時間を作って復旧テストもやらなければ~

Tags:

Server

サーバーのバックアップ2

by manamana 9. February 2009 01:18

サーバー環境のバックアップを少しずつ構築しています。
標準の Windows Server バックアップを使うつもりでテストしてみたところ、
思った以上に負荷が高く、システム全体が無反応になってしまってさあ大変・・・
単純に負荷が高いというより、何かの条件が揃ったらいきなり無反応という感じです。
※このサイトも参照不能だったはず

バックアップ用のHDDは USB2.0 で接続されているモデルでして、
300GB程のバックアップに4時間かかる感じです・・・遅いけど、予想の範囲。
無反応に陥るのは USB2.0 が原因とも考えられ、e-SATA なら解消されるかも?
この辺もテストしてみたいところです。 

Windows Server バックアップをスケジュール起動する場合、ドライブをバックアップ専用にします。
ところがこれ、ドライブレターを与えられず、Explore からファイルとして認識できない、
つまり、出来上がったイメージファイルを他の場所にコピー出来ないという仕様になっています。
テープドライブと決別したと思ったら、HDDがテープの代わりになっていました・・・笑えない。

こんな感じで試行錯誤していましたが、gigazine に気になる記事が・・・
Windowsが起動したままの状態でハードディスクをまるごとイメージ化できるフリーソフト「Macrium Reflect FREE Edition」
紹介されている Macrium Reflect は、 True Image と同様に、HDDを丸ごとイメージ化することができます。
Free バージョンは Win2008 の様な Server にはインストールできませんが、正式版は Win2008 に対応しています。
そして驚くことに、お値段 $39.99 ・・・や、安い。価格破壊? 
日本語版とかはありませんが、記事通りの内容なら買いです。

Tags:

Server

サーバーのバックアップ

by manamana 5. February 2009 23:45

Windows Server 2008 のバックアップ体制をどうしようか検討していましたが、
大体の方針が決まりました。

Win2008 に備わる「Windows Server バックアップ」は、Win2003 までのそれとは大きく違います。
ファイルやフォルダー単位のバックアップが出来ない代わりに、
ボリューム単位(≒ドライブ単位)でのバックアップに重点が置かれ、
システムを含めたバックアップ&復旧を実現しています。

我が家の場合、C: システム D: データ という構成で、これがバックアップ対象です。
S: シャドウコピー を用意し、毎日のバックアップとします。
Z: バックアップ を用意し、Windows Server バックアップを用いて週毎に C: D: をバックアップします。

シャドウコピーは、事実上ファイル単位のバックアップになります。
ネットワーク越しに削除されたファイルも復活できるので手放せません。
Vista シャドウコピーは採用されていますがサブセットでしかありません。
Win2008 仕様のシャドウコピーなら歓迎されると思います。

Z: のバックアップは、システム丸ごとのバックアップです。
これが使われる状況にはあまり合いたくないですが、転ばぬ先の杖といった所です。
ミラーリングというのも有効ですが、私のシステムでは運用しながらのリビルドに非対応なので
このスタイルの方が都合が良いのです。
Windows Server バックアップは、世代管理も自動化されるので、大きめのHDDが有利です。

本当は使い慣れた TrueImage で運用したいところですが、
残念なことに Server OS にはインストールできません。
もちろん Server 版もありますが価格的に躊躇します。
Windows Server バックアップは、細かい指定は出来ませんが、
OS の丸ごとバックアップに対応しているのが嬉しいところです。

OS が稼働しながらのバックアップなので多少の不安がありますが、
VSS(=Volume Shadow  copy Service) がうまく稼働すればたぶん大丈夫・・・のはず。
そのうち復旧試験もしてみます。


追記:
自動バックアップをしようとすると、専用のドライブが必要になるとは・・・
そうすると、イメージファイルの持ち出しやコピーがやりにくい。困った。
Hyper-V のバックアップにはおまじないが必要。
スケージューラの制限が厳しい。毎日は不要=>タスクスケジューラで調節。

Tags:

Server


スポンサーリンク

Calendar

<<  October 2024  >>
SunMonTueWedThuFriSat
293012345
6789101112
13141516171819
20212223242526
272829303112
3456789

View posts in large calendar

Month List

Twitter