ForgeVision Engineer Blog

フォージビジョン エンジニア ブログ

Amazon FSx for NetApp ONTAP のスナップショットがリストアできない！？AWS Backupとの意外な関係と復旧戦略

AWS Amazon FSx for NetApp ONTAP

こんにちは、こんばんわ！クラウドインテグレーション事業部の魚介系エンジニア松尾です。

今回は、Amazon FSx for NetApp ONTAP（以下、FSxN）にてスナップショットのリストア検証中に遭遇した、ちょっとした落とし穴について共有したいと思います。

発生した問題

検証で利用しているFSxNでは数時間ごとにAWS Backupでバックアップを取得した上で、ONTAPで毎日・毎時スナップショットを取得しておりました。 そこで、AWS Backupkで取得した最新のバックアップよりも以前に取得されたスナップショットからのリストアを試みたところ、「スナップショットの復元に失敗する」というエラーに直面しました。

原因を調査した結果、AWS Backupとの関係性が深く関与していることが分かりました。

FSx for NetApp ONTAPの障害復旧方法について改めて整理

本題に進む前にまずFSxNの障害復旧方法について復習します。

FSxNはNetApp ONTAPの機能をAWS上で提供するマネージドサービスであり、障害復旧手段も多様です。

以下に代表的な4つの復元方法をご紹介します。

スナップショットからのリストア

  • 仕組み: NetApp ONTAPのスナップショットは、取得時点のボリューム静止点をコピーします。差分管理なので容量効率が高く、作成もほぼ即時です。
  • リストア方法:
    • snapshot restore コマンドでボリューム全体を指定したスナップショット時点にリストア可能
    • クライアント側からは .snapshot ディレクトリを通じてファイル単位でも復元できる
  • 制約: ONTAPの仕様により、AWS Backupが参照している最新スナップショットより古いスナップショットにはリストアできません。

Multi-AZ構成での障害復旧

  • 特徴: FSxNはSingle-AZとMulti-AZ構成を選択可能です。Multi-AZではプライマリとスタンバイのファイルシステムが異なるAZに配置されます。
  • 復旧の仕組み: AZ障害時には自動フェイルオーバーが発生し、スタンバイ側が即座に昇格。これによりRPO=0、RTO数分レベルの高可用性を実現できます。
  • 注意点: 構築後にSingle⇔Multi-AZの変更はできません。設計段階でRTO/RPO要件を満たす構成を選択する必要があります。

SnapMirrorによるバックアップ・リストア

  • 仕組み: NetApp独自のレプリケーション機能です。FSxN間、オンプレミスのONTAP間、リージョン間でデータを非同期／同期複製可能です。
  • 用途:
    • 災害対策（DR）として別リージョンをリカバリーサイトとして構築
    • クロスアカウント／クロスリージョンでの保護
    • 大規模環境においても短いRPO/RTOを実現
  • メリット: AWS Backupより柔軟で、10TiB以上の大規模データや厳しいRTO要件に適しています。

AWS Backupからのリストア

  • 仕組み: AWS Backupで定期的にバックアップを取得することが可能です。復元時は新しいボリュームとして作成されます。
  • 特徴:
    • AWSマネージドで運用が簡単
    • 他AWSリソースと統合管理可能
    • 小規模環境やシンプルなバックアップ管理に適する
  • 制約: AWS Backupが作成した「参照スナップショット」が存在する限り、それ以前のスナップショットへはリストアできません。

スナップショットとAWS Backupの関係について(なぜこの問題が起きたのか)

要点:
FSxNで「最新のAWS Backup参照スナップショットより古いスナップショットをリストアできない」のは、ONTAPのスナップショット管理仕様とAWS Backupの仕組みが組み合わさった結果で、データ保護の基準点として参照されているスナップショットより古いものはリストアできないという制約によるものです。

仕組みの整理

1. NetApp ONTAPのスナップショット管理

  • ONTAPのスナップショットは「差分参照方式」で作られます。
  • 新しいスナップショットは、古いスナップショットを参照して差分を保持します。
  • あるスナップショットが「参照スナップショット」として利用されている場合、そのスナップショットより古いものを昇格リストアすると参照関係が壊れるため、システムが禁止しています。

2. AWS Backupの動作

  • AWS BackupはFSxNのバックアップを取得する際に、内部的に専用スナップショット（backup-xxxx）を作成します。
  • このスナップショットは「データ保護の基準点」として保持され、バックアップの整合性を保証するために参照され続けます。
  • そのため、この参照スナップショットより古いスナップショットをリストアしようとするとエラーになります。

3. 実際のエラーメッセージ

過去のスナップショットをリストアしようとした場合以下のようなエラーが出力します。

Failed to promote Snapshot copy "App_Daily.2025-10-17_0000"
because one or more newer Snapshot copies are currently used
as a reference Snapshot copy for data protection operations: backup-xxxxxxxx
  • 「App_Daily.2025-10-17_0000」をリストアしようとしたものの、それより新しい「backup-xxxx」がデータ保護の参照点になっているため、リストアが不可という旨のメッセージです。

