Amazon FSx for OpenZFS スナップショット周りの仕様をまとめて検証してみた
はじめに
みなさんこんにちは、クラウド事業本部コンサルティング部の浅野です。
Amazon FSx for OpenZFSでは、ボリューム単位でスナップショットを取得でき、誤ってデータを削除した時にボリューム全体、またはその中の特定のディレクトリやファイルを指定して高速にリストアすることが可能です。
スナップショットはファイルシステム内の.zfs/snapshotに読み取り専用としてボリューム単位で保存され、各ディレクトリやファイルを指定してリストアする場合はcpコマンドが使用可能で、ボリューム単位でリストアしたい場合はAWS CLIコマンドまたはコンソールから操作可能です。
本記事では、ルートボリューム/fsxからスナップショットの取得・復元を実際に行い挙動をまとめて検証していきます。
バックアップとの役割比較
Amazon FSx for OpenZFSには、ファイルシステム単位でのバックアップ機能もあり、スナップショットとそれぞれどう違うかを表形式で比較してみました。
| 項目 | バックアップ | スナップショット |
|---|---|---|
| 保存先 | Amazon S3 (AWS管理) | ファイルシステム内（.zfs/snapshot） |
| スコープ | ファイルシステム全体 | ボリューム単位 |
| 耐久性 | 高（S3、リージョン間コピー可） | ファイルシステムに依存 |
| ストレージ料金 | S3料金（別途） | ファイルシステム容量を消費 |
| 保持期間 | 自動: 1〜90日 / 手動: 無期限 | 手動管理 |
| 復元方法 | 新規ファイルシステム作成 | ボリュームロールバック or ファイルコピー |
| 復元速度 | 遅い | 高速 |
| クローン作成 | ✕ | ◯（書込可能コピーを即座に作成） |
| FS削除後の保持 | ◯（保持される） | ✕（消失） |
| AWS Backup連携 | ◯ | ✕ |
| 主な用途 | 災害復旧、コンプライアンス、長期保存、環境複製 | セルフサービス復元、開発テスト、DB操作前保護、バージョン比較 |
バックアップは災害復旧やファイルシステム複製のために定期的に取得する長期保存用です。一方、スナップショットは開発や検証用に一部の本番データをコピーしたい場合や、重要な操作の前にファイルを誤って削除・変更しないよう復元用に取得して使用するイメージです。
スナップショットからボリュームを復元する方法
復元方法の種類
スナップショットからデータを復元する方法は主に以下4つがあります。
| 方法 | 概要 |
|---|---|
| ファイル単位で復元 | .zfs/snapshotから必要なファイルを手動コピー |
| クローンボリューム作成 | スナップショットから新しいボリュームを作成（参照型） |
| 完全コピーボリューム作成 | スナップショットから独立したボリュームを作成（物理コピー） |
| ボリューム復元（ロールバック） | 既存ボリュームを過去のスナップショット状態に巻き戻す |
クローンボリュームと完全コピーボリュームの違いについて
スナップショットから新しいボリュームを作成する方法には「クローンボリューム」と「完全コピーボリューム」の2種類があります。
クローンボリューム
クローンボリュームは元のスナップショットを参照した書き込み可能なボリュームでスナップショットから高速で作成可能です。スナップショットとファイルシステム内の容量を共有しておりスナップショットからの変更分のみファイルサイズが増加する仕組みです。クローンが存在する限りそのスナップショットは削除できません。
完全コピーボリューム
完全コピーボリュームはスナップショットの全データを物理的にコピーした独立したボリュームです。データ量に応じて作成に時間がかかりますが、元のスナップショットとの依存関係がないため、作成後はスナップショットを自由に削除できます。作成時のストレージ容量は元データと同量を消費します。
まとめ表
| 項目 | クローン | 完全コピー |
|---|---|---|
| 仕組み | スナップショットを参照 | 全データを物理コピー |
| 作成速度 | 即時 | データ量に依存 |
| 初期ストレージ消費 | なし（変更分のみ） | 元データと同量 |
| スナップショットへの依存 | あり | なし |
スナップショットからのボリューム復元について
また、既存のボリュームを過去のスナップショットの状態に巻き戻す「ボリューム復元（ロールバック）」が可能です。
ボリューム復元では、「復元先」と「現在の状態」の間の時刻に作成されたスナップショットを「中間スナップショット」と呼びます。
中間スナップショットやそこから作成されたクローンボリュームが存在すると、依存関係によりボリュームの復元が失敗します。復元を成功させるには、これら全てを削除する必要があります。
コンソールからボリュームを復元する際、以下のような画面で削除オプションが表示され、中間スナップショットとそれに紐づくクローンボリュームを削除する必要があることが記載されています。
構成
今回はスナップショットに関する操作の検証用として以下の「マウント用EC2 1台」+「FSx for OpenZFS(SingleAZ non-HA)」の簡易構成でシステムを構築しました。
上記のネットワーク構成、EC2インスタンスの用意、FSxファイルシステムの準備までをCDKスタックにて用意しました。
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';
/**
* FSx for OpenZFS スナップショット検証用スタック
*/
export class DemoFsxOpenzfsSnapshotStack extends cdk.Stack {
constructor(scope: Construct, id: string, props?: cdk.StackProps) {
super(scope, id, props);
// VPC
const vpc = new ec2.Vpc(this, 'Vpc', {
maxAzs: 1,
natGateways: 0,
subnetConfiguration: [
{
cidrMask: 24,
name: 'Public',
subnetType: ec2.SubnetType.PUBLIC,
},
],
});
// EC2用セキュリティグループ
const ec2Sg = new ec2.SecurityGroup(this, 'Ec2Sg', {
vpc,
description: 'Security group for EC2 instance',
allowAllOutbound: true,
});
// FSx用セキュリティグループ
const fsxSg = new ec2.SecurityGroup(this, 'FsxSg', {
vpc,
description: 'Security group for FSx for OpenZFS',
allowAllOutbound: true,
});
fsxSg.addIngressRule(ec2Sg, ec2.Port.tcp(2049), 'NFS Server');
fsxSg.addIngressRule(ec2Sg, ec2.Port.tcp(111), 'NFS RPC');
fsxSg.addIngressRule(ec2Sg, ec2.Port.tcpRange(20001, 20003), 'NFS Mount');
// FSx for OpenZFS ファイルシステム
const fileSystem = new fsx.CfnFileSystem(this, 'FileSystem', {
fileSystemType: 'OPENZFS',
subnetIds: [vpc.publicSubnets[0].subnetId],
securityGroupIds: [fsxSg.securityGroupId],
storageCapacity: 64,
openZfsConfiguration: {
deploymentType: 'SINGLE_AZ_1',
throughputCapacity: 64,
rootVolumeConfiguration: {
dataCompressionType: 'ZSTD',
nfsExports: [
{
clientConfigurations: [
{
clients: '*',
options: ['rw', 'crossmnt', 'no_root_squash'],
},
],
},
],
},
},
});
// EC2用IAMロール (SSM用)
const ec2Role = new iam.Role(this, 'Ec2Role', {
assumedBy: new iam.ServicePrincipal('ec2.amazonaws.com'),
managedPolicies: [
iam.ManagedPolicy.fromAwsManagedPolicyName('AmazonSSMManagedInstanceCore'),
],
});
// EC2インスタンス
const instance = new ec2.Instance(this, 'Instance', {
vpc,
vpcSubnets: {
subnetType: ec2.SubnetType.PUBLIC,
},
instanceType: ec2.InstanceType.of(ec2.InstanceClass.T3, ec2.InstanceSize.MICRO),
machineImage: ec2.MachineImage.latestAmazonLinux2023({
cpuType: ec2.AmazonLinuxCpuType.X86_64,
}),
securityGroup: ec2Sg,
role: ec2Role,
});
}
}
やってみた
それでは上記のCDKスタックをデプロイした状態で以下の確認項目を確認しながら実際に検証してみます。
| 検証項目 | |
|---|---|
| 1 | スナップショットの作成と確認 |
| 2 | ファイル単位の復元 |
| 3 | クローンボリュームの作成と確認 |
| 4 | スナップショットのストレージ消費確認 |
| 5 | 完全コピーボリュームの作成と確認 |
| 6 | ボリューム復元（ロールバック） |
CDKをデプロイした直後の状況は以下のようにファイルシステムが作成され、ルートボリューム/fsxのみ存在する状況です。
ファイルシステムのDNS名をコピーしておきます。
それでは、EC2内にSSM接続して「/fsx」ディレクトリに作成したファイルシステムのルートボリュームをマウントします。
sudo mkdir -p /fsx
sudo mount -t nfs -o nfsvers=4.1 <上記でコピーしたFileSystemDnsName>:/fsx /fsx
# 確認
df -h /fsx
# 出力
Filesystem Size Used Avail Use% Mounted on
fs-066f38c00eb53b46c.fsx.ap-northeast-1.amazonaws.com:/fsx 64G 0 64G 0% /fsx
上記作業にてローカルディレクトリの「/fsx」にFSx for OpenZFSの「/fsx」ボリュームをマウントして準備完了です。
1. スナップショットの作成と確認
まず初めにスナップショットを取得して特定のファイルのみを復元できることを確認するためにEC2内に適当なディレクトリを２つ作成し、それぞれテストファイルを格納します。
# テスト用ディレクトリを2個作成
mkdir -p /fsx/test1 /fsx/test2
# 各フォルダにテストファイルを作成
echo "Hello Test File Path: /fsx/test1 - $(date)" > /fsx/test1/test.txt
echo "Hello Test File Path: /fsx/test2 - $(date)" > /fsx/test2/test.txt
# 「test1」ディレクトリ内のファイル内容を確認
cat /fsx/test1/test.txt
# 出力
Hello Test File Path: /fsx/test1 - Sun Jan 25 05:34:13 UTC 2026
# 「test2」ディレクトリ内のファイル内容を確認
cat /fsx/test2/test.txt
# 出力
Hello Test File Path: /fsx/test2 - Sun Jan 25 05:34:14 UTC 2026
「FSx」コンソール画面に戻り「ボリューム」>「該当のボリューム」をチェック > 「アクションタブ」の「スナップショットを作成」を選択してスナップショット名を設定し作成します。
スナップショット名を「test-snapshot」に設定して作成します。
以下のようにスナップショット「test-snapshot」が作成されました。
また以下のようにEC2内で.zfs/snapshotを確認してみると同じようにスナップショットの作成が確認できました。
# 作成したスナップショットをEC2内から確認
ls -al /fsx/.zfs/snapshot
# 出力
total 1
drwxrwxrwx. 2 root root 2 Jan 25 05:36 .
drwxrwxrwx. 1 root root 0 Jan 25 03:20 ..
drwxrwxrwx. 4 root root 4 Jan 25 05:34 test-snapshot
# ファイルツリー形式で確認
tree /fsx/.zfs/snapshot/test-snapshot
# 出力
/fsx/.zfs/snapshot/test-snapshot
├── test1
│ └── test.txt
└── test2
└── test.txt
2 directories, 2 files
このようにOpenZFSのスナップショットの実態はファイルシステムレベルで管理されており、.zfs/snapshot/<スナップショット名>/にアクセスすると、スナップショット時点のボリュームの内容がそのままのディレクトリ構造で見えます
# スナップショット内の「test1」ディレクトリの中身を確認
ls -alk /fsx/.zfs/snapshot/test-snapshot/test1
# 出力
total 2
drwxr-xr-x. 2 ssm-user ssm-user 3 Jan 25 05:34 .
drwxrwxrwx. 4 root root 4 Jan 25 05:34 ..
-rw-r--r--. 1 ssm-user ssm-user 64 Jan 25 05:34 test.txt
ファイルのパーミッションだとスナップショットファイルも書き込みできるように見えますが、スナップショット領域自体が読み取り専用でマウント
されているので、試しに書き込んでみると以下のようにできないことがわかります。
# スナップショットに書き込みを試してみる
echo "write test" >> /fsx/.zfs/snapshot/test-snapshot/test1/test.txt
# 出力
sh: /fsx/.zfs/snapshot/test-snapshot/test1/test.txt: Read-only file system
これにてスナップショットの作成と確認ができました。
2. ファイル単位の復元
取得したスナップショットからディレクトリ・ファイル単位のリストアを試してみます。ボリューム内のフォルダやファイル単位のリストアについてはマネジメントコンソールからはできないので、EC2内からcpコマンドなどを通じて行います。
# /fsx/test1 ディレクトリを間違えて削除してしまったとする
rm -rf /fsx/test1
# 削除されたことを確認
ls /fsx/test1
# 出力
ls: cannot access '/fsx/test1': No such file or directory
# 取得しているスナップショット「test-snapshot」から「test1」ディレクトリを復元
cp -r /fsx/.zfs/snapshot/test-snapshot/test1 /fsx/test1
# 即座に復元されることを確認
cat /fsx/test1/test.txt
# 出力
Hello Test File Path: /fsx/test1 - Sun Jan 25 05:34:13 UTC 2026
このように、単純にファイルのコピー操作で簡単にディレクトリ・ファイルを指定してリストアできました。
3. クローンボリュームの作成と確認
続いて「test-snapshot」からクローンボリュームを作成して各挙動を確認してみます。
「FSx」コンソール画面 > 「OpenZFS スナップショット」>「test-snapshot」を選択してアクションタブの「スナップショットをコピーしてボリュームを作成」を選択します。
「ファイルシステム」をCDKで作成したファイルシステムに設定し、「親ボリュームID」にルートボリュームを指定します。ボリューム名は「clone-volume」として設定しました。
その他オプションは全てデフォルトのまま、「ソーススナップショットコピーの戦略」に「クローン」を選択して
「Create Volume」を選択して作成します。
以下のように/fsx/clone-volumeとして「test-snapshot」からクローンボリュームが作成されました。
続いてルートボリュームをマウントしているEC2内に再度接続し、作成されたクローンボリュームをマウントして操作してみます。
# クローンボリュームマウント用ディレクトリを作成
sudo mkdir -p /fsx/clone-volume
# クローンボリュームをマウント
sudo mount -t nfs <ファイルシステムDNS名>:/fsx/clone-volume /fsx/clone-volume
# 書き込みできることを確認
echo "Clone volume write test - $(date)" > /fsx/clone-volume/clone-test.txt
cat /fsx/clone-volume/clone-test.txt
# 出力
Clone volume write test - Sun Jan 25 06:22:39 UTC 2026
このようにクローンボリュームにマウントができ、ファイルを新たに書き込みできることも確認できました。
続いてマネジメントコンソールに戻り「test-snapshot」の削除を試みてみます。
「FSx」コンソール画面 > 「OpenZFS スナップショット」>「test-snapshot」を選択してアクションタブの「削除」を選択します。
削除を試みようとすると「このスナップショットからボリュームをシャローコピーしているため削除できない」という旨のエラーが発生しました。
以下のように作成したクローンボリューム「clone-volume」を先に削除してみるとスナップショット「test-snapshot」が削除できるようになりました。
これでクローンボリュームに関する一連の操作を確認しました。
4. スナップショットのストレージ消費確認
検証順番が前後しましたが、スナップショットは取得した時点ではファイルシステム全体の追加容量はほぼゼロです。元データが変更された後に、変更前のデータを保持するため容量を消費するようになっておりこの挙動を確認します。
まずEC2内に入って以下のコマンドを実行して「1GiB」相当のファイルを作成します。
# 既存スナップショットが存在しないことを確認
ls -al /fsx/.zfs/snapshot
# 出力
total 0
drwxrwxrwx. 2 root root 2 Jan 25 07:02 .
drwxrwxrwx. 1 root root 0 Jan 25 03:20 ..
# 圧縮されないように1GiBのファイルを作成
dd if=/dev/urandom of=/fsx/test-1gib.dat bs=1M count=1024
# 出力
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 7.38819 s, 145 MB/s
# 作成されたファイルサイズを改めて確認
ls -lh /fsx/test-1gib.dat
# 出力
-rw-r--r--. 1 ssm-user ssm-user 1.0G Jan 25 07:13 /fsx/test-1gib.dat
「1GiB」相当のファイルを作成した時点でファイルシステム全体の使用量を確認してみます。
# ファイルシステム使用量を確認
df -h /fsx
# 出力
Filesystem Size Used Avail Use% Mounted on
fs-066f38c00eb53b46c.fsx.ap-northeast-1.amazonaws.com:/fsx 64G 1.1G 63G 2% /fsx
このように Used列にて「1.1G」相当のファイルサイズが使用されています。
続いて、先ほどの「test-snapshot」を取得したのと同じ手順で、コンソールから「test-snapshot-for-fullcopy」を作成します。
「test-snapshot-for-fullcopy」スナップショットが作成された後に再度EC2内に接続し、ファイルシステム全体の容量を確認してみます。
# スナップショット「test-snapshot-for-fullcopy」が作成されたことを確認
ls /fsx/.zfs/snapshot
# 出力
test-snapshot-for-fullcopy
# ファイルシステム使用量を確認
df -h /fsx
# 出力
Filesystem Size Used Avail Use% Mounted on
fs-066f38c00eb53b46c.fsx.ap-northeast-1.amazonaws.com:/fsx 64G 1.1G 63G 2% /fsx
このようにスナップショットを作成した時点ではファイルシステムの容量を消費していないことがわかります。
続いて/fsx/test-1gib.dat「1GiB」相当のファイルを「100MiB」相当のサイズに上書きしてみます。
# 現状の「test-1gib.dat」ファイルのサイズを確認
ls -al /fsx/test-1gib.dat
# 出力
-rw-r--r--. 1 ssm-user ssm-user 1073741824 Jan 25 07:13 /fsx/test-1gib.dat
# 「100MiB」相当に上書き
dd if=/dev/urandom of=/fsx/test-1gib.dat bs=1M count=100
# 出力
100+0 records in
100+0 records out
104857600 bytes (105 MB, 100 MiB) copied, 0.631842 s, 166 MB/s
# 再度「test-1gib.dat」ファイルのサイズが減っていることを確認
ls -al /fsx/test-1gib.dat
# 出力
-rw-r--r--. 1 ssm-user ssm-user 104857600 Jan 25 07:30 /fsx/test-1gib.dat
この状態でファイルシステム全体の使用量を再度確認してみます。
# ファイルシステム使用量を確認
df -h /fsx
# 出力
Filesystem Size Used Avail Use% Mounted on
fs-066f38c00eb53b46c.fsx.ap-northeast-1.amazonaws.com:/fsx 63G 100M 63G 1% /fsx
Usedは「100M」に更新されていました。スナップショットの保持分も含めて「1.1G」になると思っていたのですが、よく見るとSizeが 64G → 63G に減少しています。
つまり、スナップショットが保持している容量（約1GiB）は Used ではなく Size（利用可能な総容量）から差し引かれていることが発見できました。
ちなみにスナップショットが元データ(1GiB)を引き続き保持していることも確認できました。
# スナップショット内のファイルサイズを確認
ls -lh /fsx/.zfs/snapshot/test-snapshot-for-fullcopy/test-1gib.dat
# 出力
-rw-r--r--. 1 ssm-user ssm-user 1.0G Jan 25 07:13 /fsx/.zfs/snapshot/test-snapshot-for-fullcopy/test-1gib.dat
# 現在のファイルサイズと比較
ls -lh /fsx/test-1gib.dat
# 出力
-rw-r--r--. 1 ssm-user ssm-user 100M Jan 25 07:30 /fsx/test-1gib.dat
この検証にて以下のことが確認できました。
- スナップショット取得時点では追加容量を消費しない
- 元データが変更されると、スナップショットが変更前のデータを保持し、その容量は
dfコマンドにてUsedではなくSizeから差し引かれたことが確認できる
5. 完全コピーボリュームの作成と確認
続いて検証4で作成したスナップショット「test-snapshot-for-fullcopy」から完全コピーボリュームを作成してみます。
「FSx」コンソール画面 > 「OpenZFS スナップショット」>「test-snapshot-for-fullcopy」を選択してアクションタブの「スナップショットをコピーしてボリュームを作成」を選択します。
クローンボリュームを作成した手順と同じく「ファイルシステム」をCDKで作成したファイルシステムに設定し、「親ボリュームID」にルートボリュームを指定します。ボリューム名は「fullcopy-volume」として設定しました。
その他オプションは全てデフォルトのまま、「ソーススナップショットコピーの戦略」に「完全コピー」を選択して
「Create Volume」を選択して作成します。
以下のように/fsx/fullcopy-volumeとして「test-snapshot-for-fullcopy」から完全コピーボリュームが作成されました。
続いてEC2内に再度接続し、作成された完全コピーボリュームをマウントして確認してみます。
# 完全コピーボリュームをマウント
sudo mkdir -p /fsx/fullcopy-volume
sudo mount -t nfs <ファイルシステムDNS名>:/fsx/fullcopy-volume /fsx/fullcopy-volume
# `fsx/fullcopy-volume`配下に1GiBのファイルが存在することを確認（物理コピーされている）
ls -lh /fsx/fullcopy-volume/test-1gib.dat
# 出力
-rw-r--r--. 1 ssm-user ssm-user 1.0G Jan 25 07:13 /fsx/fullcopy-volume/test-1gib.dat
完全コピーはスナップショットの物理コピーなのでファイルシステム全体の容量が追加で増加します。
# `/fsx/fullcopy-volume`使用量を確認
df -h /fsx/fullcopy-volume
Filesystem Size Used Avail Use% Mounted on
fs-066f38c00eb53b46c.fsx.ap-northeast-1.amazonaws.com:/fsx/fullcopy-volume 63G 1.0G 62G 2% /fsx/fullcopy-volume
# ファイルシステム全体の使用量を確認
df -h /fsx
Filesystem Size Used Avail Use% Mounted on
fs-066f38c00eb53b46c.fsx.ap-northeast-1.amazonaws.com:/fsx 62G 100M 62G 1% /fsx
このように/fsx の Size が 63G → 62G に減少しており、完全コピーによって1GiBの物理コピーが作成され、ファイルシステム全体の容量を消費しています。
続いてマネジメントコンソールに戻り「test-snapshot-for-fullcopy」の削除を試みます。
クローンボリュームと違い完全コピーボリュームはスナップショットとの依存関係がないため、ボリュームを削除しなくても以下のようにスナップショットが削除できました。
6. ボリューム復元（ロールバック）
最後にボリューム復元を実行すると、復元先スナップショットより後の時刻に作成された中間スナップショットが削除され、ファイルが復元先の状態に戻ることを確認します。具体的には以下の手順で検証します。
restore-point-snapshot（復元先）→intermediate-snapshot（中間）を時系列で作成restore-point-snapshotに復元を実行- ファイルが復元先の内容に戻り、中間スナップショットが削除されていることを確認
まずルートボリューム以外の全てのボリュームを削除し、ファイルシステムを新規作成された状態にしました。
# `/fsx`配下のファイルを全て削除したことを確認
ls /fsx -al
total 1
drwxrwxrwx. 2 root root 2 Jan 25 08:25 .
dr-xr-xr-x. 19 root root 248 Jan 25 05:20 ..
# スナップショットも存在しないことを確認
ls -al /fsx/.zfs/snapshot/
total 0
drwxrwxrwx. 2 root root 2 Jan 25 08:07 .
drwxrwxrwx. 1 root root 0 Jan 25 03:20 ..
この状態で復元先のスナップショットの状態であるファイルを作成します。
# 復元先スナップショット用のデータ
echo "restore-point-snapshot - $(date)" > /fsx/rollback-test.txt
cat /fsx/rollback-test.txt
# 出力
restore-point-snapshot - Sun Jan 25 08:31:34 UTC 2026
この時点で「restore-point-snapshot」をコンソールから作成しました。
# 「restore-point-snapshot」が作成されたことを確認
ls -al /fsx/.zfs/snapshot
# 出力
total 1
drwxrwxrwx. 2 root root 2 Jan 25 08:33 .
drwxrwxrwx. 1 root root 0 Jan 25 03:20 ..
drwxrwxrwx. 2 root root 3 Jan 25 08:31 restore-point-snapshot
続いて「intermediate-snapshot」用のファイルを追加します。
# 中間スナップショット用にファイルを追加
echo "intermediate-snapshot - $(date)" > /fsx/intermediate-file.txt
cat /fsx/intermediate-file.txt
# 出力
intermediate-snapshot - Sun Jan 25 08:35:18 UTC 2026
# ファイルの追加を確認
ls -al /fsx
# 出力
total 2
drwxrwxrwx. 2 root root 4 Jan 25 08:35 .
dr-xr-xr-x. 19 root root 248 Jan 25 05:20 ..
-rw-r--r--. 1 ssm-user ssm-user 53 Jan 25 08:35 intermediate-file.txt
-rw-r--r--. 1 ssm-user ssm-user 54 Jan 25 08:31 rollback-test.txt
この時点で中間スナップショットである「intermediate-snapshot」をコンソールから作成しました。
# 「intermediate-snapshot」が作成されたことを確認
ls -al /fsx/.zfs/snapshot
# 出力
total 1
drwxrwxrwx. 2 root root 2 Jan 25 08:37 .
drwxrwxrwx. 1 root root 0 Jan 25 03:20 ..
drwxrwxrwx. 2 root root 4 Jan 25 08:35 intermediate-snapshot
drwxrwxrwx. 2 root root 3 Jan 25 08:31 restore-point-snapshot
マネジメントコンソール上で二つのスナップショットが存在することを確認
「FSx」コンソール画面 > 「ボリューム」>「/fsx」ボリュームを選択してアクションタブの「ボリュームを復元」を選択します。
以下のオプションにチェックを入れないと「中間スナップショットが存在するのでスナップショットからの復元が出来ませんでした」というエラーが発生しました。
- 最新の共有親オブジェクトよりも最近に作成された中間スナップショットをすべて削除
- これらの中間ボリュームから作成されたすべてのクローンボリュームを削除
２つのオプションにチェックを入れるとボリュームの復元処理が開始されました。
しばらく経過すると中間スナップショットである「intermediate-snapshot」が削除されました。
ボリュームの復元が完了すると、EC2内に接続し、ファイルシステムが復元先の「restore-point-snapshot」の時点まで戻っていることを確認します。
# 再度スナップショット「intermediate-snapshot」が削除されていることを確認
ls -al /fsx/.zfs/snapshot
# 出力
total 1
drwxrwxrwx. 2 root root 2 Jan 25 08:43 .
drwxrwxrwx. 1 root root 0 Jan 25 03:20 ..
drwxrwxrwx. 2 root root 3 Jan 25 08:31 restore-point-snapshot
# `/fsx`ファイル一覧を確認
ls -al /fsx
# 出力 「intermediate-file.txt」が削除されていることを確認
total 1
drwxrwxrwx. 2 root root 3 Jan 25 08:31 .
dr-xr-xr-x. 19 root root 248 Jan 25 05:20 ..
-rw-r--r--. 1 ssm-user ssm-user 54 Jan 25 08:31 rollback-test.txt
この検証にて復元先より後に作成された中間スナップショットは削除しないとスナップショットからボリュームを復元できないことが確認できました。
最後に
本記事では、Amazon FSx for OpenZFSのスナップショット機能について、バックアップとの違いや復元方法の種類を整理し、実際に各操作を検証しました。
検証した内容は以下のとおりです。
- スナップショットの作成と
.zfs/snapshot配下での確認 - ファイル単位での復元（
cpコマンドによる手動コピー） - クローンボリュームの作成と、元スナップショットとの依存関係の確認
- スナップショットのストレージ消費動作の確認
- 完全コピーボリュームの作成と、スナップショットから独立していることの確認
- ボリューム復元（ロールバック）時の中間スナップショット削除の確認
検証を通じて、スナップショットは取得時点では追加容量を消費せず、.zfs/snapshotからファイル単位で復元する挙動を確認できました。
また、クローンボリュームと完全コピーボリュームの違いや、ボリューム復元時の中間スナップショットの扱いなど、実際に操作することで理解が深まりました。この記事がどなたかの参考になれば幸いです。今回は以上です。
