「rsync」コマンドを用いてEC2上のファイルデータをFSx for OpenZFSに移行してみた
はじめに
みなさんこんにちは、クラウド事業本部コンサルティング部の浅野です。
現在Amazon EC2上でデータを管理しているが、EFSやFSx等の共有ファイルストレージに移行したいというシチュエーションはあるのではないでしょうか。
今回はEC2内で管理しているデータをFSx for OpenZFSに「rsync」コマンド経由で移行してみてデータ移行のイメージを体感してみようと思います。
AWSでNFSベースの共有ファイルストレージといえばAmazon EFS等もありますが、今回はFSx for OpenZFSを選択しました。
FSx for OpenZFSはストレージ容量とスループットを事前に指定するプロビジョニング型の料金体系のため、EFSと比べて月額コストが予測しやすいというメリットがあります。また、圧縮が標準で利用でき、ZFSネイティブのスナップショットやボリューム単位でのクォータ設定など、ファイルシステムとしての機能が充実していることもEFSとの相違点だと思います。
本番データを移行する場合は、より安全にデータ移行計画を立て、「AWS DataSync」等を用いてカットオーバーのタイミングやエラー時の切り戻し等を考慮したうえで行った方が良いですが、今回はデータ移行のイメージを簡易的に体感してみたいので、「rsync」コマンド経由でデータの移行動作を検証します。
rsyncコマンドとは
rsyncは、Unix系OSで使用できるファイル同期・転送コマンドです。今回はこちらを使用してEC2内のターミナルからデータを移行する予定です。
主な特徴
| 特徴 | 説明 |
|---|---|
| 差分転送 | 変更があったファイルのみを転送するため、効率的にデータを同期できる |
| 圧縮転送 | 転送時にデータを圧縮し、ネットワーク帯域を節約できる |
| 属性保持 | パーミッション、所有者、タイムスタンプなどのファイル属性を保持したまま転送できる |
| 再開可能 | 転送が中断しても、途中から再開できる |
参考: rsync公式ページ
基本構文
rsync [オプション] 転送元 転送先
よく使うオプション
| オプション | 説明 |
|---|---|
-a |
アーカイブモード（-rlptgoDと同等）。パーミッションやタイムスタンプを保持 |
-v |
詳細な出力を表示 |
-z |
転送時にデータを圧縮 |
-P |
進捗表示と部分転送の再開を有効化（--progress --partialと同等） |
--delete |
転送元に存在しないファイルを転送先から削除 |
注意点
- WindowsではWSL（Windows Subsystem for Linux）を利用するか、cwRsyncなどのサードパーティツールが必要です
構成
今回は下記のリソースをCDKで構築してデータ移行をしてみます。
※ Google Gemini上のNano Banana Pro により生成
CDKスタック
import * as cdk from 'aws-cdk-lib';
import { Construct } from 'constructs';
import * as ec2 from 'aws-cdk-lib/aws-ec2';
import * as fsx from 'aws-cdk-lib/aws-fsx';
import * as iam from 'aws-cdk-lib/aws-iam';
export class DemoFsxOpenzfsMigrationStack extends cdk.Stack {
constructor(scope: Construct, id: string, props?: cdk.StackProps) {
super(scope, id, props);
// VPC
const vpc = new ec2.Vpc(this, 'FsxMigrationVpc', {
ipAddresses: ec2.IpAddresses.cidr('10.0.0.0/24'),
maxAzs: 1,
natGateways: 0,
subnetConfiguration: [
{
cidrMask: 26,
name: 'Private',
subnetType: ec2.SubnetType.PRIVATE_ISOLATED,
},
],
});
// VPCエンドポイント用セキュリティグループ
const vpcEndpointSg = new ec2.SecurityGroup(this, 'VpcEndpointSg', {
vpc,
description: 'Security group for VPC Endpoints',
allowAllOutbound: true,
});
vpcEndpointSg.addIngressRule(
ec2.Peer.ipv4(vpc.vpcCidrBlock),
ec2.Port.tcp(443),
'Allow HTTPS from VPC'
);
// SSM用VPCエンドポイント（SSM Agent 3.3.40.0以降は ssm と ssmmessages の2つでOK）
vpc.addInterfaceEndpoint('SsmEndpoint', {
service: ec2.InterfaceVpcEndpointAwsService.SSM,
subnets: { subnetType: ec2.SubnetType.PRIVATE_ISOLATED },
securityGroups: [vpcEndpointSg],
});
vpc.addInterfaceEndpoint('SsmMessagesEndpoint', {
service: ec2.InterfaceVpcEndpointAwsService.SSM_MESSAGES,
subnets: { subnetType: ec2.SubnetType.PRIVATE_ISOLATED },
securityGroups: [vpcEndpointSg],
});
// S3ゲートウェイエンドポイント（yumリポジトリアクセス用）
vpc.addGatewayEndpoint('S3Endpoint', {
service: ec2.GatewayVpcEndpointAwsService.S3,
subnets: [{ subnetType: ec2.SubnetType.PRIVATE_ISOLATED }],
});
// EC2ファイルサーバー用セキュリティグループ
const ec2FileServerSg = new ec2.SecurityGroup(this, 'Ec2FileServerSg', {
vpc,
securityGroupName: 'ec2-fileserver-sg',
description: 'Security group for EC2 File Server',
allowAllOutbound: true,
});
// FSx用セキュリティグループ
const fsxSg = new ec2.SecurityGroup(this, 'FsxOpenzfsSg', {
vpc,
securityGroupName: 'fsx-openzfs-sg',
description: 'Security group for FSx OpenZFS',
allowAllOutbound: false,
});
// FSx へのNFSアクセス許可
fsxSg.addIngressRule(ec2FileServerSg, ec2.Port.tcp(111), 'NFS RPC');
fsxSg.addIngressRule(ec2FileServerSg, ec2.Port.tcp(2049), 'NFS');
fsxSg.addIngressRule(ec2FileServerSg, ec2.Port.tcpRange(20001, 20003), 'NFS mount/status/lock');
fsxSg.addIngressRule(ec2FileServerSg, ec2.Port.udp(111), 'NFS RPC');
fsxSg.addIngressRule(ec2FileServerSg, ec2.Port.udp(2049), 'NFS');
fsxSg.addIngressRule(ec2FileServerSg, ec2.Port.udpRange(20001, 20003), 'NFS mount/status/lock');
// EC2ファイルサーバー（Amazon Linux 2）
new ec2.Instance(this, 'Ec2FileServer', {
vpc,
vpcSubnets: {
subnetType: ec2.SubnetType.PRIVATE_ISOLATED,
},
instanceType: ec2.InstanceType.of(ec2.InstanceClass.T3, ec2.InstanceSize.MICRO),
machineImage: ec2.MachineImage.latestAmazonLinux2({
cpuType: ec2.AmazonLinuxCpuType.X86_64,
}),
securityGroup: ec2FileServerSg,
role: new iam.Role(this, 'Ec2FileServerRole', {
assumedBy: new iam.ServicePrincipal('ec2.amazonaws.com'),
managedPolicies: [
iam.ManagedPolicy.fromAwsManagedPolicyName('AmazonSSMManagedInstanceCore'),
],
}),
blockDevices: [
{
deviceName: '/dev/xvda',
volume: ec2.BlockDeviceVolume.ebs(20, {
volumeType: ec2.EbsDeviceVolumeType.GP3,
}),
},
],
});
// FSx for OpenZFS
new fsx.CfnFileSystem(this, 'FsxOpenzfs', {
fileSystemType: 'OPENZFS',
storageCapacity: 64,
subnetIds: [vpc.isolatedSubnets[0].subnetId],
securityGroupIds: [fsxSg.securityGroupId],
openZfsConfiguration: {
deploymentType: 'SINGLE_AZ_2',
throughputCapacity: 160,
rootVolumeConfiguration: {
dataCompressionType: 'LZ4',
},
automaticBackupRetentionDays: 0,
},
tags: [
{
key: 'Name',
value: 'fsx-openzfs-migration',
},
],
});
}
}
2025年12月現在、CDKでFSx for OpenZFSのファイルシステムリソースの作成はL2コンストラクトが存在しないようです。今回はL1コンストラクト(Cfnレベル)で作成しています。
環境情報
- リージョン: ap-northeast-1（東京）
- ネットワーク: VPC内の単一Private Subnetにリソースを配置
EC2インスタンス（移行元）
- OS: Amazon Linux 2
- アーキテクチャ: x86_64
- セキュリティグループ:
ec2-fileserver-sg - 移行元ディレクトリ:
/data - マウントポイント:
/mnt/fsx
FSx for OpenZFS（移行先）
- デプロイメントタイプ: Single-AZ 2（non-HA）
- ストレージ容量: 64 GB
- スループット: 160 MBps
- データ圧縮: LZ4
- 自動バックアップ: 無効（0日）
今回は検証目的のため、FSx for OpenZFSの最小構成（ストレージ64GB、スループット160MBps）を選択しています。Single-AZ 2（non-HA）は高可用性が不要な検証用途に適しており、コストを抑えられます。本番環境では、データ量・アクセス頻度・可用性要件に応じて適切な構成を選択してください。
セキュリティグループ設定（FSx ENI用）
fsx-openzfs-sgのインバウンドルール:
| タイプ | ポート | ソース |
|---|---|---|
| NFS | 2049 | ec2-fileserver-sg |
| TCP | 111 | ec2-fileserver-sg |
| TCP | 20001-20003 | ec2-fileserver-sg |
上記セキュリティグループの設定は下記の公式ドキュメント推奨構成を使用しています。
やってみた
上記CDKをデプロイしたところから始めます。
以下の画面のようにFSx for OpenZFSのファイルシステムとボリュームが作成されていることが確認できました。
構築したEC2内にSSMを用いて接続してデータを移行してみます。
移行元データの準備
移行元となるテストデータを作成します。今回は以下の4つの検証パターンを試すため、2種類の擬似データを用意します。
検証パターン
| 検証内容 | rsyncオプション |
確認ポイント |
|---|---|---|
| ①基本同期 | -avz |
初回転送の出力、属性保持（パーミッションやタイムスタンプ） |
| ②差分転送 | -av |
変更・追加ファイルのみが転送されること |
| ③中断→再開 | -avP |
大容量ファイルを途中で中断しても再開できること |
| ④削除同期 | -av --delete |
削除の反映確認 |
用意する擬似テストデータ
| ディレクトリ | 内容 |
|---|---|
/data/documents |
テキストファイル（5個） |
/data/large |
大容量ファイル（50MB） |
以下のコマンドでディレクトリの作成とテストデータの生成を行います。
# 移行元ディレクトリをroot直下に作成
sudo mkdir /data
# 所有者を現在のユーザーに変更（書き込み権限付与）
sudo chown -R $(whoami):$(whoami) /data
# サブディレクトリの作成
sudo mkdir /data/{documents,large}
# テキストファイルの生成（ドキュメント）
for i in {1..5}; do
echo "This is document file $i - $(date)" > /data/documents/doc_$i.txt
done
# 大容量ファイルの生成（50MB）
dd if=/dev/urandom of=/data/large/largefile.bin bs=1M count=50 2>/dev/null
生成されたデータを確認します。
# treeのインストール
sudo yum install -y tree
# ディレクトリ構造の確認
tree /data
/data
├── documents
│ ├── doc_1.txt
│ ├── doc_2.txt
│ ├── doc_3.txt
│ ├── doc_4.txt
│ └── doc_5.txt
└── large
└── largefile.bin
# 各ディレクトリのサイズ確認
du -sh /data/*
20K /data/documents
50M /data/large
これで移行元データの準備が完了しました。次にFSx for OpenZFSをマウントして、rsyncコマンドでデータを移行します。
FSx へのマウント
続いては構築したFSx for OpenZFSをEC2にNFSマウントします。
まず、NFSクライアントがインストールされているか確認します。
# nfs-utilsのインストール確認
rpm -qa | grep nfs-utils
nfs-utils-1.3.0-0.54.amzn2.0.2.x86_64
通常、Amazon Linux 2ではnfs-utilsがプリインストールされています(Amazon Linux 2023も同様)。インストールされていない場合はsudo yum install -y nfs-utilsでインストールしてください。
まず、現在のマウント一覧を確認します。
# マウント一覧確認
df -h
Filesystem Size Used Avail Use% Mounted on
devtmpfs 459M 0 459M 0% /dev
tmpfs 470M 0 470M 0% /dev/shm
tmpfs 470M 344K 470M 1% /run
tmpfs 470M 0 470M 0% /sys/fs/cgroup
/dev/nvme0n1p1 20G 2.1G 18G 11% /
当然ながら、まだマウント一覧には表示されていません。マウントポイントとなるディレクトリを作成します。
# マウントポイントの作成
sudo mkdir -p /mnt/fsx
ファイルシステムとの疎通確認
FSx for OpenZFSのDNS名をAWSコンソールから確認します。
ファイルシステムの詳細画面で「ネットワークとセキュリティ」タブを開き、「DNS名」をコピーします。
# FSxのDNS名を変数に設定（実際のDNS名に置き換えてください）
FSX_DNS="fs-xxxxxxxxxxxxxxxxx.fsx.ap-northeast-1.amazonaws.com"
# 疎通確認（showmountでエクスポート一覧を表示）
# NFS サーバーが外部に公開している export（共有ディレクトリ）一覧を取得するコマンド
showmount -e $FSX_DNS
Export list for fs-xxxxxxxxxxxxxxxxx.fsx.ap-northeast-1.amazonaws.com:
/fsx *
上記のようにエクスポート一覧が表示されれば、FSxとの疎通は成功です。
マウント
続いてNFSマウントを実行します。
# NFSマウント
sudo mount -t nfs -o nfsvers=4.1 $FSX_DNS:/fsx/ /mnt/fsx
マウントコマンドを実行したら再度マウント状況を確認します。
# 再度マウント一覧確認
df -h
Filesystem Size Used Avail Use% Mounted on
devtmpfs 459M 0 459M 0% /dev
tmpfs 470M 0 470M 0% /dev/shm
tmpfs 470M 348K 470M 1% /run
tmpfs 470M 0 470M 0% /sys/fs/cgroup
/dev/nvme0n1p1 20G 2.1G 18G 11% /
fs-015efe70397d1307a.fsx.ap-northeast-1.amazonaws.com:/fsx 64G 0 64G 0% /mnt/fsx
先ほどの結果からfs-xxxxで始まる行が追加されており、マウント先も/mnt/fsxと意図したとおりに設定されており、マウントに成功したことが確認できました。
これでマウントが完了し、rsyncコマンドでデータを移行する準備が整いました。
データ移行
まず、rsyncコマンドがインストールされているか確認します。
which rsync
/usr/bin/rsync
Amazon Linux 2ではrsyncがプリインストールされています(Amazon Linux 2023も同様)。
インストールされていない場合はsudo yum install -y rsyncでインストールしてください。
それでは、4つの検証パターンを順番に試していきます。
① 基本同期
まずは初回の全体転送を行います。-a（アーカイブモード）でパーミッションやタイムスタンプを保持し、-vで詳細出力、-zで転送時の圧縮を有効にします。
sudo rsync -avz /data/ /mnt/fsx/
sending incremental file list
rsync: chgrp "/mnt/fsx/." failed: Operation not permitted (1)
./
documents/
documents/doc_1.txt
documents/doc_2.txt
documents/doc_3.txt
documents/doc_4.txt
documents/doc_5.txt
large/
large/largefile.bin
sent 52,459,432 bytes received 211 bytes 34,973,095.33 bytes/sec
total size is 52,429,075 speedup is 1.00
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1179) [sender=3.1.2]
エラーが発生しました。
エラーの原因
rsync: chgrp "/mnt/fsx/." failed: Operation not permitted (1) というエラーは、NFSマウント時の権限設定に起因しています。
FSx for OpenZFSのNFSエクスポートでは、デフォルトでroot_squashが有効になっています。root_squashとは、NFSクライアントからrootユーザーでアクセスした場合に、権限をルート権限を持たない匿名ユーザーにマッピングしてセキュリティを確保する仕組みです。
この設定により、rsyncの-aオプションに含まれる-g（グループ保持）でchgrpを実行する際に、権限不足でエラーとなります。
対応方針（no_root_squash設定）
rsyncやDataSyncを使ったデータ移行時には、FSx for OpenZFSのNFSエクスポートに以下のオプションを設定することが推奨されています。
| オプション | 説明 |
|---|---|
rw |
読み取りと書き込みを許可 |
crossmnt |
ボリューム内の子ボリュームへアクセスを継承する。スナップショットへのアクセスに必要 |
no_root_squash |
クライアントのrootからのアクセスを、そのままrootとして扱う |
下記はDataSyncを用いた転送方法の補足説明ですが、rsyncで転送する際にも同じNFSエクスポートを設定する方が良いでしょう。
設定手順:
- AWSコンソールでFSx for OpenZFSのボリューム詳細画面を開き、「アクション」>「ボリュームを更新」を選択
- 「NFSエクスポート」項目の「NFSオプション」を編集して
rw,crossmnt,no_root_squashを設定し、更新
- 更新の反映を確認
設定変更後の再実行
NFSエクスポート設定を変更後、設定を反映させるために一度アンマウントして再マウントします。その後、先ほどエラーが発生した際に転送されたファイルを削除してから再度rsyncを実行します。
# アンマウント
sudo umount /mnt/fsx
# 再マウント
sudo mount -t nfs -o nfsvers=4.1 $FSX_DNS:/fsx/ /mnt/fsx
# 転送先のファイルを削除
sudo rm -rf /mnt/fsx/*
# 再度rsyncを実行
sudo rsync -avz /data/ /mnt/fsx/
sending incremental file list
./
documents/
documents/doc_1.txt
documents/doc_2.txt
documents/doc_3.txt
documents/doc_4.txt
documents/doc_5.txt
large/
large/largefile.bin
sent 52,459,436 bytes received 149 bytes 20,983,834.00 bytes/sec
total size is 52,429,075 speedup is 1.00
上記のようにエラーなく転送が完了しました。
出力の最後の行に注目してください。-zオプションによる圧縮効果や差分転送の効率が以下の項目で確認できます。
| 項目 | 説明 |
|---|---|
sent |
実際にネットワーク経由で送信したバイト数（プロトコルオーバーヘッド含む） |
total size |
転送したファイルの実際のサイズ |
speedup |
total size / sent の比率。圧縮や差分転送が効くと1より大きくなる |
今回はspeedup is 1.00となっており、圧縮効果がほとんど出ていません。sentがtotal sizeより約30KB大きいのは、rsyncプロトコルのオーバーヘッド（メタデータ、チェックサム等）が含まれるためです。
今回検証用に用意した大容量ファイルをランダムデータで生成したため圧縮が効きにくいデータでしたが、テキストファイルやログファイルなど圧縮しやすいデータを転送する場合は、speedupの値が1より大きくなりネットワーク帯域を節約できます。
転送先を確認します。
ls -la /mnt/fsx/*
/mnt/fsx/documents:
total 4
drwxr-xr-x 2 ssm-user ssm-user 7 Dec 14 00:30 .
drwxr-xr-x 4 ssm-user ssm-user 4 Dec 14 00:29 ..
-rw-r--r-- 1 ssm-user ssm-user 55 Dec 14 00:30 doc_1.txt
-rw-r--r-- 1 ssm-user ssm-user 55 Dec 14 00:30 doc_2.txt
-rw-r--r-- 1 ssm-user ssm-user 55 Dec 14 00:30 doc_3.txt
-rw-r--r-- 1 ssm-user ssm-user 55 Dec 14 00:30 doc_4.txt
-rw-r--r-- 1 ssm-user ssm-user 55 Dec 14 00:30 doc_5.txt
/mnt/fsx/large:
total 51242
drwxr-xr-x 2 ssm-user ssm-user 3 Dec 14 00:31 .
drwxr-xr-x 4 ssm-user ssm-user 4 Dec 14 00:29 ..
-rw-r--r-- 1 ssm-user ssm-user 52428800 Dec 14 00:31 largefile.bin
これでデータが無事移行されていることと、パーミッションや所有者が保持されていることが確認できました。
② 差分転送
rsyncの機能の一つである差分転送時の動作と出力を確認します。まず、転送元にファイルを追加します。
# 新しいファイルを追加
echo "This is a new document - $(date)" > /data/documents/doc_6.txt
# 既存ファイルを更新
echo "Updated content - $(date)" >> /data/documents/doc_1.txt
再度rsyncを実行します。
sudo rsync -av /data/ /mnt/fsx/
sending incremental file list
documents/
documents/doc_1.txt
documents/doc_6.txt
sent 534 bytes received 59 bytes 1,186.00 bytes/sec
total size is 52,429,176 speedup is 88,413.45
このように、変更・追加されたファイル（doc_1.txt、doc_6.txt）のみが転送され、変更のないファイルはスキップされることが確認できました。
③ 中断→再開
大容量ファイルの転送を途中で中断し、再開できることを確認します。-Pオプションは--progress（進捗表示）と--partial（部分転送ファイルを保持）の組み合わせです。
まず、転送先の大容量ファイルを削除して再転送します。
# 転送先のlargeディレクトリを削除
sudo rm -rf /mnt/fsx/large
# -Pオプション付きで転送開始（転送中にCtrl+Cで中断）
sudo rsync -avP /data/large/ /mnt/fsx/large/
sending incremental file list
created directory /mnt/fsx/large
./
largefile.bin
52,428,800 100% 326.59MB/s 0:00:00 (xfr#1, to-chk=0/2)
^C'
rsync error: received SIGINT, SIGTERM, or SIGHUP (code 20) at rsync.c(638) [sender=3.1.2]
rsync error: received SIGINT, SIGTERM, or SIGHUP (code 20) at io.c(511) [generator=3.1.2]
Ctrl+Cで途中中断を試みましたが、50MB程度のファイルでは転送が一瞬で完了してしまい、Ctrl+Cで中断する前に100%になってしまいました。
中断→再開の動作を確認するため、500MBのファイルを作成し直します。
# 500MBの大容量ファイルを作成
dd if=/dev/urandom of=/data/large/largefile.bin bs=1M count=500 2>/dev/null
# 転送先のlargeディレクトリを削除
sudo rm -rf /mnt/fsx/large
# -Pオプション付きで転送開始（転送中にCtrl+Cで中断）
sudo rsync -avP /data/large/ /mnt/fsx/large/
sending incremental file list
created directory /mnt/fsx/large
./
largefile.bin
195,854,336 37% 186.75MB/s 0:00:01
^C
rsync error: received SIGINT, SIGTERM, or SIGHUP (code 20) at rsync.c(638) [sender=3.1.2]
rsync error: received SIGINT, SIGTERM, or SIGHUP (code 20) at io.c(511) [generator=3.1.2]
上記のように37%ほどの進行中に途中でCtrl+Cを押して中断しました。転送先を確認すると、部分的に転送されたファイルが残っていました。
ls -la /mnt/fsx/large/
total 230470
drwxr-xr-x 2 ssm-user ssm-user 3 Dec 14 02:25 .
drwxr-xr-x 4 ssm-user ssm-user 4 Dec 14 02:25 ..
-rw-r--r-- 1 ssm-user ssm-user 235831296 Jan 1 1970 largefile.bin
再度同じコマンドを実行します。
sudo rsync -avP /data/large/ /mnt/fsx/large/
sending incremental file list
./
largefile.bin
524,288,000 100% 192.96MB/s 0:00:02 (xfr#1, to-chk=0/2) # 「100%」の部分がはじめは「37%」から始まっていました
sent 524,416,135 bytes received 38 bytes 149,833,192.29 bytes/sec
total size is 524,288,000 speedup is 1.00
中断した37%の位置から転送が再開され、100%まで完了しました。このように、途中で予期せぬ転送の中断が起こっても効率的に再開できます。
大容量ファイルの転送やネットワークが不安定な環境では、-Pオプションを有効にすることをお勧めします。
④ 削除同期
最後に、転送元で削除したファイルを転送先でも削除する削除同期の動作を確認します。
# 転送元でファイルを削除
rm /data/documents/doc_3.txt
# 削除前の転送先を確認
ls /mnt/fsx/documents/
doc_1.txt doc_2.txt doc_3.txt doc_4.txt doc_5.txt doc_6.txt
--deleteオプションを付けてrsyncを実行します。
sudo rsync -av --delete /data/ /mnt/fsx/
sending incremental file list
./
deleting documents/doc_3.txt
documents/
sent 278 bytes received 47 bytes 650.00 bytes/sec
total size is 524,288,321 speedup is 1,613,194.83
上記のようにdeleting documents/doc_3.txtと表示され、転送元に存在しないファイルが転送先から削除されました。
# 削除後の転送先を確認
ls /mnt/fsx/documents/
doc_1.txt doc_2.txt doc_4.txt doc_5.txt doc_6.txt
最後に
本記事では、Amazon EC2上のデータをFSx for OpenZFSにrsyncコマンドで移行する手順を検証しました。
実施した内容は以下のとおりです。
- CDKを使用してVPC、EC2インスタンス、FSx for OpenZFSを構築
- EC2からFSx for OpenZFSへのNFSマウントを実施
- rsyncコマンドの4つの検証パターン（基本同期、差分転送、中断→再開、削除同期）を確認
再度記載しますが、今回は検証のため、いきなりrsyncコマンドでデータを移行していますが、本番環境でのデータ移行を行う場合は「削除同期」に関わらず、下記を含めて安全に実行しましょう。
- 計画
- バックアップ
---dry-runオプションでの実行前動作確認
rsyncは差分転送や中断後の再開など、データ移行に便利な機能を備えていますが、大規模なデータ移行では、AWS DataSyncの利用も検討してください。DataSyncはエラーハンドリングや転送の監視機能が充実しており、より安全にデータ移行が行えます。
この記事がどなたかの参考になれば幸いです。今回は以上です。
