關於AWS的備份策略

  AWS有一個很強大的功能，就是snapshot，翻譯過來就是對EBS進行快照。通俗的說，便是對整個硬盤進行完整的鏡像備份。如此一來，在其中一臺EC2掛掉的時候，咱們迅速的另起一臺EC2，並將經過快照恢復的EBS掛載到新的實例上，便可完成新主機的服務的切換和恢復。snapshot用於非root或者非C盤的數據備份是極好的。然而，一旦涉及到root或者C盤，就會有一些坑了。因此，官方的推薦方法，是若須要針對C盤或者Root這類系統數據進行備份，請使用AMI。

  AMI底層的實現其實也依賴snapshot的機制。只是AMI作了進一步的抽象和智能化，以便做爲一個更加高效特殊的服務提供給客戶：例如，能夠customize本身的AMI，而後在啓動EC2時，指定對應的AMI做爲root或者C盤的數據來源。因此，一個好的practice，就是將操做系統文件和部分關鍵軟件（如apache，mysql）和對應的配置的文件放置在根目錄，作成AMI。這部分的數據有一個特色，就是不會常常變更。這樣依此新啓動的實例在一開始就是至關因而安裝好了全部的軟件而且配置好。省卻了不少工做。至於其餘的常常讀寫變更的數據，則放置在其餘EBS作snapshot備份便可。新啓動實例時，直接mount就好。

  通常而言，snapshot比AMI更加快速，而且更加節省空間（Depending on the size of the volumes, it can take several minutes for the AMI-creation process to complete (sometimes up to 24 hours).You may find it more efficient to create snapshots of your volumes prior to creating your AMI. This way, only small, incremental snapshots need to be created when the AMI is created, and the process completes more quickly (the total time for snapshot creation remains the same)）

  可是snapshot和AMI都會面臨一個問題，就是數據一致性和完整性（Integrity & consistency）。在不關機的狀況下作備份，會出現必定的問題：

  對於snapshot，文檔中這樣描述[3]：However, snapshots only capture data that has been written to your Amazon EBS volume at the time the snapshot command is issued. This might exclude any data that has been cached by any applications or the operating system. 

  對於AMI，文檔中這樣描述[1]：If you choose No reboot, we can't guarantee the file system integrity of the created image.

  若是網站訪問壓力不大，則能夠在夜間完成關機備份。或者，若是能夠接受數據的暫時損失，不關機備份也是OK的。若是不能接受關機備份，也能夠採用多機部署，在夜間流量不大的狀況下，分批次對主機進行備份，各個主機輪換對外提供服務。

  前面說到，snapshot用於root備份會有一些問題。但不表明snapshot就不能備份root。咱們最終的目的，就是備份舊的EC2數據，而且成功還原到新的EC2上。爲此，通常有如下三種方式進行備份和還原:

1）EC2-->AMI-->launch new EC2

2）old EBS-->snapshot-->AMI-->launch new EC2

3）EBS-->snapshot-->EBS-->mount to new EC2-->start new EC2

  第一種方案是比較穩妥的方案，直接對EC2作AMI。不管linux仍是windows，收費仍是免費，均可以使用。可是AMI更像是作穩定的系統盤，而不是頻繁的備份。過程可參閱[1]。

  第二種方案是先對root盤作snapshot，而後再從snapshot中建立AMI，可參閱[2]。這種方法有個弊端：

Some Linux distributions, such as Red Hat Enterprise Linux (RHEL) and SUSE Linux Enterprise Server (SLES), use the EC2 billingProduct code associated with an AMI to verify subscription status for package updates. Creating an AMI from an EBS snapshot does not maintain this billing code, and subsequent instances launched from such an AMI will not be able to connect to package update infrastructure.

Similarly, although you can create a Windows AMI from a snapshot, you can't successfully launch an instance from the AMI.

對於收費的windows和linux，沒有用。

  第三種方案，沒有出如今官方文檔中，算是一種黑科技[4]:

- Create an EBS volume "X" from the snapshot that has your good system on it.

- Run a new instance "A" of the base AMI.  This creates a volume "Y" as the main disk of that instance.

- Stop instance "A".  

- Detach volume "Y" from stopped instance "A".  

- Attach the good volume "X" to stopped instance "A".

- Start instance "A".

  通過嘗試，親測有效。可是不知在其餘地方是否藏有隱藏BUG……我的覺得，關鍵在於EC2實例類型和EBS中的OS類型必須匹配，不要把一個linux root ebs掛載到windows實例上。

  此外，也有網友總結了三種經常使用的備份windows實例的方法，參見[5]。思路和咱們上面說的高度類似。除了裏面有一條說到將root備份和數據備份分開進行。最後，對snapshot和AMI區別有疑惑的，能夠參考文章[6][7]。

完~

Reference

1] http://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/Creating_EBSbacked_WinAMI.html

2] http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-launch-snapshot.html

3] http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-creating-snapshot.html

4] https://forums.aws.amazon.com/thread.jspa?messageID=165839

5] http://www.n2ws.com/blog/3-ways-ec2-windows-backup-and-recovery.html

6] http://serverfault.com/questions/268719/amazon-ec2-terminology-ami-vs-ebs-vs-snapshot-vs-volume

7] http://stackoverflow.com/questions/17619580/aws-difference-between-a-snapshot-and-ami