AWS BackupでFSx for OpenZFSのバックアップ失敗をSNSでメール通知してみた

AWS BackupでFSx for OpenZFSのバックアップ失敗をSNSでメール通知してみた

2026.03.06

はじめに

みなさんこんにちは、クラウド事業本部コンサルティング部の浅野です。

FSx for OpenZFSのバックアップ手段には、FSxのネイティブバックアップ機能と、AWS Backupを用いる方法の2種類があります。

参考:
https://docs.aws.amazon.com/ja_jp/fsx/latest/OpenZFSGuide/using-backups.html

シンプルな用途であればネイティブバックアップ機能で十分ですが、複数サービスのバックアップを統一管理したい場合やコンプライアンス要件がある場合はAWS Backupが適しています。

2つのバックアップ手段の主な違いは以下の通りです。

ネイティブバックアップ AWS Backup
管理コンソール FSxコンソール AWS Backupコンソール(複数サービス一元管理)
自動バックアップ 保持期間(1〜90日)で設定 バックアッププランで柔軟に設定
クロスリージョンコピー 手動コピーのみ バックアッププランで自動化可能
クロスアカウントコピー 手動コピーのみ AWS Organizations経由で自動化可能
削除保護 なし Backup Vault Lockで設定可能
コンプライアンス・監査 なし AWS Backup Auditで対応可能

本記事では、FSx for OpenZFSに対してAWS Backupを設定しバックアップJobが失敗した時にメール通知する構成を作成します。

FSx シリーズのバックアップ注意点

ネイティブバックアップ機能でも、AWS Backupを用いても、FSxのバックアップをスケジュールする際に週次メンテナンスウィンドウ開始時刻の4時間前以内にバックアップが開始されると、バックアップが失敗します。

例えばメンテナンスウィンドウが「3:00開始」に設定している場合、「23:00以降」に開始されるバックアップは失敗する可能性があります。

この制限はFSx for OpenZFSに限らず、FSx for Windows File ServerやFSx for Lustreなど全てのFSxシリーズに適用されます。

公式ドキュメント引用

Amazon FSx は、メンテナンスウィンドウまたは自動バックアップウィンドウの 4 時間前またはウィンドウの間に、バックアップを開始することはできません (Amazon Aurora は、このメンテナンスウィンドウ制限の対象外です)。

参考:
https://docs.aws.amazon.com/aws-backup/latest/devguide/troubleshooting.html

バックアップは設定した開始時刻にピタッと必ず開始されるわけではなく、AWS Backup には「次の時間以内に開始」項目が選択でき最低「1時間」から設定できるので、「バックアップ開始」時刻と週次メンテナンスウィンドウの開始時間は少なくとも「5時間以上」は開けた方が良さそうです。

AWS Backup バックアッププラン作成画面
2026-03-06-fsx-backup-failed-sns-01

ちなみに「次の時間以内に完了」という項目は設定してもFSx シリーズには効力がなく意味がありません。

公式ドキュメント引用

([以内に完了] パラメータは Amazon FSx リソースには適用されません)

参考:
https://docs.aws.amazon.com/ja_jp/aws-backup/latest/devguide/plan-options-and-configuration.html

これらの注意点を考慮して適切に「バックアップ開始時刻」と「メンテナンスウィンドウ開始時刻」を設定しましょう。

ただしAWS Backup の「次の時間以内に開始」という項目は、必ずその時間内に開始が保証されるわけではなく、万が一バックアップウィンドウ時間内に開始されなければ、ジョブを「失敗」としてマークするという挙動になります。よってAWS Backupが万が一設定時間内に開始されず「失敗」した時の運用に備えて失敗したジョブを通知する設定が必要となります。

構成

今回の構成は以下の通りです。AWS BackupがFSxのバックアップを取得し、Job失敗時にBackup VaultからSNS経由でメール通知が届きます。

2026-03-06-fsx-backup-failed-sns-02

