ワイヴァンアイエス研究所ブログ

ストレージシステムやITの技術動向やテクノロジーなどを紹介。その他、趣味的な話題もあります
ワイヴァンアイエス研究所ブログ TOP  >  バックアップ/リストア

重複排除の削減効果を計算してみよう!

だいぶ前から考えていたのですが、バックアップにおける重複排除の効果、これをどう説明したらよいか? にチャレンジしてみました。


教科書的なパターン(ポリシー)で、バックアップデータの保管容量に重複排除がどれほど効果があるか理論上の計算になります。簡単にするため容量のみの表にしています。バックアップストレージの速度がわかればバックアップ時間も表に追加することは簡単です。


では、いろいろな前提や条件、仮定を以下に列挙します。

バックアップポリシー

各曜日の業務終了後にバックアップを実施

  • 日曜日:フルバックアップ
  • 月~土:増分バックアップ

バックアップ対象データ

  • プライマリーストレージのデータ:10TB(初期値)

データ増加率

  • 月~金曜:0.2%
  • 土曜日:0.05%(少数の休日業務などを考慮)
  • 日曜日:0%(データ増加なし)

データにある重複部

  • 重複部の検出率(10%)

上記のポリシーや条件(仮定)で、4週間(28日間)にわたってバックアップを継続し、28日間のバックアップデータを保管した時の計算が以下の表となります。


表の最後の行の赤枠の2箇所にご注目ください。通常のバックアップでは、約41.1TBの容量を格納するストレージが必要となります。一方、重複排除バックアップでは約9.39TBの容量を格納できるストレージでよいのです。重複排除の効果によって、約「4.4分の1」のサイズとなっています。


(計算あってるかな? 間違いがなければいいんですが…)


ちなみに、同条件でこの計算を繰り返しバックアップ期間を3か月間(12週、84日)とした場合、通常のバックアップに必要な保管容量は約129TBとなりますが、重複排除バックアップにすると約10.2TBで済みます。保管するバックアップデータ量は約「12分の1」になります。


つまり、バックアップを重複排除ストレージで行うと、通常のストレージ(ストレートディスク)に比べてはるかに少ない容量サイズのストレージ装置でバックアップデータを保管できることがわかります。


また、日々のデータの増加率が高くなると重複排除効果は低くなり、データに重複部分が多い(重複部分の率が高い)と当然のことながら重複排除効果は高まります。

参考記事:

上記の計算は「@IT」の「重複排除とは何か(2/2)」記事を参考にさせていただき、それに独自の変更を加えました。「@IT」の記事では、月曜日にフルバックアップを行い、土曜と日曜日にはデータの増加がない、という前提の表になっています。また説明文中に「差分バックアップ」とありますが、これは「増分バックアップ」の誤り?と理解して今回の表を作成しました。

以上です。



すべての記事をまとめた★カテゴリーごとの全記事一覧★がありますのでご覧ください。


以下のバナーをクリックいただくと、とても励みになります!

にほんブログ村 IT技術ブログ IT技術情報へ

[Ctrl]キーを押しながらクリックすると他のページに飛びません

[ 2020年04月27日 12:40 ] カテゴリ:バックアップ/リストア | TB(0) | CM(0)

バックアップウインドウとスケールアウト

  • はじめに

長くなりそうなので結論を先にします。重複排除バックアップストレージでは、バックアップ速度のみではなくリストア速度も重要という説明をしてきました。今回は「アップグレードの方法」にも配慮が必要、という内容です。

  • バックアップウインドウ

バックアップウインドウですが、『データバックアップのために使用できる時間枠』のことです。最近では、業務アプリケーションの稼働時間が長くなってきているため、バックアップに割ける時間は限られています。バックアップウインドウを長くとることは避けたいのです。

