我一直在浏览我的脑子,为我们运行SharePoint Services的单个Windows 2008服务器找到一个简单的备份策略.这是一个EBS支持的具有一个数据卷的服务器的映像.我不需要任何异国情调.我只需要一个“每日”备份(丢失一天的数据并不是灾难性的).
我们创建并保存了一个我们习惯使用的EBS支持的AMI图像(Windows 2008).我们开始通过简单地创建新的EBS AMI图像来进行备份.这非常简单,但正在运行的服务器在创建映像的前10到15分钟内处于脱机状态 – 这并不理想.
创建备份的标准方法似乎是创建附加到正在运行的实例的卷的快照.同样,它非常简单,服务器在快照生成期间仍然可用.明显的Catch-22是您不能直接从快照启动新实例.
我知道如何将正在运行的实例捆绑到S3存储,然后从S3存储桶注册AMI.这允许我捕获正在运行的实例的备份,并且如果正在运行的实例丢失,则从S3存储桶注册AMI并启动新的AMI以恢复该实例,但这看起来真的很复杂并且看起来很荒谬在AWS控制台和适用于Firefox的S3 Organizer插件之间来回切换,以实现此目的. (请不要提及命令行方法,这是一个010级课程).
从使用EBS支持的图像开始,以下方法似乎对我有用(所有这些都在AWS控制台中完成):
1.对于备份,只需根据需要对系统卷(/ dev / sda1)进行快照.
2.如果丢失了正在运行的实例,请执行以下操作:
a.从上次快照备份中创建新卷
b.启动您的起始AMI的另一个实例(必须由EBS支持)
c.这个例子.
d.从新停止的实例中删除现有系统卷并丢弃.
e.将新创建的卷作为系统卷(/ dev / sda1)附加到已停止的实例.
f.Re-启动新实例.
我已经对它进行了几次测试,它似乎对我有用.
问题:这种方法有什么问题吗?
为了减少自上次备份以来数据丢失的影响,以及EBS卷故障(不太可能,但仍然可能),您可以将数据存储在与系统文件不同的EBS卷上,并且比系统卷更频繁地备份数据卷.
使用您当前的策略,您将丢失在上次备份时和实例失败之间创建的所有数据.使用新方法,数据卷将一直写入,直到实例失败,因此您可以在新实例启动并运行后将其重新附加到新实例.
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。