Kubernetesバックアップの重要性

Kubernetes バックアップとは？

Kubernetes バックアップとは、Kubernetes クラスター内の重要なコンポーネントとデータを保護し、事業継続性と災害復旧を確保する取り組みです。これにはクラスターの状態と、その内部で実行されているアプリケーションデータの両方が含まれます。

バックアップすべき主要コンポーネントは以下の通りです：

• etcd データベース： Kubernetes コントロールプレーンの中核であり、構成、状態、メタデータを含むすべてのクラスターデータを格納します。クラスタ状態を復元するには、etcdの定期的なバックアップが不可欠です。
• 永続ボリューム（PV）： 実際のアプリケーションデータを格納します。PVをバックアップすることで、アプリケーションが使用するデータの復旧が可能になります。
• Kubernetesリソース： アプリケーション構成（Deployments、Services、ConfigMaps、Secretsなど）、ネームスペース、その他のクラスタレベルのリソースが含まれます。

バックアップ・シナリオには以下が含まれます：

アプリケーション対応型バックアップ： 特定のアプリケーション（永続データおよび関連するKubernetesリソースを含む）のバックアップに焦点を当てます。これにより個々のアプリケーションを細かく復元できます。

クラスターレベルバックアップ： etcd、パーシステントボリューム、すべてのKubernetesリソースを含むクラスター全体の状態をキャプチャします。完全な災害復旧シナリオに不可欠です。

定期バックアップ: データの重要度に応じた頻度（例: etcdの毎日バックアップ、クラスター全体の毎週バックアップ）で自動化されたバックアップスケジュールを実装します。

オフサイト/クラウドバックアップ: バックアップをオフサイトまたはAWS S3、Azure Blob、Wasabiなどのクラウドストレージソリューションに保存します。不変性とエアギャップによるセキュリティが理想的です。

✅ ヒント: N2WSはクロスクラウドバックアップと不変ストレージを標準でサポートしているため、データは改ざん防止され、常にあなたの管理下に置かれます

KubernetesのバックアップがVMやモノリスと異なる点とは？

Kubernetes環境は疎結合で分散したコンポーネントで構成され、頻繁に変更されます。ワークロードは宣言型かつ一時的な性質を持ち、コンテナは随時再スケジュールされ、マニフェストから状態が再構築される可能性があります。このため、データだけでなく動的な構成やオブジェクト間の関係性も捕捉するバックアップが必要となりますが、従来のVM中心のバックアップはこれを想定していません。

モノリシックシステムとは異なり、Kubernetesは外部ストレージプロバイダー、コントローラー、APIに依存しており、これらをアプリケーションを意識した協調的な方法でバックアップする必要があります。etcd、パーシステントボリューム、リソース定義全体の一貫性を確保するには、ワークロードを静的なマシンとして扱うのではなく、Kubernetesのコントロールプレーンとストレージセマンティクスを理解するツールが必要です。

Kubernetesのバックアップが重要な理由

Kubernetes環境で情報をバックアップすべき理由はいくつかあります：

分散システムにおけるデータ保護と回復力： Kubernetesクラスターはノード間で分散ワークロードを実行し、ステートレスおよびステートフルアプリケーションの両方を管理します。適切なバックアップがない場合、ハードウェアまたはソフトウェアの障害により、重大なデータ損失や長期にわたるサービス停止が発生する可能性があります。バックアップソリューションは、部分的または完全なインフラストラクチャ障害後も、永続的なアプリケーションデータ、構成、システム状態をすべて復元可能にします。

設定ドリフトと誤削除の防止：Kubernetes環境は極めて動的であり、設定、デプロイメント、リソースへの変更が自動的またはオペレーターによって頻繁に発生します。この柔軟性は設定ドリフトのリスクを高めます。バックアップによりシステム状態を特定の時点にキャプチャでき、意図しない変更や手動エラーが運用を妨げた場合に安定性を回復するために活用できます。

ランサムウェアおよび内部脅威への防御：Kubernetesワークロード（特に永続ストレージを使用するもの）は、データを暗号化または流出させる攻撃者の標的となり得ます。データとクラスター状態の両方を不変のオフサイト場所にバックアップすることで防御ラインを構築し、稼働中のデータが暗号化または破壊された場合でも、クリーンで侵害されていないコピーを復元可能にします。

