はじめに
個人開発しているRailsアプリ「TaskLink」をAWS EC2上で運用しています。
運用を続ける中で、
- EC2が故障したら？
- PostgreSQLのデータが消えたら？
- 誤ってDBを壊したら？
という不安があり、バックアップ環境を構築することにしました。
今回は、
- PostgreSQLバックアップ作成
- AWS S3への保存
- IAM Roleによる認証
- ディスクフル障害からの復旧
まで行ったので、その記録をまとめます。
構成
バックアップの流れは以下の通りです。
PostgreSQL
↓
pg_dump
↓
gzip圧縮
↓
AWS S3
バックアップスクリプト
#!/bin/bash
DB_NAME="tasklink_production"
BACKUP_DIR="./backups"
DATE=$(date +"%Y-%m-%d_%H-%M-%S")
FILE_NAME="tasklink_backup_$DATE.sql"
mkdir -p $BACKUP_DIR
sudo -u postgres pg_dump $DB_NAME > $BACKUP_DIR/$FILE_NAME
gzip $BACKUP_DIR/$FILE_NAME
aws s3 cp \
$BACKUP_DIR/$FILE_NAME.gz \
s3://tasklink-backups/
echo "Backup created and uploaded: $FILE_NAME.gz"
実行すると、
./backup.sh
upload: backups/tasklink_backup_xxx.sql.gz to s3://tasklink-backups/...
Backup created and uploaded: tasklink_backup_xxx.sql.gz
のようにS3へ保存されます。
IAM Roleを利用
最初はアクセスキーを利用する予定でしたが、より安全な方法としてIAM Roleを採用しました。
EC2へRoleを付与することで、
- Access Key不要
- Secret Key不要
- 認証情報管理不要
となり、セキュリティ面も向上しました。
ハマったポイント
ディスク容量不足
作業中に以下のエラーが発生しました。
No space left on device
確認すると、
df -h
/dev/root 100%
となっており、EC2のディスクがいっぱいになっていました。
原因を調査すると、
- swapfile
- aptキャッシュ
- bundle関連ファイル
が容量を圧迫していました。
不要なファイルを整理することで復旧できました。
学んだこと
今回の作業を通じて、
- バックアップの重要性
- IAM Roleによる安全な認証
- EC2のディスク容量管理
- apt / dpkg の障害対応
について学ぶことができました。
アプリを作るだけでなく、運用まで経験することで学べることが多いと感じました。
おわりに
今回構築したことで、PostgreSQLのバックアップをAWS S3へ保存できるようになりました。
次は、
- cronによる自動バックアップ
- S3ライフサイクル設定
- CloudWatch監視
にも挑戦したいと思います。