「合成フルバックアップ」とは：システム管理者が知っておくべき事実
バックアップには、フルバックアップ、増分バックアップ、差分バックアップなど、複数の方法があります。フルバックアップは時間がかかり、ハードウェアリソースを消費するため、頻繁に実行するのは不便であるばかりか、技術的に不可能な場合もあります。そのような場合、増分バックアップと synthetic full バックアップの手法は役立つことがあります。
このブログ記事では、その内容について解説します。 synthetic full バックアップとは何か、またアクティブ・フルとの違いは forever-incremental バックアップの手法。
とは Synthetic Full バックアップ？
A synthetic full バックアップとは、前回の完全バックアップおよび関連する増分バックアップを利用して、新しい完全バックアップを作成する手法です。つまり、バックアップソリューションはソースマシンから全データを転送する必要がなく、最新の増分バックアップと前回の完全バックアップを統合して、次の synthetic full バックアップ。
どのように Synthetic Full バックアップ作業？
まず、で用いられる完全更新法と増分更新法について見てみましょう synthetic full バックアップ。また、以下の内容についても取り上げます forever-incremental バックアップ。これらは、合成バックアップといくつかの共通点を持っています。
完全バックアップ
A 完全バックアップ これは、ソースマシンからターゲットストレージへすべてのデータをコピーする作業です。フルバックアップの利点は、信頼性が高く、データの復元が容易かつ迅速に行えることです。ソースマシンからすべてのデータを直接コピーするフルバックアップは、 active full バックアップ.
現代のバックアップソリューションでは、従来のバックアップ手法を採用し、定期的にフルバックアップを実行する必要があります。しかし、仮想マシンや物理マシンのフルバックアップのみに依存するアプローチには、次のような欠点があります:
- バックアップに時間がかかりすぎる。
- フルバックアップを作成すると、インフラストラクチャのリソース(プロセッサ、ディスクドライブ、メモリ)とネットワークの両方に余分な負荷がかかります。
- ソースサーバー上で実行されている仮想マシンなどの処理速度が低下する可能性があります。
- 時間の経過とともにフルバックアップの履歴が蓄積されるにつれ、バックアップデータの量は膨大になり、バックアップリポジトリ内のストレージ容量を大量に消費するようになります。
増分バックアップ
ある 増分バックアップ 前回のフルバックアップまたは増分バックアップ以降に変更されたデータのみをコピーするものです。増分バックアップは高速であり、フルバックアップのようにデータセット全体を保存するよりも、変更されたデータ分のストレージ容量で済みます。
増分バックアップの連鎖を使用してデータを復元する場合、複数の増分バックアップの連鎖を用いて"変更ログを再生"し、データを再構築する必要があるため、フルバックアップに比べて時間がかかります。 データ復元のために再生する必要がある増分バックアップの数が多いほど、復旧にかかる時間は長くなります。
もう一つの欠点は、一連の増分バックアップのうち1つが破損している場合、その増分バックアップ以降にバックアップされたデータを復元できないことです。これが、通常、定期的に完全バックアップを作成し、それを incremental-with-full 信頼性の高いデータ保護戦略のためのバックアップ手法。
定期的にフルバックアップを作成しても、本番環境のマシンやネットワークに負荷がかかることは変わりません。そこで、 synthetic full そこでバックアップの出番だ。
Synthetic full バックアップ
Synthetic full バックアップでは、前回の完全バックアップと、それに続く増分バックアップの連鎖を使用して、 合成する 定期的に新しいフルバックアップを作成します。この場合、ソースマシンからデータがコピーされないため、本番サーバーやソースサーバー、ディスク、ネットワークに負荷がかかりません。バックアップストレージ内の増分バックアップが、このバックアップを作成するためのソースとして使用されます。 synthetic full バックアップ。バックアップサーバーとターゲットディスク(バックアップが保存される場所)のみが読み込まれます。
Using synthetic full backupは、高速で本番環境のマシンに依存しないため、定期的なフルバックアップを作成するのに最適な方法です。それでは、その具体的な例を見てみましょう。 synthetic full バックアップは正常に動作します。
例として full synthetic バックアップ
ディスク上に4つのブロック(A、B、C、D)があり、そのうちいくつかは毎日変更されるとします。変更後、 1 がブロック名に追加されます。たとえば、ブロックAが変更された場合、その名前は A1. もしブロック A1 再び変更され、次のように名前が変更されます A2、などなど。
バックアップサイクルは、毎週日曜日にフルバックアップを作成するように設定されています。増分バックアップは毎日1回作成されます。
日曜日は day 1 バックアップスケジュールに組み込み、下図のように最初のアクティブ完全バックアップを作成します。すべてのデータがソースサーバーからバックアップ先のサーバーにコピーされます。
1週間後、 synthetic full バックアップは日曜日に行われます(day 8) を作成する代わりに active full バックアップ。この場合、前回の増分バックアップから完全バックアップが生成されます。データは、日曜日に作成された最初の完全バックアップを使用して組み立てられます(day 1) およびそれに続く増分バックアップの連鎖(days 2 ～へ 7)。その結果、私たちは synthetic full 日曜日のバックアップ(day 8) とブロック (A4, B4, C1, D1).
日曜日のバックアップリポジトリ内のデータセット(day 8) はソースサーバー上のものと同じです(A4, B4, C1, D1)。ただし、変更されたブロックのデータのみ(B4, D1)は日曜日(day 8) アクティブ・フル・バックアップを実行してすべてのデータをコピーする代わりに、増分バックアップを実行することで、バックアップリポジトリにデータを追加します。
その結果、日曜日にフル・バックアップが作成されます(8)以下の2つの操作を行った後:増分バックアップの作成と、 full synthetic バックアップ。
週に1回のフルバックアップと毎日の増分バックアップを行うバックアップ構成を用いて、ソースサーバーからバックアップサーバーへどれだけのデータがコピーされるかを具体的に見てみましょう。これまでと同様に、毎週日曜日にフル合成バックアップを作成します。説明を簡単にするため、ソースサーバーには毎日データが書き込まれるものの、削除は行われないものと仮定します。
その後、 synthetic full バックアップは日曜日(day 8)、その同じ日曜日に作成された増分バックアップは、日曜日のデータを復元できるため削除しても構いません(day 8) 復旧ポイントから synthetic full その日に作成されたバックアップ。
1日1回バックアップを作成し、週に1回完全合成バックアップを作成する場合、毎週のパターンは同じになります。保存期間の設定で、すべてのバックアップを2週間保存する必要がある場合は、2週間以上経過したバックアップ(完全バックアップおよび増分バックアップ)を削除できます。なお、この例では、3回の完全バックアップを保存しておく必要があります。 days 8, 15、および 22、～の増分バックアップの連鎖として days 9-14 は、フルバックアップに依存します day 8.
Forever-incremental バックアップ
Forever-incremental 最初のフルバックアップを1回だけ作成し、それ以降のバックアップはすべて増分バックアップとなります。バックアップデータは、バックアップリポジトリ内のカタログとして一意のブロックに分類されます。依存関係や関連性も追跡されます。この情報により、バックアップリポジトリからデータを再構築することで、必要な復旧時点のデータを復元することができます。
バックアップリポジトリは、アクティブまたは synthetic full 定期的にバックアップを行います。データは、復旧に必要な場合にのみ再構築されます。リカバリポイントの有効期限が切れると、この最も古い増分バックアップは、保持設定(保持するリカバリポイントの数)に基づいて、フルバックアップと統合されます。
Forever-incremental バックアップでは、合成バックアップストレージモードのアプローチを採用しています。このモードの原理は、フルバックアップを一度だけ作成すればよいというものです。その後、 forever-incremental スケジュールに基づいてバックアップが実行され、これらの増分バックアップには、前回のバックアップ以降にソースマシンに加えられた変更のみが含まれます。
合成バックアップを作成するには、バックアップソリューションが、バックアップリポジトリに保存されている初期のフルバックアップとすべての増分バックアップを読み取り、これらのデータを統合してバックアップを作成します。この合成バックアップは、アクティブなフルバックアップと同一であり、特定の時点におけるソースマシンの状態を完全に反映します。
現在のバックアップソリューションは、両方をサポートしています synthetic full バックアップと forever-incremental バックアップ。詳細はこちら その他のバックアップ手法 当ブログで。
なぜ合成バックアップを使うのか？
バックアップを作成する際の合成アプローチには、いくつかの利点があります。具体的には以下の通りです:
- 合成バックアップは、ソースサーバーの負荷を軽減します。これは、合成バックアップが バックアップリポジトリ ソースサーバーを使用するのではなく、
- 合成バックアップでは、ソースサーバーからバックアップリポジトリへ転送されるデータ量が大幅に削減されるため、ネットワークへの負荷が軽減されます。転送するデータ量が少なければ、コピーにかかる時間も短縮され、これにより 改善する
RPO. - 機械や個々のアイテムは、必要な時にいつでも簡単かつ迅速に復元できます。データ復元にかかる時間が短い を改善する
RTO.
Full Synthetic バックアップデータの保存先として NAKIVO Backup & Replication
現代の VMバックアップソリューション, NAKIVO Backup & Replication バックアップの作成と保存には、合成アプローチを採用しています。最初の完全バックアップの後、すべてのジョブは増分バックアップとなり、定期的に完全バックアップが実行されます。 forever-incremental. を使用して CBT そして RCT この技術では、製品は変更されたデータブロックを追跡し、これらのブロックのみをバックアップリポジトリに転送します。
を使用する場合、 forever-increment NAKIVOソリューションの仕組みについて説明します。各バックアップジョブの実行後、リカバリポイントが作成されます。これは、バックアップリポジトリ内の単一プールに格納されたデータブロックへの参照情報の集合です。これらのリカバリポイントを使用することで、特定の時点における必要な仮想マシンを復元することができます。
したがって、バックアップリポジトリ内のデータは、いわゆる"フル・シンセティック・モード"を使用して保存されるため、バックアップ変換が不要となり、定期的なフルバックアップを作成する必要はありません。
フル・シンセティック・モードでは、 NAKIVO Backup & Replication 従来のバックアップ手法を採用した製品に比べて優れている点は、以下の通りです:
- すべてのデータブロックは1回のみ格納され、一意であり、複数のリカバリポイントから参照されることがあります。
- 合成バックアップは、フルバックアップを実行する必要がないため、大幅に高速です。また、各リカバリポイントは、マシン全体の復元に必要なデータブロックを"記憶"しています。
- 合成バックアップは、従来のバックアップに比べてはるかに安全です。データブロックやチェーン内の増分データが失われた場合でも、NAKIVOのソリューションなら復元可能な増分データを提供します。
- 各リカバリポイントは、VMのリカバリにどのデータブロックを使用すべきかをすでに"認識"しているため、リカバリ処理は大幅に高速化されます。
定期的にフルバックアップを作成するバックアップ方式を採用する必要がある場合、NAKIVOソリューションでは定期的に active full バックアップ、または synthetic full バックアップ。フルバックアップモードを選択した画面は、以下のスクリーンショットに示されています。
完全バックアップを作成する頻度を設定できます。たとえば、毎週7日目、5回に1回のバックアップジョブなどです。
柔軟な保存期間の設定や、 GFS 定着支援策 これはNAKIVOのバックアップリポジトリと非常に相性が良いです。
結論
合成バックアップは、従来のバックアップ手法を用いてVMデータをバックアップする代わりに利用できる優れた選択肢です。これにより、VMのバックアップと復旧が容易かつ迅速になり、 RPO そして RTO、インフラリソースやネットワークの負荷を軽減し、時間とコストを節約します。
