![]() ![]() ![]() Amazon promises S3 to be very safe (“no single point of failure”) and has the added benefit of being available independently of EC2 instances. The approach we ended up taking uses S3 however. Your replicated instance could even live in a different availability zone, although you would then incur bandwidth cost on exchanged data on top of the cost of running an extra instance. Note that SQL Server Express can subscribe to a Standard instance in a replication setup, although it cannot publish. ![]() You could also copy backup-files to another instance mounting its own EBS volume, or set up replication - allowing you to recover very quickly. While I have no knowledge of Amazon datacenter topologies, one could fear that different EBS volumes attached to the same instance end up being hosted on the same EBS-SAN-thingamebob, the death of which would then also be your undoing. While obviously capable of recovering from such an indescretion and rolling back to a safe state, this can be something of a hassle.Īnother option is to do normal backups to another EBS volume mounted on the same instance. It’s a rather low-level approach though, and you could easily find yourself restoring from a snapshot taken with SQL Server’s pants around its ankles, in the middle of a transaction. It works fine and could conceivably be automated using the AWS API. I’ve used this to muck around with test-environments and such. This basically saves the (diff of the) contents of your volume to S3, from whence it can be restored to life if something happens to the volume. In other words, you should take backups.Ī simple approach is to use the snapshotting feature of EBS. Bear in mind, however, that this failure rate is compounded by other factors such as Windows or SQL Server malfunctioning and corrupting the volume, you pressing the wrong button in AWS console/Management Studio, a disgruntled employee doing it on purpose or something else entirely. You may decide this is good enough for your purposes and leave it at that. While i haven’t had an instance die from under me, if one should cop it, all data on the local disks will be gone-gone.ĮBS volumes can fail too however, and will do se at an annualised rate of 0.1% to 0.5% according to Amazon. They can sustain many more random IOPS than instance disks (good for typical workloads) and they live independently of your instances. To start with, you should probably be running your database off an EBS (Elastic Block Storage) volume. In this post, I’ll sketch some options and end with a simple PowerShell script usable on both Express and Standard versions, that’ll backup your database to S3. The many backup modes offered by Microsoft SQL server, combined with the prodigious hardware options offered on Amazon EC2 can make choosing a backup strategy for your setup a little confusing. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |