はじめに
こんにちは、kanazawaです。
前回の記事ではEC2 Windows ServerのファイルサーバーをFSx for Windows File Serverに移行しました。
今回はその続きとして、FSx for Windows File ServerのバックアップをAWS Backupで管理してみます。
1. 概要・構成
AWS Backupについて
AWS Backupは、AWSリソースのバックアップを一元管理・自動化するフルマネージドサービスです。ポリシーによる定期実行や監視、リージョン・アカウント間コピー、監査対応などを効率化できます。
FSx for Windows File Serverのほか、EC2・RDS・EFSなど複数のサービスのバックアップを同じコンソールで管理できます。
バックアッププランを作成することで、スケジュールや保持期間を柔軟に設定できます。
FSx標準バックアップとの比較
FSx for Windows File Serverには標準でバックアップ機能が備わっています。
ドキュメントに記載の通り、取得されるバックアップはAWS Backupも同レベルです。
AWS Backup は、Amazon FSx の組み込みバックアップ機能を使用します。 AWS Backup コンソールから取得したバックアップは、Amazon FSx コンソールから取得したバックアップと同じレベルのファイルシステムの整合性とパフォーマンス、および同じ復元オプションを持ちます。
AWS Backupとの違いは以下の通りです。
| 比較項目 | FSx標準バックアップ | AWS Backup |
|---|---|---|
| 管理対象 | 個別のFSxファイルシステム | FSxを含む複数のAWSサービスを一元管理 |
| 実行頻度 | 自動バックアップは1日1回。手動バックアップは任意のタイミングで実行可能 | 最短1時間ごとに、日次・週次・月次などのスケジュールを設定可能 |
| リージョン間コピー | 同一アカウント内で手動コピー可能 | バックアッププランによる自動コピーが可能 |
| アカウント間コピー | FSx単体では対応しない | AWS Organizationsを利用して別アカウントへコピー可能 |
| リソース指定 | ファイルシステムごとに設定 | リソースIDやタグを使用して一括指定可能 |
| 削除保護 | IAMによる削除権限制御 | IAMに加え、Backup Vault Lockによる削除・変更防止が可能 |
FSx標準バックアップは、単一のFSxを日次で保護するシンプルな構成に適しています。
一方で、AWS Backupは1日複数回の取得、長期保存、リージョン・アカウント間コピー、削除防止などが必要な場合に適しています。
ドキュメントでは、FSxの自動日次バックアップを有効にしつつ、AWSサービス横断の集中管理にAWS Backupを使用する構成が推奨されています。
構成
本記事で構築するのは前回の移行後構成にAWS Backupを追加した構成です。
AWS BackupはVPC外のマネージドサービスとして動作し、VPC内のFSxに対してバックアップ・リストアを行います。

2. 事前準備
IAMロールの確認
AWS BackupがFSxに対してバックアップ・リストアを実行するには、IAMロール AWSBackupDefaultServiceRole が必要です。
AWS Backupをコンソールから初めて設定し、デフォルトのサービスロールを選択すると、IAMロールAWSBackupDefaultServiceRoleが自動的に作成されます。
IAMコンソールの「ロール」で、AWSBackupDefaultServiceRoleが存在することを確認してください。
なお、独自のIAMロールを指定する構成では、このデフォルトロールは必須ではありません。CLIで作成する場合も自動作成ではなく、手動での設定が必要です。
バックアップ対象ファイルの用意
前回の記事で作成したFSxの共有フォルダ (\\<FSxのDNS名>\share) にバックアップ対象のファイルが存在することを確認します。
クライアント用EC2にRDPで接続し、以下のコマンドでファイルの存在を確認します。
dir \\<FSxのDNS名>\share
# 例
PS C:\Windows\system32> dir Z:\
ディレクトリ: Z:\
Mode LastWriteTime Length Name
---- ------------- ------ ----
-a---- 2026/08/17 10:43 169966 TestFile01.png
-a---- 2026/08/17 10:44 251627 TestFile02.png
ファイルが存在することを確認できれば事前準備は完了です。
3. AWS Backupの設定
ではAWS Backupの設定をAWSコンソール画面で進めていきます。
バックアップボールトの作成
バックアップボールトはバックアップデータの保存先です。
AWS Backupコンソールから「ボールト」→「新しいボールトを作成」を選択します。
- ボールトタイプは「バックアップボールト」を選択します。
- 論理的にエアギャップのあるボールトは、コンプライアンス・高セキュリティ要件向けのため今回は使用しません。

バックアッププランの作成
バックアッププランはバックアップのスケジュールや保持期間を定義するものです。
ボールト作成後、「バックアッププラン」→「バックアッププランを作成」を選択します。
- 今回は「新しいプランを立てる」を選択します。

- 作成したボールトを選択し、バックアップ頻度を設定します。今回は12時間を選択しています。