コンプライアンスと保存ポリシーへの対応：多くの業界では、データ保存、バックアップ、復元可能性を義務付ける規制枠組みへの厳格な順守が求められます。Kubernetes上でワークロードを実行する組織も例外ではなく、本番環境と機密データがコンプライアンス基準に従ってバックアップされていることを実証できる必要があります。

バックアップすべき主要なKubernetesコンポーネント

1. etcd データベースのバックアップ

etcd は Kubernetes コントロールプレーンの中核をなすキーバリューストアであり、クラスターの状態、構成、メタデータをすべて保持しています。etcd データストアが破損または喪失した場合、クラスター自体が復旧不能になる可能性があります。etcd の定期的なバックアップは基本であり、特にゾーンやリージョンにまたがる高可用性クラスターでは、バージョン互換性と一貫性のあるスナップショットをサポートする手法を含める必要があります。

これらのバックアップの保護も極めて重要です。etcdには機密設定データ、シークレット、アクセス情報が含まれる可能性があるためです。定期的なバックアップのスケジュール設定、暗号化、オフサイトまたは不変ストレージへのバックアップ保存により、データ破損、改ざん、不正アクセスのリスクを低減できます。復元テストを実施することで、これらのバックアップが実際に使用可能であり、実環境シナリオにおいてクラスターを確実に再構築またはロールバックできることを保証します。

✅ ヒント: N2WSを使用すれば、Amazon EKS向けのKubernetesバックアップを自動化・スケジュール設定できます。同じクラスターまたは新しいクラスターへの簡単な復元機能も完備しています。

2. パーシステントボリューム（PV）とパーシステントボリュームクレーム（PVC）のバックアップ

Kubernetesは、パーシステントボリューム（PV）とパーシステントボリュームクレーム（PVC）を通じてステートフルワークロードを実現します。PVは基盤となるストレージを抽象化し、PVCはデータベース、ファイルアップロード、その他のステートフルデータのためのストレージリソースへのポッドアクセスを許可します。PVのバックアップは、ワークロードの変更や再デプロイに関係なく、アプリケーションレベルのデータが保護されることを保証します。

バックアップ対象のストレージ技術（ブロックストレージ、ファイル共有、オブジェクトストア）に応じて、PVのバックアップ手法は異なります。ツールはストレージプロバイダーと連携し、アプリケーション整合性のあるスナップショットを作成するか、データを安全にオフロードする必要があります。いずれの場合も、復旧時にPVCを復元されたPVにマッピングすることは、アプリケーションの継続性にとって極めて重要です。不一致があると、ワークロードが永続ストレージへのアクセスを回復できなくなる可能性があるためです。

3. クラスタ構成のバックアップ

クラスタ構成には、認証設定、アドミッションコントローラー、ネットワークポリシー、スケジューラー設定などの要素が含まれます。これらのコンポーネントは、アクセス制御、ワークロード配置、Kubernetes環境のセキュリティモデルを管理します。このような構成を失うと、サービス停止、セキュリティ脆弱性、ガバナンスの喪失を引き起こす可能性があります。

エクスポートツールまたはインフラストラクチャ・アズ・コードワークフローを介したクラスタ構成のエクスポートとバージョン管理を自動化することで、これらの詳細がバックアップに確実に記録されます。この構成の復元は、データ復旧と同様に重要です。特に、コントロールプレーンやetcdが再構築されたインシデント後には不可欠です。

4. Kubernetesリソースのバックアップ

Kubernetesリソースのバックアップにより、ワークロードのメタデータ、構成、運用定義をアプリケーションデータと共に復元できます。デプロイメント、サービス、カスタムオブジェクトなどのリソースは、復旧時の依存関係、ネットワーク動作、スケーリングロジックを維持するために確実に取得する必要があります。これらのマニフェストをエクスポートするか、自動的に収集するツールを使用することは、環境を正しく再構築するために不可欠です。

ConfigMap

ConfigMapは、YAMLとしてエクスポートするか、リソース定義のスナップショットを撮るバックアップツールを使用してバックアップし、復元後に設定を再適用できるようにします。

シークレット(Secrets)

シークレットは、アプリケーションアクセスに必要な認証情報や機密データを含むことが多いため、Kubernetes APIまたは外部シークレットストアを通じて、暗号化された形式で安全にバックアップします。

Deployments

Deployment マニフェストをバックアップに含め、レプリカ設定、コンテナ仕様、更新戦略をクラスタやネームスペース間で一貫して復元できるようにします。

Services