例えば、平日の深夜にバックアップウインドウが3時間とれるとして、このバックアップウインドウ内でバックアップ運用を設計し運用を始めたとします。当初は良いのですが、時間の経過とともにバックアップ運用が所定のバックアップウインドウに収まりきれない状態になります(バックアップ時間が2時間、2時間半、3時間超、というように増えてきます)。なぜなら、データ量が増加するからです(参考『世界データ生成量』)。ごく自然な話です。

データ量の増加への対応はストレージ容量を増加することで解決できます。多くの重複排除バックアップストレージは「シェルフ」追加で容量のみを増設するアップグレードで対応していきます。容量への対応という点ではなんら問題はありません(それぞれ装置によって容量増設の限界はありますが)。

しかし、『時間』の側面はどうでしょう。容量のみ増加のアップグレードではバックアップ時間が長くなることは避けられません。

  • スケールアップとスケールアップ

一般のストレージ装置の話になりますが、アップグレードには「スケールアップ」と「スケールアウト」があるのはご存じかと思います。専用の重複排除バックアップストレージにも、この二種類のアップグレード方法があります。容量の増加のみにシェルフ追加で対応するのが「スケールアップ」で、容量と重複排除エンジン能力の増加に対応するのが「スケールアウト」です。専用の重複排除バックアップストレージの多くは「スケールアップ」型となります。まだ多くはありませんが、重複排除バックアップストレージでも「スケールアウト」型もあります。

  • 重複排除バックアップストレージでのスケールアップとスケールアウト

スケールアップ型の重複排除バックアップストレージで問題になるのは、バックアップウインドウに収まらなくなった時のアップグレードです。これまでの装置では時間枠に収まらないので、高処理能力の上位機種に上位機種にそっくり置き換え(入れ替え)なければなりません。これを「フォークリフトアップグレード」なんていったりします(フォークリフトを使って装置を運ぶイメージ)。それまでの投資を捨てることになりますし、置き換えですから、システムの停止も伴います。

スケールアウト型では、アップグレード時に容量だけではなく重複排除エンジンのリソースも追加しますので、バックアップ時間の増加を抑えます。所定のバックアップウインドウ内に収められることで、バックアップ運用を長く継続できます。装置の増設においては、これまでの装置と混在して継続使用できますので、投資を有効に活用できます。たいてい運用を止めずにアップグレードが可能です。

  • まとめ

重複排除バックアップストレージでの重要な要素は、バックアップ速度、リストア速度、アップグレード方式、になります。個人的な意見ですが。

  • 補足

関連する過去記事として、「複排除バックアップストレージの意外な盲点」「VMに適切な重複排除バックアップストレージの条件」「ターゲット型バックアップ重複排除処理の種類」があります。

データの増加に関しては、データアーカイブの検討が有効で価値がありますが、今回はデータアーカイブには言及しません。バックアップにのみ着目して単純化した内容です。データアーカイブについては、ちょっと古くなりましたが「データ駆動型社会を支えるデータアーカイブ」という過去記事をご覧ください。



すべての記事をまとめた★カテゴリーごとの全記事一覧★がありますのでご覧ください。


以下のバナーをクリックいただくと、とても励みになります!

にほんブログ村 IT技術ブログ IT技術情報へ

[Ctrl]キーを押しながらクリックすると他のページに飛びません

[ 2020年03月19日 19:30 ] カテゴリ:バックアップ/リストア | TB(0) | CM(0)

ターゲット型バックアップ重複排除処理の種類

反省を込めた内容です。

ターゲット型バックアップ重複排除ストレージについては、『いつ重複排除が行われるか』というタイミングによって、「Inline(インライン)」型と「Post-Process(ポストプロセス)」型に分類されるのは、ITのストレージ関係者にはよく知られていることかと思います。


