- 重複排除の削減効果を計算してみよう！ [2020/04/27]
- バックアップウインドウとスケールアウト [2020/03/19]
- ターゲット型バックアップ重複排除処理の種類 [2020/03/04]
- VMに適切な重複排除バックアップストレージの条件 [2020/02/25]
- 重複排除バックアップストレージの意外な盲点 [2020/02/18]
- Macrium Reflect7 Free Edition のバックアップ操作説明 [2019/02/22]
- 見事に失敗！「復元ポイント」からのシステム復元 [2018/03/09]
- Reflect v6 Free（バックアップフリーソフト）の使い方 ー リストア編 [2017/07/17]
重複排除の削減効果を計算してみよう！
だいぶ前から考えていたのですが、バックアップにおける重複排除の効果、これをどう説明したらよいか？ にチャレンジしてみました。
教科書的なパターン（ポリシー）で、バックアップデータの保管容量に重複排除がどれほど効果があるか理論上の計算になります。簡単にするため容量のみの表にしています。バックアップストレージの速度がわかればバックアップ時間も表に追加することは簡単です。
では、いろいろな前提や条件、仮定を以下に列挙します。
バックアップポリシー
各曜日の業務終了後にバックアップを実施
- 日曜日：フルバックアップ
- 月～土：増分バックアップ
バックアップ対象データ
- プライマリーストレージのデータ：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」の記事では、月曜日にフルバックアップを行い、土曜と日曜日にはデータの増加がない、という前提の表になっています。また説明文中に「差分バックアップ」とありますが、これは「増分バックアップ」の誤り？と理解して今回の表を作成しました。
以上です。
すべての記事をまとめた★カテゴリーごとの全記事一覧★がありますのでご覧ください。
以下のバナーをクリックいただくと、とても励みになります！
[Ctrl]キーを押しながらクリックすると他のページに飛びません
バックアップウインドウとスケールアウト
- はじめに
長くなりそうなので結論を先にします。重複排除バックアップストレージでは、バックアップ速度のみではなくリストア速度も重要という説明をしてきました。今回は「アップグレードの方法」にも配慮が必要、という内容です。
- バックアップウインドウ
バックアップウインドウですが、『データバックアップのために使用できる時間枠』のことです。最近では、業務アプリケーションの稼働時間が長くなってきているため、バックアップに割ける時間は限られています。バックアップウインドウを長くとることは避けたいのです。
例えば、平日の深夜にバックアップウインドウが3時間とれるとして、このバックアップウインドウ内でバックアップ運用を設計し運用を始めたとします。当初は良いのですが、時間の経過とともにバックアップ運用が所定のバックアップウインドウに収まりきれない状態になります（バックアップ時間が2時間、2時間半、3時間超、というように増えてきます）。なぜなら、データ量が増加するからです（参考『世界データ生成量』）。ごく自然な話です。
データ量の増加への対応はストレージ容量を増加することで解決できます。多くの重複排除バックアップストレージは「シェルフ」追加で容量のみを増設するアップグレードで対応していきます。容量への対応という点ではなんら問題はありません（それぞれ装置によって容量増設の限界はありますが）。
しかし、『時間』の側面はどうでしょう。容量のみ増加のアップグレードではバックアップ時間が長くなることは避けられません。
- スケールアップとスケールアップ
一般のストレージ装置の話になりますが、アップグレードには「スケールアップ」と「スケールアウト」があるのはご存じかと思います。専用の重複排除バックアップストレージにも、この二種類のアップグレード方法があります。容量の増加のみにシェルフ追加で対応するのが「スケールアップ」で、容量と重複排除エンジン能力の増加に対応するのが「スケールアウト」です。専用の重複排除バックアップストレージの多くは「スケールアップ」型となります。まだ多くはありませんが、重複排除バックアップストレージでも「スケールアウト」型もあります。
- 重複排除バックアップストレージでのスケールアップとスケールアウト
スケールアップ型の重複排除バックアップストレージで問題になるのは、バックアップウインドウに収まらなくなった時のアップグレードです。これまでの装置では時間枠に収まらないので、高処理能力の上位機種に上位機種にそっくり置き換え（入れ替え）なければなりません。これを「フォークリフトアップグレード」なんていったりします（フォークリフトを使って装置を運ぶイメージ）。それまでの投資を捨てることになりますし、置き換えですから、システムの停止も伴います。
スケールアウト型では、アップグレード時に容量だけではなく重複排除エンジンのリソースも追加しますので、バックアップ時間の増加を抑えます。所定のバックアップウインドウ内に収められることで、バックアップ運用を長く継続できます。装置の増設においては、これまでの装置と混在して継続使用できますので、投資を有効に活用できます。たいてい運用を止めずにアップグレードが可能です。
- まとめ
重複排除バックアップストレージでの重要な要素は、バックアップ速度、リストア速度、アップグレード方式、になります。個人的な意見ですが。
- 補足
関連する過去記事として、「複排除バックアップストレージの意外な盲点」「VMに適切な重複排除バックアップストレージの条件」「ターゲット型バックアップ重複排除処理の種類」があります。
データの増加に関しては、データアーカイブの検討が有効で価値がありますが、今回はデータアーカイブには言及しません。バックアップにのみ着目して単純化した内容です。データアーカイブについては、ちょっと古くなりましたが「データ駆動型社会を支えるデータアーカイブ」という過去記事をご覧ください。
すべての記事をまとめた★カテゴリーごとの全記事一覧★がありますのでご覧ください。
以下のバナーをクリックいただくと、とても励みになります！
[Ctrl]キーを押しながらクリックすると他のページに飛びません
ターゲット型バックアップ重複排除処理の種類
反省を込めた内容です。
ターゲット型バックアップ重複排除ストレージについては、『いつ重複排除が行われるか』というタイミングによって、「Inline（インライン）」型と「Post-Process（ポストプロセス）」型に分類されるのは、ITのストレージ関係者にはよく知られていることかと思います。
このブログでも2015年に「インライン」型と「ポストプロセス」型の対比表を紹介したことがありました。その当時は、この二つのタイプのみが存在して、バックアップには「ポストプロセス」型から発展して出現した「インライン」型の重複排除が市場での事実上の標準であり、「インライン」型を採用すればバックアップ対応に特に問題はない、との思い込みがありました。しかし、バックアップを検討するにあたっては、リストアへの考慮を抜きにしてはいけない、とのことから処理方式を調べなおしてみました。そして分かった内容から、「重複排除バックアップストレージの意外な盲点」と「VMに適切な重複排除バックアップストレージの条件」の２つの記事をアップしました。
さて、インラインとポストプロセスの2種類以外に「Adaptive（アダプティブ）」という処理方式があることが分かったため、今回はそれを含めた比較表を作成してみました。なお、説明を簡略化するため、レプリケーション処理は省略してあります（基本的に、レプリケーションは重複排除と同じタイミングで開始）。
データ取り込み（ingest:インジェスト）時の動作による分類
| 分類 | インライン |
アダプティブ （ランディングゾーン使用） |
ポストプロセス |
| 重複排除のタイミング（バックアップサーバーからデータを受信したときの振る舞い） |
|
|
|
| プラス面 |
|
|
|
| マイナス面 |
|
|
|
＊「アダプティブ」処理の記述については、個人的に理解した内容です。もう少し知りたい場合は、例えばExaGridの情報が参考になるかと思います。なお、記載内容につきましても個人的な見解であり、間違いがないことを保証するものではないことをご了承ください。
すべての記事をまとめた★カテゴリーごとの全記事一覧★がありますのでご覧ください。
以下のバナーをクリックいただくと、とても励みになります！
[Ctrl]キーを押しながらクリックすると他のページに飛びません
VMに適切な重複排除バックアップストレージの条件
堅い話が続いて大変すみません！
現在ではバックアップする対象はデータだけではなく、VM（仮想マシン）そのものが対象になることが多くなっています。
VMでシステムを構築している場合には、その環境を重複排除ストレージにバックアップすると重複排除率が高く効果的ということは良く知られています。そのため、バックアップ先のストレージとして、ターゲット型重複排除ストレージが多くの場で使われています。
通常、バックアップしてあるVMを復旧するには
- 故障したプライマリーストレージを復旧
- 重複排除バックアップストレージからプライマリーストレージからリストア
という作業となります。
上記の１および、特に２ですが、他のトピックで説明しましたようにインライン重複排除バックアップからのリストア処理には時間がかかります。リストアが遅いとそれだけ業務停止時間が長くなりビジネスへの影響が大きくなります。
ところで、バックアップアプリケーションによっては、バックアップイメージファイルからリストアなどの作業を行わずに、バックアップしたストレージからVMを起動できる機能を持っています。『バックアップストレージから直接VMを起動できる』（即時的なVMリカバリー）機能があれば、上記の１と２の作業完了を待たなくとも（暫定的なVMとして）業務を数分で再開でき業務の停止時間を最小限に抑えられます。とても有効な機能です。
しかし、アプリケーション側にそのような機能があっても、インライン重複排除バックアップ装置からVMを起動するときには、重複排除されたVMの状態からRehydrate（再水和、再構成）してもとのVMイメージに戻すのに長時間（数時間）かかってしまいますので、せっかくのバックアップアプリの即時的なVMリカバリー機能が全く生かせないことになります。
VMのバックアップに重複排除バックアップ装置は大変に効果があることは確かです。さらにリストアが短時間に済めば、もっと効果的です。バックアップの策定には必ずリストアを含めて考えると良いですね。
参考サイト：
- 重複排除バックアップの高速リストアについて（ExaGrid）
- バックアップアプリのVM即時起動について（Veeam Instant VM Recovery）
すべての記事をまとめた★カテゴリーごとの全記事一覧★がありますのでご覧ください。
以下のバナーをクリックいただくと、とても励みになります！
[Ctrl]キーを押しながらクリックすると他のページに飛びません
重複排除バックアップストレージの意外な盲点
少々専門的な内容です。
エンタープライズ系のバックアップでは、ターゲット型の重複排除ストレージが多く採用されていて、市場での実質的なスタンダードとなっています。それらの製品群では、CPUの高速化や搭載メモリの大容量化そして処理の進化などが進み、重複排除を「インライン」で処理することが常識化してしまっています。そこに疑問を投げかける人はまずいないようです。
『バックアップで大容量のデータ容量が大幅に縮小されバックアップ速度もまずまず高速だから、何が問題なのか？』という質問は当然です。
故障に関することではありません。一言でいうと、『リストアスピードが遅い』のです。
インライン重複排除ストレージの本質的な仕組みのため、現在の装置ではリストアの速度はバックアップ時の速度の「数分の1」になります。多分、この実態を知らないで導入していることは多いと思います。バックアップはリストアとセットで考えるべきなのですが、リストア時の事態が想定されていないことが多そうです。装置メーカー側もこのことを話題にはしませんし。
バックアップ時間を8時間で済むように装置を選定した場合、例えばリストア速度がバックアップ速度の「5分の1」に遅くなると、データのリストアには40時間（約1.7日）かかることになってしまいます。これでは、あまりよいバックアップ装置とは言えません。
（なぜ、リストア速度がバックアップ速度よりもかなり遅くなるかの原因は、このトピックの最後に説明しますが、ちょっと面倒な内容なので飛ばしても構いません。）
リストア速度はバックアップ速度よりもかなり遅くなることを考えずにバックアップの設計を進めてはいけないことを意識すべきです。
ターゲット型重複排除ストレージを調べてみると、その中にもリストアがバックアップ速度と変わらない（遅くならない）製品もありました。しかし日本ではその道の専門家にもあまり知られていません。
例えば、ExaGridという製品ですが、これはインラインとは異なる「Adaptive」型というアーキテクチャを採用してます。その結果、インライン同等のバックアップ速度を実現しながら、リストアもバックアップと同じ速度を実現しているようです。「ポストプロセス」という古いアーキテクチャとは異なっているユニークな製品ですね。内容を調べてみたら、意外と面白い製品でした。リストアも高速というのが、役に立つバックアップといえると思います。
（以下の説明は、あまり正確性を追求しておりませんがご参考まで）
インライン処理では、データをストレージに格納する前に重複排除を行う。バックアップサーバーから送られてきた大量のデータを受ける側（ターゲット型重複排除装置）が自身の内部のストレージ（主にHDD)に保存する前に重複排除処理を行う。そうすると、バックアップ装置に保存されるデータのすべては重複排除された形式（元のデータとは全く異なるそれぞれがユニークな小片の集まり）となる。これをそのまま元の装置（主にプライマリーストレージ）に戻しても使えない。本来の元のデータに戻すため（リストア）には、『rehydrate』、直訳では再水和、という大量の小片群から必要なものを引っ張り出して元のデータ形式に戻すコンピューティング集中型の処理が必要になる。これがリストアで時間が長くかかる原因となる。
データの重複排除というのは、部品と設計図に展開する作業に例えるとイメージしやすいかと思う。バックアップ時には、元のデータ（製品に相当）を重複しないユニークな部品に分解して、その部品がどの場所に使われているかを設計図とする。リストア時には、この設計図をもとにしてばらばらの部品群から必要な部品を見つけ出してもとの製品を組み立てる作業に似ている。これがとてもとても時間がかかる処理になる。
すべての記事をまとめた★カテゴリーごとの全記事一覧★がありますのでご覧ください。
以下のバナーをクリックいただくと、とても励みになります！
[Ctrl]キーを押しながらクリックすると他のページに飛びません
Macrium Reflect7 Free Edition のバックアップ操作説明
以前（2017.07.13）「Reflect v6 Free（バックアップフリーソフト）の使い方 ー バックアップ編」という記事をアップしました。
(参考：Reflect 8 については、Windows および Linux イメージバックアップ編｜Macrium Reflect 8 に操作説明があります ← 2023年01月22日追記)
2018年にすでにバージョン7（Reflect7）がリリースされていることは、「見事に失敗！「復元ポイント」からのシステム復元」の記事で触れましたが、特に操作説明は行ってきませんでした。
この度、改めてReflect7のバックアップ操作のスクリーンショットを取り直しましたので、バックアップ操作をスクリーショットで説明します。前回同様、レスキューディスクを作成し、そのディスクから起動する操作になりますが、WindowsにインストールしたReflect7を起動してバックアップする操作にも使えるはずです。
システム環境：
- Windows 10 Home 64ビット
- 内蔵ドライブ１台（Windowsとデータ用の２パーティション構成）
- バックアップデータ保管用にUSB経由で外付けドライブ接続
注）バックアップを保管するドライブは、識別できるようにドライブ名を設定しておくことをお勧めします。間違いを防ぐことができ操作が楽になります。ここでは、「backup$WD1000」としています。
以下のスクリーンショットの配列に工夫はしておりません。ただ上から下にダラダラと並べてあるだけです。スクリーンショット中の赤字説明を参考にしてください。赤字説明以外の本文での説明は最小限になります。
では、Reflect7レスキューディスク起動のスクリーショットから始めます。
キー入力を待ってます。素早く何らかのキーを押してください
勝手に進行します
自動的に起動します
Reflect7起動直後です
追加説明なしです
追加説明なしです
追加説明なしです
追加説明なしです
①この例では、バックアップデータ保管のドライブとして「backup$WD1000」を使っていますので、ドライブ名が「backup$WD1000」あることを確認してください
スクロールして、バックアップデータを保管するドライブを選択します
追加説明なしです
バックアップデータ保管用のドライブが選択されているか、ドライブレターを確認してください
①この例では「年月日」のフォルダーを作ってバックアップデータを保管しています。キーマップが英語キーボードになっていますので、記号の文字を使わないことをお勧めします。
追加説明なしです
backupファイル名はデフォルトのままでも良いです。続いて「Advanced Options」を選択することをお勧めします
追加説明なしです
ブランクから変更します
追加説明なしです
四角で囲った箇所を確認したら、<Finish>でバックアップを実行します
初期化が始まり、バックアップの速度がチェックされています
あとは勝手に進行します
進行していきます
進行中です
進行中です
Verify（バックアップデータの確認）が始まりました
Verifyが進行中です
Verify（バックアップデータの確認）が無事終了してバックアップが完了です
<Close>してください
バックアップしたデータが圧縮されていることがわかります
終了操作です
とくに説明はありません
スクリーンショットに書き込んだ説明を参考にしてください
以上までがバックアップ操作のスクリーンショットになります。
以下は、バックアップ時にエラーが起きたときのスクリーンショットです。あまり目にすることはないと思いますので、参考までに掲載します。
バックアップデータを格納するドライブをフォーマットし直すなどのチェックが必要ですが、交換するのが無難です！何らかの異常が発生している可能性があります。
追記（2023.01.22）
- エラー発生の原因には上記ストレージの不良以外も考えられます。USB/SATA 変換ケーブルを使用しているときは、その変換ケーブルに問題がある場合もあります。PC 側の接続 USB ポート に問題があることも考えられます。別ポートに接続するか、変換ケーブルを交換するなどで対応してみてください。
- Reflect 8 の操作説明は、Windows および Linux イメージバックアップ編｜Macrium Reflect 8をご覧ください。
すべての記事をまとめた★カテゴリーごとの全記事一覧★がありますのでご覧ください。
以下のバナーをクリックしていただくと、とても励みになります！
[Ctrl]キーを押しながらクリックすると他のページに飛びません
見事に失敗！「復元ポイント」からのシステム復元
前触れもなく、あるソフト（アプリ）が起動しなくなりました。
経理用に使っているアプリです。『･････ 起動モジュールは動作を停止しました』というメッセージを排出して、起動不能です。
この時期、原因を探して解決策を考える時間がもったいないので、正常な状態のときの「復元ポイント」からシステムを復元すべく「システムの復元」を試みました。システム領域の空き容量は150GB程度ありますので、問題ないはずです。
しかし、見事に失敗しました。ブート不能の深みにはまった、その顛末記です！
システムの復元が進みPCが再起動するのですが、以下のメッセージが表示されて、うまく復元できないのです。
セーフモードにして復元ポイントからのシステム復元を行っても、上記と同様『正しく完了しませんでした。･･･』が表示されます。
次に、復元ポイントをもう少し古い時点のものにして再度行ってみましたら、ブルースクリーン（ブルーバック）のコード「0xc000021a」を発生するという状態になりました。その後、自動的に修復状態に入るのですが修復不能、つまりブート不能の状態になってしまいました。
Windowsインストールメディアからシステム領域を修復することも考えたのですが、どうせ修復しても目的のアプリが起動しない状態に戻るのであまり意味がありません。ましてや、作業に時間をかけたくありません。
そこで、約20日前に作成しておいたイメージバックアップからシステムをリストア（復旧/復元）することにしました。バックアップを作成した時点では、すべて正常な状態でしたので、この時点にシステムを戻すことにしたのです。
リストアは、過去に何度も行っている操作です。簡単にもとの正常な状態に戻りました。目的のアプリも問題なく起動します。作業は、1時間もかかりません。
復元ポイントを使う「システムの修復」はお手軽かと思っていましたが、とんでもありませんでした。最初からバックアップデータからリストアした方が、復旧が早かったようです。
このWindowsの「システムの修復」がうまくいかないという情報はWeb上でかなり見かけます。それからみると「バックアップ/リストア」の方が確実ですね。
バックアップ/リストアに使っているのは、Macrium Reflectの無料版です。その記事は、過去のトピックにあります。その記事はバージョン6（v6）で説明してありますが、現行バージョンのv7でも基本機能と操作に大きな違いはありません。
バックアップ編:
>http://yvernis.blog.fc2.com/blog-entry-64.html
リストア編：
バックアップは「転ばぬ先の杖」ですので、ぜひ取っておくことをお勧めします。今回のこの例のように、障害から確実に復旧できる手段となります。
Reflect v6 Free（バックアップフリーソフト）の使い方 ー リストア編