Service オブジェクトをバックアップし、アプリケーションが使用するネットワーク動作、クラスタ IP アサインメント、ルーティングルールを保持します。

CRDs (カスタムリソース定義)

CRD とそのカスタムリソースインスタンスをエクスポートし、プラットフォーム拡張機能を維持するとともに、復旧時にコントローラーが期待される状態を再構築できるようにします。

Kubernetesの バックアップ戦略

1. アプリケーション中心型とクラスター全体型のバックアップ

アプリケーション中心型バックアップ戦略は、個々のワークロードの永続データ、リソースマニフェスト、依存関係をバックアップすることで保護に焦点を当てます。これらの戦略により、特定のアプリケーションやネームスペースに対する迅速な粒度の細かい復元が可能となり、孤立したインシデントのダウンタイムを最小限に抑えます。アプリケーション中心のバックアップは、マルチテナントクラスタやワークロードの重要度が異なる環境において特に有用です。すべてのリソースが同レベルの保護を必要としない場合です。

クラスタ全体のバックアップは、すべてのネームスペース、クラスタ設定、システムリソースを含むKubernetes環境の完全な状態をキャプチャします。このアプローチは、壊滅的な障害後のクラスタ全体の復元やワークロードの新環境への移行といった災害復旧シナリオに適しています。クラスタ全体のバックアップはより多くのストレージを消費し、復元速度が遅くなる場合がありますが、最大限のカバー範囲を提供し、復旧時の依存関係の見落としリスクを最小限に抑えます。

2. スナップショットベースのバックアップ

スナップショットベースのバックアップは、基盤となるストレージまたはクラウドプラットフォームの機能を使用して、データボリュームやetcdの特定の時点のコピーを作成します。スナップショットは高速かつストレージ効率に優れた手法であり、通常は変更されたブロックのみをキャプチャし、本番ワークロードへの影響を最小限に抑えながら自動的にトリガーできます。クラウドプロバイダーや主要ストレージシステムは、Kubernetesバックアップツールが活用できる統合スナップショット機能をしばしば提供しています。

スナップショットの制限事項の一つは、アプリケーションの一貫性を確保することです。スナップショット取得中にアプリケーションがデータを書き込むと、復元時に破損または不整合な状態が生じる可能性があります。これを解決するには、スナップショットワークフローをワークロードのクワイエット化と調整するか、アプリケーション認識フックと連携するように設計する必要があります。スナップショットと従来のリソースエクスポートを組み合わせることで、ステートフルかつミッションクリティカルなアプリケーションに対してより高い信頼性を提供できます。

3. 増分バックアップと差分バックアップ

増分バックアップは前回のバックアップ以降に変更されたデータのみを保存し、差分バックアップはベースラインとなるフルバックアップ以降の変更を追跡します。いずれのアプローチも、変更されていないデータの冗長なコピーを回避することで、ストレージ要件を削減しバックアッププロセスを高速化します。Kubernetesでは、増分または差分バックアップをパーシステントボリュームとエクスポートされたリソースオブジェクトの両方に適用でき、大規模または頻繁に変更されるクラスターのバックアップサイクルを最適化します。

増分バックアップの実装には、参照の明確な連鎖を維持し、復元時に確実に望ましい状態を再構築できることが求められる。バックアップセットの増加に伴い管理複雑性が高まるため、カバレッジの欠落を防ぐ自動化と整合性チェックが不可欠である。定期的な検証と周期的なフルバックアップは増分/差分スケジュールを補完し、連鎖内のバックアップが破損または利用不能になった場合の代替手段を提供する。

4. クラウドネイティブおよびハイブリッドバックアップ手法

クラウドネイティブのKubernetesバックアップソリューションは、マネージドサービスやインフラストラクチャAPIと直接統合され、多様な環境におけるリソース検出、バックアップ、復元を自動化します。これらのツールはマルチリージョン、クロスクラスター、またはマルチクラウド展開をネイティブにサポートし、クラスターの拡張や移行時の柔軟性を提供します。クラウドネイティブオプションは、ポリシーベースの自動化、グローバルモニタリング、統合暗号化などの機能を頻繁に提供します。

ハイブリッドバックアップソリューションは複数拠点にまたがるか、オンプレミスインフラとパブリッククラウドを組み合わせます。異種ストレージタイプ、ネットワーク、セキュリティモデルをサポートする必要があります。ハイブリッド戦略を統合するには、データやワークロードの所在に関わらず一貫した保護とシームレスな復旧を保証するため、統一管理ツールと標準化されたバックアップ形式が求められます。