このブログでも2015年に「インライン」型と「ポストプロセス」型の対比表を紹介したことがありました。その当時は、この二つのタイプのみが存在して、バックアップには「ポストプロセス」型から発展して出現した「インライン」型の重複排除が市場での事実上の標準であり、「インライン」型を採用すればバックアップ対応に特に問題はない、との思い込みがありました。しかし、バックアップを検討するにあたっては、リストアへの考慮を抜きにしてはいけない、とのことから処理方式を調べなおしてみました。そして分かった内容から、「重複排除バックアップストレージの意外な盲点」と「VMに適切な重複排除バックアップストレージの条件」の2つの記事をアップしました。


さて、インラインとポストプロセスの2種類以外に「Adaptive(アダプティブ)」という処理方式があることが分かったため、今回はそれを含めた比較表を作成してみました。なお、説明を簡略化するため、レプリケーション処理は省略してあります(基本的に、レプリケーションは重複排除と同じタイミングで開始)。


データ取り込み(ingest:インジェスト)時の動作による分類

分類 インライン

アダプティブ

(ランディングゾーン使用)

ポストプロセス
重複排除のタイミング(バックアップサーバーからデータを受信したときの振る舞い)
  • 直ちに重複排除を開始
  • ディスク(ストレージ)に保存する過程(途中)で重複排除
  • ディスクには重複排除された形式でのみ格納(バックアップアプリのネイティブフォーマット形式では保存されない)
  • ランディングゾーン(特定のディスク領域)への書き込みとともに、重複排除を適応的(ランディングゾーンへの書き込みを最優先)に実行
  • ディスク(ストレージ)には、バックアップアプリのネイティブフォーマットのイメージおよび重複排除されたデータの二種類が保存
  • ランディングゾーン(特定のディスク領域)へ格納
  • その後に重複排除を開始
  • ディスクには、バックアップアプリのネイティブフォーマットイメージおよび重複排除されたデータの二種類が保存
プラス面
  • バックアップイメージをストレージ上に保持する特定領域が不要(ポストプロセス型に比べて必要なストレージ容量は約1/2)
  • 現在の主流で、市場における事実上の標準
  • 技術が最新の印象
  • データ取り込みの終了に重複排除処理の影響を受けない(バックアップサーバーから見て重複排除処理のオーバーヘッドを気にせずに完了)
  • リストアは高速(ランディングゾーンのバックアップイメージがそのまま使える場合は重複排除されたデータを再構成する処理が不要)
  • データ取り込みの終了に重複排除処理の影響を受けない(バックアップサーバーから見て重複排除処理のオーバーヘッドを気にせずに完了)
  • リストアは高速(ランディングゾーンのバックアップイメージがそのまま使える場合は重複排除されたデータを再構成する処理が不要)
  • 重複排除処理に必要な高性能なCPUやメモリーなどにかけるコストが少なくて済む
マイナス面
  • データの取り込み時に重複排除処理のオーバーヘッドが発生することがある
  • リストア速度はバックアップ速度と比較してかなり低速(ランディングゾーンを使用した方式と比べて低速)
  • 重複排除処理に高性能なCPUやメモリー容量などが必要(CPUやメモリーなどにコストがかかる)
  • ネイティブのバックアップイメージを保持する特定の領域が別途必要(インライン型に比べて約2倍のストレージ容量)
  • 市場での認知度が低い
  • ネイティブのバックアップイメージを保持する特定の領域が別途必要(インライン型に比べて約2倍のストレージ容量)
  • 技術が古い印象

*「アダプティブ」処理の記述については、個人的に理解した内容です。もう少し知りたい場合は、例えばExaGridの情報が参考になるかと思います。なお、記載内容につきましても個人的な見解であり、間違いがないことを保証するものではないことをご了承ください。



すべての記事をまとめた★カテゴリーごとの全記事一覧★がありますのでご覧ください。


以下のバナーをクリックいただくと、とても励みになります!

にほんブログ村 IT技術ブログ IT技術情報へ

[Ctrl]キーを押しながらクリックすると他のページに飛びません

