OSの入った物理ディスクをコピーしてEC2で動かしてみた

はじめに

こんにちは！社会人一年目?のタレカツです!

今回は最近自宅のディスクが壊れることがあり、自宅で動作しているOSをAWS上に移行できないかと考え、物理マシンで動作しているLinuxサーバをEC2で動作させてみました。移行はできたのですが、実際に試す際は自己責任で行なってください。

今回の物理から仮想化は推奨された事項ではないので、あくまでテストなどで試してください。物理マシンで動いていた物を仮想化して動かそうとすると、ドライバなどの影響で不具合があると思うので、基本的にEC2に移したマシンを常用利用するのはしないでください。

ローカルのサーバの移行には、AWS Application Migration Service (AWS MGN)の移行サービスやその他の移行サービスを使う方が、ベストだと思います。

移行可能な条件は以下に記載されていました。

システム構成

ローカルのディスクをddで仮想ディスク化して、s3にアップロードしてVM importをしています。作成されたAMIから、EC2のインスタンスを作成しました。

ローカルサーバ(Ubuntu)操作

ddコマンドを用いて、物理ディスクから仮想ディスクを作成しています。この際物理サーバにはコピーするディスクとは別に起動ディスクを用意して、ディスクのコピーを行いました。(起動しながらでもLVMのスナップショットを使用すれば可能？ただ、OSが起動しているディスクで、I/Oを多く発生させるのは好ましくないので、考えて行ってください)

手順としては、diskの確認をまず行います。今回は起動ディスクがsdaでもともと起動していたディスクがmmcblk0になります。

ディスクの確認を間違えないようにしてください

root@backup:/work# lsblk
NAME                         MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
loop0                          7:0    0  63.3M  1 loop /snap/core20/1822
loop1                          7:1    0 111.9M  1 loop /snap/lxd/24322
loop2                          7:2    0  49.8M  1 loop /snap/snapd/18357
sda                            8:0    0 223.6G  0 disk
├─sda1                         8:1    0     1G  0 part /boot/efi
├─sda2                         8:2    0     2G  0 part /boot
└─sda3                         8:3    0 220.5G  0 part
  └─ubuntu--vg--1-ubuntu--lv 253:1    0   100G  0 lvm  /
mmcblk0                      179:0    0  29.1G  0 disk
├─mmcblk0p1                  179:1    0     1G  0 part
├─mmcblk0p2                  179:2    0     2G  0 part
└─mmcblk0p3                  179:3    0  26.1G  0 part
  └─ubuntu--vg-ubuntu--lv    253:0    0    20G  0 lvm
mmcblk0boot0                 179:8    0     4M  1 disk
mmcblk0boot1                 179:16   0     4M  1 disk

今回はddコマンドを使用して、仮想マシンのディスクイメージを作成しました。ifが元データでofが出力先になります。

何度も言いますが、ofの出力先にもともとのディスクを書いてしまうと、元データが書き換えられてしまう可能性があるので、気をつけてください

root@backup:/work# dd if=/dev/mmcblk0 of=disk.raw bs=4M status=progress
31151095808 bytes (31 GB, 29 GiB) copied, 282 s, 110 MB/s
7455+0 records in
7455+0 records out
31268536320 bytes (31 GB, 29 GiB) copied, 282.72 s, 111 MB/s

S3へのアップロード

特別な操作は行なっておらず、aws CLIコマンドでS3にアップロードを行いました。自分の環境が悪いのかもしれないですが、かなりの時間がかかりました。

圧縮した上で転送して、AWS側で解凍するのがいいかもしれないですが、S3側で解凍を簡単にする方法が思いつかなかったので、今回はそのまま転送しています。

PS C:\Users\Tarekatsu\Documents> aws s3 cp .\disk.raw s3://bucket-name/disk.raw
upload: .\disk.raw to s3://bucket-name/disk.raw

AWS VM importでAMIの作成

VM importでAMIを作成する際は、S3に仮想ディスクをアップロードしている必要があります。また、仮想ディスクからVMを作成するためには必要なサービスロールを作成して、必要なIAM policyをアタッチします。

