06:10前回の「完全」バックアップは納得のいかないものでした。「常に増分バックアップを実行する」にしておきました。昨日(=一週間後)またしても「完全」バックアップが実行されたのです・・・まとめると・パフォーマンス設定の構成は(GUI上からは)機能していない・一週間毎に完全バックアップが実行されるが、その他は増分バックアップディスクの使用量は相変わらず微増でして、とても3回完全バックアップをしたとは思えません。同一のファイルがあれば記録しないとかいう感じなのかもしれません。このあたりは良くできていると感じています。22:29訂正の訂正・・・というか、意味不明です。完全バックアップを始めています。それと異なると書きました。バックアップの運用を始めて一週間ですが、順調に増分データを作っていました。本日のバックアップは「完全」バックアップで、またしてもシステムがハング状態となったのです。オプションは「常に完全バックアップを実行する」に設定しているので、正しい動きではあります。この一週間の増分データは一体何だったんでしょうか?ヘルプを読み返しましたが、肝心の「パフォーマンス設定の構成...」に関する記述がない~元々、完全バックアップで運用するつもりだったので、時間が掛かったりするのはOKです。意図しない動きをは大変困ります。これは問い合わせをした方がいいのかも?追記:先ほどバックアップが終了しました。約250GBほど利用しています。動作原理が私の理解とは大きく異なっていることを示します。VSSと密接にリンクしています。完全バックアップといっても、驚くほどデータの圧縮がされるのかもしれません。バックアップ(=WSB)に対して大きな誤解をしていました。WSBの場合、パフォーマンスの最適化オプションとして・常に完全バックアップを実行するバックアップの速度は遅くなりますが、全体的なパフォーマンスに影響はありません。・常に増分バックアップを実行するバックアップの速度は速くなりますが、シャドウコピーが後に残るため、ボリュームのパフォーマンスが低下する場合があります。ハードディスクを多用するアプリケーションがあるサーバーにはお勧めしません。・カスタム完全バックアップと増分バックアップのどちらを実行するかをボリュームごとに指定できます。完全バックアップ=>指定したボリュームの完全なコピーイメージ増分バックアップ=>完全バックアップ以降の増分データイメージとなり、完全バックアップで出来上がるイメージファイルがバックアップの基本な訳です。「増分バックアップ」に対応するのです。完全バックアップ=>シャドウコピーファイルを作り直す増分バックアップ=>シャドウコピーファイルを作り置きしておくという違いなわけです。非常に時間がかかる&システム負荷がかかる作業です。短時間&システム負荷は軽めとなります。初回さえ乗り切ればそれほど心配する事なくバックアップが進んでいくのでした。WSBはOSを含めたシステムの復旧ができるハズです。01:18サーバー環境のバックアップを少しずつ構築しています。単純に負荷が高いというより、何かの条件が揃ったらいきなり無反応という感じです。接続されているモデルでして、300GB程のバックアップに4時間かかる感じです・・・遅いけど、予想の範囲。解消されるかも?この辺もテストしてみたいところです。バックアップをスケジュール起動する場合、ドライブをバックアップ専用にします。ファイルとして認識できない、つまり、出来上がったイメージファイルを他の場所にコピー出来ないという仕様になっています。テープドライブと決別したと思ったら、HDDがテープの代わりになっていました・・・笑えない。同様に、HDDを丸ごとイメージ化することができます。