[ 2020年03月04日 12:25 ] カテゴリ:バックアップ/リストア | TB(0) | CM(0)

VMに適切な重複排除バックアップストレージの条件

堅い話が続いて大変すみません!

現在ではバックアップする対象はデータだけではなく、VM(仮想マシン)そのものが対象になることが多くなっています。


VMでシステムを構築している場合には、その環境を重複排除ストレージにバックアップすると重複排除率が高く効果的ということは良く知られています。そのため、バックアップ先のストレージとして、ターゲット型重複排除ストレージが多くの場で使われています。


通常、バックアップしてあるVMを復旧するには

  1. 故障したプライマリーストレージを復旧
  2. 重複排除バックアップストレージからプライマリーストレージからリストア

という作業となります。


上記の1および、特に2ですが、他のトピックで説明しましたようにインライン重複排除バックアップからのリストア処理には時間がかかります。リストアが遅いとそれだけ業務停止時間が長くなりビジネスへの影響が大きくなります。


ところで、バックアップアプリケーションによっては、バックアップイメージファイルからリストアなどの作業を行わずに、バックアップしたストレージからVMを起動できる機能を持っています。『バックアップストレージから直接VMを起動できる』(即時的なVMリカバリー)機能があれば、上記の1と2の作業完了を待たなくとも(暫定的なVMとして)業務を数分で再開でき業務の停止時間を最小限に抑えられます。とても有効な機能です。


しかし、アプリケーション側にそのような機能があっても、インライン重複排除バックアップ装置からVMを起動するときには、重複排除されたVMの状態からRehydrate(再水和、再構成)してもとのVMイメージに戻すのに長時間(数時間)かかってしまいますので、せっかくのバックアップアプリの即時的なVMリカバリー機能が全く生かせないことになります。


VMのバックアップに重複排除バックアップ装置は大変に効果があることは確かです。さらにリストアが短時間に済めば、もっと効果的です。バックアップの策定には必ずリストアを含めて考えると良いですね。