なぜ制約があるのか

  • データ保護の一貫性維持: AWS Backupが保持するバックアップは、最新の参照スナップショットを基準にしているため、それを壊す操作は許されない。
  • 差分管理の整合性: 古いスナップショットをリストアすると、参照関係が逆転し、バックアップの整合性が失われる可能性がある。なお、整合性の観点から最新のスナップショットはそれより古いバックアップが存在する限り削除することができない。
  • 設計思想: ONTAPは「最新の参照スナップショットを保護点」として扱い、それ以前のスナップショットは直接リストアできないようにしている。

仕様のまとめ

  • 過去分のスナップショットがリストアできない理由:
    • AWS Backupが作成した「参照スナップショット」が存在するため
    • ONTAPの仕様上、その参照スナップショットより古いものはリストアできない
  • 結果: 最新のAWS Backup参照スナップショット以前のスナップショットは、元ボリュームへのリストアでは利用できない

過去のスナップショットから復元する最適な方法

では、AWS Backupの参照スナップショットより古いスナップショットから復元したい場合どうすればよいのでしょうか？

復旧ケースにもよりますが、以下の3つの方法が有効であると考えます。

.snapshot ディレクトリからファイル単位で復元

  • 方法:
    • Linux/macOSクライアントではボリューム直下の .snapshot ディレクトリにアクセスし、必要なファイルをコピー。
    • Windowsクライアントでは「以前のバージョン」タブから復元可能。
  • メリット:
    • ボリューム全体を戻さずに必要なファイルだけ復元できる
    • 誤削除やランサムウェア被害時に迅速な部分復旧が可能
  • 注意点:
    • .snapshot 内のデータは読み取り専用
    • 大量ファイル復旧には時間がかかる場合あり

FlexCloneで過去スナップショットからRWボリュームを即時生成

概要

FlexCloneは今回の制約下でも利用可能です。元ボリュームに対して古いスナップショットを昇格できなくても、その古いスナップショットを親に持つRWクローンボリュームを作成することは可能です。

  • 利点: 即時（メタデータ中心）で作成、容量効率が高く、すぐに読み書き可能な過去状態を提供できます。

代表手順例（ONTAP CLI想定）

①クローン作成:

 volume clone create -vserver dev-stg-fsxn-svm-testserver-01 -flexclone vol_restore_2025_09_09 -type RW -parent-volume dev_stg_fsxn_volume_testserver_01 -parent-snapshot App_Daily.2025-09-09_0900

②エクスポート/共有設定（NFS/CIFS/iSCSI）を移植または新規設定
③クライアントのマウント切替（メンテナンス計画に沿って短時間の切替を実施）
④アプリケーション整合性の確認（DBならリカバリ、ファイルサーバならACL確認）

注意点

  • 長期運用時の容量管理: クローンは親のデータブロックを共有し、そこからの差分のみ書き込みます。書き込みが増えるほど容量消費が増えるため、長期利用なら後段で「フル独立化（Split）」を検討してください。

    • Split実行
      volume clone split start -vserver dev-stg-fsxn-svm-testserver-01 -flexclone vol_restore_2025_09_09

  • パフォーマンス/機能面: クローン機能は本番ワークロードでも問題なく使えますが、運用ポリシーにより「クローンは短期利用・移行のため」と位置付けるケースが多いです。

SnapMirrorで“参照スナップショット非依存”の復元経路を確保

概要

  • ねらい: AWS Backupの参照スナップショットに縛られない復元経路を用意するため、DR用やセカンダリ系のSnapMirrorを構成しておく。
  • 利点: セカンダリ側ボリュームに対して、過去スナップショットを基点とした対処（クローン/リストア/カットオーバー）が柔軟にできる。

実運用パターン

  • セカンダリFSxN（またはオンプレONTAP）にミラーを保持。障害/誤操作が発生した場合、セカンダリ側で過去スナップショットからボリュームを用意して本番へ切替。
  • 「AWS Backupの参照スナップショット」に阻まれるのはプライマリのリストアだけなので、別系統の復元ポイントを持つことで設計上の抜け道ではなく、正式な復元レーンを確保できます。

さいごに

FSxNのスナップショット運用においては、AWS Backupが参照しているスナップショットが昇格制限の起点になるという仕様を理解しておくことが非常に重要です。

特に、RTO（目標復旧時間）を満たすための設計では、スナップショットとAWS Backupの役割分担を明確にし、どの手段でどのタイミングのデータを復元できるかを事前に把握しておく必要があります。(特にAWS Backupからのリストアは、容量が多いと数日かかる可能性もあるため注意！！)

この記事が、FSxNの運用設計や障害復旧戦略の参考になれば幸いです！！

では次回もお楽しみに！！！