I have an EC2 small instance, which has two EBS volumes attached and has EBS as root device. Now the EC2 instance is not reachable for some reason (AWS engineers are looking into it). In the mean while, we are thinking about launch another EC2 instance and attach it to the two EBS volumes. What's the best practice for that purpose? Do I need to take snapshot of the volumes before re-attach to the new EC2 instance? Can we attach to them without destroying the existing data on the volumes?
You do not need to take a snapshot in order to attach the volume to a new instance. You can simply detach the volumes and re-attach them to a new instance.
Your data will not be destroyed in this process.
Hope it helps.
Related
I create an instance but do not add additional storage / a volume, will a snapshot backup the instance and the changes I have made to the config or does it only backup data from the volumes?
I am making some training material and would like to do the following:
Create an instance
Create users
Make a few more config/program installation changes
At this point, I would have a "clean copy".
I then would like to take a Snapshot of the state of the instance.
fool around, possibly break stuff
Then restore the instance to the "clean copy" after the instance has been created but before I started messing around.
Is this possible with snapshots?
Let's clarify some terminology:
A Snapshot can be made of an Amazon EBS volume. This makes a backup of the specific disk volume. The snapshot can be used later to create a new EBS Volume.
Or, you can create an Amazon Machine Image (AMI) of an Amazon EC2 instance. This creates an EBS Snapshot of all associated volumes and also stores some metadata about the AMI.
You can then Launch a new Amazon EC2 instance from the AMI. This will include a copy of the disks.
If you wish to restore the instance to the "clean copy", then it is best to launch a new instance from the AMI rather than trying to 'reset' the instance to an earlier state. The instance will have a different Instance ID and a different IP address, but will otherwise be the same as the instance from which the AMI was created.
So I create an instance using one of the Public AMI EBS Ubuntu flavors. I create an EBS volume and attach it to the instance. I format the volume and add an entry to /etc/fstab to mount it on /vol. I add mysql to the AMI and move the data files to the EBS volume I formatted and mounted at /vol. I then create an AMI from the running instance. Then I terminate the running instance.
I start a new instance using the freshly created AMI (with mysql on it). The /vol is mounted has the mysql data files - good, I expect that. Here's where I am confused. When I create any directory or files on the EBS volume /vol they aren't there any more after I terminate the instance and create a new one. The mysql stuff is there but no new stuff I created. Aren't those files and directory supposed to be there? Or am I misunderstanding how this works?
When you create an AMI, "Amazon EC2 powers down the instance, takes images of any volumes that were attached, creates and registers the AMI, and then reboots the instance." -Amazon. When the AMI is used to launch an instance, the images (snapshots) of the attached drives are used to create new volumes. It is these new volumes that are attached to the new instance, not your original EBS. (This generates lots of orphan volumes and snapshots with ongoing use.)
There is no automatic attaching of the EBS volume you created. What is automatically attached is the volume it creates at the time of launching the instance from your AMI! It creates this volume from the snapshot it made of your EBS at the time of the AMI creation!
The way to avoid clone volumes from being created and attached to new instances is simple: detach your volumes before making AMIs. You need to attach your EBS volumes manually with the EC2 Web Control Panel, or programmatically with .net or Java programming, scripting or command line tools.
EBS volumes are not tied to an AMI, only to the literal instance you attach them to. When you created your AMI and a new instance from that, the EBS is not cloned, nor does it follow you to the new instance.
You could move the EBS drive to the new instance manually. Alternately you could snapshot the EBS volume & clone a new drive from that.
Due to system crash after update i set up new instance with ebs(old instance has an instance store). But i need to copy some data form old instance to new. It`s possible to mount instance store from old instance to new? How to do this?
Have you come across this thread: Mounting Old EBS Volume to the new Instance - Amazon EC2
I'm not sure if that's what you're looking for, but the answer on that thread details the process of mounting the old EBS volume to the new one on an Amazon EC2 instance.
So, in a simple situation, if there is only one instance, then I can store the data into a EBS volume mounted on that instance. e.g. /mnt/db
However, how does it work if I scale and have multiple instance (either static or dynamic scaling)?
Because one EBS can only attach to one instance, if I have multiple instance, does it mean that I have to attach an EBS volume for each instance? If that's the case, the data on each Instance's EBS volume will be different.
It is obvious that I want all instances to access (R & W) a single volume (as data-storage). and the data in the volume will constantly grow and there is no downtime.
What is the solution? Is there a way that I don't mount the device (EBS), and just call it for accessing the data?
Here is what I can think of:
1) if each instance has its own EBS volume, then each time interval (e.g. 1 hour), all instances will unmount & detach the EBS volume,and attach a new one. Then there is one powerful instance that mount all the EBS volumes just detached, and aggregate all the data.
2) or similar to 1), instead of detach and attach, I just take a snapshot on all volumes for all instances. Then the powerful instance aggregateness the data from the snapshot. And save the result into either another EBS or S3.
These two approach seem to be working.. but require a lot of work. is there a smarter way to approach this problem? thanks.
by the way, because of performance issue, I cannot have the instance writes data to S3. :)
OH how about this
3) First, all instances have their own EBS and write data into the EBS. and then each hour, data will be sent to S3. Then another instance will aggregate them.
how about having ang NFS instance which can be mounted to the other instances?
It seems that you need to create an EBS snapshot of your most up to date EC2 instance. This will create an EBS backed AMI. You would then need to terminate all your EC2 instances that are not up to date and launch a new stack of instances from your newly created AMI. If you had a load balancer running then you would have to attach these new instances to your load balancer also.
It seems a little long-winded but it can all be done programmatically. At least this is how I think scaling in the cloud with Amazon works and far as propagating changes across multiple instances goes. Somebody else with more experience verify this. I plan to test it out myself later on.
I am new to Amazon web services. I need to create a server image with a few software packages pre installed on the EC2 instances.
One option I am considering is to create an EBS volume with these packages and then use them to launch EC2 instances.
The other option I am thinking of is to create a private AMI and then use them to launch the EC2 instances.
I am not sure which option is better.
One other slightly related question I have is can I create a private EBS volume and share it with some other account.
You should create your own AMI, as it's probably more efficient. In order to create an instance, you must specify an AMI. Specifying an EBS snapshot as the root device in addition to specifying the AMI (if this even works, I haven't tested it) would just result in the EC2 cloud launching your instance with the AMI, followed by overwriting it with the EBS snapshot for the root volume.
It's easy enough to keep the AMIs laying around as prototypes.