今回は検証に必要な下記のリソースをCDKを用いて用意しました。

  • VPC
    • CIDR: 10.0.0.0/24
    • サブネット: プライベートサブネット×1
  • セキュリティグループ
    • FSx用(NFSポート: 111, 2049, 20001-20003)
  • FSx for OpenZFS
    • デプロイメントタイプ: SINGLE_AZ_2
    • ストレージ容量: 64GB
    • スループット: 160 MB/s
    • 圧縮: LZ4
    • メンテナンスウィンドウ: 毎週木曜 0:00 JST
  • SNSトピック
    • バックアップJob失敗時にメール通知
  • Backup Vault
    • 失敗イベント(BACKUP_JOB_FAILED)をSNSへ通知
  • Backup IAM Role
    • AWSBackupServiceRolePolicyForBackup
    • AWSBackupServiceRolePolicyForRestores
  • Backup Plan
    • スケジュール: 毎日 23:00 JST
    • 開始ウィンドウ: 1時間以内
    • 保持期間: 7日間
    • 対象: タグ(BackupTarget=true)で指定

今回はバックアップJobを意図的に失敗させるため、バックアップ開始時刻(23:00 JST)とメンテナンスウィンドウ開始時刻(木曜 0:00 JST)の間隔を1時間に設定しています。冒頭で触れたように、メンテナンスウィンドウ開始の4時間前以内はバックアップを開始できないため、「水曜23:00 JST」に開始するバックアップは確実に失敗します。

CDKスタック
demo-fsx-backup-failed-sns-stack.ts
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 backup from 'aws-cdk-lib/aws-backup';
import * as iam from 'aws-cdk-lib/aws-iam';
import * as sns from 'aws-cdk-lib/aws-sns';
import * as events from 'aws-cdk-lib/aws-events';

export class DemoFsxBackupFailedSnsStack extends cdk.Stack {
  constructor(scope: Construct, id: string, props?: cdk.StackProps) {
    super(scope, id, props);

    // VPC
    const vpc = new ec2.Vpc(this, 'FsxVpc', {
      ipAddresses: ec2.IpAddresses.cidr('10.0.0.0/24'),
      maxAzs: 1,
      natGateways: 0,
      restrictDefaultSecurityGroup: false,
      subnetConfiguration: [
        {
          cidrMask: 26,
          name: 'Private',
          subnetType: ec2.SubnetType.PRIVATE_ISOLATED,
        },
      ],
    });

    // FSx用セキュリティグループ
    const fsxSg = new ec2.SecurityGroup(this, 'FsxSg', {
      vpc,
      securityGroupName: 'fsx-sg',
      description: 'Security group for FSx OpenZFS',
      allowAllOutbound: false,
    });

    // AWS BackupからFSxへのNFSアクセスに必要なインバウンドルール
    fsxSg.addIngressRule(ec2.Peer.ipv4(vpc.vpcCidrBlock), ec2.Port.tcp(111), 'NFS RPC');
    fsxSg.addIngressRule(ec2.Peer.ipv4(vpc.vpcCidrBlock), ec2.Port.tcp(2049), 'NFS');
    fsxSg.addIngressRule(ec2.Peer.ipv4(vpc.vpcCidrBlock), ec2.Port.tcpRange(20001, 20003), 'NFS lock/mount/status');

    // FSx for OpenZFS(Single AZ)
    new fsx.CfnFileSystem(this, 'FsxOpenzfs', {
      fileSystemType: 'OPENZFS',
      storageCapacity: 64,
      subnetIds: [vpc.isolatedSubnets[0].subnetId],
      securityGroupIds: [fsxSg.securityGroupId],
      openZfsConfiguration: {
        deploymentType: 'SINGLE_AZ_2',
        throughputCapacity: 160,
        // メンテナンスウィンドウ: 毎週木曜 0:00 JST(水曜 15:00 UTC)。FSx形式は d:HH:MM(月=1)
        weeklyMaintenanceStartTime: '3:15:00',
        rootVolumeConfiguration: {
          dataCompressionType: 'LZ4',
        },
        automaticBackupRetentionDays: 0,
      },
      tags: [
        { key: 'Name', value: 'fsx-openzfs' },
        { key: 'BackupTarget', value: 'true' }, // タグでバックアップリソースを判定
      ],
    });

    // SNSトピック
    const alertTopic = new sns.Topic(this, 'FsxAlertTopic', {
      topicName: 'fsx-alert-topic',
      displayName: 'FSx Backup Alert',
    });

    // Backup Vault
    const backupVault = new backup.BackupVault(this, 'FsxBackupVault', {
      backupVaultName: 'fsx-backup-vault',
      notificationTopic: alertTopic, // 指定のSNSトピックにイベントを通知
      notificationEvents: [backup.BackupVaultEvents.BACKUP_JOB_FAILED], // バックアップの失敗を指定してイベントを送信
      removalPolicy: cdk.RemovalPolicy.DESTROY,
    });

    // Backup IAM Role
    const backupRole = new iam.Role(this, 'FsxBackupRole', {
      roleName: 'fsx-backup-role',
      assumedBy: new iam.ServicePrincipal('backup.amazonaws.com'),
      managedPolicies: [
        iam.ManagedPolicy.fromAwsManagedPolicyName('service-role/AWSBackupServiceRolePolicyForBackup'),
        iam.ManagedPolicy.fromAwsManagedPolicyName('service-role/AWSBackupServiceRolePolicyForRestores'),
      ],
    });

    // Backup Plan
    const backupPlan = new backup.BackupPlan(this, 'FsxBackupPlan', {
      backupPlanName: 'fsx-backup-plan',
      backupVault,
      backupPlanRules: [
        new backup.BackupPlanRule({
          ruleName: 'daily-23-jst',
          // 毎日 23:00 JST(14:00 UTC)。メンテナンスウィンドウ開始(水曜 15:00 UTC)の1時間前に開始
          scheduleExpression: events.Schedule.expression('cron(0 14 * * ? *)'),
          // 開始ウィンドウ1時間以内に開始しなければ失敗
          startWindow: cdk.Duration.hours(1),
          deleteAfter: cdk.Duration.days(7),
        }),
      ],
    });

    // Backup Selection(FSxをバックアップ対象に指定)
    new backup.BackupSelection(this, 'FsxBackupSelection', {
      backupPlan,
      role: backupRole,
      resources: [
        backup.BackupResource.fromTag('BackupTarget', 'true'),
      ],
    });
  }
}