✅ ヒント: N2WSはAWS、Azure、Wasabiを横断するハイブリッドクラウドバックアップ専用に設計されており、すべて単一コンソールから管理可能です。

5. GitOpsベースの構成バックアップ

GitOps戦略では、宣言型リソースマニフェストをソースコードとして扱い、Gitなどのバージョン管理リポジトリで維持します。このモデルでは、更新や変更がコミットされるたびに構成バックアップが自動的に実行され、監査可能で可視化された履歴記録が作成されます。復旧時にはGitリポジトリからクラスター状態を同期するため、復元が効率化されると同時に構成ドリフトのリスクが低減されます。

インフラストラクチャ・アズ・コードと自動化ツール（FluxやArgoCDなど）を活用することで、GitOpsベースのバックアップワークフローはバージョン管理とワークロード・プラットフォーム設定の迅速な再デプロイの両方を促進します。このアプローチはバックアップ、セキュリティ、デプロイのワークフローを統合し、Kubernetes運用における信頼性と追跡可能性を向上させます。

Kubernetesバックアップにおける一般的な課題

動的環境での複雑性

Kubernetes環境は俊敏性と迅速なスケーリングを目的に設計されているため、ワークロードの配置、リソース割り当て、システムトポロジーが頻繁に変更されます。この動的な性質は、特にどのリソース、状態、データを保護すべきかを常に追跡するという点で、バックアップ戦略に課題をもたらします。従来のバックアップツールは、こうした継続的な変化に対応しきれず、保護範囲の欠落や不完全なカバレッジを招く可能性があります。

コンテナオーケストレーターはインフラストラクチャを抽象化するため、基盤となる依存関係や構成を直接把握することが困難になります。バックアップが環境の現在の稼働状態を反映するためには、自動検出、ネイティブAPIとの統合、イベント駆動型トリガーが不可欠です。この複雑性に対処することは、信頼性の高い復旧を実現し、運用上の死角を最小限に抑えるための基礎となります。

クラウドネイティブバックアップが役立つ方法:

• ネイティブAPI統合によるリソースとトポロジー変更の自動検出。
• 固定スケジュールではなくイベントに基づいてバックアップをトリガー。
• 現在の稼働状態を反映したアプリケーション認識型スナップショットを取得。

ステートフルとステートレスアプリケーションの取り扱い

Kubernetesのステートレスワークロードは永続データなしで再デプロイやスケールアウトが可能であり、バックアップと復元の要件が簡素化されます。一方、ステートフルアプリケーションは一貫性のあるボリュームとデータに依存しており、復元ワークフローでは復元時にこうした情報が正しく取得・マッピングされる必要があります。これら2種類のワークロードを統合的なバックアップ戦略で調整するには、精緻なツールと、各アプリケーションの完全性にとって重要なリソースを慎重に特定する必要があります。

ステートフルワークロードでは永続ボリュームのみのバックアップでは不十分であり、関連するKubernetesオブジェクト（StatefulSets、ConfigMaps、Secretsなど）も保護する必要があります。これらの関連性を考慮しない場合、部分的な復旧や復旧失敗が発生し、アプリケーションが微妙な方法で破損し、デバッグが困難になる可能性があります。エンドツーエンドの状態依存性を考慮した、きめ細かくアプリケーションを意識したバックアップ計画は、これらの課題に対処します。

クラウドネイティブバックアップが役立つ方法:

• アプリケーションコンポーネントを特定し、永続ボリュームを対応するKubernetesオブジェクトとリンクする。
• ステートフルバックアップの静止化や調整のためのワークロードを意識したフックを提供する。
• 状態保持型アプリケーションを、正しいPVCマッピングと依存関係順序で復元します。

大規模ストレージとネットワークI/Oの管理

本番環境向けKubernetesクラスターは大量のデータをホストし、数十から数百ノードにまたがるため、バックアップ操作の複雑さが増大します。このような環境でのバックアップデータの移動・保存は、ストレージシステム、ネットワークスループット、バックアップウィンドウに負荷をかけます。クラスタのパフォーマンスに影響を与えずに大規模なバックアップを効率的にオーケストレーションするには、並列化、スロットリング、増分コピー技術が必要です。