参考サイト:

  • 重複排除バックアップの高速リストアについて(ExaGrid
  • バックアップアプリのVM即時起動について(Veeam Instant VM Recovery



すべての記事をまとめた★カテゴリーごとの全記事一覧★がありますのでご覧ください。


以下のバナーをクリックいただくと、とても励みになります!

にほんブログ村 IT技術ブログ IT技術情報へ

[Ctrl]キーを押しながらクリックすると他のページに飛びません

[ 2020年02月25日 12:20 ] カテゴリ:バックアップ/リストア | TB(0) | CM(0)

重複排除バックアップストレージの意外な盲点

少々専門的な内容です。

エンタープライズ系のバックアップでは、ターゲット型の重複排除ストレージが多く採用されていて、市場での実質的なスタンダードとなっています。それらの製品群では、CPUの高速化や搭載メモリの大容量化そして処理の進化などが進み、重複排除を「インライン」で処理することが常識化してしまっています。そこに疑問を投げかける人はまずいないようです。


バックアップで大容量のデータ容量が大幅に縮小されバックアップ速度もまずまず高速だから、何が問題なのか?』という質問は当然です。


故障に関することではありません。一言でいうと、『リストアスピードが遅い』のです。


インライン重複排除ストレージの本質的な仕組みのため、現在の装置ではリストアの速度はバックアップ時の速度の「数分の1」になります。多分、この実態を知らないで導入していることは多いと思います。バックアップはリストアとセットで考えるべきなのですが、リストア時の事態が想定されていないことが多そうです。装置メーカー側もこのことを話題にはしませんし。


バックアップ時間を8時間で済むように装置を選定した場合、例えばリストア速度がバックアップ速度の「5分の1」に遅くなると、データのリストアには40時間(約1.7日)かかることになってしまいます。これでは、あまりよいバックアップ装置とは言えません。


(なぜ、リストア速度がバックアップ速度よりもかなり遅くなるかの原因は、このトピックの最後に説明しますが、ちょっと面倒な内容なので飛ばしても構いません。)


リストア速度はバックアップ速度よりもかなり遅くなることを考えずにバックアップの設計を進めてはいけないことを意識すべきです。


ターゲット型重複排除ストレージを調べてみると、その中にもリストアがバックアップ速度と変わらない(遅くならない)製品もありました。しかし日本ではその道の専門家にもあまり知られていません。


例えば、ExaGridという製品ですが、これはインラインとは異なる「Adaptive」型というアーキテクチャを採用してます。その結果、インライン同等のバックアップ速度を実現しながら、リストアもバックアップと同じ速度を実現しているようです。「ポストプロセス」という古いアーキテクチャとは異なっているユニークな製品ですね。内容を調べてみたら、意外と面白い製品でした。リストアも高速というのが、役に立つバックアップといえると思います。


(以下の説明は、あまり正確性を追求しておりませんがご参考まで)

インライン処理では、データをストレージに格納する前に重複排除を行う。バックアップサーバーから送られてきた大量のデータを受ける側(ターゲット型重複排除装置)が自身の内部のストレージ(主にHDD)に保存する前に重複排除処理を行う。そうすると、バックアップ装置に保存されるデータのすべては重複排除された形式(元のデータとは全く異なるそれぞれがユニークな小片の集まり)となる。これをそのまま元の装置(主にプライマリーストレージ)に戻しても使えない。本来の元のデータに戻すため(リストア)には、『rehydrate』、直訳では再水和、という大量の小片群から必要なものを引っ張り出して元のデータ形式に戻すコンピューティング集中型の処理が必要になる。これがリストアで時間が長くかかる原因となる。

データの重複排除というのは、部品と設計図に展開する作業に例えるとイメージしやすいかと思う。バックアップ時には、元のデータ(製品に相当)を重複しないユニークな部品に分解して、その部品がどの場所に使われているかを設計図とする。リストア時には、この設計図をもとにしてばらばらの部品群から必要な部品を見つけ出してもとの製品を組み立てる作業に似ている。これがとてもとても時間がかかる処理になる。



すべての記事をまとめた★カテゴリーごとの全記事一覧★がありますのでご覧ください。


以下のバナーをクリックいただくと、とても励みになります!

にほんブログ村 IT技術ブログ IT技術情報へ

[Ctrl]キーを押しながらクリックすると他のページに飛びません

[ 2020年02月18日 07:40 ] カテゴリ:バックアップ/リストア | TB(0) | CM(0)

Macrium Reflect7 Free Edition のバックアップ操作説明

以前(2017.07.13)「Reflect v6 Free(バックアップフリーソフト)の使い方 ー バックアップ編」という記事をアップしました。


2018年にすでにバージョン7(Reflect7)がリリースされていることは、「見事に失敗!「復元ポイント」からのシステム復元」の記事で触れましたが、特に操作説明は行ってきませんでした。


この度、改めてReflect7のバックアップ操作のスクリーンショットを取り直しましたので、バックアップ操作をスクリーショットで説明します。前回同様、レスキューディスクを作成し、そのディスクから起動する操作になりますが、WindowsにインストールしたReflect7を起動してバックアップする操作にも使えるはずです。


システム環境:

  • Windows 10 Home 64ビット
  • 内蔵ドライブ1台(Windowsとデータ用の2パーティション構成)
  • バックアップデータ保管用にUSB経由で外付けドライブ接続


注)バックアップを保管するドライブは、識別できるようにドライブ名を設定しておくことをお勧めします。間違いを防ぐことができ操作が楽になります。ここでは、「backup$WD1000」としています。


以下のスクリーンショットの配列に工夫はしておりません。ただ上から下にダラダラと並べてあるだけです。スクリーンショット中の赤字説明を参考にしてください。赤字説明以外の本文での説明は最小限になります。


では、Reflect7レスキューディスク起動のスクリーショットから始めます。


Reflect7op_p05.gif

キー入力を待ってます。素早く何らかのキーを押してください


Reflect7op_p06.gif

勝手に進行します


Reflect7op_p07.gif 

自動的に起動します


Reflect7op_p08.gif

Reflect7起動直後です


Reflect7op_p09.gif

追加説明なしです


Reflect7op_p10.gif

追加説明なしです


Reflect7op_p11.gif

追加説明なしです


Reflect7op_p12.gif

追加説明なしです


Reflect7op_p13.gif

①この例では、バックアップデータ保管のドライブとして「backup$WD1000」を使っていますので、ドライブ名が「backup$WD1000」あることを確認してください


Reflect7op_p14.gif

スクロールして、バックアップデータを保管するドライブを選択します


Reflect7op_p15.gif

追加説明なしです


Reflect7op_p16.gif

バックアップデータ保管用のドライブが選択されているか、ドライブレターを確認してください


Reflect7op_p17.gif

①この例では「年月日」のフォルダーを作ってバックアップデータを保管しています。キーマップが英語キーボードになっていますので、記号の文字を使わないことをお勧めします。


Reflect7op_p18.gif

追加説明なしです


Reflect7op_p19.gif

backupファイル名はデフォルトのままでも良いです。続いて「Advanced Options」を選択することをお勧めします


Reflect7op_p20.gif

追加説明なしです


Reflect7op_p21.gif

ブランクから変更します


Reflect7op_p22.gif

追加説明なしです


Reflect7op_p23.gif

四角で囲った箇所を確認したら、<Finish>でバックアップを実行します


Reflect7op_p24.gif

初期化が始まり、バックアップの速度がチェックされています


Reflect7op_p25.gif

あとは勝手に進行します


Reflect7op_p26.gif

進行していきます


Reflect7op_p27.gif

進行中です


Reflect7op_p28.gif

進行中です


Reflect7op_p30.gif

Verify(バックアップデータの確認)が始まりました


Reflect7op_p31.gif

Verifyが進行中です


Reflect7op_p32.gif

Verify(バックアップデータの確認)が無事終了してバックアップが完了です


Reflect7op_p33.gif

<Close>してください


Reflect7op_p34.gif

バックアップしたデータが圧縮されていることがわかります


Reflect7op_p35.gif

終了操作です


Reflect7op_p36.gif

とくに説明はありません


Reflect7op_p37.gif

スクリーンショットに書き込んだ説明を参考にしてください


以上までがバックアップ操作のスクリーンショットになります。


以下は、バックアップ時にエラーが起きたときのスクリーンショットです。あまり目にすることはないと思いますので、参考までに掲載します。

Reflect7op_p38.gif

バックアップデータを格納するドライブをフォーマットし直すなどのチェックが必要ですが、交換するのが無難です!何らかの異常が発生している可能性があります。



すべての記事をまとめた★カテゴリーごとの全記事一覧★がありますのでご覧ください。


以下のバナーをクリックしていただくと、とても励みになります!

にほんブログ村 IT技術ブログ IT技術情報へ

[Ctrl]キーを押しながらクリックすると他のページに飛びません

[ 2019年02月22日 10:25 ] カテゴリ:バックアップ/リストア | TB(0) | CM(0)

見事に失敗!「復元ポイント」からのシステム復元

前触れもなく、あるソフト(アプリ)が起動しなくなりました。


経理用に使っているアプリです。『・・・・・ 起動モジュールは動作を停止しました』というメッセージを排出して、起動不能です。


この時期、原因を探して解決策を考える時間がもったいないので、正常な状態のときの「復元ポイント」からシステムを復元すべく「システムの復元」を試みました。システム領域の空き容量は150GB程度ありますので、問題ないはずです。


しかし、見事に失敗しました。ブート不能の深みにはまった、その顛末記です!


システムの復元が進みPCが再起動するのですが、以下のメッセージが表示されて、うまく復元できないのです。

メッセージ
システムの復元は正しく完了しませんでした。システムの復元は、復元ポイントからディレクトリの復元中に失敗しました。・・・・・

セーフモードにして復元ポイントからのシステム復元を行っても、上記と同様『正しく完了しませんでした。・・・』が表示されます。


次に、復元ポイントをもう少し古い時点のものにして再度行ってみましたら、ブルースクリーン(ブルーバック)のコード「0xc000021a」を発生するという状態になりました。その後、自動的に修復状態に入るのですが修復不能、つまりブート不能の状態になってしまいました。


Windowsインストールメディアからシステム領域を修復することも考えたのですが、どうせ修復しても目的のアプリが起動しない状態に戻るのであまり意味がありません。ましてや、作業に時間をかけたくありません。


そこで、約20日前に作成しておいたイメージバックアップからシステムをリストア(復旧/復元)することにしました。バックアップを作成した時点では、すべて正常な状態でしたので、この時点にシステムを戻すことにしたのです。


リストアは、過去に何度も行っている操作です。簡単にもとの正常な状態に戻りました。目的のアプリも問題なく起動します。作業は、1時間もかかりません。


復元ポイントを使う「システムの修復」はお手軽かと思っていましたが、とんでもありませんでした。最初からバックアップデータからリストアした方が、復旧が早かったようです。

このWindowsの「システムの修復」がうまくいかないという情報はWeb上でかなり見かけます。それからみると「バックアップ/リストア」の方が確実ですね。


バックアップ/リストアに使っているのは、Macrium Reflectの無料版です。その記事は、過去のトピックにあります。その記事はバージョン6(v6)で説明してありますが、現行バージョンのv7でも基本機能と操作に大きな違いはありません。


バックアップ編:

>http://yvernis.blog.fc2.com/blog-entry-64.html


リストア編:

>http://yvernis.blog.fc2.com/blog-entry-67.html

バックアップは「転ばぬ先の杖」ですので、ぜひ取っておくことをお勧めします。今回のこの例のように、障害から確実に復旧できる手段となります。


ランキングに参加しています。

以下のバナーをクリックしていただくと、とても励みになります!

にほんブログ村 IT技術ブログ IT技術情報へ


見やすい★カテゴリーごとの記事一覧★もご参照ださい。

[ 2018年03月09日 20:51 ] カテゴリ:バックアップ/リストア | TB(0) | CM(0)

Reflect v6 Free(バックアップフリーソフト)の使い方 ー リストア編

 今回は「Reflect v6 Free(バックアップフリーソフト)の使い方 ー バックアップ編」で保存したバックアップイメージを使ってリストアする操作です。

レスキューディスクから起動 → Windowsシステムを含めたデータをリストア

<リストア>
バックアップイメージを使って復元することが「リストア」です。リストアによって、バックアップイメージを保存した時点の状態に戻すことができます。この方法を使えば、ランサムウェアなどへの感染やシステムに異常を発生する前の正常な状態に戻すことができます。当然ながら、システムが正常な時点でバックアップイメージを保存してある、ということが前提となります。

【1】 レスキューディスクから起動
 reflect61-s.png
 BIOSの設定で、CD/DVDドライブから起動させます。上のように「Press any key to boot from CD or DVD..」が表示されたら、スペースバーやリターンキーなどを押してください。押さないと、通常のWindowsが起動してしまいます。

【2】 Windows PEの起動画面
 reflect62-s.png
 このまま待ちます。Windowsマークが出るまでしばらく黒い画面の状態が続きます。

【3】 Reflect v6の起動画面
 reflect63-s.png
 このまま待ちます。

【4】 Reflect v6の初期画面
 restore01-ss.png
 「Restore」タブが選択されています。「Browse for an image file...」をクリックして、リストア(復元)するバックアップイメージを指定します。

【5】 バックアップイメージの選択
 ドライブの指定
 restore02-ss.png
 この例では、「F:」のMXbackupDiskという名前のドライブにバックアップイメージを保存してありますので、このドライブをダブルクリックするか、選択して「Open」をクリックして指定します。

 フォルダーの指定
 restore03-ss.png
 フォルダー「reflect6」をダブルクリックするか、選択して「Open」をクリックして指定します。

 イメージの指定
 restore04-ss.png
 リストアできるバックアップイメージが2個(2回分)表示されています。ここでは「20170713-00-00」のほうをダブルクリックするか、選択してから「Open」をクリックして指定します。

【5】 リストア
 restore05-ss.png
 「Restore Image」をクリックします。

 restore10-ss.png
 「Source」(復元するバックアップイメージ)として、対象のパーティションが選択(チェック)されていることを確認します。この例では、DとCです。
 「Copy selected partions when I click 'Next'」にチェックがついていることを確認して、「Next>」をクリックします。

 restore11-ss.png
 「Restore Summary」には、リストアに使うバックアップイメージ名、復元されるパーティション、SSDなら「Trim」処理が行われることなどの情報が表示されます。確認したら、「Finish」をクリックします。

 restore13-ss.png
 パーティションCとDが上書きされること「WARNING: The following drives will be overwritten」が警告として表示されます。復元のため上書きしますので「Continue...」をクリックします。

 restore14-s.png
 リストア処理が開始します。リストア先(destination)がSSDの場合、リストア処理に自動的にTrim処理が行われます。復元する前にSSDに「Trim」処理をしたくないときは、事前に「Advanced Options」から「SSD Trim」項目で、「Enable TRIM on restore」のチェックを外します(この記事の最後に説明)。

 restore15-ss.png
 リストア処理が完了したら、「Close」をクリックします。

【9】 リストア処理の終了とWindowsの再起動
 restore16-ss.png
 CD/DVDドライブに入っているレスキューディスクを取り出してください。右上の「X」をクリック、または左上の「File」タブから「Exit」と進むとPCの再起動に移ります。タスクバーの左端にあるマークからも再起動できます。(「Reflect v6 Free(バックアップフリーソフト)の使い方 ー バックアップ編」の【13】と同じ方法です)

 以上の操作によって、バックアップイメージを作った時点の状態にシステムとデータを復元することができます。

 PCが正常なときにバックアップを取って(バックアップイメージを作成)おけば、ウィルス・マルウェア感染(ランサムウェアなど)にあったとしても、慌てる必要はありません。リストア処理によって対処が可能になります。

 以下は、オプション的な操作の説明です。

【A】 バックアップイメージのベリファイ(Verify)
 バックアップイメージを作成した後、または、リストアを実施する前に、バックアップイメージを確認(Verify)を行うことができます。
 restore09-ss.png 
 「Verify Image」をクリックします。

 restore06-s.png
 確認処理が進行します。

 restore07-ss.png
 成功すれば「Image Successfully Verified」が表示されますので、「OK」をクリックして終了します。

【B】 SSD使用時Trimのオン・オフ
「Restore Summary」のウィンドウ
 restore21-ss.png
 「Advanced Options」を選択します。

 restore12-ss.png 
 「SSD Trim」をクリックして、「Enable TRIM on restore」項目を確認します。チェックが入っていれば、リストア先(destination、復元先)がSSDの場合、リストアする前にTrim処理を行います。デフォルトでチェックがついていますので、何もしなくともSSDにリストアする前にTrim処理が入ります。


ランキングに参加しています。
 ↓ 以下のバナーをクリックしていただくと、とても励みになります!
 にほんブログ村 IT技術ブログ IT技術情報へ
[ 2017年07月17日 19:14 ] カテゴリ:バックアップ/リストア | TB(0) | CM(0)