IT業界の新人必見！インフラ知識が学べる
  1. TOP
  2. Lv.2_バックアップをもっと学ぶ人が読む記事
更新日：2023-10-02
Level 2　バックアップを少し学んだ人が読む記事

第3章　クラウド編

よく「クラウドバックアップ」「クラウドのLift & Shift」のワードを当たり前のように耳にします。
一見手軽なクラウドですが、従来のオンプレミス環境と同じように考えていたら、環境移行時に痛い目を見てしまうケースも。
本記事は、大きく2つの視点からクラウドバックアップの基礎を学べます。
①オンプレミス環境をクラウドストレージにバックアップする場合 ②クラウド環境をクラウドストレージへバックアップする場合 クラウド環境のメリット・デメリットを押さえた上で、あなたの環境にあった活用方法を選択しましょう！

  1. はじめに押さえよう「クラウドバックアップ」の考え方
    1. オンプレファーストとクラウドファースト
  1. オンプレミス環境をクラウドストレージにバックアップする場合
    1. オブジェクトストレージへのデータ保存
    2. メリット①従来のストレージよりコストが安い
    3. メリット②減価償却の対象外
    4. 注意点①データ復旧時にダウンロード料金がかかる
    5. 注意点②リストア時は細かい単位で復旧しよう
    6. 注意点③DRサイトとしてクラウドを利用する際、バックアップサーバーの電源管理はできるか？
    7. 注意点④クラウドにダイレクトバックアップする構成も考えよう
    8. 注意点⑤クラウドのマルチテナント機能で不要なコスト増加を防ごう
  1. 【番外編】バックアップメーカー独自のクラウドバックアップサービス
    1. Amazon S3やAzure Blob Storageと比べてメリットある？
    2. ポイント①データセンターの場所
    3. ポイント②データ復旧時にダウンロード料金がかからない
    4. ポイント③DR利用の際は、事前に契約が必要
  1. クラウド環境をクラウドストレージへバックアップする場合
    1. クラウドファーストのバックアップ
    2. IaaSのしくみ
    3. IaaSポイント①クラウド独自のハイパーバイザーと連携する
    4. IaaSポイント②マーケットプレイスからバックアップソフトを入手すれば初期設定簡単
    5. IaaSポイント③Amazon Linux対応
    6. PaaSのしくみ
    7. PaaSポイント：独自のデータベース
    8. SaaSのしくみ
    9. SaaSポイント：Microsoft 365のメールはゴミ箱に入れて14日で消えてしまう…
    10. 非構造化データの保存先オブジェクトストレージをバックアップしよう
    11. ファイルサーバーに比べコスト・拡張性で有利
    12. ベンダーロックイン回避
    13. 選定ポイント①リストア時の挙動
    14. 選定ポイント②カタログデータをバックアップサーバー側で保持するか否か
    15. 選定ポイント③レジューム機能
    16. 選定ポイント④オンプレ・クラウドで同じ管理画面
▲目次に戻る

はじめに押さえよう「クラウドバックアップ」の考え方

mamoru_bikkuri.png
城宝　守
博士いよいよクラウド編ですね。なんだかわくわくします。
バックアップ博士
うむ、まず考えて欲しいのが最近はクラウドファーストと言って、クラウド利用を前提として考えている企業もある。だからオンプレには必要最小限の設備しか置かずに基幹システムですらクラウドに置く企業が出てきている。
この様な企業は、日本では比較的まだ少なく、出来立てのベンチャー企業や小規模事業者が多い。これは小規模事業者やベンチャー企業は比較的過去の縛りなどが少なくシステムを移動しやすいことが、クラウドへの移行に起因していることが多い。
hakase.png
mamoru_nayami.png
城宝　守
・・・？？？
クラウドスマートって何ですか？
バックアップ博士
クラウドスマートとは、デジタル庁ガバメントクラウドチームによる新しいクラウドの利用方針じゃ。まずはクラウドの利用を検討する「クラウドファースト」からクラウドを賢く適切に利用する「クラウドスマート」に方針がアップデートされておる。

各府省の政府情報システムは「クラウド・バイ・デフォルト原則」。つまりクラウドサービスの利用を第一候補として検討すること、と規定されている。具体的には以下のような優先順位でプラットフォームを検討しているようじゃ。
hakase.png
オンプレファースト
saaspaasiaas
mamoru_kangaechu.png
城宝　守
なるほど。
なんとなくわかりました。クラウド利用を政府も推進しているんですね。
バックアップ博士
そうじゃな。
まあ課題はいろいろあるようじゃがの…
それはさておき、単にクラウドバックアップと言っても、大きく2通りの使い方がある。
「パブリッククラウドにバックアップ」と、「パブリッククラウドをバックアップ」じゃ。
hakase.png
パブリッククラウドにバックアップ
backup_to_cloud
パブリッククラウドをバックアップ
backup_cloud
mamoru_nayami.png
城宝　守
言っている事はわかりますが、いまいちイメージが湧かないです。

オンプレファーストとクラウドファースト

バックアップ博士
うむ、まず考えて欲しいのが最近はクラウドファーストと言って、クラウド利用を前提として考えている企業もある。だからオンプレには必要最小限の設備しか置かずに基幹システムですらクラウドに置く企業が出てきている。
この様な企業は、日本では比較的まだ少なく、出来立てのベンチャー企業や小規模事業者が多い。これは小規模事業者やベンチャー企業は比較的過去の縛りなどが少なくシステムを移動しやすいことが、クラウドへの移行に起因していることが多い。
hakase.png
オンプレファースト
on-premise_first
クラウドファースト
cloud_first
mamoru_kangaechu.png
城宝　守
なるほど。
やっぱり長年オンプレでシステム運用している企業は、全システムをいきなりクラウドに持っていくのは難しいんですね。
バックアップ博士
そうじゃな。
ただクラウドは構成の柔軟さであったり、使い方によって非常にコストが安くなるメリットがある。クラウドにすべてのリソースを移行できない企業は、まずはクラウドをバックアップやアーカイブなどのデータ保存先として利用することから始める企業が多いんじゃ。
hakase.png
▲目次に戻る

