[小ネタ] AWS Backupで取得したEC2イメージ（AMI）の取得ポイントについて

はじめに

こんにちは、ディーネットの山田です。

AWS Backupで普段からEC2のバックアップをAMIで取得していますが、複数のEBSが接続されている（マルチボリューム構成の）場合における取得ポイントについてあまり意識していなかったので、少し調べてみました。

AWSドキュメントでの記載について

引用元：Amazon EBS multi-volume, crash-consistent backups

By default, AWS Backup creates crash-consistent backups of Amazon EBS volumes that are attached to an Amazon EC2 instance. Crash consistency means that the snapshots for every Amazon EBS volume attached to the same Amazon EC2 instance are taken at the exact same moment. You no longer have to stop your instances or coordinate between multiple Amazon EBS volumes to ensure crash-consistency of your application state.
Since multi-volume, crash-consistent snapshots are a default AWS Backup functionality, you don’t need to do anything different to use this feature.

と記載されており、日本語では、

デフォルトでは、 は Amazon EC2 インスタンスにアタッチされた Amazon EBS ボリュームのクラッシュコンシステントバックアップ AWS Backup を作成します。クラッシュの一貫性は、同じ Amazon EC2 インスタンスにアタッチされたすべての Amazon EBS ボリュームのスナップショットがまったく同じ瞬間に取得されることを意味します。アプリケーションの状態のクラッシュコンシステントを確保するために、インスタンスを停止したり、複数の Amazon EBS ボリューム間で調整する必要がなくなりました。
マルチボリュームのクラッシュコンシステントスナップショットはデフォルトの AWS Backup 機能であるため、この機能を使用するには別の操作を行う必要はありません。

のように記載されており、マルチボリューム構成であってもクラッシュコンシステントは確保されることがわかりました。

そもそもクラッシュコンシステントバックアップとは？

ディスクに対し既に書き込まれたデータのみを記録します。

つまり、システムが突然停止（クラッシュ）した際の状態に近しい形でデータのバックアップが行われる手法になります。

メモリ上やファイルシステムに反映されていないI/O操作は、バックアップに含まれないためOSやアプリケーション内で処理されていた内容は残念ながらバックアップに含まれない形となります。

（特にデータベースなどといったI/O操作が頻繁に行われ、正しい静止点がないと困るものについてはアプリケーションレベル（dump等）で必ずバックアップを行いましょう）

さて、話を戻しますが、マルチボリューム構成であってもクラッシュコンシステントは確保されるとのことですので、すべてのボリュームにおいて同じ瞬間のデータがバックアップされることがわかります。

そのため、ボリューム間でタイミングの違うバックアップは取得といったことはないので、AWS Backupでバックアップしていれば安心ですね♪

検証環境の構成

検証内容

2つのEBSにデータを書き込む

Pythonを用いて2つのEBSにデータを書き込むプログラムを準備して実行しました。

AWS Backupでバックアップを取得

AWS Backupのオンデマンドバックアップを実行しました。

AWS Backupで取得されたAMIでEC2を起動

2つのEBSで同じデータが正しく記録されているか確認

約100ミリ秒単位でデータを書き込んでおりましたが、ちゃんと同じタイミングの記録が復元できました。

[root@ip-1X-XX-XX-XXX ~]# ls -laR /test[1,2]/*
/test1/20251031:
total 0
drwxr-xr-x  3 root root 16 Oct 31 02:21 .
drwxr-xr-x. 3 root root 22 Oct 31 02:21 ..
drwxr-xr-x  2 root root 56 Oct 31 02:22 02

/test1/20251031/02:
total 12
drwxr-xr-x 2 root root   56 Oct 31 02:22 .
drwxr-xr-x 3 root root   16 Oct 31 02:21 ..
-rw-r--r-- 1 root root  154 Oct 31 02:21 20251031_0221.txt
-rw-r--r-- 1 root root 5918 Oct 31 02:22 20251031_0222.txt

/test2/20251031:
total 0
drwxr-xr-x 3 root root 16 Oct 31 02:21 .
drwxr-xr-x 3 root root 22 Oct 31 02:21 ..
drwxr-xr-x 2 root root 56 Oct 31 02:22 02

/test2/20251031/02:
total 12
drwxr-xr-x 2 root root   56 Oct 31 02:22 .
drwxr-xr-x 3 root root   16 Oct 31 02:21 ..
-rw-r--r-- 1 root root  154 Oct 31 02:21 20251031_0221.txt
-rw-r--r-- 1 root root 5918 Oct 31 02:22 20251031_0222.txt

[root@ip-1X-XX-XX-XXX ~]# tail /test2/20251031/02/20251031_0222.txt /test1/20251031/02/20251031_0222.txt
==> /test2/20251031/02/20251031_0222.txt <==
022253_381
022253_482
022253_583
022253_684
022253_785
022253_886
022253_987
022254_088
022254_189
022254_290

==> /test1/20251031/02/20251031_0222.txt <==
022253_381
022253_482
022253_583
022253_684
022253_785
022253_886
022253_987
022254_088
022254_189
022254_290

まとめ

検証したところ、マニュアルに記載されている通り、マルチボリューム構成であってもクラッシュコンシステントは確保されておりました。