
実行しているハイパーバイザの種類(VMware、Hyper-Vなど)に関係なく、あらゆる仮想環境でバックアップは必要です。あらゆる障害シナリオに、効果的に対処することができるルールの一つに3-2-1バックアップルールと呼ばれるものがあります。この手法は、「いくつのバックアップファイルをどこに保存すべきか。」といった二つの重要な疑問に対する回答に役立ちます。
続きを読む実行しているハイパーバイザの種類(VMware、Hyper-Vなど)に関係なく、あらゆる仮想環境でバックアップは必要です。あらゆる障害シナリオに、効果的に対処することができるルールの一つに3-2-1バックアップルールと呼ばれるものがあります。この手法は、「いくつのバックアップファイルをどこに保存すべきか。」といった二つの重要な疑問に対する回答に役立ちます。
続きを読むクラウドが登場する以前は、ストレージは高価であるだけでなく、非常に限られていました。 GFSバックアップ・スキームは、ストレージ・スペースの貴重なリソースを節約するための重要なスマート戦略の1つでした。
続きを読むVeeam Backup & Replication v10では、クラウド(オブジェクトストレージ)へのアーカイブ機能が強化されました。今回のブログではVeeamによるオブジェクトストレージへのアーカイブ機能がどのように強化されたのか、どのような手順でオブジェクトストレージへのアーカイブを実施するのかという点についてご紹介します。 続きを読む
N2WS Backup & Recoveryは企業内でのタグ・ベースの継続的なバックアップおよびリカバリソリューションを資産化すると同様にこれらのタグを活用してバックアップを管理するのに役立ちます。EBSボリュームをバックアップするには、特定のタグを作成して、N2WSでタグスキャンをスケジュールします。N2WSは事前に設定されたスケジュールでアカウントをスキャンし、それに応じてバックアップポリシーを設定します。これらの機能は、さまざまな場合に有益です。
続きを読む
Veeam Backup & ReplicationではVMware仮想マシンのバックアップ時のコンポーネントを分散させることが可能です。このため、Veeamインストールマシン以外の仮想/物理マシンに以下のような役割を割り当て、構成に合わせて追加していくことで、仮想環境の成長に合わせてスケールアウトな構成を実現できます。
Kubernetesへの移行を成功させるにはの続きです。Kubernetesを導入したいけど、Kubernetesは単なるコンテナ処理ツールではなく、開発プロセスの変革をもたらすので、気軽には手が出せない、手を出す余裕がないと感じている開発チームも多いのではないでしょうか。
続きを読むVeeam Backup & Replication Ver.9.5 Update 4のシステム要件です。
※最小構成では、管理サーバ、プロキシサーバ、リポジトリサーバ、テープサーバを同一のサーバで兼用することも可能です。その場合には、4つすべてのサーバの要件を考慮する必要があります。
続きを読むVeeam Backup & Replication Ver.10のシステム要件です。
※最小構成では、管理サーバ、プロキシサーバ、リポジトリサーバ、テープサーバを同一のサーバで兼用することも可能です。その場合には、4つすべてのサーバの要件を考慮する必要があります。
続きを読むVeeam Backup & Replication Ver.12のシステム要件です。
※最小構成では、管理サーバ、プロキシサーバ、リポジトリサーバ、テープサーバを同一のサーバで兼用することも可能です。その場合には、4つすべてのサーバの要件を考慮する必要があります。
続きを読むVeeam Backup & Replication Ver.12.1のシステム要件です。
※最小構成では、管理サーバ、プロキシサーバ、リポジトリサーバ、テープサーバを同一のサーバで兼用することも可能です。その場合には、4つすべてのサーバの要件を考慮する必要があります。
続きを読むVeeamも認めるKubernetesバックアップ ソリューション Kasten K10
クライムのブログ記事でも何度か紹介してきたKastenのクラウド ネイティブ バックアップ ソリューションが、Veeamパートナーに正式に採用されました。マイクロサービス環境でのDevOpsとCI/CDがアプリケーション開発のスタンダードになりつつある昨今、Kubernetesを導入する企業が急増しています。サポートの幅を広げて顧客ニーズに応えたいVeeamにとって、KastenのソリューションはVeeamの要件と哲学に合致するもので、両社にとってウィンウィンのパートナーシップが実現したようです。
続きを読む異種ハイパーバイザ、パブリッククラウド間のレプリケーションを提供するZertoですが、ほぼリアルタイムなレプリケーションであるため、ESXiなどのホストのメンテナンス時に少々手間がありました。
下記のようなアーキテクチャでソース、ターゲットとなるホスト上でデプロイされたVRAが処理を行っていますので、ホストのメンテナンス時にVRAも停止してしまうと、そのままではレプリケーションが中断されてしまいます。
ソース側に関してはホストのメンテナンス時には仮想マシンは別のホストに移動しているかパワーオフ状態であるため、影響はありませんが(vMotion先のホストでVRAが稼働していればレプリケーションも続行されます。)、問題となるのは復旧先となるホストです。
続きを読むAmazon EC2を含むクラウド・サービスへのサーバ全体のバックアップとリストア(復元)を、MSP360(CloudBerry) Backup で実現できます。これは、予備のハードウェアがなくてもサーバを復元する必要がある災害復旧に役立ちます。
(1)[Restore to EC2]オプションを選択
今回はZerto Virtual Replicationを使用する上で考慮すべき要素をご紹介します。Zerto Virtual Replicationは仮想マシンをベストエフォートでレプリケーションし、数秒のRPOを実現していますが、ベストエフォートであるがゆえに、どれだけのRPOを実現できるかどうかは保護対象となるVMの特性やレプリケーションを行う環境の構成に依存します。このようなレプリケーションのパフォーマンスに関して考慮すべき要素は以下の通りです。
続きを読む
災害後に、通常多くのリソースを迅速に稼働させる必要があります。 N2WS Backup and Recovery v3.0が登場する前は、各リソースを個別にリカバリする必要がありました。この作業には多くの貴重な時間が費やされていました。 このVer3での更新では、一緒に回復される複数のリソースを含むリカバリ・シナリオを構成できるようになりました。 さらに各環境には独自の要件と依存関係があるため、ターゲット・リソースを復元する順序を選択することできます。 新しいインスタンスが別のリージョンまたはアカウントでスピンされているときに、さまざまなバックアップ前および後のスクリプトを実行して、柔軟性を高めることもできます。
N2WS Backup & Recoveryは登録したAWSアカウントに紐づいている
EC2インスタンスやRDSなどのAWSリソースのバックアップ/リストアを
コーディングすることなく、簡単に行えるソフトウェアとなります。
EC2インスタンスのバックアップ方式としては、AWSがネイティブに提供している
スナップショット機能を用いたものとなりますが、全てのリストアポイントを
EBSスナップショットとして保持しておくことはバックアップシナリオとして正解ではありません。
EBSスナップショット自体はAWSの内部的にAWS S3のストレージに格納されますが、
この時選択されるストレージクラスは標準ストレージクラスが使用されます。