您已进入Amazon EC2 EBS支持的Windows映像010的简介备份…
我一直在浏览我的大脑，为我们运行SharePoint Services的单个Windows 2008服务器find一个简单的备份策略。 这是具有一个数据量的一台服务器的EBS支持的映像。 我不需要任何异国情调。 我只需要一个“每日”备份（丢失一天的数据不是灾难性的）。
我们创build并保存了EBS支持的AMI映像（Windows 2008），我们正在使用它。 我们开始通过简单地创build一个新的EBS AMI映像来进行备份。 这非常简单，但是在创build映像的前10到15分钟内运行的服务器会处于脱机状态 – 这并不理想。
创build备份的标准方式似乎是创build连接到正在运行的实例的卷的快照。 再次，这是非常简单的，服务器在快照生成过程中保持可用。 明显的Catch-22是你不能直接从快照启动一个新的实例。
我知道如何将正在运行的实例绑定到S3存储，然后从S3存储桶中注册AMI。 这使我可以捕获正在运行的实例的备份，如果运行实例丢失，请从S3存储区注册AMI，然后启动新的AMI以恢复实例，但这看起来确实令人费解，看起来很荒谬在AWS控制台和Firefox的S3 Organizer插件之间来回滚动以实现这一点。 （请不要提及命令行的方法，这是一个010级的课程）。
从玩EBS支持的图像，下面的方法似乎适用于我（全部在AWS控制台内完成）：
1.对于备份，只需根据需要快照系统卷（/ dev / sda1）即可。 2.如果丢失正在运行的实例，请执行以下操作：a。从上次快照备份创build新卷b。启动另一个启动AMI实例（必须由EBS支持）c。停止此实例。 d。从新停止的实例中删除现有的系统卷并丢弃。 e。将新创build的卷作为系统卷（/ dev / sda1）添加到已停止的实例。 f。重新启动新的实例。 我已经testing了几次，它似乎为我工作。
问：这种方法有什么问题吗？
你的方法听起来非常好 – 但我可以想出一个可能的方法来改善它。
为了减less自上次备份以来的数据丢失和EBS卷故障（不太可能，但仍有可能）的影响，您可以将数据存储在与系统文件不同的EBS卷上，并且比系统卷更频繁地备份数据卷。
使用您当前的策略，您将失去上次备份时间与实例失败时间之间创build的所有数据。 使用新方法，数据量将被写入直到实例失败，因此，只要启动并运行，就可以将其重新附加到新实例。
我使用bash脚本为我的帐户中的每个卷生成快照
#!/bin/bash ec2-describe-volumes | awk '{ print $2 }' | sort -u > /tmp/ebs_volumes for i in $(cat /tmp/ebs_volumes); do echo $i; ec2-create-snapshot $i; done 这里是脚本，它将为您的VPC中的所有ec2实例创buildAMI备份
#!/bin/bash #Script to Automate AMI backup echo "----------------------------------\n `date` \n----------------------------------" aws ec2 describe-instances --filters Name=vpc-id,Values=vpc-xxx | awk '{ print $8 }' | sort -n | grep "i-" > /tmp/instanceid.txt echo "Starting the Daily AMI creation: " #To create AMI from instance-id for i in $(cat /tmp/instanceid.txt); do echo "Creating AMI for Instance id $i ......." echo "instance-`date +%d%b%y`-$i" > /tmp/aminame.txt aws ec2 create-image --instance-id $i --name "`cat /tmp/aminame.txt`" --description "This is created by ami-backup.sh" --no-reboot | grep -ir ami | awk '{print $4}' > /tmp/amiID.txt echo "AMI Name is: `cat /tmp/aminame.txt`\n" done echo done