PageTop

Fujitsu Cloud Direct当社が提供するサービスを法人のお客様へ直接販売するサイトです。

CLOUD NAVIクラウドとは?からクラウドを支える技術や関連用語まで解説

FJcloud実践

Acronis Cyber Protect Cloudを利用してFJcloud-Vにサーバーを移行する part2

公開日:2026 5
Acronis Cyber Protect Cloudを利用してFJcloud-Vにサーバーを移行する part2

FJcloud-Vへ移行を検討する際の選択肢の一つにAcronis Cyber Protect Cloud(以降Acronis)を利用する方法があります。 しかし、移行元のサーバーが実際に移行できるのか、あるいは何らかの移行できない条件があるのではないか、といった疑問をお持ちの方も多いのではないでしょうか。

この記事では、Acronisを利用してFJcloud-Vにサーバーを移行する際の条件を細分化して移行可否を検証した結果をご紹介します。

今回の記載内容と今後の記載内容

本ブログは第3編まで掲載予定です。

  • part1
    • Windows Serverにおける、ローカルディスクの容量による移行可否と詳細
    • Windows Server、RedHat Enterprise Linux で増設ディスクを付与している場合の移行可否と詳細
  • part2(本編)
    • 移行元サーバーのディスク容量と使用量がFJcloud-Vの仕様を超過している場合の移行可否と詳細
  • part3
    • 移行元サーバーのディスク本数がFJcloud-Vの仕様を超過している場合の移行可否と詳細

本記事で扱う内容

本記事(part2)では、以下のケースについて検証結果をもとに移行可否を整理します。

  • 移行元サーバーの ディスク容量が FJcloud-V の仕様を超過している
  • かつ ディスク使用量も仕様を超過している
  • ただし 同一ディスク内でパーティションが分割されている

このような構成に対して、Acronis を利用した移行が可能かを検証しました。

前提条件

本記事は、以下の前提知識がある方を想定しています。

  • FJcloud-V の基本的なコントロールパネル操作およびサービス仕様
  • Acronis Cyber Protect Cloud(以降 Acronis)の基本的な操作・知識

Acronis や FJcloud-V の基本仕様、ライセンスに関する注意事項については part1 を参照してください。

検証概要

本検証では、移行元サーバーを Acronis でバックアップし、FJcloud-V 上に作成したサーバーへリストアすることで移行可否を確認しています。

01_overview.png

機能・サービス

検証で利用する機能・サービスを記載します。

  • Acronis
    FJcloud-Vで利用しているサーバーやお客様のオンプレミス環境にある物理・仮想サーバー、クライアントOSを含めたシステムやデータを、まるごとバックアップ・復元できるサービスです。

  • Red Hat Cloud Access
    Red Hat認定クラウドプロバイダーのFJcloud-Vでは、 Red Hat Cloud Accessにより"Bring Your Own Subscription"が可能となり、お客様保有のOSイメージをお持ち込みいただきFJcloud-V上でご利用いただけます。サポートはRed Hat社から提供されます。

想定構成と課題

想定する移行元サーバー構成

  • 単一ディスクの容量が FJcloud-V のディスク上限を超過
  • ディスク内で複数パーティションに分割
  • 各パーティションの容量は FJcloud-V のディスク仕様内

例(Windows Server)

  • 増設ディスク容量:10TB
    • Dドライブ:5TB
    • Eドライブ:5TB

02_source_disk001.png

課題点

FJcloud-V では 1つの増設ディスクあたりの容量上限 が定められているため、以下のような構成は、ディスク単位での単純な復元では移行できません。

  • 容量上限を超過
  • 使用量も仕様超過(単純な縮小復元ができない)

解決策:ボリュームマッピングを利用した移行

Acronis のリストア機能では、復元時に ボリューム単位で復元先ディスクを指定できます。

本検証では、以下の方法を採用しました。

  • 移行先 FJcloud-V で複数の増設ディスクを事前に作成
  • リストア時に、パーティション(ボリューム)ごとに別々の増設ディスクへ割り当て 02_source_disk002.png
  • 移行後のイメージ 02_source_disk003.png

前提条件

  • 移行元ディスクがパーティション分割されていること
  • 各パーティションの容量がFJcloud-V のディスク容量の仕様内であること

検証パターン

パターン OS 移行元構成 移行先構成
Windows Server 2016 200GB×1
・D:100GB
・E:100GB
100GB×2
Red Hat Enterprise Linux 7 200GB×1
・vdb1:100GB
・vdb2:100GB
100GB×2

※ システムディスク容量は本検証の考慮範囲外としています。

検証結果

検証結果は以下の通りです。

  • Windows Server / Red Hat Enterprise Linux ともに 移行成功
  • いずれのパターンも、パーティション単位での復元が可能でした

OS別:ボリュームマッピング時の注意点

Windows Server における注意点

Windows Server の場合、本検証ではリストア時に明示的なボリュームマッピング変更は不要でした。
ただし、以下の点には注意が必要です。

  • システム領域(C:)を含むディスクは、必ず「ディスク1」に割り当てが必要
    • データボリューム(D: / E:)については、自動割り当てのままでも問題なく復元された

システム領域を誤ったディスクに割り当てた場合、復元自体は成功しても OS が正常に起動しない可能性があります。

Red Hat Enterprise Linux における注意点

