こんにちは。バックエンドエンジニアの筒井(@tsuttsun_wind)です。
PR TIMESではファイルストレージとしてAmazon FSx for NetApp ONTAP（以降、FSx）を利用しています。
通常は自動バックアップを行っていますが、「特定のタイミングでバックアップをしたい」や、「過去のバックアップから必要なタイミングでリストアしたい」といったケースが生じます。
この記事では、FSx上での手動バックアップの実行やリストアを行う際の具体的な手順と運用上の注意点を紹介します。
FSxのバックアップについて
FSxでは、ボリュームごとに自動および手動のバックアップの作成を行うことが可能です。
バックアップの作成自体は比較的シンプルですが、リストア時はバックアップを元のボリュームに上書きするのではなく、新しいボリュームを作成し、そこにデータをリストアする方式となっています。
ファイルシステムを作成する
FSxのファイルシステムのページから、「ファイルシステムを作成」をクリックします
ファイルシステムのオプションは、一番左の「Amazon FSx for NetApp ONTAP」を選択してください
リストアしたいバックアップのファイルシステムの設定に合わせて、ファイルシステムを作成してください。
その際、以下の点に注意が必要です。
SSDストレージ容量は余裕を持つ必要がある
- バックアップからのリストア時に途中で中断される場合があるため、容量は多めに設定しておくことがオススメです。
プロビジョンドIOPS・スループットキャパシティはリストア速度にも影響
- リストア中は大量のデータ転送やディスクI/Oが発生するため、プロビジョンドIOPSやスループットキャパシティの設定値が低いとリストア速度が想定以上に遅くなります。
- 普段よりも高めの値を一時的に設定し、復元作業が終わったら減らすという運用がオススメです。
手動でバックアップを作成する
ファイルシステムの作成が終わったら、以下の手順でバックアップを作成します。
- FSx管理コンソールから、バックアップ対象のボリュームを選択します。
- 「バックアップ作成」を選び、任意のバックアップ名を入力します。
- バックアップの作成が始まり、数時間程度で完了します。
- バックアップの進行状況はコンソールから確認できます。
バックアップからリストアする手順
バックアップからリストアを行う場合は、新規ボリュームとして復元が行われます。
流れは以下の通りです。
- 対象バックアップを選択します。
- 「バックアップを復元」を選択し、リストア先ボリュームの情報を設定します。
- ファイルシステム
- ストレージ仮想マシン(SVM)
- ボリューム名
- ボリュームサイズ
- ボリュームタイプ
- Read-Write(RW)：通常のファイル共有やストレージ運用で利用する読み書き可能なボリュームです。通常はこちらを選択します。
- Data Protection(DP)：データ保護専用のボリュームです。SnapMirrorでレプリケーションする場合やバックアップ元との同期管理のために利用されます。
- ジャンクションパス（マウントパス）
- ストレージ効率化（重複排除や圧縮等、必要に応じて選択してください）
- 設定を確認し、リストアを実行する
- ライフサイクルの状態が「作成」になり、リストアが始まります
リストアの仕組み
FSxでバックアップからリストアを実行する際、内部ではSnapMirror（NetAppのレプリケーション技術）が活用されています。
ただし、一般的なONTAP間SnapMirrorとはいくつか挙動や制約が異なります。
1. オブジェクトストア上のバックアップから新規ボリュームを作成
まず、バックアップデータ（S3互換のオブジェクトストレージ領域）をソースとして、指定したファイルシステム上に新たなボリュームが作成されます
2. DPボリュームとしてリストアが開始される
リストア処理はDPボリュームとしてスタートし、バックアップデータの復元と整合性確認が行われます。進行中の状態は、ONTAP CLIで確認可能です。
ONTAP CLIにログインする
# ファイルシステムを指定してsshで接続する
[ec2-user@your-ip~]$ ssh fsxadmin@management.fs-XXXXXXXXXXXXX.fsx.ap-northeast-1.amazonaws.com
# ファイルシステム作成時に設定したパスワードでログインする
(fsxadmin@management.fs-XXXXXXXXXXXXX.fsx.ap-northeast-1.amazonaws.com) Password:進行状況を確認する
進行状況の確認は、job showで確認可能です。この時、内部で snapmirror restore と同等の処理が動いていることがわかります。
FsxIdXXXXXXXXXXX:: > job show
Owning
Job ID Name Vserver Node State
------ -------------------- ---------- -------------- ----------
XXXXX SnapMirror restore fsx FsxIdXXXXXXXXX Running
Description: SnapMirror restore from source "..."エラーログを確認する
エラーログの確認は、 event log showで確認可能です。 エラーが出ていない場合は This table is currently empty. と出力されます。
FsxIdXXXXXXXXXXX:: > event log show
This table is currently empty.3. リストア完了後、RWボリュームに昇格（DP指定時は対象外）
復元が正常に完了し、リストア実行時にRWボリュームを指定していた場合、DPボリュームは自動的にRWボリュームへ昇格（snapmirror promote と同等のコマンドが実行）されます。 その後、ジャンクションパス（マウントパス）が適用され、通常のボリュームとして利用できる状態になります。
リストアは「オブジェクトストア」と「ONTAPボリューム」の間で行われるため、一般的なクラスタ間SnapMirrorとは異なり、ユーザーがsnapmirror break等のコマンドでpromote/failoverの実行は不可です。
Error: command failed: SnapMirror Break is not allowed for object store relationships.また、FSxではONTAP CLIの低レベル領域のコマンドは、AWS側で制限が掛けられているため、レプリケーション運用のような柔軟なSnapMirror設定を行うことは不可です。
使用できるコマンドは、ONTAP CLIで <コマンド名> ? と打つことで一覧が表示されます。ONTAP公式ドキュメントにもcommandがまとめられているため、以下をご覧いただければと思います。
失敗談
最初にリストアを行う際はステージング環境へのリストアを試みましたが、ストレージ容量不足と、プロビジョンドIOPS・スループットキャパシティの設定値が低かったため、リストアが途中で停止したり、1ヶ月以上掛かっても完了しないという事態に陥りました。
最終的には失敗し、リストアを初めからやり直すことになってしまいました。
2回目は新たにファイルシステムを作成し、十分なストレージ容量と高めのプロビジョンドIOPS・スループットキャパシティを確保した上でリストアを実施しましたが、それでも完了まで約6日掛かりました。
この経験から、最初から十分なストレージとプロビジョンドIOPS・スループットキャパシティを確保しておくことの重要性を痛感しました。
参考情報
2025年4月7日に、FSx（NetApp ONTAP限定）で不審なアクティビティを検知してSnapshotを自動で作成するAutonomous Ransomware Protection(ARP)がリリースされました。
これによってビジネスクリティカルなデータをランサムウェアやマルウェアから保護し、障害発生時のビジネスインパクトが抑えられることが期待されます。
詳細は以下のリンクからご覧ください。
まとめ
FSxにおける手動バックアップやリストアは、一見すると難しく感じる部分もありますが、仕組みや注意点を押さえておけば運用面での安心感が大きく変わると感じています。
FSx特有の「新規ボリュームへのリストア」や ONTAP特有の「SnapMirror周りの自動昇格や制約」は、初めて触れると意外と迷いがちなポイントだと思います。個人的に、知らないと詰まりやすいと感じる部分だったので、復旧フロー設計のためにもぜひ押さえておきたいところです。
今後も運用上の知見が貯まった際には、継続して共有していこうと思います。