オンプレミス環境をクラウドストレージにバックアップする場合

クラウドのオブジェクトストレージに保存するべき理由

バックアップ博士
パプリッククラウドをバックアップ先として利用する場合から見ていこう。
オンプレミス側からクラウド側へデータをバックアップする際に考えるポイントは3つじゃ。 AWSではS3、AzureではBlob Storageと呼ばれるオブジェクトストレージにデータを保存する際、以下のいずれかの形式や用途で保存している。
hakase.png
①バックアップデータをそのまま
保存 （フォーマット未変換）
unformatted
②DRサイトをクラウドに構築
（フォーマット変換）
format_conversion
③アーカイブデータとして
クラウドに保存
archive_to_cloud
mamoru_nayami.png
城宝　守
博士、なぜクラウド上への保存先はオブジェクトストレージなんですか？
オブジェクトストレージ以外に保存はできないんでしょうか？
バックアップ博士
うん、いいところに気づいたな。
前にも伝えたようにクラウドにはいろんなサービスがある。そのいろいろあるサービスの中で、ストレージサービスとして最も有名なのがAWSならAmazon S3（Simple Storage Service）、AzureならAzure Blob Storageじゃ。
それ以外にもデータを保管するサービスとしてAWSにはEBS（Amazon Elastic Block Store）、EFS（Amazon Elastic File System）がある。
Azureにはマネージドディスク(※1)と言われるサービスがある。
(※1)マネージドディスクの詳細はこちら…https://azure.microsoft.com/ja-jp/services/storage/disks/
hakase.png
AWS
Azure
バックアップ博士
ただしバックアップデータの保存にオブジェクトストレージを利用する決定的な理由がある。それは値段じゃ。
いくら便利でもコストもそれなりに安くなければ、クラウドを利用する価値はない。
hakase.png
▲目次に戻る

メリット①従来のストレージよりコストが安い

バックアップ博士
例えば S3の例で考えると次のように非常にコストメリットがある。
最初の50TBまで0.023USD/GBでざっくり1USD＝130円で計算すれば3.25円/GBである。価格.comでコンシューマー向けの4TBのHDDが9,000円前後（2.2円/GB）で販売されているので、それと比較しても少し高いレベルである。非常に堅牢性も高く、データの管理もしてくれて色んなサービスと連携できるので、これを利用しない手はない。
※2023年8月現在
hakase.png
※2023年8月現在Amazon Simple Storage Service一般ユーザー向けHDD（4TB）
製品 S3 HDD
参考価格0.023USD/GB9,000円
1GBにかかるコスト3.25円/GB
※1ドル＝130円レート		2.2円/GB
従来のストレージ
traditional_storage
クラウドのオブジェクトストレージ
cloud_object_storage
▲目次に戻る

メリット②減価償却の対象外

バックアップ博士
また、機器を購入した場合には通常5年で機器を減価償却するために資産となり、全額経費として計上できないが、クラウドであれば減価償却対象とならないため全額経費として計上できるメリットもある。
hakase.png

減価償却とは

資産購入した場合、購入金額をそのまま経費と計上せず、購入したものの耐用年数に分けて経費計上すること。節税効果が高いので、費用の大きな固定資産を購入した時は減価償却を行った方がお得です。一方、減価償却資産として処理するには経理担当者にとっては結構手間であり、償却資産税にも影響があるデメリットもある。

depreciation
accounting_is_hard
▲目次に戻る

注意点①データ復旧時にダウンロード料金がかかる

バックアップ博士
ただし注意点としてS3などのオブジェクトストレージは通常、データの復旧時に別途ダウンロード料金とAPIリクエスト料金が発生するので注意しなければならない。
hakase.png
egress_cost
mamoru_nayami.png
城宝　守
え～じゃあ怖くて利用できないじゃないですか？
バックアップ博士
そこまで利用料金が高いわけではないので、一応考えとして持っておくレベルでよい。
ちなみにS3 標準のダウンロード料金とAPIリクエスト料金は以下の通りじゃ。
・ダウンロード料金：0.114USD/GBだから14.8円/GB程度。 （9.999TB/月まで）
・APIリクエスト料金：1,000リクエストあたり0.0047USDだから0.611円程度。
月に転送するデータの総量やサービスを提供するリージョンなどによっても異なるので詳細は AWSのサイトで調べてほしい。検索サイトで「AWS S3 料金」 などで検索すればすぐに出てくるぞ。
※2023年8月時点（１ドル＝130円レート）
hakase.png
mamoru_ureshii.png
城宝　守
そうなんですね。安心しました。
▲目次に戻る

注意点②リストア時は細かい単位で復旧しよう

バックアップ博士
通常のバックアップ用途で、毎月たくさんのデータをリストアすることは考えにくい。ただし、バックアップデータを開発等で再利用するなど、大量の保存バックアップデータを再利用（ダウンロード）しなければならない場合は気をつけた方がいい。
このような観点からもデータ復旧の際はファイル単位など、出来るだけ細かい単位でリストアできる製品を選択することも重要になるんじゃ。 1つのファイルをリストアしたいだけなのにボリューム丸ごとダウンロードしてから、1つのファイルをリストアして取り出すのは非効率じゃ。
hakase.png
ボリューム単位でリストア