今回のポイントはこの箇所です。Backup Vaultの設定にて「イベントの種類」と「通知先」を以下のように指定しています。

// Backup Vault
const backupVault = new backup.BackupVault(this, 'FsxBackupVault', {
    backupVaultName: 'fsx-backup-vault',
    notificationTopic: alertTopic, // 指定のSNSトピックにイベントを通知
    notificationEvents: [backup.BackupVaultEvents.BACKUP_JOB_FAILED], // バックアップの失敗を指定してイベントを送信
    removalPolicy: cdk.RemovalPolicy.DESTROY,
});

ジョブの失敗以外にも多数のイベントが通知できます。以下をご参考ください。

やってみた

上記CDKスタックをデプロイしたところから始めます。

SNSサブスクリプション登録

まず「Amazon SNS」コンソールから「トピック」にて作成したトピックを選択します。

2026-03-06-fsx-backup-failed-sns-03

トピックを選択すると「サブスクリプション」>「サブスクリプションの作成」を選択します。

2026-03-06-fsx-backup-failed-sns-04

「プロトコル」欄に「Eメール」を選択し、「エンドポイント」欄に通知したいメールアドレスを入力し、「サブスクリプションを作成」を選択します。

2026-03-06-fsx-backup-failed-sns-05

登録したサブスクリプションのステータスが「保留中の確認」となっていればOKです。

2026-03-06-fsx-backup-failed-sns-06

これにてEメールのサブスクリプションが登録できました。次にこのサブスクリプションをメールアドレス側で承認してあげる必要があります。

SNSサブスクリプション承認

登録したメールアドレス宛にメールが来ているのを確認します。
件名の「AWS Notification - Subscription Confirmation」で検索すると良いですね。

2026-03-06-fsx-backup-failed-sns-07

メール内の「Confirm subscription」を押すと、以下の画面のように「サブスクリプションの承認」が完了します。

2026-03-06-fsx-backup-failed-sns-08
2026-03-06-fsx-backup-failed-sns-09