VM Import/Exportに必要なロールの作成手順は以下のページにまとめられています。

上の手順で必要なロールの設定が完了したら、以下のbucketと先ほど転送した仮想diskの情報を記述したjsonファイルを作成します。

[
  {
    "Description": "My Ubuntu VM",
    "Format": "raw",
    "UserBucket": {
      "S3Bucket": "bucket-name",
      "S3Key": "disk.raw"
    }
  }
]

これで必要な準備が整ったので、importを実行します。

PS C:\Users\Tarekatsu\Documents> aws ec2 import-image --description "My Imported VM" --disk-containers file://containers.json
{
    "Description": "My Imported VM",
    "ImportTaskId": "import-ami-xxxxxxxxxxxx",
    "Progress": "1",
    "SnapshotDetails": [
        {
            "Description": "My Ubuntu VM",
            "DiskImageSize": 0.0,
            "Format": "raw",
            "UserBucket": {
                "S3Bucket": "bucket-name",
                "S3Key": "disk.raw"
            }
        }
    ],
    "Status": "active",
    "StatusMessage": "pending"
}

時間があるそれなりにかかりますが、以下のコマンドで進捗を確認することができます。import-task-idsには、importコマンドを実行した時に表示されたものを指定してください。Progressが進捗の%表示になります。

aws ec2 describe-import-image-tasks --import-task-ids import-ami-xxxxxxxxx
{
    "ImportImageTasks": [
        {
            "Description": "My Imported VM",
            "ImageId": "",
            "ImportTaskId": "import-ami-xxxxxxxxxxxx",
            "Progress": "43",
            "SnapshotDetails": [
                {
                    "DiskImageSize": 31268536320.0,
                    "Format": "RAW",
                    "Status": "completed",
                    "UserBucket": {
                        "S3Bucket": "bucket-name",
                        "S3Key": "disk.raw"
                    }
                }
            ],
            "Status": "active",
            "StatusMessage": "updating",
            "Tags": []
        }
    ]
}

作成されたAMIからEC2インスタンスの作成

特に普通にEC2インスタンスを作成するときと変わりはないですが、いかに手順を示します。

起動イメージで自分のAMIに表示が出ていると思うので、選択します。

インスタンスタイプはt2.microが選択できなかったので、t3.microを選択しました。おそらくbios のブートモードで設定されていないとt2.microが選択できないと思います。

ストレージですが、仮想ディスクの値に依存するので30GiBで作成しました。

最後に起動してみて、sshで接続して元のデータが残っていることを確認しました。

 System information as of Fri Oct  3 10:34:40 PM UTC 2025

  System load:  0.0                Processes:             106
  Usage of /:   40.2% of 19.52GB   Users logged in:       0
  Memory usage: 24%                IPv4 address for eth0: 10.0.15.150
  Swap usage:   0%


Expanded Security Maintenance for Applications is not enabled.

0 updates can be applied immediately.

Enable ESM Apps to receive additional future security updates.
See https://ubuntu.com/esm or run: sudo pro status


Last login: Tue Sep 30 15:20:25 2025 from 172.10.1.103
tarekatsu@tarekatsu:~$ 

終わりに

今回はOSの入った物理ディスクを仮想ディスクにしてAWSに転送し、EC2で仮想マシンを作成しました。仮想マシンの動作検証はほとんどしていないので、物理マシンとEC2上という環境の違いによる不具合はあると思うので、普段の利用では考えないことをお勧めします。
また、ローカルの物理マシンや仮想マシンから少ない台数の移行であればいいかもしれないですが、使用したことはないですが、AWS MGNなどのサービスの方がシステムを止めないで移行することや、手順も手作業で行う範囲も少ないと思います。また、データの移行という観点であれば他のサービスが複数あるので、状況によって選択してください。

追記　物理マシンの移行ではなく、仮想ディスファイルとしてバックアップを挙げておくのはいいかもしれないと思いました(後でダウンロードして新しいディスクに書き込む)。