必要以上にダウンロード料金がかかってしまう…

cost_up
ポリシーべースのバックアップ

必要な分のみダウンロード料金を抑えられる！

cost_down
▲目次に戻る

注意点③DRサイトとしてクラウドを利用する際、バックアップサーバーの電源管理はできるか？

バックアップ博士
他にも、コスト面で注意が必要なのは、クラウドをDRサイトとして利用する場合じゃ。クラウド上のバックアップサーバーの起動とシャットダウンを制御できるかなど、バックアップソフト側の機能を確認する必要がある。
hakase.png
mamoru_bikkuri.png
城宝　守
もう少し詳しく教えてください。
バックアップ博士
よかろう。
前回のLv.1バックアップを最初に学ぶ人が読む記事！「第1章バックアップの基礎」 の復習じゃ。
例えば有事の際にクラウド側でDRサイトを立ち上げるためには、事前に各クラウドのファイルフォーマット形式に合わせて保存しておかなければならない。AWSであればAMI形式、AzureであればVHD形式じゃ。ここまでは理解しておるな？
hakase.png
file_format
mamoru_niyari.png
城宝　守
はいもちろんです。前回やりましたからね。
物理環境のフォーマットのままクラウドにバックアップした場合と、あらかじめクラウドのフォーマットに変換してバックアップした場合を図で説明するとこんな感じですよね。
物理環境のフォーマットのまま
バックアップ
※クラウド環境にバックアップサーバーがない場合

そのままバックアップすると変換の手間は省けるがリストアするときには一度のバックアップサーバーでイメージを復元して使わなければいけない。つまりクラウド環境にバックアップサーバがない場合には一度ダウンロードして復元するなど、利用したいときに即座に利用できない可能性がある。

physical_format
クラウドのフォーマットへ変換して
バックアップ

各クラウド環境に合わせてイメージをバックアップした場合には、クラウド上では仮想サーバーとしていつでもすくに起動できる状態。つまり災害時に即時利用できたりするなどいろんなメリットがある。つまりバックアップを利用するときのことを考えて事前に準備している。

cloud_format
バックアップ博士
そうじゃ。その通り。
そしてここで問題になるのがクラウド側にデータを送った際にデータをAMI形式に変換したり、有事の際にデータをマウントして起動をするなどの管理をするメディアサーバーが、電源ONのままではなく、必要な時だけ起動できるかどうかが重要じゃ。
hakase.png
mamoru_nayami.png
城宝　守
どうして電源管理が重要なんですか？
サーバー関係は基本電源を落とさないほうがいいと新人研修で習いました。
バックアップ博士
確かにサーバー類は電源を落とさないほうがいいという考え方もある。
ただしクラウドになると少し話は変わってくる。
何故ならクラウド上のサーバー（EC2）などは起動している時間で課金をされるからじゃ。だからDRサイトなど常時使わないサイトの電源はコスト削減のために出来れば落としておきたい。その為、電源管理をバックアップソフト側で制御できるかも重要な商品選定のポイントじゃ。
hakase.png
power_management
EC2_Instance
▲目次に戻る

注意点④クラウドにダイレクトバックアップする構成も考えよう

バックアップ博士
また、バックアップ対象を直接クラウド側にバックアップをしたいという顧客の要望も増えている。
hakase.png
mamoru_bikkuri.png
城宝　守
えっ！
オンプレミスのバックアップサーバーを介さないということですか？
通常の構成
normal_configuration
クラウドダイレクト構成
direct_cloud_configuration
バックアップ博士
そうじゃ。
大分理解してきたようじゃな。
hakase.png
mamoru_ureshii.png
城宝　守
直接クラウドに転送できるなんて便利ですね！
バックアップ博士
直接クラウド側に送れるものは、直接クラウドへ転送した方がオンプレミス側にストレージを用意する必要がないためコストメリットは大きい。 ただし、直接クラウドに送る場合、回線速度の影響によっては一旦オンプレミスに保存してから重複排除された差分データをゆっくり転送する方がいい場合もある。 環境によってバックアップの仕方を考える必要があるんじゃ。
hakase.png

本社バックアップサーバーにVPNで経由してクラウドへ転送する構成

via_VPN

直接クラウドへデータを転送する構成

direct_cloud
バックアップ博士
ストレージコストを抑えるため、回線速度が遅いのに大容量なデータの一次バックアップ先をオブジェクトストレージにすると、といつまで経っても時間内にバックアップがおわらない…といったリスクもあるんじゃ。
hakase.png
mamoru_kangaechu.png
城宝　守
なるほど。
ケースバイケースでオブジェクトストレージの使い方を検討する必要がありますね！
▲目次に戻る

注意点⑤クラウドのマルチテナント機能で不要なコスト増加を防ごう

バックアップ博士
次はマルチテナント機能についても伝えておきたい。大きな企業ユーザーになるとバックアップの中でもクラウド用の担当に分かれていたり、グループ別でバックアップ管理者がいたりポリシーが分かれていることはよくあることじゃ。
hakase.png
システムで管理を分ける場合
systematize
社内部署で管理を分ける場合
department

クラウドのマルチテナント機能

cloud_multi-tenancy
バックアップ博士
そんな場合には、クラウドの管理者だけがクラウド上のバックアップのポリシーの割り当て（AWSでいうIAM設定）などを行い、不要なコスト増加を管理しながら未然に防ぐなどが可能である。
hakase.png
mamoru_cry.png
城宝　守
うわーなんだかクラウドにオンプレのデータをバックアップするだけでも色んなポイントを考慮しなければいけないんですね。
バックアップ博士
そうじゃな。
利用用途を明確にして必要な機能を選択することでコストの大幅削減が可能じゃ。
hakase.png
▲目次に戻る