マネジメントコンソールのサブスクリプションを確認してステータスが「確認済み」になっていれば完了です。

2026-03-06-fsx-backup-failed-sns-10

バックアップジョブの失敗通知設定が適切にされているか確認する

AWS Backupのマネジメントコンソール画面から「バックアップジョブが失敗すると特定のSNSに通知される」といった紐付けは確認できません。

以下のようにCLIを使って設定が適切になされているか確認できます。

#「fsx-backup-vault」の箇所は作成したボールト名に変更してください
aws backup get-backup-vault-notifications --backup-vault-name fsx-backup-vault
{
    "BackupVaultName": "fsx-backup-vault",
    "BackupVaultArn": "arn:aws:backup:ap-northeast-1:************:backup-vault:fsx-backup-vault",
    "SNSTopicArn": "arn:aws:sns:ap-northeast-1:************:fsx-alert-topic",
    "BackupVaultEvents": [
        "BACKUP_JOB_FAILED"
    ]
}

適切なSNSトピックへの通知、イベントの種類が「BACKUP_JOB_FAILED」に設定されていることが確認できました。

バックアップの失敗を確認する

ここまでの作業でAWSリソースの作成からメール通知までの構成が整いました。実際に既定の時刻(23:00頃)にバックアップが失敗するか確認しましょう。

  • バックアップの開始予定時刻: 23:00(1時間以内に開始しない場合は失敗)

  • メールアドレス宛に届いた通知 (23:27)

以下のような件名でAWS Backupのジョブが失敗したことが通知されました。

理由も詳しく「メンテナンスウィンドウの時刻と被っているよ」と記載してくれています。

{ジョブID} could not start because it is either inside or too close to the weekly maintenance window configured in Fsx.
2026-03-06-fsx-backup-failed-sns-11

続いてAWS Backupのマネジメントコンソールから「バックアッププラン」>「作成したプランを指定」し、バックアップジョブの失敗を確認します。

2026-03-06-fsx-backup-failed-sns-12

2026-03-06-fsx-backup-failed-sns-13

こちらの画面でもメール通知と同じくバックアップジョブの開始時刻がメンテナンスウィンドウとの開始時刻と近いので失敗したと記載されていました。

2026-03-06-fsx-backup-failed-sns-14

「失敗」した時はオンデマンドバックアップを作成しましょう。

今回は必ず週1回メンテナンスウィンドウの曜日に設定した直前のバックアップは失敗するように設定していますが、それ以外の設定時に予期せぬ失敗があった場合は以下の手順で「オンデマンドバックアップ」を作成することが可能です。

「バックアッププラン」の画面に戻り「オンデマンドバックアップを作成」を選択します。
2026-03-06-fsx-backup-failed-sns-15

以下の内容で適切に設定し、「オンデマンドバックアップを作成」を選択します。

  • リソースタイプ: FSx
  • ファイルシステムID: {作成したFSxのファイルシステムID}
  • 合計保持期間: {バックアッププランで指定したものと同じ保持日数を選択}
  • バックアップボールト: {作成したバックアップボールト名}
  • IAMロール: {バックアッププランで指定したものと同じIAMロールを選択}

2026-03-06-fsx-backup-failed-sns-16

適切にバックアップジョブが開始されたことを確認します。

2026-03-06-fsx-backup-failed-sns-17

少し時間を待って適切にバックアップジョブが完了すればオンデマンドバックアップ成功です。

2026-03-06-fsx-backup-failed-sns-18

最後に

今回はFSx for OpenZFSに対してAWS Backupを設定し、バックアップJobが失敗した際にSNSでメール通知する構成を試しました。

AWS BackupとBackup VaultをSNSと組み合わせるだけでEventBridgeを挟まずシンプルに通知設定できる点が便利でした。またFSx特有のメンテナンスウィンドウとバックアップ開始時刻の制限は見落としやすい注意点なので、バックアップ設計の際はスケジュールに余裕を持たせるようにしましょう。

この記事がどなたかの参考になれば幸いです。今回は以上です。

この記事をシェアする

FacebookHatena blogX

関連記事