しらせ(HN)とあるIT企業のインフラエンジニア。プライベートでは開発もちょっとやります。
※本ブログの内容はすべて個人の見解であり、所属する企業とは関連ありません。
2023/09/30 暫く更新停止中m
生活・子育て(10)
FaaS(1)
働き方(2)
SaaS(2)
自作PC(6)
IT入門(1)
IaaS(13)
IDaaS(2)
ITIL(1)
PHP(2)
OS(6)
システム監視(1)
コミュニティ(1)
PCアプリ(10)
ストレージ(4)
ブログ(9)
ActiveDirectory(2)
デバイス(7)
旅行(10)
デザイン(3)
カンファレンス(5)
セキュリティ(9)
インフラ(19)
コーディング(11)
ゲーム(28)
インターネット(18)
未分類(8)1 [今日]
1605 [昨日]
【AWS】EC2で細々と稼働するWebサーバのバックアップの一例
2021/11/13
2021/11/13
IaaS
お疲れ様です。
しらせです。
AWSのEC2で稼働しているこのブログも定期的にアップデートを実施しています。
Amazon Linux 2をベースにApacheとphpくらいしか稼働していない小さなWebサーバですが、事前にちゃんとバックアップやスナップショットを取ってます。
頻繁に実施していることですので忘れることはありませんが、まとめとして残しておこうと思います。
※WordpressはMySQLなどが入っていたりしますので環境に合わせて以下読み替えてください。
もくじ
バックアップの種類
私が管理しているEC2インスタンスのバックアップは主に以下の2種類で取得しています。
スナップショット
システムに大きな変更を加えるような作業前やパッケージのバージョンアップを入れる前に取得しています。
基本的にはAWSの管理コンソールで完結します。
- 頻度：EC2インスタンスに変更を入れる前に必ず取得
- 手法：AWS管理コンソールからボリュームのスナップショットを取得
- 世代：直前の1世代のみ保持
データのコピー
EC2インスタンスに保持している設定ファイルやデータをローカルPCにコピーします。
ちょっとしたミスで設定を変えてしまった際はデータのコピーから復帰させた方が早いケースがあるためです。
ローカルPCで実行されている仮想マシンのテスト用のコピーとしても使います。
- 頻度：月に1回程度
- 手法：必要なデータのみtarで固めてSCPでダウンロード
- 世代：PCのディスクが許容する範囲で
スナップショットの取得
EC2インスタンスにSSHログインすると丁寧にもアップデートがある旨を表示してくれます。
この通知を見かけたら、基本的にバージョンアップ前にスナップショットを取得しています。
まずは、AWS管理コンソールのEC2メニューから「ボリューム」を選択します。
名前を設定していないなどの理由で、対象のマシンが分からないときは詳細欄からEBSがアタッチされたマシンが分かります。
対象のボリュームにチェックを付けたらアクションから「スナップショットの作成」をクリック。
「説明」を入力したらあとは作成ボタンを押すだけです。
どのスナップショットなのか分かるように「日付-紐づくマシン名」とかにしています。
スナップショットのページに移動すると処理の状態が確認できます。
数分で完了してステータス欄が緑色マーク「Complete」に変化します。
スナップショットの作成に成功したら古いスナップショットを消します。
本Webサーバの運用では別途データのコピーも取得していますので、スナップショットは複数世代保持する必要はありません。
あくまでもOSが起動できないようなケースに備えた対応ということですね。
スナップショットの詳細な仕様やAWSの公式マニュアルがあります。
https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/ebs-creating-snapshot.html
データのコピー
スナップショットはEC2インスタンスが起動しなくてOSごとお亡くなりになった際に備えたOSレベルのバックアップです。
一方データのコピーは、データの消失防止に備えたバックアップになります。
アプリケーションの変更によるバグや、自分の誤操作でデータが吹き飛ぶ事ほど悲しいものはありません。。
サンプルですが、以下のようなスクリプトを実行して必要なデータだけアーカイブします。
ドキュメントディレクトリとか、httpdやcronの設定、あとは一応letsencryptのディレクトリなど。
（あれ、phpの設定回りが抜けてるな。。）
DDD=`date +"%Y%m%d"`
HHH=`hostname`
sudo tar cvf ./backup-${HHH}varwww${DDD}.tar /var/www
sudo tar cvf ./backup-${HHH}varwww${DDD}data.tar /data
sudo tar cvf ./backup-${HHH}etchttpd${DDD}.tar /etc/httpd
sudo tar cvf ./backup-${HHH}etcletsencrypt${DDD}.tar /etc/letsencrypt/
sudo cp /etc/crontab ./backup-${HHH}etccrontab
sudo tar cvf ./backup${DDD}.tar ./backup-${HHH}*
sudo rm ./backup-${HHH}varwww${DDD}.tar
sudo rm ./backup-${HHH}varwww${DDD}data.tar
sudo rm ./backup-${HHH}etchttpd${DDD}.tar
sudo rm ./backup-${HHH}etcletsencrypt${DDD}.tar
sudo rm ./backup-${HHH}etccrontab
ホームディレクトリなどでスクリプトを実行して、出来上がったファイルはSCPでPCにコピーします。が、
この時、ファイルサイズが大きかったり、頻度が多いとAWSのネットワーク転送料金に跳ね返ってきますのでご注意！！
10TBまでは1GBあたり$0.114となっていますが、1GBのデータを毎日コピーすると400円くらいかかります。
昔調子に乗ってめちゃくちゃコピーしまくってたら料金が跳ね上がって焦った記憶があります。
なので私の場合は月1回とかの頻度で、ローカルでテストしたいようなケースに限ってコピーするようにしています。
誤って消してしまったファイルが更新頻度の低いような場合は、このデータを解凍して使えるので便利です。
まとめ
今回は一例として、私の手元で稼働しているWebサーバのバックアップについて解説させていただきました。
重要なポイントは、稼働するシステムの可用性や耐障害性（信頼性）、障害時の回復性などを総合的に見て仕組みや運用を考えることにあります。
ですので、本来であればスナップショットやデータのコピーについても、どのような想定でRPO/RTOをどれくらいに設定してどうやって復旧させるかまで考えておかなければいけません。
「バックアップを取っているから安心！」
「これだけやっておけば大丈夫！」
「何か起きた時に考えればOK！」
という言葉に聞き覚えがある方。
某銀行のように事が起きる前に運用の見直しが必要かもしれません。
私も月間1万アクセスを超える未来が来るのなら、バックエンド見直しのモチベが上がるかもしれませんね？ｗ
以上
おつかれさまでした。