【番外編】バックアップメーカー独自のクラウドバックアップサービス

Amazon S3やAzure Blob Storageと比べてメリットある？

バックアップ博士
では次に大手パブリッククラウドではなく、バックアップメーカー側が独自に用意するクラウドサービスについても確認しておこう。
以下二つのパターンがある。
①バックアップデータを保存するストレージサービス
②Backup as a service（BaaS）
hakase.png
mamoru_tehe.png
城宝　守
・・・？どう違うんですか？
バックアップ博士
わかりやすく言うと、バックアップメーカーがサービス提供する範囲が違う。 図解すると以下の通りじゃ。
hakase.png
バックアップデータを保存する
ストレージサービス

バックアップ専用のストレージサービスのみ提供する。同社のバックアップソフトやサーバーなどのリソースを別途構築する必要がある。


backupstorage
Backup as a service
（BaaS）

バックアップ機能とバックアップ先のストレージをサービスとして提供する。SaaS型のバックアップサービスのため、別途バックアップソフトやサーバーなどのリソースが不要。サイジングや構築もバックアップメーカーがサービスとして請け負ってくれる。

BaaS
mamoru_tehe.png
城宝　守
へ～そんな違いがあるんですね。
BaaSはバックアップシステムの構築もメーカーが請け負ってくれる点がいいですね。いずれの場合も、やはりクラウドですから大手パブリッククラウドとほぼ同じと考えていいのでしょうか？
バックアップ博士
それがそうでもないんじゃ。
データセンターの場所やサービス内容が各社異なるから導入前には条件をよーく確認する必要があるんじゃ。
hakase.png
mamoru_bikkuri.png
城宝　守
サービスが異なるというと…

ポイント①データセンターの場所

バックアップ博士
では早速見ていこう。まずはデータセンターの場所じゃ。
巨大なパブリッククラウドベンダーが提供するクラウドの場合には沢山のデータセンターが世界各地、通常東京や大阪にあるので、自分の会社に近いリージョンを選択することが可能じゃ。しかしバックアップメーカーが提供するデータセンターはパブリッククラウドベンダーと比較すると数が少ない。つまりどんな事が問題になると思うかね。守くん。
hakase.png
大手パブリッククラウド
many_data_centers
バックアップメーカーの独自クラウド
few_data_centers
mamoru_kangaechu.png
城宝　守
はい。例えば、会社が東京にあって、バックアップメーカーの提供するクラウドのデータセンターが北アメリカなど遠い場合には、データの遅延が発生します。またGDPRなどのデータ保護の観点からもやはり、データセンターの場所により法律が変わるので注意が必要です。
delayed
GDPR
バックアップ博士
うん。よくできたな！
災害などの観点からいうとバックアップ先のデータセンターは遠い方がいい場合ももちろんある。だが、実際に有事にデータセンターのデータをダウンロードしようとした時に、遅延が発生して遅くて使えないなんてことでは困る。だから回線の太さなどの環境も合わせて確認する事が必要じゃ。
hakase.png
delayed_occurrence
mamoru_kangaechu.png
城宝　守
その他に考慮すべき点はどこでしょうか？

ポイント②データ復旧時にダウンロード料金がかからない

バックアップ博士
次はデータのダウンロード料金の有無じゃ。通常のパブリッククラウドは前にも伝えた様に、データをリカバリする際には、ダウンロードの従量制課金が別途発生する。バックアップメーカーが提供するクラウドは基本、通常時には利用しない事を前提に構築されている。だから有事の際にはデータのダウンロード料金が別途加算されないベンダーもある。
この考え方はバックアップメーカーの提供するクラウド特有の考え方なので、データのダウンロード時に料金が発生しないことはバックアップメーカーの独自クラウドの大きなメリットの一つと言える。
hakase.png
大手パブリッククラウド
storage&egress_cost
バックアップメーカーの独自クラウド
only_storage_cost

ポイント③DR利用の際は、事前に契約が必要

バックアップ博士
またAWSなどは豊富なリソースがあるので、リソースが枯渇する事は基本的に無いと考えて良いが、バックアップメーカーの用意するデータセンターなどの場合にはリソースに限りがあるので事前にDRサイトとしてリソース確保の契約をしておかないといけないバックアップベンダーもあるぞ。
hakase.png
machine_resources_for_DR
mamoru_cry.png
城宝　守
んー、なんだか考えることが多くて迷ってきたなぁ…
▲目次に戻る

クラウド環境をクラウドストレージへバックアップする場合

クラウドファーストのバックアップ

バックアップ博士
では次にクラウドのプラットフォームをメインで運用するクラウドファーストのバックアップを考えてみよう。
hakase.png
mamoru_nayami.png
城宝　守
はぁ～、それにしてもまだあるんですね。
バックアップ博士
ん？泣き言か！？まだまだじゃ。
クラウドファースト、つまりクラウドでのシステム運用がメインの場合には考慮することが沢山あるから順番に見て行こう。
ここでのクラウドはAzure、AWSと定義し、バックアップソフトがどのクラウドを保護できるのか？オンプレとクラウドの違いは何か？を考えてみよう！
hakase.png
mamoru_bikkuri.png
城宝　守
あれ！？
前回、クラウドベンダーが提供するサーバーはクラウド専用の仮想サーバーだと勉強したので、てっきり従来のオンプレと仕組みはあまり変わらないと考えていたのですが…
バックアップ博士
完全に勉強不足じゃのう…
hakase.png
mamoru_cry.png
城宝　守
…（ぴえん）
バックアップ博士
まずそもそもクラウドベンダーはいろんなサービスを展開している。それも数えきれないほどのサービスが存在しており、毎月新しいものがリリースされている。
オンプレとの違いを簡単に言えば、オンプレはシステムに必要なリソースすべてユーザー側で用意しなくてはいけないが、クラウドは必要なリソースをクラウドベンダーが“サービスとして提供してくれる”んじゃ。
まずは大きく分けて3つのサービスに考えるのがいいじゃろう。
IaaS、PaaS、SaaSについてはもちろんわかっておるな？守くん？
hakase.png
IaaS&PaaS&SaaS
mamoru_bikkuri.png
城宝　守
えー・・あー・・あの・・・
バックアップ博士
まだまだじゃのう。
あまり詳しく説明するとクラウドバックアップの勉強ではなく、クラウド自体の勉強になってしまうからここではざっくりと説明するぞ。
hakase.png
▲目次に戻る

