AWS EC2のディスク(EBSボリューム)を丸っとダウンロードする方法
先日開発に使っていたサーバーを引っ越ししたので、サーバーを破棄する前にバックアップを残しておきたいと思った。
AWSで立てたサーバーなのでEBSボリュームのスナップショットを取るのが楽ちんではあるが300GBほど必要なため、
1年置いておくと
300GB × $0.05/月 × 12ヵ月 = $180($1=108円で約2万円)
となる。
少々もったいないためローカルにあるバックアップ用HDDに退避することにした。
イメージ図
「★対象サーバー」がバックアップを取りたいサーバーで、
「★作業サーバー」がバックアップ作業を行うサーバー。
「★対象サーバー」のEBSボリュームを「★作業サーバー」に接続し直したうえでファイルをコピー&ダウンロードしてしまう作戦。
Amazonが公開している
EC2 Linux インスタンスが起動せず、緊急モードになるのはなぜですか?
https://aws.amazon.com/jp/premiumsupport/knowledge-center/ec2-linux-emergency-mode/
のレスキュー手順にアーカイブ作成の操作を絡めただけの方法である。
1. バックアップ作業を行う「★作業サーバー」を用意する。
バックアップを取りたいインスタンスと同じアベイラビリティーゾーンに作業用のインスタンスを立てる。
2. 「★対象サーバー」のEBSボリュームを「★作業サーバー」に繋ぎ変える。
EBSボリュームの管理画面に移動し、
「★対象サーバー」で使っているEBSを右クリックし、「ボリュームのデタッチ」をクリックする。
確認画面が出るので「デタッチする」をクリックする。
状態が「available」になったことを確認する。
もう一度「★対象サーバー」で使っているEBSボリューム右クリックし、
「★作業サーバー」のインスタンスIDを入力して「アタッチ」をクリックする。
状態が「in-use」になればOK。
3. 「★作業サーバー」にバックアップ対象のEBSボリュームをマウントする。
「★作業サーバー」にSSHでログインし、以下のコマンドを打つ。
rootに成り上がる。
sudo su -
EBSボリュームマウント用のディレクトリを作成する。
mkdir /mnt/target_ebs
マウントするデバイスファイルを調べる。
lsblk -lf
NAME FSTYPE LABEL UUID MOUNTPOINT
xvda
xvda1 xfs / 74fc4c15-c86f-4c31-92f6-0df873546b85 /
xvdf
xvdf1 xfs / 74fc4c15-c86f-4c31-92f6-0df873546b85
「xvdf1」が今回のマウント対象
マウントする。
mount /dev/xvdf1 /mnt/target_ebs
mount: /mnt/target_ebs: wrong fs type, bad option, bad superblock on /dev/xvdf1, missing codepage or helper program, or other error.
エラーになった。
tail /var/log/messages
でエラーを確認すると、
Apr 15 07:39:36 ip-172-31-3-97 kernel: XFS (xvdf1): Filesystem has duplicate UUID 74fc4c15-c86f-4c31-92f6-0df873546b85 - can't mount
という感じでUUIDの重複が原因だった。
いろいろ調べてみるとmountコマンドに「-o nouuid」のオプションを付ければUUIDを無視してくれるらしいので、以下のコマンドを実行。
mount -o nouuid /dev/xvdf1 /mnt/target_ebs
今度はエラーは特に出なかった。
マウントできているか確認する。
lsblk -lf
NAME FSTYPE LABEL UUID MOUNTPOINT
xvda
xvda1 xfs / 74fc4c15-c86f-4c31-92f6-0df873546b85 /
xvdf
xvdf1 xfs / 74fc4c15-c86f-4c31-92f6-0df873546b85 /mnt/target_ebs
「MOUNTPOINT」にマウント先のディレクトリ名が表示された。
cd /mnt/target_ebs
ll
total 16
lrwxrwxrwx 1 root root 7 Mar 26 17:35 bin -> usr/bin
dr-xr-xr-x 4 root root 4096 Mar 26 17:36 boot
drwxr-xr-x 3 root root 136 Mar 26 17:36 dev
drwxr-xr-x 80 root root 8192 Apr 15 05:48 etc
drwxr-xr-x 3 root root 22 Apr 15 05:48 home
lrwxrwxrwx 1 root root 7 Mar 26 17:35 lib -> usr/lib
lrwxrwxrwx 1 root root 9 Mar 26 17:35 lib64 -> usr/lib64
drwxr-xr-x 2 root root 6 Mar 26 17:35 local
drwxr-xr-x 2 root root 6 Apr 9 2019 media
drwxr-xr-x 2 root root 6 Apr 9 2019 mnt
drwxr-xr-x 4 root root 27 Mar 26 17:36 opt
drwxr-xr-x 2 root root 6 Mar 26 17:35 proc
dr-xr-x--- 3 root root 124 Apr 15 06:29 root
drwxr-xr-x 3 root root 18 Mar 26 17:36 run
lrwxrwxrwx 1 root root 8 Mar 26 17:35 sbin -> usr/sbin
drwxr-xr-x 2 root root 6 Apr 9 2019 srv
drwxr-xr-x 2 root root 6 Mar 26 17:35 sys
drwxrwxrwt 7 root root 93 Apr 15 07:08 tmp
drwxr-xr-x 13 root root 155 Mar 26 17:35 usr
drwxr-xr-x 20 root root 281 Apr 15 06:29 var
うまく中身が見えていそう。
試しに「★対象サーバー」に置いておいたテキストファイルを見てみると、
cat /mnt/target_ebs/var/data/memo.txt
AAA
という感じでちゃんと見えたのでOK。
4. アーカイブを作成する。
cd /mnt/target_ebs
tar -cf /mnt/target_ebs.tar *
tar: var/lib/gssproxy/default.sock: socket ignored
tar: var/spool/postfix/private/tlsmgr: socket ignored
tar: var/spool/postfix/private/rewrite: socket ignored
tar: var/spool/postfix/private/bounce: socket ignored
tar: var/spool/postfix/private/defer: socket ignored
tar: var/spool/postfix/private/trace: socket ignored
tar: var/spool/postfix/private/verify: socket ignored
tar: var/spool/postfix/private/proxymap: socket ignored
tar: var/spool/postfix/private/proxywrite: socket ignored
tar: var/spool/postfix/private/smtp: socket ignored
tar: var/spool/postfix/private/relay: socket ignored
tar: var/spool/postfix/private/error: socket ignored
tar: var/spool/postfix/private/retry: socket ignored
tar: var/spool/postfix/private/discard: socket ignored
tar: var/spool/postfix/private/local: socket ignored
tar: var/spool/postfix/private/virtual: socket ignored
tar: var/spool/postfix/private/lmtp: socket ignored
tar: var/spool/postfix/private/anvil: socket ignored
tar: var/spool/postfix/private/scache: socket ignored
tar: var/spool/postfix/public/pickup: socket ignored
tar: var/spool/postfix/public/cleanup: socket ignored
tar: var/spool/postfix/public/qmgr: socket ignored
tar: var/spool/postfix/public/flush: socket ignored
tar: var/spool/postfix/public/showq: socket ignored
ソケットファイルを無視したというメッセージが出るが、とりあえず「/mnt/target_ebs.tar」にEBSボリュームの内容を固めることができた。
5. ダウンロードする。
WinSCP等で「★作業サーバー」に接続し、先ほど作成したアーカイブファイルをダウンロードし、
ローカルで解凍&中身が大丈夫そうか確認できたらバックアップ完了。
後はAWS Consoleから「★作業サーバー」と「★対象サーバー」のEC2インスタンスとEBSボリュームを廃棄すれば今回の作業は完了だが、
バックアップ対象のサーバーを引き続き使っていく場合は以下の手順で元に戻す。
おまけ1-1. 「★作業サーバー」にバックアップ対象のEBSボリュームをアンマウントする。
cd /
umount /mnt/target_ebs
lsblk -lf
NAME FSTYPE LABEL UUID MOUNTPOINT
xvda
xvda1 xfs / 74fc4c15-c86f-4c31-92f6-0df873546b85 /
xvdf
xvdf1 xfs / 74fc4c15-c86f-4c31-92f6-0df873546b85
※上記の流れで「cd /」を打たずにアンマウントしようとするとカレントディレクトリが「/mnt/target_ebs」になっているため、
unmontコマンド実行時に
umount: /mnt/target_ebs: target is busy.
というエラーになる。
必ずマウントディレクトリ外に移動したうえでアンマウントする。
おまけ1-2. 「★対象サーバー」のEBSボリュームを「★対象サーバー」に接続し直す。
EC2インスタンスの管理画面で「★対象サーバー」のルートデバイス名を調べる。
今回は「/dev/xvda」だった。
EBSボリュームの管理画面に移動し、「★対象サーバー」のEBSボリュームをデタッチする。
「available」になればデタッチ完了。
今度はアタッチしていく。
アタッチする際にインスタンスに「★対象サーバー」のインスタンスIDを入力し、
デバイスには先ほどメモしたルートデバイス名の「/dev/xvda」を入力する。
「in-use」になればアタッチ成功。
おまけ1-3. 「★対象サーバー」を起動する。
後はEC2インスタンスの管理画面に移動し、「★対象サーバー」を立ち上げれば元通り。
ただ、今後も使う予定のあるサーバーのEBSボリュームを繋ぎ変えるのは少々怖いので、
EBSボリュームのスナップショットのデータを基に別途EBSボリュームを作成し、
そっちからバックアップを取る方がリスクが少ない。
おまけ2-1. EBSスナップショットを基にバックアップを取る。
EBSスナップショットの管理画面に移動し、スナップショットを右クリックし、「ボリュームの作成」をクリックする。
ボリューム作成のオプション指定時にバックアップ作業を行う「★作業サーバー」と同じアベイラビリティーゾーンを指定し、
「ボリュームの作成」をクリックする。
これでスナップショットからEBSボリュームが出来上がるので、
手順2のデタッチ操作をせずにこのEBSボリュームをアタッチして進めればOK。
同じ用な状況に直面していまして、環境を完全に廃棄し終えてtarファイルしか残っていない状態から、環境を復元するにはどのような手順を行えばよいか教えていただけませんか。考察でもよいので回答いただけると幸いです。
新たな作業用サーバに空のEBSをマウントし、tarを回答してcpコマンドで移すと言った方法しか当方は思いつきません。
tarからEBSにうまいここと書き込む方法があればおしえてください。
tarからは書いてもらったように空のEBSを用意してcpコマンドでコピーするくらいしか思いつきませんでした。
お力になれなくてすいません。
https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/ami-store-restore.html#store-ami