Q&A
今まで運用していたサーバを一時運用を取りやめるにあたり、
無用なコストを発生させたくない為、AWSのアカウント自体削除しようと思っております。
ただ、今まで使っていたサーバは保存しておきたいと思っており、
AMIやスナップショット情報をローカルPCに保存しておき、
再度サービスを再開する時に、新しいアカウントを作成し、ローカルに保存しておいた
AMI/Snapshotから復旧を考えております。
調べてみた結果、直接ローカルにコピーできない為、一度S3にファイルを保存した後に、ローカルに持ってくる方法しかないように思われるのですが、もっと良いやり方、他の方法等がありましたらご教授いただければと思っております。
回答3件
0
AMIやSnapshotを自分のPCにダウンロードすることはできません。AMIやSnapshotはS3に保管されているのですが、その領域に一般のユーザがアクセスできないからです。
もし、お使いの仮想マシンがVM ImportでAWSに構築したものであれば、VM ExportによってOVAファイルに変換された仮想マシンをダウンロードすることができます。
AWSで新規構築した仮想マシンはVM Exportを利用できません。したがって、OSレベルでのフルバックアップをご検討ください。OSレベルでのバックアップと復旧が面倒であれば、アカウントを維持したままスナップショットの代金を払い続けることをお勧めします。
投稿2017/05/26 12:40
総合スコア432
0
ベストアンサー
AMI をそのアカウント(A)でそのまま保持するか、別のアカウント(B)で create-image や copy-image でアカウント(B)所有の AMI を作るといいのではないでしょうか。
アカウント(A)所有の元の AMI を、アカウント(B)で実行できるよう、あらかじめ許可しておく必要があります。
どうしても、ローカルに保存しておきたいということであれば、Linux 限定ですが、以下の手順が考えられます。
AMI を維持するコストと比べると、割に合わないと思います。
###バックアップ
- snapshot から volume に展開する。
- AMI と同じ OS を新たに標準 AMI から起動し、volume を attach しマウントする。
- tar などで、volume の中身をバックアップファイルにコピーする。この際、SELinux のコンテキストや、capability を保持するようにする。例:
tar cz --selinux --xattrs -f (バックアップファイル) (マウントポイント) - バックアップファイルをローカルにダウンロードする。
- AMI の作成(register-image)に必要な情報をメモに記録しておく。
・volume サイズ、ファイルシステム、tar などのオプション
・AMI の情報: architecture, kernel-id, ramdisk-id, root-device-name, block-device-mappings, virtualization-type, など
###リストア
- volume を作成する。
- AMI と同じ OS を新たに標準 AMI から起動し、volume を attach する。
- volume にファイルシステムを作成し、マウントする。
- バックアップファイルをアップロードする。
- tar などでマウントポイントに展開する。この際、SELinux のコンテキストや、capability を保持するようにする。
- volume をアンマウントし、detach する。
- volume の snapshot を作成する。
- AMI を作成(register-image)する。
投稿2017/05/26 15:27
総合スコア12146
0
kongou-aeさんが言われておりますが、AMIやSnapshotは、S3に保存しています。
これは、AWSが確保している領域ですので、ユーザーからは乖離された領域でバックアップしています。
そのためAWS専用線で通信しており、S3領域もアクセスが許可されていない領域に保存されています。
従いまして、TaichiYanagiyaさんの回答されている自己流の保存方法しかできないと思います。
サーバイメージを何らかの方法で保存したいとのことですが、
結論から言いますと使わないサーバの長期バックアップは好ましくありません。
例として話しますと、
4年前に主流だったEC2インスタンスの基盤、EC2クラシックは、VPCになりました。
＃当時はEC2クラシックと言う文言自体もありませんでした。
＃EC2クラシックはm1.smallなどのインスタンスです。
VPCができたことによりVPCで動くEC2インスタンスに移り変わりました。
そのため、EC2クラシックで動くEC2インスタンスは取り残されることになります。
また新しい技術を使うためにVPCに変更せざるを得なくなりました。
EC2クラシックEC2インスタンスのAMIは、VPCにすることはできませんので
VPCのEC2インスタンスを新規作成し、ミドルとアプリを構築する羽目になりました。
つまり何が言いたいかというと、使えなくなるかもしれないAMIを残すよりも
ミドル以上の保存方法を考えた方が良いということです。
ちなみにAmazonLinuxの場合、AMIからローンチさせた時にカーネルのバージョンアップが勝手に走ります。
知らないとローンチ後に予期せずバッチコマンドが動かないなど有り得ますので覚えておいてください。
抑止方法は以下のようなやり方です。
Q: 初回起動時に非常に重要なセキュリティアップデートの自動インストールを無効にするにはどうすればよいですか?
リクエストインスタンスウィザードの「高度なインスタンスオプション」ページに、Amazon Linux AMI のユーザーデータを送信するテキストフィールドがあります。このデータは、テキストとして入力するか、またはファイルとしてアップロードすることができます。どちらの場合でも、データは以下のようになります。
command:抑止方法
1#cloud-config 2repo_upgrade: none
投稿2017/06/05 04:49
編集2017/06/05 04:50
総合スコア1294
あなたの回答
tips
プレビュー
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。