IaaSのしくみ

バックアップ博士
IaaSは 「Infrastructure as a Service」 の頭文字を取った略語で「イァース」と読むことはもちろんすでに知っているじゃろう。情報システムの稼動に必要な仮想サーバー等のインフラを、ユーザーが自分で必要なハードウェアのスペックやOSを自由に選定して利用することが可能である。Amazon Elastic Compute Cloud（EC2）やAzure Virtual Machinesの上に利用したいOSをインストールして利用するサービスじゃ。
基本的にIaaSのバックアップは、オンプレの仮想サーバーと同じ観点での保護が必要となる。
hakase.png
IaaS
IaaS_merits&demerits
mamoru_nayami.png
城宝　守
つまりここはオンプレの仮想マシンと同じでしょうか？
具体的にはIaaSで用意した仮想マシン（インスタンス）にエージェントを入れて、バックアップを取るイメージですか？
install_Agent
バックアップ博士
うーん、50点じゃ。
例えばオンプレの仮想マシンに一つずつバックアップのエージェントをインストールする方法も確かにある。でもそれでは非常に手間もかかる。
hakase.png
▲目次に戻る

IaaSポイント①クラウド独自のハイパーバイザーと連携する

バックアップ博士
オンプレでもハイパーバイザーと連携して、仮想マシン本体はエージェントレスでバックアップを取得する方法があるじゃろ？それと同じじゃ。クラウド独自のハイパーバイザーと連携し、インスタントをエージェントレスでバックアップする方法もあるんじゃ。
hakase.png

エージェントレスバックアップ

agentless_backup

IaaSのバックアップ

IaaS_backup
mamoru_nayami.png
城宝　守
えー、
でもAmazonやAzureで同じことを実現するのは、すごーく大変なんじゃないですか？
通常、クラウドベンダーのハイパーバイザーは操作できないと聞きましたが…
▲目次に戻る

IaaSポイント②マーケットプレイスからバックアップソフトを入手すれば初期設定簡単

バックアップ博士
そうじゃ。だからAWSやAzureのマーケットプレイスから、バックアップソフトを選択することでそれを実現するんじゃ。
例えばAWSのマーケットプレイスに提供しているバックアップメーカーは、本来ユーザーが行うと非常に面倒で複雑なAmazon APIと連携してバックアップを簡単にするインスタンス（AMI）を提供している。ユーザーはそのインスタンスを立ち上げて、簡単なGUIの操作画面でバックアップの取得頻度やポリシー設定を行うことができるんじゃ。
hakase.png
AWS Marketplaceを利用しない場合
no_Marketplace
AWS Marketplaceを利用する場合
Marketplace
mamoru_bikkuri.png
城宝　守
難しいことを考えずに操作できるのは確かにうれしいですね。
▲目次に戻る

IaaSポイント③Amazon Linux対応

バックアップ博士
まだまだIaaSで注意しなければいけないことがあるぞ。 IaaSはOSを選択して利用するじゃろ。その際に、バックアップメーカーのサポートが様々なLinuxディストリビューションの種類に対応しているかどうかも重要じゃ。
ただLinuxに対応しているだけだと問題がある。RHEL、CentOS、Ubuntuは最低限必要で、それ以外のクラウドが用意する独自のディストリビューション、例えばAWS で言えばAmazon Linuxなどに対応しているかも考える必要がある。
hakase.png
Amazon_Linux_support
mamoru_nayami.png
城宝　守
博士・・・ なぜAmazon Linuxを利用するんですか？確かAmazon LinuxはRed Had系と聞いた事があります。
RHELやCentOSなど同じ系列のディストリビューションではダメなのでしょうか？
バックアップ博士
ふむ、いい質問じゃ。
確かにEC2上では、他のLinuxのディストリビューションも選択可能だが、Amazon Linuxを利用した時のメリットを考えてほしい。
CentOSで存在するコマンドがAmazon Linuxに存在しないなどのデメリットが多少はあるが、全体的にはメリットが大きい。例えば次のようなことじゃ。
hakase.png

Amazon Linuxのメリット

メリット①

Amazon社が開発しているためサポートを受けやすい。

AWS_support
メリット②

Red Hatベースであるため、 Red Hat系のディストリビューションを多く扱う人であれば難なく扱うことが可能。

Red_Hat_based
メリット③

Amazon Web Servicesの各種サービスとの親和性が良い。

good_affinity
メリット④

Amazon LinuxはAmazon Web Servicesと連携できるコマンドが多数ある。

linked_commands
mamoru_kangaechu.png
城宝　守
確かにEC2上で動かすのであれば、AWSとの連携は重要ですね。
▲目次に戻る

PaaSのしくみ

バックアップ博士
よし、では次はPaaSじゃ。
PaaSは 「Platform as a Service」 の頭文字を取った略語で「パース」だ。
アプリケーションソフトが稼働するためのデータベースやプログラム実行環境などがあらかじめ提供されるサービスのことをじゃ。
hakase.png
PaaS
PaaS_merits&demerits

