背景
EC2上でEBSを用いてMongoDBを構築しており、これの日時バックアップにAWS Backupを検討していた。
そこで無停止バックアップ取得時のAWS Backupのファイルシステムの整合性の担保について調べた。
調べたこと
- AWS Backupを用いても整合性を気にしなくてはならないのか
- 整合性を気にしなくてはならない場合はどのような手法があるのか
結果
前提として、AWS Backupは既存の別サービスを呼び出しているだけである。
たとえば、バックアッププランを作成すると、そのバックアッププランに従って自動的にバックアップを作成するときに、AWS Backup は EBS スナップショット機能を使用します。
そしてEBSのスナップショット取得については書き込みを止めることを推奨している
If you can pause any file systems on the volume long enough to take a snapshot, your snapshot should be complete. However, if you cannot pause all file writes to the volume, you should unmount the volume from within the instance, issue the snapshot command, and then remount the volume to ensure a consistent and complete snapshot. You may remount and use your volume while the snapshot status is
pending.
スナップショット作成完了時に CreateSnapshot のイベントが発生するため、バックアップの開始時刻に書き込みを停止し、CreateSnapshot のイベントが届いたら書き込みを再開するというすれば整合性のあるバックアップ取得が行えそうだ。
「AWS Backupを用いても整合性を気にしなくてはならないのか」について
AWS Backupを用いても整合性については考慮する必要がある。
ジャーナルログをみてその時間帯のファイルシステムだけ復元してほしかったが、fsync (2)が呼ばれていない場合は整合性が保てない恐れがあるしそれはファイルシステム側で検出することができないということだと思われる（それはそう