- バックアップを開始する時刻を設定します。今回は日本時間3時から12時間毎で設定しています。

- 保持期間を設定します。今回は14日(2週間)で設定しています。

- 別リージョンにコピーすることで、障害発生時にコピー先のリージョンでリストアが可能になります。コピーする場合は事前にコピー先でボールトを作成してください。

- Windows VSSを有効にして、ファイルが使用中であっても整合性のあるバックアップが取得できるようにします。

リソースの割り当て
プランを作成すると自動で割り当ての設定画面に遷移します。
バックアッププランに対してバックアップ対象のリソースを割り当てます。
- IAMロールはデフォルトロールを使用します。

- リソースタイプはFSxを選択し、バックアップ対象のFSxを指定します。

- 今回の例ではリソースを1つ指定していますが、AWS Backupを利用する大きなメリットの1つである、特定のリソース除外や、タグでの絞り込みが可能です。

4. バックアップの実行・確認
オンデマンド実行
スケジュールによる自動実行を待たずに、手動でバックアップを実行します。
AWS Backupコンソールから「バックアッププラン」→「オンデマンドバックアップを作成」を選択します。
- リソースタイプはFSxを選択し、バックアップ対象のFSxを指定します。合計保持期間は7日で設定しています。

- ボールトとIAMロールを選択します。

復旧ポイントの確認
バックアップジョブが完了すると、復旧ポイントが作成されます。
「ジョブ」から該当のジョブを開き、ステータスが「完了」になっていることを確認します。
ジョブの詳細画面では復旧ポイントARNなどの情報が確認できます。

「ボールト」から対象のバックアップボールトを開くと、作成された復旧ポイントの一覧が確認できます。
5. リストア
それでは作成した復旧ポイントからリストアを実施してみます。
- AWS Backupコンソールから「ボールト」を開き、リストアさせたい復旧ポイントを選択して「アクション」→「復元」を選択します。

- リストアしたFSxを作成するため、VPCやサブネット、AD認証情報などを入力します。ストレージ容量やストレージタイプは変更できません。
- リストアが開始されると以下の画面に遷移するので、ステータスが「完了」になるまで待機します。

- リストアが完了したら、クライアント用EC2にRDPで接続し、リストアされたFSxの共有フォルダにアクセスしてファイルが存在することを確認します。
- テスト用として、事前にリストア前にアクセスしていた共有フォルダからファイルを削除しています。
# リストアされたFSxをマウント net use Y: \\<リストアされたFSxのDNS名>\share # ファイルの存在確認 dir Y:\
- バックアップしたファイルがリストアされていることが確認できました。
PS C:\Windows\system32> net use Y: \\<リストアされたFSxのDNS名>\share
コマンドは正常に終了しました。
PS C:\Windows\system32>
PS C:\Windows\system32>
PS C:\Windows\system32> dir Y:\
ディレクトリ: Y:\
Mode LastWriteTime Length Name
---- ------------- ------ ----
-a---- 2026/08/17 10:43 169966 TestFile01.png
-a---- 2026/08/17 10:44 251627 TestFile02.png
6. 補足・まとめ
リストアの挙動について
先述の手順の通り、AWS BackupによるFSxのリストアは、元のFSxを上書きするのではなく、新しいFSxとして別途作成されます。
そのため、リストア後に元のFSxと置き換える場合は、クライアントの接続先DNS名を新しいFSxのDNS名に切り替える必要があります。
FSx標準バックアップとの併用について
AWS Backupを使用する場合でも、FSxの自動日次バックアップはデフォルトで有効になっています。
AWS Backupと標準バックアップを併用することで、より細かい頻度のバックアップと日次バックアップの両方を保持できます。
ただし、バックアップの保存コストが増加するため、不要であればFSxコンソールから自動バックアップを無効化することを検討してください。
バックアップ失敗時のアラート設定について
AWS Backupはスケジュールに従って自動実行されますが、ジョブが失敗してもデフォルトでは通知されません。
気づかないままバックアップが取得されていない状態が続くリスクがあるため、失敗時の通知設定を合わせて行うことを推奨します。
Amazon EventBridgeとAmazon SNSを組み合わせることで、バックアップジョブの失敗をメールなどで通知できます。
以下がイベントパターンの例です。
{
"source": ["aws.backup"],
"detail-type": ["Backup Job State Change"],
"detail": {
"state": ["FAILED"]
}
}
まとめ
今回はFSx for Windows File ServerのバックアップをAWS Backupで管理する手順を試しました。
FSx標準バックアップと比較して設定の手間はかかりますが、バックアップ頻度の柔軟な設定や複数AWSサービスの一元管理など、運用規模が大きくなるほどAWS Backupのメリットが活きてきます。
FSx単体の小規模構成であれば標準バックアップで十分なケースも多いですが、要件に応じてAWS Backupの導入を検討してみてください。




