共有ドライブをバックアップ手順に含めるには、次の手順に従ってください：
●ドメインに有効なSharePoint/Teams/共有ドライブのライセンスが割り当てられていることを確認してください。
●共有ドライブが表示されない場合は、十分なライセンスがあることと、バックアップアカウントがドライブにアクセスできることを確認してください。
必要な権限：
●読み取りアクセス権：バックアップを実行するには、共有ドライブへの読み取りアクセス権が必要です。
●書き込みアクセス権：復元操作を実行するには、書き込みアクセス権が必要です。使用するサービスアカウントは、バックアップまたは復元対象の各共有ドライブに対して明示的なアクセス権限を持っている必要があります。
このエラーメッセージは、Microsoft 365が使用しようとしているサービスを有効化またはライセンス化していないことを意味します。通常、影響を受けるサービスはOneDriveとSharePointですが、メール、連絡先、カレンダーなどの他のサービスでも発生する可能性があります。修正するには、Microsoft 365でユーザーにライセンスを割り当て、影響を受けたサービスにログインして有効化してください。
いいえ、システムはローカルエージェントなしで動作します。
Climb Cloud Backupは、すべての操作を実行するために、セキュアなOAuthおよびGraph/Google APIを介したクラウドネイティブでAPIベースのアクセスを利用しています。
はい。バックアップおよび復元操作のためのAPIレベルアクセスを有効にするには、初期設定時にClimb Cloud Backup for Google Workspaceバックアップアプリをインストールしてください。
●ライフサイクルポリシーでコスト削減：古いバックアップをAmazon S3 Glacierなどの低コストストレージに移行するライフサイクルポリシーを設定します。これによりストレージコストを大幅に削減できます。
●異なるリージョンやアカウントへのバックアップ：バックアップを異なるAWSリージョンやアカウントに複製することで、災害復旧計画を強化します。これにより、リージョン固有の問題やセキュリティ上の課題からデータを保護できます。
●RTO短縮のためのバックアップ自動化：AWS Backupを使用して頻繁なバックアップ間隔を設定します。1時間ごと、あるいは数分おきの自動バックアップにより、データを迅速に復旧でき、ダウンタイムを最小限に抑えられます。
●リソースにタグを付けて管理を容易に：タグにより関連するバックアップを迅速に識別・グループ化でき、管理やコスト監視が容易になります。これによりレポート作成やコンプライアンスチェックも簡素化されます。
●災害復旧計画を定期的にテスト：DRドリルを自動化し、バックアップと復旧プロセスを確認します。バックアップが機能し、データを迅速に復元できることを確認することで、潜在的な問題を発見・修正できます。
分散環境では、データレプリケーションは、可用性、スケーラビリティ、回復性を確保するための確立されたプラクティスです。ただし、最大のリスクの 1 つは、デスティネーションにレプリケートされたデータがソースの現在の状態を反映していないことです。
データの不整合として知られるこの不整合は、ビジネス上の意思決定のエラーから自動化されたプロセスの誤動作まで、深刻な結果をもたらす可能性があり、システム全体の信頼性を直接損ないます。
複数のノード、データセンター、または分散サービスで運用されている組織では、テクノロジーガバナンスの原則に従って堅牢でスケーラブルで一貫性のあるアーキテクチャを構築するには、レプリケートされたデータの整合性を最優先事項にする必要があります。
📌 このずれの原因は何ですか?
➡️ レプリケーション・モデルの設計が不十分
➡️ ノード間のレイテンシーが高い
➡️ 書き込み競合の処理におけるエラー
➡️ 検証と整合性監査の欠如
📌 このリスクを軽減するにはどうすればよいでしょうか?
➡️ 効率的なトポロジーの設計
➡️ 整合性とリカバリの明確なポリシー
➡️ 運用の継続的な監視とトレーサビリティ
➡️ 技術アーキテクチャとビジネス目標の整合性
今日、企業のデータは戦略的資産です。
このため、複製されるものが原点に忠実であることを保証することは、事業継続性、制度的セキュリティ、デジタルの持続可能性のための構造的条件です。
SC//HyperCoreは、コンテナのシームレスなプログラムによるデプロイを可能にします。SC//HyperCore上でコンテナを実行するには、コンテナ最適化OSと任意のコンテナランタイム（通常はDocker、またはKubernetes環境ではcontainerdやCRI-O）をデプロイするだけです。
●REST APIとcloud-initのサポートにより、ユーザーがコンテナ化されたワークロードを実行する方法が根本的に改善されます
●オペレーティングシステム、コンテナランタイム、ワークロードコンテナの自動インストールを実現
●標準化を通じて一貫した変更管理とより信頼性の高い更新を可能にします
●バックアップ自動化にマネージド ID を使用する: スクリプトに資格情報を埋め込む代わりに、Azure のマネージド ID を使用して、自動化されたエクスポート/インポート操作のためにストレージ アカウントへの安全なアクセスを許可します。
●バックアップと復元のパフォーマンスを監視する：Azure Monitorを使用してバックアップ/復元操作のパフォーマンスを追跡し、障害や異常な長時間動作に対するアラートを設定します。
●地理的に冗長化されたストレージを賢く活用する：RA-GRSは耐久性に優れていますが、一部の高度なセキュリティシナリオでは、パフォーマンスとコストを最適化するためにゾーン冗長ストレージ（ZRS）またはローカル冗長ストレージ（LRS）の使用が有益です。
●機密データベースのバックアップ暗号化を有効化: 透過的データ暗号化 (TDE) でデータベース バックアップを暗号化します。セキュリティ強化のため、Azure Key Vault に保存された顧客管理キー (CMK) を使用します。
●重要なバックアップに不変ストレージを組み込む: 誤削除やランサムウェアから保護する長期バックアップに適用します。これにより、保持期間中バックアップが改ざんされないことが保証されます。
●増分データアップロードによる最適化: 大規模なデータセットを繰り返しアップロードする代わりに、変更されたデータや新規データのみを転送する増分アップロード戦略を導入します。これにより帯域幅の使用量が削減され、アーカイブ処理が高速化されます。
●メタデータ管理にBlob Indexerを活用: アーカイブ済みデータの検索を簡素化するため、Azure Blob Indexerを統合し、アーカイブ前にファイルに検索可能なメタデータを付加します。これにより、ユーザーはデータセット全体をスキャンすることなく、関連データを迅速に特定・取得できます。
●アーカイブ前の圧縮：アーカイブ層へのアップロード前にGzipやParquet形式などの圧縮ツールを使用します。圧縮により、特にログやテキスト主体のデータセットにおいて、大容量ファイルのサイズを最小化し、ストレージコストを大幅に削減できます。
●災害耐性のあるアーカイブにはRA-GRSを採用：高い耐久性と災害復旧が必要な場合は、Read-Access Geo-Redundant Storage（RA-GRS）を選択します。これによりアーカイブデータが複数リージョンに複製され、リージョン障害時でもアクセスが可能になります。
●優先度の高いデータはCool層に事前配置：数週間以内に取得が必要となる可能性のあるアーカイブデータは、Archive層へ移動する前にCool層に事前配置してください。これにより高コストで遅延の多い優先取得料金を回避しつつ、可用性とコストのバランスを保てます。
●災害復旧テストを自動化し、現実的なシナリオをシミュレートする：理論上のDR計画だけに頼らず、現実的な障害シナリオをシミュレートする自動テストスクリプトを作成してください。インフラストラクチャレベルとアプリケーションレベルの両方の耐障害性を検証することを確認してください。
●異なるIAMロールを用いたクロスリージョンレプリケーションの導入：マルチリージョンDRは強力ですが、レプリケーションパイプライン（例：S3クロスリージョンレプリケーション）には最小限の権限を持つ専用IAMロールを設定し、侵害された認証情報の影響範囲を制限してください。
●不変バックアップとランサムウェア対策を活用：S3オブジェクトロック、AWS BackupのVault Lock、またはN2Wのような不変バックアップをサポートするサードパーティ製バックアップソリューションを使用し、改ざんや削除を防止する。
●アプリケーションレベルのチェックポイント機能を統合：ステートフルなアプリケーションの場合、Amazon DynamoDB StreamsやS3バージョン管理などを使用してアプリケーション状態をチェックポイントするDR手順を設計する。これによりデータ損失を低減（ヒント：N2Wはアプリケーション一貫性を保持）。
●DNSヘルスチェックによるネットワークフェイルオーバー設計：AWS Route 53ヘルスチェックと遅延ベースルーティングを組み合わせ、DRリージョンの健全なエンドポイントへトラフィックを自動リダイレクト。障害時の手動介入を最小化。
●S3 オブジェクトロックを使用して不変のバックアップを実装する：これにより、ランサムウェアが環境を侵害した場合でも、バックアップの改ざんを防止できます。
●認証情報のローテーションを自動化する：AWS Secrets Manager または IAM ポリシーを使用して、AWS アクセスキーとシークレットキーを頻繁にローテーションします。これにより、攻撃者にとっての機会を制限できます。
●機密性の高いワークロードを分離する：個別のアカウントまたは仮想プライベートクラウド (VPC) を使用して、ワークロードを分離するように AWS 環境を設計します。これにより、ランサムウェア攻撃が発生した場合の攻撃範囲を制限できます。
●バックアップの異常検出を設定する：AWS Backup Audit Manager を使用して異常検出を設定し、突然の削除や異常なバックアップパターンなどの予期しない変更が発生したときにチームメンバーに警告を送信します。
●AWS WAF を有効にして悪意のあるトラフィックをブロックする：AWS Web Application Firewall (WAF) を使用して、ウェブアプリケーションを保護します。SQL インジェクションや悪意のあるペイロードなどの一般的な攻撃ベクトルをブロックするルールを設定します。
●データベースクローンによる迅速な復旧シナリオ: 完全な復元ではなく、テストやトラブルシューティングにはデータベースクローンを検討してください。クローン機能により、ダウンタイムなしで既存のRDSインスタンスのコピーを作成でき、実験やデバッグを迅速に行えます。
●スナップショット整理にタグを活用：RDSスナップショットに「本番環境バックアップ」「コンプライアンスアーカイブ」「移行準備」など目的を明示する一貫したタグ付けを実施。タグ付けによりスナップショット管理が効率化され、適切なスナップショットの検索が容易になります。
●重要インスタンスの削除保護を有効化：重要データを含むRDSインスタンスには常に削除保護を有効化し、誤削除を防止。この簡単な手順で、スナップショットからの復旧作業時間を大幅に削減できます。
●読み取りレプリカとスナップショットを組み合わせたハイブリッド復旧戦略: 読み取りレプリカをスケーラビリティだけでなく、災害復旧の追加レイヤーとして活用します。緊急時には、読み取りレプリカをスタンドアロンデータベースに昇格させることが可能です。
●ライフサイクルポリシーによるスナップショットストレージの最適化: Amazon Data Lifecycle Manager (DLM) を使用して、RDSスナップショットの保持と削除を自動化します。これにより、不要なストレージコストを防止しつつ、復旧に必要なバックアップが確実に利用可能になります。
EspressReport は、Java EE (Enterprise Edition) の標準技術に基づいて構築されたレポートツールであるため、Java EE アプリケーションサーバー環境との連携は完全に可能です。EspressReport は Java エコシステムと密接に連携しているため、Java EE/Jakarta EE 環境での利用は設計上の前提となっています。
EspressReport を Java EE 環境で利用する際の主なポイントと連携方法は以下の通りです。
EspressReport のサーバーコンポーネントである EspressReport ES (Enterprise Server) は、標準的な Java EE の Web アプリケーションとして提供されます。
Java EE 環境で開発された独自のアプリケーションから EspressReport の機能を利用する方法はいくつかあります。
Climb Cloud Backup for Google Workspace (CCB4GWS) のようなGmail 自動バックアップツールを使用すると、選択した Gmail データまたはすべての Gmail データを、指定した保存場所に自動的にバックアップできます。
Climb Cloud Backup for Google Workspace
例えば、Climb CloudBackup for Google Workspace は、Gmail やその他の主要な Google Workspace サービスに保存されているデータの完全バックアップとデータ保護をサポートします。CCB4GWSは、メールとその関連メタデータ（添付ファイルを含む）だけでなく、Google ドライブのデータ、連絡先、カレンダーの予定も自動的にバックアップできます。
Gmail データ保護を柔軟かつきめ細かく制御できるように、Climb CloudBackup for Google Workspace には、増分バックアップ、バックアップ対象のフォルダやラベルを個別に選択する機能、きめ細かな復元オプションなどの機能が搭載されています。また、ロールベースのアクセス制御によるバックアップデータの保護、AES 暗号化、監査ログ、スケジュール設定も可能です。
Climb Cloud Backupのもう一つの利点は、Amazon S3、Wasabi、Azure Blob Storageなどを含む様々なクラウドストレージプラットフォームと連携し、バックアップデータの保存場所を幅広く選択できることです。この柔軟性により、大量のGmailデータをバックアップする企業にとって重要な、費用対効果の高いGmailバックアップオプションを見つけるのに役立ちます。また、このソリューションは、Gmailバックアップのストレージとプロセスに対する強力なセキュリティと正確な制御により、コンプライアンス要件の遵守にも役立ちます。
EspressReport機能から、エンタープライズ向けのWebアプリケーションにおける以下のような利用が想定されます。
| 業界 | 想定される利用シーン | 特徴的な要件 |
| 金融 | 顧客向けの取引明細書、残高報告書、契約書類、法定帳票などの生成。 | 高い信頼性とセキュリティ、膨大なデータを処理するパフォーマンス、複雑なレイアウトの再現。 |
| 製造 | 受注伝票、出荷伝票、品質管理レポート、サプライヤー向けの各種帳票の生成。 | 帳票のリアルタイム出力、外字やバーコードへの対応、PDFでの正確な印刷保証。 |
| 公共 | 住民や職員向けの申請書、証明書、統計レポート、通知書などの発行。 | 公文書としての正確なフォーマット、アクセシビリティへの配慮、長期的なメンテナンス性。 |
Wasabiは、学術情報ネットワークSINETに接続するためのサービスを提供しています。これにより、大学や研究機関は、SINETの高速かつセキュアな閉域網を通じて、Wasabiのクラウドストレージに安全かつ高速にアクセスできるようになります。
接続方法の概要
詳細な手順
より詳細な手順については、以下の資料をご参照ください。
このガイドには、接続に必要な情報や設定手順が詳しく解説されています。
留意事項
ご不明な点がありましたら、お問い合わせください。
StarWind VSANをKVMベースの環境にデプロイする際の基本的な流れは、Controller Virtual Machine (CVM) を利用することが鍵となります。
CVMは、StarWind VSANのソフトウェアが動作するLinuxベースの仮想アプライアンスであり、これをKVMホスト（物理サーバー）上にデプロイすることで、ホストのローカルストレージを共有ストレージプールとしてまとめ、iSCSIターゲットとしてホスト側へ提供します。
以下に、一般的なKVM環境（例：Proxmox VE、oVirt/OLVMなど）でのデプロイ手順の概要を、ステップごとに説明します。
このCVMアプローチにより、StarWind VSANはKVM環境でハイパーコンバージドインフラストラクチャ (HCI) を実現し、ローカルストレージのみで高可用性を提供します。
StarWind VSANは、KVMをベースとした様々なハイパーバイザーソリューションをサポートしています。
これは、StarWind VSANが、Controller Virtual Machine (CVM) と呼ばれるLinuxベースの仮想マシンとしてデプロイされ、iSCSIストレージとしてKVMホストに高可用性ストレージを提供する方式を採用しているためです。
具体的なKVMベースのソリューションとしては、以下のようなものが挙げられます:
Tomcatを含むJakarta EE（旧Java EE）とSalesforceとの連携手法はいくつかあります。
Jakarta EEはJavaベースのエンタープライズアプリケーションプラットフォームであり、JavaのプログラムからSalesforceのAPIを利用することで連携が可能です。Jakarta EEにはTomcat以外の製品ではRed HatのJBoss, Oracle WebLogic, IBM WebSphereなどがあります。
主な連携手法として、Salesforceが提供するAPIを利用するのが一般的です。Jakarta EE環境で動作するJavaアプリケーションから、これらのAPIを呼び出します。
java.net.http.HttpClientやサードパーティのライブラリ）を使用してRESTfulなリクエストを構築・送信します。
連携を実現するためには、適切な認証設定とライブラリの利用が重要です。
SalesforceとのAPI連携では、セキュリティ確保のために接続アプリケーションを作成し、OAuth 2.0フロー（例：認証コードグラント、クライアントクレデンシャルなど）を利用してアクセストークンを取得するのが標準的な手順です。
連携したい具体的なSalesforceの機能や、Jakarta EE環境のバージョン、利用したいフレームワーク（例: Spring Boot, MicroProfileなど）によって、最適な実装アプローチは変わってきます。
SalesforceとJakarta EEを連携させる上で、主要なAPIであるREST APIとSOAP APIには以下のような違いがあります。
結論として、特別な理由がない限り、新規の連携にはよりシンプルで柔軟なREST APIが推奨されます。
| 項目 | REST API (Representational State Transfer) | SOAP API (Simple Object Access Protocol) |
| 通信方式 | HTTPの標準的なメソッド (GET, POST, PUT, DELETEなど) を利用。 | SOAPプロトコルを使用し、通常はHTTP/HTTPS経由で通信。 |
| データ形式 | 主に JSON (JavaScript Object Notation) を使用。XMLも利用可能。 | XML (Extensible Markup Language) のみを使用。 |
| 構造 | リソース指向 (URLでリソースを識別)。軽量でシンプル。 | メッセージ/サービス指向。厳格で複雑なメッセージ構造を持つ。 |
| 処理速度 | メッセージが小さく、オーバーヘッドが少ないため、高速。 | XMLパース処理などにより、RESTよりも遅い傾向がある。 |
| セキュリティ | HTTPS (SSL/TLS) を使用。OAuth 2.0認証が主流。 | HTTPS (SSL/TLS) を使用。WS-Securityなどの標準的なセキュリティ仕様も利用可能。 |
| 連携難易度 | シンプルで、容易に実装できる。 | WSDLからのスタブ生成が必要で、複雑になることがある。 |
| 利用ケース | Webやモバイルアプリ連携、リアルタイム性の高いデータ操作など、ほとんどの新規連携。 | 厳格な仕様が求められるエンタープライズ統合、旧来のシステムとの連携。 |
Jakarta EEアプリケーションからSalesforceを操作する場合、それぞれのAPIは以下のように利用されます。
java.net.http.HttpClient）や、MicroProfile Rest Clientなどのライブラリを利用し、JSON形式のデータを送受信します。
| 選択 | 特徴と理由 |
| REST API | ほとんどの新規連携に最適です。軽量で高速、実装もシンプルで、JSON形式はJakarta EEアプリケーションでのデータ処理に適しています。 |
| SOAP API | 厳格なトランザクション管理や、WSDLベースの厳密な契約（インターフェース定義） が必要な場合に限られます。特に理由がなければRESTを選択すべきです。 |
最終的な確認はそれぞれのJakarta EE対応製品メーカにお尋ねください。
EspressReportはJavaベースのBI・レポーティングツールであり、これをSalesforceと連携させることで、Salesforceの標準機能では実現が難しい高度なデータ分析、複雑なレポーティング、および他システムとのデータ統合が可能になります。
この連携で実現できる主な機能と価値は以下の通りです。
EspressReportの持つ柔軟なレポートデザイン機能を利用し、Salesforceデータに対して、標準レポート機能の限界を超えた詳細な分析と表現を提供します。
Salesforceデータと社内の他システムデータをEspressReport上で結合し、ビジネス全体を俯瞰する複合的な分析を実現します。
Salesforceのデータを定期的に取得し、業務に必要なレポートの生成・配信プロセスを自動化します。
EspressReport+Salesforceの連携は、【高度なカスタマイズ性、データ統合、および配信自動化】という点で、Salesforceのネイティブなレポート機能に対する強力な「BIバディ（相棒）として機能します。
特に、企業固有の複雑なレポート要件や複数の基幹システムデータを含む統合ダッシュボードが必要な場合に、この連携が有効となります。
ScalityのARTESCA+VeeamソリューションがRubrikキラーとされる主な理由は、バックアップデータの保護とランサムウェア対策における強固なアーキテクチャとコスト効率にあります。特に、イミュータビリティ（不変性）の実現方法とシンプルな運用がRubrikとの差別化要因として強調されることが多いです。
Scality ARTESCAとVeeamの連携ソリューションは、以下の点でRubrikの提供する統合型バックアップ・リカバリソリューションと競合し、優位性を示すとされています。
ARTESCA+Veeamの構成は、『ベスト・オブ・ブリード』戦略（各分野で最適な製品を選択して組み合わせる）を採用したい企業にとって魅力的な選択肢となります。
| 特徴 | Scality ARTESCA + Veeam | Rubrik |
| アーキテクチャ | Software-Defined Storage (SDS) + バックアップソフトウェア | 統合アプライアンス (ソフトウェアとハードウェアの統合) |
| ハードウェア | 標準的なx86サーバー、柔軟な選択肢 | 特定の認定済みアプライアンス |
| 不変性 (Immutability) | オブジェクトストレージのS3 Object Lockによる強固なストレージ層の保護 | ソフトウェアおよびファイルシステムレベルの保護 (独自の機能) |
| コスト構造 | ハードウェアとソフトウェアを分離でき、コスト効率の高いスケールアウトが可能 | アプライアンスベースの初期投資とスケーリングコスト |
| 既存環境 | Veeamユーザーにとって導入が容易 | 独自の管理インターフェースとエコシステム |
これらのポイントから、Scality ARTESCA+Veeamソリューションは、既存のVeeamインフラストラクチャを最大限に活用しつつ、ランサムウェアからデータを保護するための堅牢でコスト効率の高いオブジェクトストレージ層を求める企業にとって、Rubrikに対する強力な代替案として位置づけられています。
先日は、BDRチームだけでなく、怒りの顧客メールや受信トレイの混乱に目を覚ました幹部からも、この質問を何十回も聞いたに違いありません。
それを理解しています。AWSがこのようにダウンすると、本能的にすべてに疑問を抱く。数字を見てください:Amazon自体は1時間あたり~$73Mを失ったと伝えられています。初期のレポートによると、Snapchat、Fortnite、Zoom などの企業は、時給 500 ドル前後のヒットを記録しました。これは、保険や訴訟費用が発生する前に、ダウンタイムとして 7 桁、場合によっては 8 桁のダウンタイムになります。
そうです、パニックは理解できます。しかし、人々に言い続けたことは次のとおりです。
ゼロから再構築する必要はありません。ただ、より良く実行する必要があります。
実際のところ、ほとんどのチームは、リージョン全体の停止を計画していませんでした。不注意だったからではなく、そのような出来事がほとんど理論的に感じられたからです。
復元の約 80% は単純で、いくつかのファイルが削除され、場合によっては重要なインスタンスが 1 つか 2 つあります。ほとんどのクラウドチームは、これらを手動で処理します(N2WSなどのツールを使用して次に進むチームもあります)。
しかし、今回は違った。すべてが一度にダウンした場合、「手動回復」が実際にいかに脆弱であるかが明らかになりました。
何を復元すればよいか推測する必要はありません。その場で優先順位を把握する必要はありません。手順書が重要です。
また、データを回復するだけでなく、サブネット、ルーティングテーブル、セキュリティグループなど、ネットワークスタック全体を回復しました。すでにクローンが作成されており、起動する準備もです。
N2WSでこれらのシナリオを簡単に構築してテストできるようになり、回復が筋肉の記憶になりました。
あるグローバルなSaaSのユーザは、その後次のように語っています。
「幸いなことに、US-East-1がダウンしたときに、地域を越えた回復シナリオはすでに整っていました。私たちは計画をトリガーしただけで、約15分で完全な環境を別の地域に稼働させました。」
それがレジリエンスとはそういうものです。
先週教えてくれたことが 1 つあるとすれば、最高の DR 計画は最も複雑ではなく、考えすぎずにプレッシャーの下で実際に実行できる計画であるということです。
Climb Cloud Backup 8.4 リリースを発表できることを嬉しく思います。本リリースでは、バックアップ計画管理のための強化された API 機能、監査ログの改善、ライセンス管理のアップグレード、およびウェブコンソールのナビゲーションの効率化を実現しています。
本リリースでは、自動化の簡素化、スケーラビリティの向上、他システムとの連携強化を実現します。バックアップ計画へのAPIアクセス導入により、MSPやIT管理者はバックアップ計画の作成、読み取り、変更、削除、開始、停止が可能となり、時間の節約と人的ミスのリスク低減につながります。
今回のリリースでは、監査ログの更新を導入します。これにより、ユーザーはバックアップ先の変更を追跡できるようになりました。この更新は、バックアップ戦略における透明性、セキュリティ、説明責任を維持するために重要です。実施された変更内容と変更を行ったユーザーを追跡するのに役立ちます。これは監査と規制順守の確保において極めて重要です。
コンピューターページで対象エンドポイントを右クリックすると表示される新メニューから、バックアップと復元プランへのアクセス、および特定エンドポイントのバックアップ履歴への直接移動が可能になりました。この更新により、ウェブコンソールの重要セクションへ迅速にアクセスでき、時間の節約につながります。最近追加されたエンドポイントの場合、このメニューにはエンドポイントの認証オプションも含まれます。
CCBでは会社単位で保存先（バケットまたはローカル）ごとにストレージ制限を設定できる新機能をリリースいたします。
本リリースにより、ローカルストレージとクラウドストレージに対して会社ごとに異なる制限を個別に適用可能となります。これにより、クラウドストレージにはより厳格な制限を設定しつつローカルストレージの柔軟性を維持することで、より精密かつ細分化されたストレージコスト管理を実現します。
ストレージ制限付きの新規バックアップ先を追加、または既存のバックアップ先を編集するには、組織タブに移動し、会社セクションを開きます。左側のプラスアイコンをクリックして新規バックアップ先を追加するか、編集ボタンをクリックして既存のバックアップ先を変更します。表示されるスライドインパネルでバックアップ先を選択してください。
StarWind Virtual SAN (VSAN) は、Microsoft Hyper-V 環境と連携し、ハイパーコンバージドインフラストラクチャ (HCI) の実現を可能にするソフトウェア定義ストレージ (SDS) ソリューションです。
これは、従来の共有ストレージ（SAN/NAS）を使用せずに、Hyper-Vホストサーバーの内蔵ストレージを論理的にプールし、高可用性（HA）と共有ストレージ機能を提供します。
StarWind VSANは、Hyper-Vクラスターに必要な共有ストレージを、サーバーローカルディスクを使って提供します。
| 特徴 | 説明 | メリット |
| 共有ストレージの不要化 | 高価な専用のSAN/NAS装置が不要。 | CAPEX/OPEXの削減と、導入・運用管理の簡素化。 |
| ハイパーコンバージドの実現 | 仮想マシン (VM) とストレージを同じサーバーで実行。 | フットプリントの削減と、効率的なリソース利用。 |
| 高可用性 (HA) | 2ノードまたは3ノード構成での同期ミラーリング。 | 99.9999% の高い可用性と、データ損失からの保護。 |
| 標準ハードウェアの活用 | 既存または安価な汎用 (コモディティ) ハードウェアを利用可能。 | 特定ベンダーに縛られないベンダーロックインの回避と柔軟な拡張性。 |
| パフォーマンス向上 | ローカルディスク、特にSSDやNVMeの性能を活かし、データ読み書きを高速化。 | 仮想環境のI/O性能の向上。 |
Hyper-V環境にStarWind VSANを導入し、クラスターを構築する基本的な手順は以下の通りです。
この連携により、最小構成の2ノードでも、VMのライブマイグレーションやホスト障害からの自動復旧が可能な、コスト効率の高いHyper-Vクラスターを構築できます。