I/Oボトルネック、ストレージ競合、ネットワーク障害は、いずれもバックアップジョブの遅延や中断を引き起こす可能性があります。これらのリスクを軽減するため、バックアップワークフローにはエラー処理、インテリジェントな再試行ロジック、堅牢な監視機能を組み込む必要があります。クラウドストレージ、オブジェクトストア、分散ファイルシステムを活用することでI/O制約をさらに緩和できますが、これらはコストとデータセキュリティの考慮事項とのバランスを取る必要があります。

クラウドネイティブバックアップの利点:

• 増分または差分コピーを活用し、ネットワークとストレージ負荷を軽減。
• ノード間でバックアップ操作を並列化し、バックアップウィンドウを短縮。
• 大規模スループットに最適化されたオブジェクトストレージやクラウドネイティブバックエンドを活用。

バージョン互換性とAPI廃止

Kubernetesは急速に進化し、新しいリソースAPIを導入し、オブジェクトスキーマを変更し、レガシー機能を廃止します。これらの変更は、特にバックアップソリューションが上流リリースに追従していない場合、バックアップと復元ワークフローを破壊する可能性があります。古いKubernetesバージョンで作成されたバックアップを新しいクラスターに復元すると、APIの欠落や変更により失敗し、不完全または不整合な復元を引き起こす可能性があります。

バージョン互換性を維持するには、バックアップツール、リソースエクスポート、検証ルーチンを進化するクラスター環境と整合させる必要があります。自動チェック、定期的なアップグレードテスト、Kubernetesのバージョン管理ガイドラインの順守は、プラットフォームのアップグレードや移行後の復元失敗や互換性の問題を最小限に抑えるのに役立ちます。

クラウドネイティブバックアップの活用方法:

APIの進化に適応するスキーマ対応エクスポートを維持。

Kubernetes APIバージョンを追跡し、バックアップロジックを自動調整。

復元前にターゲットクラスターのバージョンに対してバックアップを検証。

Kubernetes バックアップのベストプラクティス

1. インフラストラクチャ・アズ・コードと宣言型管理の採用

デプロイメント、構成、ポリシー、ストレージなど、すべてのクラスターリソースを宣言型マニフェストに記述し、バージョン管理下に置くことでコードとして扱います。これにより、環境全体をコードから再現または復元できるため、ロールバック、災害復旧、移行の信頼性が向上します。Helm、Kustomize、Terraformなどのツールを用いたインフラストラクチャ・アズ・コードは、開発、ステージング、本番環境のクラスター間で一貫性を強制します。

宣言型管理はバックアッププロセスを支援するだけでなく、インフラ変更がピアレビューと監査可能なコミット履歴を経るため、人的ミスを減らしドキュメントを強化します。この規律により、復旧作業が推測ではなく意図したクラスター状態を再現できるようになります。

2. バックアップの自動化と定期的な検証

手動のバックアップワークフローは、動的なKubernetes環境とすぐに同期が取れなくなり、リソースの漏れ、古いスナップショット、またはカバレッジのギャップを招きます。スケジューリングツール、Kubernetesネイティブコントローラー、または外部プラットフォームによるバックアップジョブの自動化は、一貫性と信頼性を確保します。自動化は前回のバックアップ以降の変更も特定できるため、ストレージと時間の効率をさらに向上させます。

検証はバックアップ自体と同じくらい重要です。本番環境に近い環境でバックアップと復元ワークフローを定期的にテストし、リソースカバレッジ、バージョン互換性、データ破損の問題を捕捉しましょう。定期的な訓練（自動化または手動）により、復旧が期待通りに実行されることを保証し、チームをインシデント対応に備えさせます。

✅ ヒント: N2Wでは、自動化されたDR訓練により復元を検証し、すべてが期待通りに動作していることを示すメール通知を受け取れます。

3. バックアップデータの暗号化と安全なアクセスを確保する

バックアップファイルには、アプリケーションのシークレット、ユーザー認証情報、システム構成など、機密データが含まれることがよくあります。保存時（ストレージ層またはアプリケーション層の暗号化を使用）および転送時（TLSまたはセキュアチャネルを使用）のバックアップデータの保護は必須です。細粒度のアクセス制御を適用し、許可されたユーザーまたは自動化されたシステムのみがバックアップデータを取得および復元できるようにします。

バックアップインフラの保護は、プライマリ環境と同様に重要です。不正アクセスを監視し、認証情報を定期的に更新し、暗号化キーはバックアップペイロードとは別に保管する。可能な限り不変ストレージまたは書き込み不可ポリシーを実装し、改ざん、誤削除、ランサムウェアに対する防御層を追加する。

