
Kubernetesを活用したいけど、単にアプリケーション開発の効率を高めるだけでなく、開発プロセスの変革をともなうので気軽には導入できない、と考えている開発チームは多いと思います。
続きを読む異種ハイパーバイザ、パブリッククラウド間のレプリケーションを提供するZertoですが、ほぼリアルタイムなレプリケーションであるため、ESXiなどのホストのメンテナンス時に少々手間がありました。
下記のようなアーキテクチャでソース、ターゲットとなるホスト上でデプロイされたVRAが処理を行っていますので、ホストのメンテナンス時にVRAも停止してしまうと、そのままではレプリケーションが中断されてしまいます。

ソース側に関してはホストのメンテナンス時には仮想マシンは別のホストに移動しているかパワーオフ状態であるため、影響はありませんが(vMotion先のホストでVRAが稼働していればレプリケーションも続行されます。)、問題となるのは復旧先となるホストです。
続きを読むAmazon EC2を含むクラウド・サービスへのサーバ全体のバックアップとリストア(復元)を、MSP360(CloudBerry) Backup で実現できます。これは、予備のハードウェアがなくてもサーバを復元する必要がある災害復旧に役立ちます。
(1)[Restore to EC2]オプションを選択

今回はZerto Virtual Replicationを使用する上で考慮すべき要素をご紹介します。Zerto Virtual Replicationは仮想マシンをベストエフォートでレプリケーションし、数秒のRPOを実現していますが、ベストエフォートであるがゆえに、どれだけのRPOを実現できるかどうかは保護対象となるVMの特性やレプリケーションを行う環境の構成に依存します。このようなレプリケーションのパフォーマンスに関して考慮すべき要素は以下の通りです。
続きを読む
データのバックアップとGlacierへのアーカイブを開始する前に、いくつか準備する必要があります。まず、アカウントを作成する必要があります。次に、「cpmdata」ポリシーを作成します。「cpmdata」ポリシーは、N2WS Backup&Recoveryデータをバックアップするための特別なポリシーです。これは、Amazon S3機能を使用するために必要であり、障害が発生した場合は、リカバリプロセスがリポジトリへのアクセスを回復するために使用されます。この手順をスキップしようとすると、たとえばリポジトリを直接作成すると、次のようなメッセージが表示されます。
続きを読む
災害後に、通常多くのリソースを迅速に稼働させる必要があります。 N2WS Backup and Recovery v3.0が登場する前は、各リソースを個別にリカバリする必要がありました。この作業には多くの貴重な時間が費やされていました。 このVer3での更新では、一緒に回復される複数のリソースを含むリカバリ・シナリオを構成できるようになりました。 さらに各環境には独自の要件と依存関係があるため、ターゲット・リソースを復元する順序を選択することできます。 新しいインスタンスが別のリージョンまたはアカウントでスピンされているときに、さまざまなバックアップ前および後のスクリプトを実行して、柔軟性を高めることもできます。
N2WS Backup & Recoveryは登録したAWSアカウントに紐づいているEC2インスタンスやRDSなどのAWSリソースのバックアップ/リストアをコーディングすることなく、簡単に行えるソフトウェアとなります。
EC2インスタンスのバックアップ方式としては、AWSがネイティブに提供しているスナップショット機能を用いたものとなりますが、全てのリストアポイントをEBSスナップショットとして保持しておくことはバックアップシナリオとして正解ではありません。
EBSスナップショット自体はAWSの内部的にAWS S3のストレージに格納されますが、この時選択されるストレージクラスは標準ストレージクラスが使用されます。
Cloudberryはバックアップの結果をバックアップレポートとしてメール通知することが可能です。本ブログではメール通知設定の方法やバックアップレポートの内容をご紹介いたします。
バックアップ計画の作成時に、[バックアップが完了したら、Emailで通知を受け取る]のチェックを有効化することでメール通知が可能です。
[ユーザ名]には任意のユーザ名を、[Email]には送り先のアドレスを、[Emailの件名]には送信される通知メールの件名を設定します。