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