誤り: 適切なソリューションであれば、1シートあたり月額数ドルで無停止のデータ保護が可能です。データ漏洩による企業の損害は平均461万ドル(前年比10%増)であり、データ・セキュリティを確保するために必要な費用を大幅に上回っています。
- Web1月22日(水) ビッグデータの見える化お助け Javaベースのチャート/帳票ツールをご紹介
- セミナー1月23日(木) 【オンライン】Veeamハンズオンセミナー Hyper-V移行編
- セミナー情報一覧
- イベント情報一覧
クラウドバックアップの社会的通念
誤り: 適切なソリューションであれば、1シートあたり月額数ドルで無停止のデータ保護が可能です。データ漏洩による企業の損害は平均461万ドル(前年比10%増)であり、データ・セキュリティを確保するために必要な費用を大幅に上回っています。
クラウドバックアップの社会的通念
誤り:Microsoft 365は、削除したメールとファイルをごみ箱に最大90日間保存するだけです。Google Workspaceは、エンドユーザーのDriveファイルとメールを30日後にゴミ箱とスパムフォルダに削除します。どちらのソリューション/プロバイダも、ユーザーエラー、データ破損、ランサムウェアの脅威が発生した場合のデータの完全な復元を保証するものではありません。マイクロソフトでは、サードパーティによるデータのバックアップをとっておくことを推奨しています(マイクロソフト サービス契約セクション6b)。
クラウドバックアップの社会的通念
誤り:このような考えは、いくつかのソリューションの可視性の欠如によって助長されている。ローカルサーバーにデータを保存するのとは異なり、ローカルレベルで障害が発生しても、クラウドベースのデータで問題が発生することはありません。軍用レベルの暗号化と、大規模で安全なデータ保存のために特別に設計されたサーバーを提供するバックアップおよびアーカイブソリューションを見つけましょう。
AWSとN2WS
復旧シナリオ : AWS環境でのデータ保護の構成管理ツール「 N2WS 」では、災害やAWSの停止が発生したときに実行できるシナリオを作成することができます。これにより、最も重要なリソースを重要度の高い順に復旧させ、RTO/RPOを最小化することができます。この機能のドライラン機能により、テストを実施し、これらの復旧を実行するための準備がすべて整っていることを確認することができます。
クロスリージョン/アカウントディザスターリカバリー :N2WSは、最も包括的なクロスアカウント/リージョンを提供し、ボタンをクリックするだけで全環境をリカバリーすることができます。AWS Backupのバージョンは非常に基本的で、実行が複雑です。
スケジュール :AWS Backupでは、バックアップのスケジュールを1/12/24時間ごとに設定するよう制限されています。N2WSではそのような制限はなく、バックアップは1分ごとにスケジュールすることができます。
ファイルレベルリカバリー : AWS Backupは、Amazon EFSのファイルレベルリカバリーのみをサポートしています。N2WSは、EFS、EC2、S3に対してファイルレベルのリカバリを実行できます(暗号化されたボリュームに対しても)。
Start/Stop Servers (Resource Source Control) : N2WSのこの機能は、EC2インスタンスのアクティブ化と非アクティブ化のスケジュールを設定することが可能である。例えば、非生産用のインスタンスを月曜日から金曜日の午前9時に開始し、午後5時に停止するようにスケジュールすることができる。これにより、お客様はAWSのコストを数千ドル削減することができます。N2WSのお客様であるGett様は、この機能により年間60,000ドルのコスト削減を実現しています。
RDS MySQL & PostgresSQL (S3) : N2WSは、これらのRDSカテゴリをS3に保存することができ、より安価でコールド・ストレージを使用することにより、ストレージコストを大幅に節約することができます。AWS Backupにはこの機能はありません。
自動化 : N2WSによる自動化のおかげで、お客様は他の重要なトピックにエネルギーを集中させることができ、N2WSにバックアップの世話をさせることができるようになります。つまり、一度必要なポリシーとスケジュールを作成すれば、あとはツールがバックグラウンドでバックアップを行い、何か問題が発生したり、注意が必要な場合はアラートが表示されるのです。N2WSは、保存ポリシーに応じて、S3、Deep Archive、Glacierなどのコールドストレージへの保存を自動化することも可能です。これにより、AWSのコストを大幅に削減することができます。
カスタマーサポート : N2WSは、24時間365日のプレミアムサポートを提供し、必要なときにはサポートします。AWSのサポートは別途費用がかかります。
レポートログとモニタリング : AWSでは、レポートログとモニタリングは別料金で、設定が必要です。N2WSでは、バックアップ、リストア、管理、監査の全活動を監視し、追加コストなしですぐに使えるレポートを提供します。
Azureコスト
環境とコストの最適化多くのクラウド環境は流動的であるため、環境のニーズ、パフォーマンス、利用状況を継続的に評価することが重要です。拡張の機会が特定されたら、さらなる対策を講じることができます。使用されているリソースの種類によっては、異なるクラスのリソースやPaaSへの移行が必要となる場合があります。
大規模な環境では、多くのワークロードが使用されていることがよくあります。多くのVMが存在するため、リソースの統合や廃棄の機会があるかどうかを判断するのは難しい場合があります。あまり使用されていないサービスを発見するのに役立つツールの1つが、モニター・サービスです。仮想マシンのインサイトセクションを利用すれば、VMの使用率に関する集計データを見つけ、最も多くのリソースを使用しているVMや最も使用していないVMを発見することができます。
適切なモニタリング戦略があれば、VMのサイズを変更するなどのさらなる措置を講じることができるかもしれませんし、従来は仮想マシン上に置かれていた特定のアプリケーションをコンテナ化して、さらにコストを削減する必要があることが分かるかもしれません。
同様に、ストレージアカウントの節約を見つけるために、「Monitor Storage Accounts Insights」セクションは、指定された期間におけるトランザクション量と使用容量を分析し、節約の機会を明らかにします。このツールは、どのアカウントが不要になり、どのアカウントを統合できるかを特定するのに役立ちます。
リソースを管理する上で見落とされがちなのが、効果的なタグ付けの方法です。使用中のリソースに適切なタグを付けることで、廃棄の対象となるリソースを容易に特定することができます。さらに、タグ付けを行うことで、リソースのライフサイクルを管理するためのレポートを作成することができます。
Azureコスト
環境が正常に稼働している間に、組織はすべてのリソースが監視され、計上されていることを確認し、コストの傾向を特定する必要があります。Azureは、リソースのコストを表示し、レポートするためのいくつかの異なるソリューションを提供しています。
Azureコスト管理ダッシュボードに注目する
結局のところ、リソースをどこでどのように使っているか、そしてその関連コストを本当に理解する唯一の方法は、ダッシュボードを使用して、最もお金がかかっている場所を可視化することなのです。Azureコスト管理は、お客様の組織とそのリソースの使用パターンを包括的に見ることができます。これには、Azureのサービスごとのコストと、サードパーティのMarketplace製品ごとのコストの両方が含まれます。
Azure内には非常に多くのコスト計算方法があるため、予約やAzure Hybrid Benefitの割引を考慮したコスト計算ソリューションがあれば、使用中のリソースに関してスマートな意思決定ができるようになります。
Azure Cost Management dashboard
また、データをCSVで他の会計システムや予算管理システムに簡単にエクスポートすることができます。ただしアドバイザーの推奨、予算管理、コスト超過を防止・予測するためのコスト警告機能が組み込まれているため、その必要はありません。
法規制とコンプライアンスの監視
コスト管理と同様に重要なのが、規制やコンプライアンスに関する管理です。
があります。Azure Security Centerには、ISO 27001、PCI DSS 3.2.1、Azure CIS 1.1.0、HIPAA HITRUSTなどの規格への準拠を確認および評価するための規制遵守ダッシュボードが含まれています。
重要な規制基準への準拠を積極的に監視することで、適切なセキュリティが確保されます。また、将来の監査において、コストのかかる頭痛の種やコンプライアンス作業を軽減することができます。
Azureコスト
適切な計画が立てば、次のステップは必要なリソースの配備です。クラウドへの完全移行に重点を置いている場合でも、単に小規模から始める場合でも、価格と柔軟性について考慮することで、将来的に大きな違いが生まれます。計算機、ディスク、データベースには、コストを大幅に削減できるさまざまなオプションが用意されています。
コンピュート・リソース
クラウドベースの仮想マシンは、最も一般的に使用されるクラウドリソースの1つであり、多くのITプロフェッショナルが最初に検討するものの1つであると思われます。仮想マシンをデプロイする必要がある場合、Azureはいくつかのコスト削減策を提供しています。
– 予約済み仮想マシンインスタンス : 指定されたリソースの年数を事前に購入することで、企業はより低いコストで利用することができます。
– スポット価格 : 特定のマシンが常に存在する必要はありません。そのような場合は、スポット価格を使用して、未使用のコンピューティング容量を大幅な割引価格で購入することができます。アプリケーションは潜在的なシャットダウンに強いことが必要ですが、その場合は大幅なコスト削減を実現できます。
– Dev-Test Pricing – 堅牢な開発およびテスト環境を持つ組織では、これらのマシンは通常短命で使用率が低いため、これらの環境の割引料金を利用することでコストを抑えることができます。
また、コンテナやPlatforms as a Service(PaaS)は、その柔軟性と使いやすさから非常に人気が出てきています。Azure Kubernetes Service (AKS) は、コンテナのオーケストレーションに最適です。ワークロードをコンテナに移行することで、企業はリソースをより緊密にまとめ、最新のマイクロサービス・アーキテクチャを活用することでコスト削減を実現することができます。App Services などの PaaS は、Web サーバーの従来の管理負担を軽減するものです。既存のWebサイトをApp Servicesに移行することで、従来のVMを使用する必要がなくなり、管理時間やコストそのものを削減できる可能性があります。
Azureストレージ層の活用
クラウド環境のコンピューティング能力を支えるのは、大容量のデータを保存する必要性です。そのため、必要なストレージの種類を適切に計画することに時間をかければ、コストを削減することができます。このことは、組織のデータストレージのニーズが高まり、特定の種類のデータが特定のストレージ層に最適であることが判明した場合に特に顕著になります。
Azure Storageのいくつかの機能は、データの安全な転送と保存のための魅力的なオプションになります。プライベートエンドポイントを使用すると、クライアントがプライベートリンクを介してストレージデータに安全にアクセスできるようにすることができます。これにより、公共のインターネットからの露出を制限し、ストレージへのアクセスの制御を強化することができます。
Azureストレージの価格
Azureで利用できるストレージにはいくつかの種類がありますが、一般的に多くのニーズを満たすのは、マネージドディスクとブロブの2種類です。
マネージドディスクは、従来のストレージメディアで、物理サーバーにインストールされた追加のハードディスクに相当します。この拡張可能なディスクには、いくつかの異なる階層があります。どのようなディスク速度を必要とするかによって、いくつかの層から選択することができます。
– プレミアムSSD
– スタンダードSSD
– スタンダードHDD
– ウルトラディスク
ディスクの速度について語るとき、一般的には1秒間に行われる入出力操作の数であるIOPSを意味します。管理対象ディスクの階層によって保証されるIOPSが異なるため、アプリケーションのパフォーマンスに直接影響を与えることができます。P30より小さいプレミアムSSDサイズでは、バースト可能なIOPSと帯域幅を提供し、VMの起動時間とアプリケーションのパフォーマンスを大幅に向上させることができます。このタイプのバーストは、VMレベルおよびディスクレベルで独立して利用可能です。一方を有効にすれば、もう一方は必要ありません。どちらも、1日を通して使用するIOPSクレジットのバケットを蓄積して使用します。このバケットを使い切ると、パフォーマンスは基本ディスク・タイプのものに戻り、使用前に再度蓄積する必要があるため、アプリケーションやVMのパフォーマンスに悪影響を与える可能性があります。
Azure Blob は、保存すべきデータが大量にある場合に、より理にかなっていると言えるかもしれません。このデータは、常にアクセスする必要がない場合もあれば、複数のリソースで簡単に共有する必要がある場合もあります。バックアップは、Blobストレージの典型的な使用例である。このタイプのストレージは、AWS S3タイプのオブジェクトおよびメタデータストレージファイルシステムに相当する。Blobストレージにはいくつかの階層があり、価格とアクセス速度に影響します。
– プレミアム
– ホット
– クール
– アーカイブ
Azure Blobストレージのコストは、月間の1日あたりの平均保存データ量(ギガバイト(GB)単位)で決定されます。例えば、月の前半に20GBのストレージを使用し、後半は全く使用しなかった場合、平均10GBの使用量に対して請求されます。クール層とアーカイブ層から45日後に削除する場合、135日分(180日から45日を引いた日数)の早期削除料が課金されますので、計画的に利用ください。
ファイルストレージとブロックブロブストレージの両方について、冗長性に関するオプションがあります。ローカル冗長ストレージ(LRS)と地理的冗長ストレージ(GRS)のどちらを選ぶかは、コストに大きく影響し、2倍から3倍のコストになることもあります。GRSは保護とアップタイムを向上させますが、コストは高くなります。レプリケーションの設定はいつでも変更可能ですが、LRSから他のタイプのレプリケーションに移行する際には、イグレス帯域幅の料金が発生します。
また、Blobストレージのアプリケーション・プログラミング・インターフェース(API)のコストも考慮しなければなりません。読み取り、書き込み、リスト、作成の各操作には、1万トランザクションあたりのコストがかかる。オブジェクト操作の量が多い場合、これは計画上予想外のコストとなる可能性がある。Blobストレージが、大きな単一オブジェクトでアクセス頻度の低いデータにのみ使用されている場合、APIコストは無視できると思われます。
Cool層とArchive層からそれぞれ30日、180日未満でデータを取り出す場合、追加料金が発生する可能性があることに留意してください。これらのストレージは、より長期的で安価なストレージであることを意図しています。
SQLエラスティックプール
SQLサーバーはすぐに高価になります。本番データベース1つにつき1台のサーバーという従来のモデルでは、特にライセンス要件によって、コストが爆発的に上昇する可能性があります。SQL Elastic Poolsは、データベース間でコンピュートとストレージのリソースを共有し、プロビジョニングされたすべてのリソースを効率的に使用するもので、コストを劇的に削減できる拡張性のあるソリューションです。
リソースの使用量を制限することで、データベースがリソースを乱用して他のデータベースに悪影響を与えないように、さらに最適化し制限することができます。プールの価格は、設定されたリソースの量に基づき、データベースの数とは無関係に決定されます。このタイプのセットアップは、データベースごとに1台のサーバーを使用するアプローチではなく、顧客のデータベースをホスティングする場合にも最適です。
例として、30人のお客様がいて、それぞれがデータベース・インスタンスを持っているとします。最も安価な5 DTUプランを約4.8971ドル/月で購入すると、顧客データベースを格納するためのコストは結局約147ドルになります。Elastic Poolsに移行すると、50 DTUプランを73ドルで購入でき、最大100個のデータベースを扱えるようになります。また、個々のデータベースが使用するリソースを制限することで、プール全体への悪影響を抑制することができます。
Azure Functionsによるサーバーレス
多くの組織が新しい「サーバーレス」能力を活用しています。インフラを管理することなくコードやアプリケーションを実行できるため、迅速な導入と開発につながります。Azure Functionsは、C#、Java、JavaScript、Python、PowerShellでコードを記述し、オンデマンドまたはスケジュールに従ってコードを実行する機能を提供します。
使用量に応じた課金モデルを採用しているため、コードの実行に費やした時間に対してのみ料金を支払う必要があります。400,000GB/s(メモリ使用量に基づくギガバイト秒)と100万回の実行が無料であるため、消費プランでは最小限のコストで始める方法が提供されています。
バックアップソリューションの最適化
ストレージ層についてのセクションで述べたように、バックアップにBlobストレージを使用すると、特にCool層とArchive層を使用する場合、コストを削減することができます。このタイプのストレージは通常、障害発生時に迅速にリストアする必要があるフルVMスナップショットには使用されません。Microsoft Azureは、各VMに適切なスナップショットが取得されるように支援するバックアップサービスを提供している。これは、VMごとの固定コストと消費されたストレージのコストに基づいています。
どのようなビジネス環境においても必要不可欠なバックアップのコストを軽減するために、Veeam Backup for Microsoft Azureのようなサードパーティ・ソリューションを使用することで、多数のVMのバックアップや、データを長期間保持する必要がある場合のコストを節約することができます。例えば、VeeamはAzure用に構築されたクラウドネイティブバックアッププロセスにより、10台のVMを無料で提供しています。ビルトインのコスト計算機により、作成するバックアップ・ポリシーにどれだけのコストがかかるかを実装前に積極的に確認することも可能です。
さらに、Veeamはクラウドに依存しないファイル形式を使用しているため、データのポータビリティを実現します。このバックアップ・プロセスの明白でない利点は、Veeamを活用してオンプレミスのマシン・バックアップを自動的にクラウドに移動することができることです。オンプレミスサイトが突然アクセス不能になった場合、データポータビリティとクラウドネイティブソリューションにより、Veeamバックアップを活用して、以前に作成したバックアップを経由して環境を迅速に起動することができます。
コンテナのバックアップの必要性については、その刹那的な性質からあまり考えないかもしれませんが、Kubernetesクラスタにはステートフルなコンテナと関連する設定やメタデータが存在することがよくあります。すべてのコンポーネントをまとめて包括的にバックアップし、環境全体を迅速に復元できるようにすることは困難です。例えばVeeamのKasten K10は、Kubernetesクラスターのあらゆる側面をバックアップする機能を提供します。さらに、適切なポリシーとリソースのディスカバリーを定義することで、適切なガバナンスを確保し、リソースの取りこぼしがないようにします。
Azureコスト
包括的な要件収集
多くの企業では、ビジネスプロセスや、ビジネスプロセスによってどのようにテクノロジーが推進されるのかについて、詳細な文書がない場合があります。このステップは、通常、計画の中で最も時間のかかる部分です。各ビジネスプロセスがどのように機能し、技術リソースとどのように相互作用するかを正確に把握することは、リソースをクラウドに移行することに意味があるのか、またどのような影響があるのかを判断するために非常に重要です。
コンピュート資源、ディスクスペース、ネットワークのニーズなどの技術的要件だけでなく、コンプライアンスや規制に関する考慮事項、リソースの可用性、他のビジネス・ワークフローとの統合も考慮する必要があります。
コストの見積
技術的なニーズとビジネスプロセスのニーズについて包括的な資料が揃ったら、ワークロードの移行、あるいはクラウドでのワークロードの再実装に関連するコストとメリットを検討し始めることができます。従来のコンピュートやストレージのニーズ以外にも、さまざまな考慮事項があります。
– バックアップのコスト、ポータビリティ、スペース
– リソースの初期転送と継続的なニーズに対応するための帯域幅
– ロードバランサー、アプリケーションゲートウェイ、スケール関連機能
– Azure AD(プレミアムの場合)およびOffice 365ユーザーのライセンスコスト
– Microsoft SQLやMicrosoft WindowsなどのVMライセンス
– 開発環境リソース
– 継続的インテグレーション/継続的デプロイメント(CI/CD)コスト
オンプレミスで購入したハードウェアの保守契約費用を除けば、ほとんどのクラウドリソースには定期的な使用費用が発生します。従来の資本支出モデルと比較すると、クラウドサービスの運用コストは複数年に渡って分散される可能性があります。短期間の利用であれば比較的リーズナブルですが、慎重に管理しないとコストオーバーにつながる可能性があります。
制約と予算のしきい値
多くの企業では、IT予算が無制限にあるわけではありません。Azureはリソースのデプロイを容易にし、それに応じて予算オーバーも容易にします。しかしAzureは「自分のペースで学べるAzure Cost Management tools」によって、クラウドのコストを計画し、コントロールすることも簡単にできます。
また、予算というと実際の金額が思い浮かぶかもしれませんが、それだけが予算ではありません。利用可能なリソースでチームを最大限に活用するために、人的資本の予算も重要です。
– 各ビジネスユニットの予算と、それが具体的なリソースにどのように関わってくるかを検討
– どの時点で、誰に、どのようなアクションを起こすべきか、予算に関する警告を行うべきかを決定する
– 拡張性のあるリソースは、無秩序な成長とコストを避けるために制約を設ける必要がある
Azureの異なるサービスやオファリングは、コストと機能価値を比較した場合、同等とは限りません。このため、利用可能な機能と関連するコストの両方を戦略的に検討し、組織にとって最も価値のあるものを選択することが重要です。
共有資産の利用可能性
類似のワークロードは、共有リソースを活用する上で魅力的なターゲットとなります。セキュリティ、セグメンテーション、パフォーマンスなどの理由で専用インスタンスを必要としないリソースは、共有のコンピュート、ストレージ、アプリケーションインスタンスを使用することでコストを削減することができます。このような基準に合致するワークロードを特定することで、統合によって使用するリソースを節約することができます。
仮想マシンの共有による統合だけが、コスト削減の手段ではありません。コンテナベースのデプロイメントを検討する場合、Azure Kubernetes Serviceのような専用の管理プラットフォームを利用すると、配置と利用を最適化でき、投資を最大限に生かすことができる場合があります。
ガバナンス戦略
IT担当に与えられた柔軟性により、クラウドは瞬く間に戦場と化す可能性があります。事前に適切なガバナンスプランと戦略を導入することで、制約のない広がりを制御すると同時に、イノベーションのための自由とコスト管理を可能にします。Azureポリシーによって、組織はIT担当者が利用できるリソースの種類、サイズ、機能を制御することができます。さらに、リソースのタグ付けを利用することで、これらのリソースをグループ化し、さまざまなチーム、リソースタイプ、プロジェクトに関連付け、レポートを作成してコストを管理することができます。すべてのリソースにタグ付けできるわけではなく、タグは継承されないため、適切なタグ付け戦略を確実に実行することが重要です。
Azureコスト
ここでは、Azureでコストをコントロールしながら、利用可能なすべてのサービスと機能を最大限に活用するための4つのステップについて説明します。新たにクラウドを導入する企業も、以前からクラウドファーストのアプローチを取っている企業も、適切な計画、展開、監視、最適化によって、Azureの活用を成功させることができます。
マイクロソフトTeams バックアップ
● Veeam Backup for Microsoft Office 365
Veeam Backup for Microsoft Office 365は、Microsoft Office 365環境の包括的なバックアップを提供します。Exchange Online、SharePoint Online、OneDrive for Business, Microsoft Teamsのバックアップが可能です。
エンドポイントデバイスおよびクラウドアプリ向けのクラウドネイティブなデータ保護サービスです。社内のあらゆるエンドユーザーデータを自動的にバックアップし、データの復元、ランサムウェア/ 情報漏洩対策、データの可視化や分析など、さまざまなデータ保護機能を提供します。
マイクロソフトTeams バックアップ
最後のベストプラクティスは、バックアップアプリケーションに関しては、使いやすさが重要であるということです。バックアップアプリケーションの中には、設定や使い方があまりにも複雑だという評判のものもあります。この問題は、複雑であればあるほどヒューマンエラーが発生する可能性が高くなることです。もし組織が直感的で使いやすいバックアップアプリケーションを選択すれば、バックアップやリカバリの失敗を高確率的に減らすことができます。
マイクロソフトTeams バックアップ
使用するバックアップソリューションで、オンプレミスかクラウドベースかにかかわらず、データをバックアップできることが重要です。使用するストレージを自由に選択できることで、パフォーマンス、回復力、コストなどの要件に最も適したストレージ階層を選択することができます。また、イミュータブル(Immutable)ストレージのような機能を利用することもできます。
マイクロソフトTeams バックアップ
もう一つのベストプラクティスは、Microsoft Teamsのデータをランサムウェアから確実に保護することです。一般的に考えられているのとは異なり、Microsoft 365に保存されているデータは、次のような方法で暗号化することができます。
ランサムウェア多くの人が個人所有のデバイスからリモートで仕事をするようになったことが、大きく影響し、ランサムウェアに感染するリスクを高めます。
ランサムウェアに感染した場合、組織のデータを復旧させるためには、通常、身代金を支払うか、バックアップを復元するかのどちらかの選択肢しかありません。身代金の支払いには高額な費用がかかる傾向があり、身代金を支払っても、実際にデータが復号化される保証はありません。たとえデータが復号化されたとしても、身代金を支払うと攻撃者が増長し、データを再暗号化し、さらに金銭を要求してくる可能性があります。バックアップを復元する方がはるかに良い選択です。バックアップは、ランサムウェアに関連するデータ損失に対する最善の防御策です。
マイクロソフトTeams バックアップ
Microsoft 365 には以前から eDiscovery 機能があり、召喚状に応じて Microsoft 365 のエコシステムの中から特定のデータを探し出すことができます。しかし、ネイティブeDiscoveryの機能もありますが、ディスカバリプロセスではバックアップソフトを使った方が効果的な場合が多いのです。
バックアップアプリケーションに優れた検索インターフェースがあれば、組織は召喚状で要求されるデータをバックアップで検索することができます。これは、ネイティブのeDiscovery機能を使用するよりも迅速かつ簡単であるだけでなく、次のような機能も備えています。
検索結果に表示された文書をリムーバブルドライブに復元し、相手方の弁護士に提供できるようにします。
マイクロソフトTeams バックアップ
Microsoft Teams Backupのベストプラクティスとして、よく見落とされるのがバックアップソリューションは、きめ細かなリカバリ機能を備えているかです。チーム全体(または複数のチーム)をリストアできることは重要ですが、チーム内のファイルやチャットをリストアできることも同様に重要です。
ユーザーが誤ってチームを削除した場合、多くの場合、そのチームを復元するにはPowerShell を使用して、Azure AD Recycle Binから関連する Azure Active Directory グループを復元します。
しかし、残念ながら、Teamsのネイティブ復旧は、無益な作業となります。Microsoft は削除されたチームを復元することを許可しますが、Microsoft 365 のネイティブ ツールを使用して個々のチームを復元することはできません。
マイクロソフトTeams バックアップ
ベストプラクティスの5番目は、サービスレベルアグリーメント(SLA)をバックアップ計画の最前線に置いておくことです。具体的には、適切なRPO(Recovery Point Objective)とSLA(Service Level Agreement)を検討する必要があります。Microsoft Teams環境のRTO(Recovery Time Objective)です。RPOは、バックアップを作成する頻度を決定し、それによって、バックアップの間に失われる可能性のあるデータの最大量を決定します。RTOは、バックアップを復元するのにかかる時間の長さに関するものです。
この2つの指標は、組織の能力に直結するため、非常に重要です。災害からの迅速かつ完全な復旧組織においてRTOとRPOは恣意的な値ではなく、組織のビジネス上の要求と、その要求を反映したものであるべきです。
マイクロソフトTeams バックアップ
ベストプラクティスその4は、バックアップにハイブリッドなアプローチを取ることです。Microsoft 365とオンプレミスのMicrosoft Office アプリケーションを別々にバックアップするのではなく、両方の環境を同時に保護できる1つのバックアップアプリケーションを使用するのがよいでしょう。
なぜなら、バックアップを復元するということは、何か悪いことが起こったということだからです。どのような事象がデータ復旧の必要性の引き金になるかを予測するのは難しいため、バックアップアプリケーションは最大限の柔軟性を持たせることが非常に重要なのです。バックアップにハイブリッドアプローチを採用することで、この柔軟性を強化することができます。例えば、オンプレミスのメールボックスをMicrosoft 365クラウドに、またはその逆に復元することができるようなことが可能です。
マイクロソフトTeams バックアップ
Microsoft Teamsのバックアップに関する3つ目のベストプラクティスは、作業に適したツールを使用していることを確認することです。Microsoft 365のエコシステムの中には、保持ポリシーや、バックアップの実行を支援する機能などがあります。
保持ポリシーと訴訟ホールドは擬似的なバックアップとして機能することができます。しかし、これらのツールは、データ保護ではなく、コンプライアンス目的のために存在します。そのため、Microsoft Teamsのデータを適切に保護することはできません。
データ保持ポリシーと訴訟ホールドは、データの保護方法に関して矛盾やカバーギャップを生じさせる可能性があります。Microsoft Teamsのすべてのデータを確実に保護する唯一の方法とは、以下のとおりです。Microsoft 365を保護するために特別に設計された専用のバックアップアプリケーションを使用することで、ビジネス要件と法的義務に一致した方法で保護することができます。
マイクロソフトTeams バックアップ
Office 365は、非常に多くの異なるMicrosoft 365コンポーネントを活用しているため、バックアップが最も困難なアプリケーションです。Exchange OnlineやSharePoint Onlineなどのアプリケーションとは異なり、Teamsは、すべてのデータを1つの場所に保存していません。その代わり、Microsoft Teamsのデータは異なるMicrosoft 365アプリケーションを使用されています。Microsoft 365のバックアップアプリケーションであれば、Teamsのデータをバックアップできるはずですが、アプリケーションがMicrosoft Teamsをサポートするように特別に設計されていない限り、復元プロセスが非常に困難になる可能性があります。
MicrosoftはTeamsのバックアップのためのAPIを提供していますが、このAPIは最近リリースされたばかりです。そのため現時点では、すべてのバックアップベンダーがTeamsバックアップAPIを製品に組み込んでいるわけではありません。
いずれは主要ななバックアップソリューションがMicrosoft Teamsをネイティブにサポートするようになると思われますが、当面はバックアップ製品に現在そのようなサポートを含んでいるかどうかを確認することが重要です。
マイクロソフトTeams バックアップ
Microsoft Teamsのバックアップに関する最良の方法は、Microsoft Teams(およびその他のMicrosoft 365アプリ)を実際にバックアップしていることを確認することです。
Microsoftは、Teamsとその他のMicrosoft 365アプリケーションに責任共有モデルを採用しています。この責任共有モデルは、基本的に Microsoft 365 アプリケーションと基盤となるインフラストラクチャを健全に保つ責任は Microsoft にあるが、Microsoft 365 の加入者は以下の責任を負うというものです。自分のデータを安全に保護する責任があります。このデータ保護責任には、データのバックアップを確認することも含まれます。
AWSスナップショット
サーバ仮想化の基本要素である、1台のホスト上に存在するすべてのVMは、物理サーバのリソースを共有し、1つのハイパーバイザによって管理されていることを忘れてはいけません。もし、これら全てのVMが同時にバックアップジョブを開始したらどうなるのでしょうか?ハイパーバイザーやホストサーバのリソースに負担がかかり、遅延が発生したり、最悪の場合バックアップが失敗したりする可能性があります。
ここでスナップショットの威力が発揮されます。スナップショットはVMのある時点のコピーを取得し、フルバックアップと比較してはるかに迅速な処理が可能です。スナップショット自体はバックアップではありませんが、イメージベースバックアップの重要な構成要素です。VMスナップショットがバックアップと同等でない主な理由は、VMから独立して保存できないからです。このため、スナップショットの取得頻度によっては、VMのストレージ容量が急速に増大し、パフォーマンスに影響を与える可能性があります。このため、取得するスナップショットの数量を認識することが重要です。
AWSスナップショット
単一のAWSアカウントと比較的少数のリソースを持つユーザーにとって、バックアップの自動化と一貫したポリシーの適用は簡単なプロセスです。しかし、複数の地域に多数のAWSアカウントを持つユーザーにとって、バックアップを監視しながらすべてのアカウントで一貫したデータ保護を実施することは、非常に困難でコストがかかる可能性があります。Kubernetesのようなアプリケーションでは、ITチームはより洗練されたデータ保護メカニズムを必要とし、スナップショットだけに頼っていては復旧目標を達成できないかもしれないので、問題はさらに複雑になります。
さらに、すべてのバックアップが異なる地域の異なるアカウントにコピーされることを保証する問題もあります。地域間で何千ものバックアップを移行するのは非常に高価であり、一般的なエグレス・チャージよりは低いものの、AWSは地域間のデータコピーに課金することになります。最後に、AWSのスナップショットはストレージ効率が良いが、長期間保存するとかなりコストがかかる可能性があります。
AWSスナップショット
効果的なバックアップとリカバリのシステムは、バックアップの古典的な3-2-1ルールに従っています – データのコピーを少なくとも3つ、少なくとも2つの異なるタイプのメディアに保存し、そのうち1つはオフサイトに保存します。
2つの異なるストレージシステムにデータを保存することは、プライマリシステムがダウンした場合にコピーが破損しないようにするためのリスク管理戦術です。このため、常に別のバックアップシステムを持ち、プライマリとバックアップの両方に同じストレージを使用しないようにします。スナップショットを作成した時点で、データのコピーを別のシステムに保存していることになるので、このルールの一部はAWSスナップショットを使用して簡単に遵守することができます。
少なくとも1つのバックアップコピーをオフサイトに保存することが、厄介な部分です。AWSスナップショットを別のリージョンにコピーすることは可能ですが、自動化するのは難しく、コストもかかります。あるリージョンから別のリージョンにデータをコピーすると、イグレスチャージが発生し、コストのかかる不要なコピーが作成されます。また、この概念をすべてのAWSアカウントに一貫して適用し、一元的な管理とレポーティングを維持することは困難です。
AWSスナップショット
AWSスナップショットとは、EC2インスタンスやEBSボリュームなどのリソースのイメージコピーで、AWSアカウント内のオブジェクトストレージに保存される。フルまたはベースラインスナップショットは、保護されたリソースの単一時点からの同一コピーである。最初のスナップショットが作成されると、それ以降の増分スナップショットには、最後のスナップショットが取得された後に変更されたすべてのブロックが含まれるようになります。
AWSスナップショットは完全なコピーであるため、破損または削除されたリソースを復元するために使用することができ、一般的にプライマリコピーが破損した場合、ITが最初に検索するものです。例えば、EC2インスタンスやEBSボリュームが破損しても、スナップショットには影響しないので、チームは簡単に復旧することができます。
これは、AWSスナップショットがバックアップのための理想的なデータソースであることを意味します 。 それは、異なるシステムに格納されているデータの独立したコピーを提供します。そらは、AWSで損傷したリソースを回復するための最も簡単で迅速な方法であり、シンプルでスピーディな災害復旧のための素晴らしいリソースを示しています。
<<続き>>
https://www.climb.co.jp/faq/faq-category/aws-snapshot