代表的なPaaSサービス

AWS_PaaS
バックアップ博士
PaaSは、開発者がプログラムの開発にだけ専念できるメリットがある。
実際に開発をしてみればわかるが、データベースをインストールしたりポートの開放を行ったりするのは非常に面倒で時間のかかる作業じゃ。環境やバージョンによってバグが出たり出なかったりして原因を突き止めるのに、何日も時間を要したなんてことは開発の世界ではざらにある。インフラから開発する手間を省きたい場合には最適じゃ。ただしRDSはAWS独自のデータベースを提供しているため、サポートできないバックアップメーカーもいる。バックアップ製品のサポート範囲かどうかは重要じゃ。
hakase.png
mamoru_kangaechu.png
城宝　守
ということは、物理環境と同じですか？
例えばデータベースのサーバーにエージェントをインストールして確実に整合性をとる…といったことが大切なのですね。
▲目次に戻る

PaaSポイント：独自のデータベース

バックアップ博士
そうじゃ。
ただし気を付けるべきは上にもあるように、“独自”というところじゃ。
例えばAWSならAmazon Auroraという独自データベースを持っている。
「MySQL互換エディション」 または 「PostgreSQL互換エディション」 のどちらかを選択できるが、問題は互換性があってもトラブルが起きた際、バックアップメーカーがサポートするかどうかを事前に確認しておく必要がある。
hakase.png
Amazon_Aurora
support_availability
mamoru_nayami.png
城宝　守
サポートしてくれないと困りますね。互換性があるなら私ならあえて独自仕様を選ばずMySQLなどオリジナルの製品を選択します。
バックアップ博士
守くんはいまいちパブリッククラウドのメリットを理解していないようじゃな。
クラウドはただ仮想マシンを提供しているだけではない。サービスを提供しているんじゃ。
例えばAWSのAuroraは通常のMySQLよりメリットがある。
ここではDBの講座ではないので詳しく説明しないがざっくりいうと、パフォーマンス、可用性、耐久性など各性能が高い上に便利な機能も色々と揃っている。
hakase.png
Aurora_merits
Auroraのポイント
  1. Auroraでは、最大15個のAuroraレプリカを持つことが可能。他のAvailability Zoneに分散配置することでデータベースの可用性を高めることができる。
  2. 互換性のあるMySQLの最大5倍、PostgreSQLの最大3倍の高速処理が可能らしい！
mamoru_kangaechu.png
城宝　守
なるほど。勉強になりました。
なぜ最近お客様からクラウドの問い合わせが多いのか、色々わかってきました。
▲目次に戻る

SaaSのしくみ

バックアップ博士
次にSaaSじゃ。
SaaSは、 「Software as a Service」 の頭文字を取った略語で「サース」じゃな。
パッケージ製品として提供されていたソフトウェアを、すでにパブリッククラウドベンダーが設定を行ってくれており、利用者は必要な情報だけを入力してすぐに利用ができる。
hakase.png
PaaS
PaaS_merits&demerits

代表的なSaaSサービス

typical_SaaS
▲目次に戻る

Microsoft 365のメールはゴミ箱に入れて14日で消えてしまう…

バックアップ博士
最も有名なサービス、Microsoft 365がSaaSであることはみんなも知っている周知の事実であろう。
hakase.png
mamoru_tehe.png
城宝　守
弊社でもバリバリ使ってます！
万が一Microsoft 365のサービスが停止してしまったら仕事が全くできないほど頼りにしてます。SaaSは管理者にとってどのようなメリットがあるのでしょう？
バックアップ博士
例えばMicrosoft 365のメールサービス機能Exchange Onlineでは、管理者が必要なアカウントの数だけ契約すれば、1万人が利用しようが、1人だけ利用しようが、パブリッククラウドベンダー側でパフォーマンスまで面倒を見てくれる。そのため、管理者によるインフラ管理の手間を省くことができるんじゃ。
ただしそのメールはパブリッククラウドベンダー側のポリシーに則り管理されている。メールのアイテムを完全に削除した場合、アイテムはフォルダー（回復可能なアイテムの削除）に移動し、規定で14日間保持*される。コンプライアンスの問題で14日以上のアイテム保持が必要な企業は、別途バックアップを行う必要が出てくるんじゃ。

*Exchange Online メールボックスの完全に削除したアイテムの保持期間を変更する
（https://learn.microsoft.com/ja-jp/exchange/recipients-in-exchange-online/manage-user-mailboxes/change-deleted-item-retention）より

hakase.png
メールサーバーをオンプレで構築する場合
User_restored
SaaSのExchange Onlineを利用する場合
SaaS_vendor_restored
もしSaaSのバックアップを取っていなかったら…
deleted_evidence
mamoru_kangaechu.png
城宝　守
なるほど。SaaSはアプリケーションサービスを利用するだけなら非常に便利ですね。 メールデータは削除後14日保持されていれば十分と思いがちですが、退職者が出たり、悪意のある社員が証拠隠滅などのため意図的にメールを削除した場合には確かに14日は少なすぎるかもしれないですね。
バックアップ博士
もっとSaaSバックアップについて知りたい人は、Lv.3バックアップをもっと学ぶ人が見る記事「SaaSバックアップ編」を読んでみよう。
hakase.png
▲目次に戻る

非構造化データの保存先オブジェクトストレージをバックアップしよう