4. クラスターとツール間のバージョン整合性を維持する

Kubernetesとそのエコシステムの頻繁な更新に伴い、クラスター、バックアップツール、プラグイン、CRD間のバージョン不整合を厳密に監視する必要がある。下位互換性や上位互換性の欠如は、バックアップ失敗、不完全な復元、非対応リソースタイプを引き起こす可能性があります。互換性のあるバージョンを追跡するポリシーを確立し、ステージング環境でアップグレードをテストし、環境全体で全てのコンポーネントを積極的に整合させましょう。

可能な限りバージョンチェックを自動化し、バックアップツールベンダーのリリースノートやコミュニティ更新情報を購読してください。一貫したバージョン管理には、クラスタとバックアップツールの両方に対するローリングアップグレードや定期メンテナンスウィンドウを含めるべきです。これにより、障害を最小限に抑え、環境とその保護機能を最新の状態に保ちます。

5. 明確な保存・ローテーションポリシーの確立

バックアップコピーの保持数、保存期間、データ消去・アーカイブ・ローテーションの条件を定義し文書化する。これらのポリシーは、ストレージコスト、法的保存要件、迅速な復旧という運用上の必要性のバランスを取るものである。優れたポリシーは日次・週次・月次のサイクルを考慮し、短期的・長期的な復元能力を維持する。

自動化された削除、低コストストレージへのアーカイブ、監査ログ記録を通じて保持ポリシーを強制します。これにより、容量不足やデータ保持要件違反のリスクを低減し、バックアップデータのコンプライアンスと管理可能な成長を長期的に保証します。

6. 本番環境に近い環境での災害復旧テスト

開発環境や隔離されたテストクラスターでのみ復旧テストを行うと、ネットワークポリシー、シークレット管理、ストレージ構成の不一致など、実環境での問題が明らかにならないことがよくあります。本番環境に可能な限り近い環境で、代表的なデータサイズとワークロードを用いて災害復旧をシミュレートします。これにより、実際のインシデント発生前にバックアップ範囲の不足、権限問題、パフォーマンスボトルネックを明らかにできます。

これらのテストを定期的にスケジュールし、CI/CDパイプラインやIT運用プレイブックに統合します。結果を文書化し、得られた教訓を技術的プロセスと組織的プロセスの両方に組み込み、バックアップおよび災害復旧計画に対する準備態勢と信頼性を高めます。

N2WSによるKubernetesバックアップ

EKSクラスターの保護は、別途プロジェクトとして行う必要はありません。N2WS Ver4.5からではAmazon EKS向けにワンクリックのポリシー駆動型バックアップと復旧を提供します。EC2、RDS、S3などの保護に既に使用しているコンソールに完全に統合されています。

新たなツールは不要。Kubernetesの複雑さも問題なし。驚くほど簡単なバックアップを実現します。

• EKSネームスペース、パーシステントボリューム、フルクラスターを自動で即時保護。
• 数クリックで同一クラスターへの復元または新規クラスターへの移行が可能。
• 設定ミスや災害からの迅速なロールバック—YAMLの魔術は不要。
• KubernetesバックアップとAWSリソースを単一の統合ダッシュボードで管理。

✅ 1つのポリシー。1つのコンソール。すべてのクラウドワークロードをカバー

Veeam Kasten によるKubernetesのデータ保護

Veeam KastenはKubernetes専用のデータ保護ソリューションで、各種Kubernetesディストリビューション上のステートレス／ステートフルなアプリケーションの構成と永続ボリューム上のデータ、OpenShift VirtualizationやSUSE Virtualization（Harvester）の仮想マシンに対してバックアップとリストア、モビリティを提供します。

関連トピックス:

• Kubernetesにおけるバックアップの5つのベスト・プラクティス
• Microsoft Azure Active Directoryのバックアップの重要性
• Kubernetesネイティブなバックアップソリューションを採用すべき7つの理由
• Kubernetesネイティブのススメ
• AWS共有責任モデルとバックアップの必要性 [N2WS Backup & Recovery]
• VMwareがついにvSphere 7を発表 ~真のハイブリッド クラウドを実現
• ESXi 6.0.xでCBT(変更ブロック追跡)を有効にした仮想マシンをバックアップすると誤った変更セクタが返されます。
• 国内企業のコンテナ普及率が二桁の大台に