Red Hat Enterprise Linux の場合、リストア時のボリュームマッピングに注意が必要です。

  • 移行元サーバーと移行先(FJcloud-V)で仮想化方式が異なる場合、ストレージデバイスのデバイス名が変更される
    • 例:移行元で /dev/vd[x] だったディスクが、FJcloud-V へ移行後 /dev/sd[x] に変更される
  • 本検証では、容量超過したディスクを別々の増設ディスクへリストアしているため、デバイス名およびパーティション番号も変更される
    • 例:移行元で /dev/vdb1/dev/vdb2 だったパーティションが、移行後は別ディスクとして /dev/sdb1/dev/sdc1 に割り当てられる
  • Acronis のデフォルト割り当てでは、意図しないディスクに復元される場合がある

そのため、以下を必ず確認してください。

  • /(ルートファイルシステム)を含むディスクは必ず「ディスク1」に割り当てる
  • 増設ディスクのパーティション(vdb1 / vdb2)は、想定したディスクに割り当てられていることを確認する

本検証では、ボリュームマッピングを調整することで問題なく復元および起動が可能であることを確認しました。

移行時の留意事項

  • 復元先ディスク選択時はシステム領域を含むディスクを必ず「ディスク1」に割り当ててください
  • OS が正常に起動しない場合は、Acronis のユニバーサルリストアを実施してください

共通の手順・注意事項については part1 を参照してください。

検証手順

基本的な移行手順(Acronis の導入、バックアップ取得、ISO起動による復元手順など)は、part1に記載している内容と同一です。
本章では、本検証(part2)において特に注意した点、およびディスク容量超過構成に起因する補足事項のみを記載します。

移行元サーバーのディスク構成の確認

本検証では、1つの増設ディスク内でパーティション(ボリューム)を分割した構成を用意しています。 まず、移行元サーバーのディスク構成を確認します。

  • 検証パターン①(Windows Server)

    容量(ディスク) 容量(ボリューム) ボリューム ファイルシステム 備考
    80GB 80GB C: NTFS システムストレージ
    200GB 100GB D: NTFS 増設ストレージ
    100GB E: NTFS 増設ストレージ

    02_windows01.png

  • 検証パターン②(Red Hat Enterprise Linux)

    容量(ディスク) 容量(ボリューム) デバイス名 マウントポイント ファイルシステム 備考
    40GB 40GB /dev/vda / など XFS システムストレージ
    200GB 100GB /dev/vdb1 /mnt/adddisk01 EXT4 増設ストレージ
    100GB /dev/vdb2 /mnt/adddisk02 EXT4 増設ストレージ

    02_rhel01.png

移行元サーバーのバックアップと移行先サーバーの準備

  • 移行元サーバーをAcronisを使ってバックアップします。
  • 移行先サーバーをFJcloud-V上に準備します。
    • それぞれ100GBの増設ディスクを2つ作成します。
    • ここでのOS上のマウント作業は不要です。

復元時のディスク選択とボリュームマッピング

ディスク容量超過構成の場合、復元時のディスク選択およびボリュームマッピングが重要な確認ポイントとなります。

  • 復元するデータの選択では、バックアップ内容を「ボリューム」単位で指定し、ディスクをすべて選択します
  • 復元先ディスク選択画面で、システム領域の復元先が「ディスク1」になっていることを必ず確認してください
    • パターン②の検証では、「MBR"ディスク1"」及び「vda1」のデフォルトの復元先がディスク2になっていたため、復元先を手動で修正しています
  • 今回の検証では復元先をそれぞれ以下の通り設定しました
    • パターン① Windows Server
      02_windows03.png
    • パターン② Red Hat Enterprise Linux
      02_rhel04.png

復元後のディスク構成の確認

復元完了後、意図した通りにパーティションが別々のディスクへ割り当てられていることを確認します。

  • パターン① Windows Server
    02_windows04.png
  • パターン② Red Hat Enterprise Linux
    02_rhel05.png
    本検証では、移行元で /dev/vdb1、/dev/vdb2 であったパーティションが、移行後は /dev/sdb1、/dev/sdc1 として別ディスクに割り当てられていることを確認しました。

まとめ

本記事では、移行元サーバーのディスク容量および使用量がFJcloud-V の仕様を超過している場合でも、以下の条件に合致していればAcronis のボリュームマッピング機能を利用することで移行可能であることを確認しました

  • ディスクがパーティション分割されている
  • 各パーティションの容量がFJcloud-V のディスク容量の仕様内であること

大容量ディスクを利用している既存環境においても、ディスク構成を整理することで FJcloud-V への移行が現実的な選択肢となります。

次回の part3 では、「移行元サーバーのディスク本数が FJcloud-V の仕様を超過している場合」について解説します。

注意事項

  • 本記事は、実現性の確認を目的としています。実際に利用する場合は実作業前にお客様にて検証および動作確認を実施し、問題なく移行できるか確認してください。
  • 本記事の掲載時点の情報になります。最新の情報は各サービスのサービスページ技術仕様ページを参照してください。
  • 本記事に記載されている会社名、製品名等の固有名詞は各社の商号、登録商標または商標です。
  • 本記事の他社サイトへのリンクにつきまして、リンク切れの際はご容赦ください。
  • 本記事の他社サービス利用に関する記載については、FJcloud-Vのサポート対象外となります。ご自身の責任でご利用ください。

Fujitsu Cloud Direct に関するお問い合わせ・ご相談

Webでのお問い合わせ
PageTop