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。