关于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