バックアップ博士
さあ次はデータを保管するオブジェクトストレージじゃ。
このオブジェクトストレージを確実にバックアップできるかどうかも重要な部分じゃ。
hakase.png
mamoru_tehe.png
城宝　守
AWSではS3、AzureではBlob Storageと言われるサービスですよね。
実はデータを保管する場所というだけであまりよく、オブジェクトストレージが何かがよくわかっていないんですが…
object_storage
バックアップ博士
オブジェクトストレージは大量の構造化データを保存するための場所じゃ。
hakase.png
mamoru_nayami.png
城宝　守
非構造化データってなんですか？
バックアップ博士
簡単に説明すると、構造化データはデータベースのデータのようにテーブル内に行と列があり、そのデータを後から分析などに再利用できるデータのことじゃ。
それに対し非構造化データは、メール文やワード文章などの後から分析がしにくいデータのことをいう。ちなみにJsonなどの形式のファイルはkey-value型といいデータの分析などができるが非構造化データとして分類されている。
hakase.png
構造化データ
structured_data
非構造化データ
unstructured_data
▲目次に戻る

ファイルサーバーに比べコスト・拡張性で有利

mamoru_kangaechu.png
城宝　守
でも非構造データって、馴染みあるデータですよね。ファイルサーバーに保存するのとあまり違いはないのでしょうか？
バックアップ博士
いいところに気が付いたな。
確かにファイルサーバーでも代用はできる。
ただし、ファイルサーバーはコスト面でも拡張性の面でも不利なんじゃ。
オブジェクトストレージはフォルダ階層を無くし、一般に検索性の高い拡張可能なメタデータとともに保存する。
スケールについて言えば、オブジェクトストレージは数ペタバイトのサイズに拡大することが可能で、通常、データの配置に関する制約がない。よってクラウドなどストレージの拡張性が謳われるAmazon S3やAzure Blob Storageは広く採用されているんじゃ。

また、可用性も高く、Amazon S3は99.999999999%の耐久性となるように設計されている。この耐久性レベルは、0.000000001%のオブジェクト平均年間予測喪失率に該当する。
例えばAmazon S3に10,000,000のオブジェクトが格納されている場合、単一のオブジェクトが喪失する確率は1万年に1度なんじゃ。
hakase.png
ファイルサーバー
low_durability
オブジェクトストレージ
high_durability
mamoru_bikkuri.png
城宝　守
すごく少ない発生の確立ですね。
ではAmazon S3に保存しておけば他の場所にバックアップする必要はないですか？
▲目次に戻る

ベンダーロックイン回避

バックアップ博士
バックアップはシステム障害に対する備えの目的ももちろんあるが、それ以外に人的ミスでデータ損失する可能性が大きいことは勉強したじゃろう。
あとはバックアップではないがベンダーロックを回避する意味においてもS3のデータを更に他の場所にバックアップすることは必要じゃ。
hakase.png
ベンダーロックイン
vendor_lock-in
ベンダーロックイン回避
vendor_lock-in_avoidance
mamoru_ureshii.png
城宝　守
確かに前回のLv.1バックアップを最初に学ぶ人が読む記事「バックアップの基礎」の時にも人的ミスによって失ったデータを復旧するケースがあることを学びました。
ベンダーロックイン回避とは、AWSからAzureやオンプレにデータを移動できることを意味していますか？
バックアップ博士
そうじゃな。
ベンダーロックインを回避するには、いろんな仕組みを作らなければいけないが、まずはS3などのオブジェクトストレージにバックアップする際はデータを移行できる仕組みを用意しておくことが重要じゃ。
2022年第四半期ではクラウド事業者シェアはAWSがNo.1じゃ。
一方で近年Microsoft Azureがすごい勢いで追い上げてきている。
クラウドのメリットは自由に簡単にかつ便利に利用できることじゃ。
一番コストパフォーマンスがよく使い勝手のいいクラウドベンダーにいつでも移れる仕組みを用意しておくことが非常に重要なんじゃ。
hakase.png
AWS_or_Azure
transfer
mamoru_kangaechu.png
城宝　守
確かにそうですね。
S3のデータをバックアップできるメーカーを選ぶようにします。
▲目次に戻る

選定ポイント①リストア時の挙動

バックアップ博士
守くん。ここで非常に重要なポイントを教えよう。
メーカーの仕様ではオブジェクトストレージのバックアップは可能であるが、実際にオンプレミス環境に戻せないメーカーの製品も多数ある。
またリストア可能な場合でも、非常に戻す手間が複雑なメーカーもある。慎重に確認することが重要じゃ。
hakase.png
クラウドバックアップは可能だが
オンプレミスに戻せない場合
no_restore
オンプレミスに戻す際に
非常に手間がかかる場合
take_time_and_effort
mamoru_nayami.png
城宝　守
えーそうなんですか？
博士が言いたいことを具体的にすると、AWSに移行するならAMIに変換、AzureならVHDに変換、そしてクラウドからオンプレのVMware環境に戻るならVMDK…
というようにバックアップ製品側でデータの形式を自由に変換しながら移行できることが大事ということでしょうか？
free_conversion
バックアップ博士
その通りじゃ。
大分勉強の効果が出てきたようじゃな。
hakase.png
mamoru_nayami.png
城宝　守
そうなんですね…
各メーカーの仕様を確認した時に、多数のメーカーが 「色々な形式にデータ変換可能！」 と書いているのをそのまま信じていました。
バックアップ博士
別にメーカーは嘘をついているわけではない。
まだ各メーカーには色んな制限があったりする。
例えばクラウドへの変換は簡単だが、リストアの際はGUIではなくCLIで沢山のコマンドを打たないといけなかったり、初めに変換した際のVMDKに戻さないといけないなど、バックアップメーカー独自の制約がつく場合があるのが現状じゃ。
特に戻る際に制限がつく場合が多いようじゃ。その辺も含めてクラウドへの移行は慎重に行わなければならない。
hakase.png

いざという時、CLIでリストアしなくてはならない場合

command

リストアの際、一度VMDK形式に戻さなくてはならない場合

many_conversions
▲目次に戻る

選定ポイント②カタログデータをバックアップサーバー側で保持するか否か

mamoru_cry.png
城宝　守
博士…
結局どこのバックアップメーカーを選ぶのが正解なのでしょうか？
バックアップ博士
うん、なかなか難しい質問じゃ。これと言う答えはない。
何故なら100点のメーカーはないからじゃ。
例えば、バックアップサーバーが壊れた時に本番環境を戻すことが非常に複雑なメーカーもある。具体的にはカタログデータを最初にリストアするなど、手順が必要なんじゃ。一方でカタログデータも必要なく、バックアップデータだけでスイスイ本番環境を戻せるメーカーもある。これだけ聞くと後者の方が優秀に思える。
hakase.png
バックアップサーバー破損に備えて
準備が必要なメーカー

あらかじめバックアップサーバー内部で保持しているカタログデータをオブジェクトストレージにバックアップ

preparation_1

バックアップサーバーが破損した際、オブジェクトストレージに保存したカタログデータをバックアップサーバーに復旧

preparation_2

クラウドのバックアップデータを本番環境に移行

migration
突然バックアップサーバーが破損しても
問題ないメーカー

②の工程が不要

クラウドのバックアップデータを本番環境に移行

migration_immediately
カタログデータとは？

バックアップの際、データの一部として、クラウドやテープに格納されるメタデータのこと。
バックアップデータ（チャンク形式）を復元する際、データを再構築するために必要な情報である。

catalog_data
バックアップ博士
ただ～し！
後者の場合はバックアップデータの内部にカタログデータも持っているために、重複排除率は前者のメーカーに比べて低くなる。
hakase.png
バックアップサーバー破損に備えて
準備が必要なメーカー
minimum_catalog_data
突然バックアップサーバーが破損しても
問題ないメーカー
manycatalog_data
mamoru_nayami.png
城宝　守
うーん。
単純にどの製品が一番いいとは一概に言えませんね。
▲目次に戻る

選定ポイント③レジューム機能

バックアップ博士
そうじゃ。
基本的に伝えたいことはこんなところだが、最後にクラウドをバックアップ先として利用する場合も、クラウドメインでシステム運用する場合にも覚えておいたほうがいいことを伝えよう。レジューム機能の有無じゃ。
hakase.png
mamoru_kangaechu.png
城宝　守
これまたあまり聞いたことのない言葉ですねほんとITの世界は奥が深いですね。
バックアップ博士
やっとわかってきたか。常に勉強じゃ。
レジューム機能は一般的なDRサイト構築時にも言える事で、回線が途中切れた場合の処理について、切れた場所からデータの再送ができる機能じゃ。
インターネット回線が途切れる事はよくあることじゃろ。
例えば監視カメラのデータなどの様に大きなファイルを転送中に途中で回線が切れた場合などに、回線が再接続した際にデータを初めから再転送をしたのでは非常に時間がかかって効率的ではない。
レジューム機能があれば、切れた途中から再転送になるので、余分な時間がかからない。レジューム機能があるかどうかも重要な確認ポイントじゃ。
hakase.png

レジューム機能なし

no_resume

レジューム機能あり

resume_available
mamoru_kangaechu.png
城宝　守
なるほど。他にはありますか？
▲目次に戻る

選定ポイント④オンプレ・クラウドで同じ管理画面

バックアップ博士
オンプレとクラウドの管理画面が異なる場合があるから注意が必要じゃ。
hakase.png

オンプレミスとクラウドで管理画面が異なる場合

multiple_GUI
cumbersome_to_manage

オンプレミス・クラウド問わず管理画面が同じ場合

single_GUI
easy_to_manage
mamoru_ureshii.png
城宝　守
確かにそうですね。
オンプレとクラウドで同じ管理画面なのは管理者にとってメリットが非常に大きいと思います。
画面が異なると言葉の定義がズレたり、学習コストが2倍になりますからね。
バックアップ博士
そうじゃな。クラウド編で基本的なところはこんなもんじゃ。
hakase.png
mamoru_bikkuri.png
城宝　守
えっ…
こんなにあってこれで基本的というのが気になりますが…

でも博士のおかげでだいぶ色んなことを考慮しなければいけないことがわかりました。
どちらが正解かを選ぶのではなくどちらがよりお客様の環境に合っているかを選択することが重要ですね。でもこれを全部覚えてお客様に提案するのは大変ですね。
バックアップ博士
安心するんじゃ。
2020年8月1日を以って30周年を迎えたネットワールドではこの辺を熟知したエキスパートが沢山おる。お客様先まで同行して、何がそのお客様にあっているかを相談にのってくれるから安心じゃ。
hakase.png
30th_Anniversary
mamoru_bikkuri.png
城宝　守
それもそうですね！
いつもお世話になっているネットワールドに相談しよーっと。
▲目次に戻る

守くんとバックアップ博士の会話は参考になりましたか？
一概に「クラウドバックアップ」と言っても、クラウドの活用方法によって多様なケースを考慮しないといけませんね。
「クラウド移行ツールとしてだけでなく、移行後もデータ管理できるバックアップ製品を選びたい」「なるべく学習コストをかけずクラウドを導入したい」という方は、ぜひネットワールドまでご相談ください。エンドユーザー様に最適な製品をご提案するお手伝いをさせていただきます。

✉ バックアップ製品について問い合わせる
  1. TOP
  2. Lv.2_バックアップをもっと学ぶ人が読む記事