title says it all. I inadvertently terminated an EC2 Instance and desperately need to restart it/relaunch it!!!
Any help? It would be disastrous if I had to start all over!! Does anyone know how I can fix this?
Basically it goes like this:
Your machine is gone, you cannot restart, you need to create a new instance
all the data you had on an instance store volume are gone (you cannot recover those)
If you had EBS Volume attached and you had setting enable for 'delete on termination' the latest data are gone. You can recover if you have a snapshot from this volume.
If you had EBS Volume attached without flag for 'delete on termination' you can recover those data
So what you can do:
check your snapshots and Volumes in the ec2 console. If you have no snapshot/volumes, you cannot recover anything
if you have root volumes,
make a snapshot of those you want to recover
from the snapshot, make an image
from the ami, launch a new instance for the specific image you've just created
if you dont have root volumes
create volumes from snapshot if you have any snapshot you need to recover data
create a new ec2 instance
attach and mount the volumes to the new instance
read and backup your data
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.
I'm using a community AMI, it's great but some of the stuff in it is outdated. Every time I spin up a new machine based on it I have to update all the libraries. I want to instead update them once and save the modified image. It's and EBS backed AMI. I tried creating a snapshot off of the volume of the running instance and then creating an AMI from the snapshot. The resulting AMI does indeed have all the modifications I made but the operating system is different! The original AMI has ubuntu while the thing that comes out is "other linux" - and some things are not working (CUDA). Both "RAM disk ID" and "kernel ID" in the original AMI details are blank so I leave them as "default" when creating the new AMI.
The preferred way to save a modified EC2 instance is to burn an AMI directly from the running instance, rather than taking a snapshot of its root volume.
If for any reason all you had was a snapshot of the root volume of a previously running instance, to create a bootable AMI you have to follow the following process: launch one of the stock EC2 AMIs, one that has the same OS as your EBS snapshot. Create an EBS volume from that snapshot. Stop the newly launched instance. Detach the root volume, and attach the new volume you created form the EBS snapshot as the root volume and start the instance. See Launching a Linux Instance from a Backup. NOTE: Although you can create a Windows AMI from a snapshot, you cannott successfully launch an instance from the AMI.
The easiest way to save an AMI with new modificationa, is to create the AMI image directly from the running instance, and not simply take a snapshot of the running volume.
From the AWS Management Console, click on the instance, then right-click Image -> Create Image.
From that dialog, set the Name, Description etc. Make sure to leave No Reboot unchecked. From the Instance Volumes section adjust the volume settings.
Note that your instance will reboot during the image creation process. Make sure you are prepared for the temporary loss of service of the instance during this time.
Production went down today with no disk space remaining error. After deleting files and restarting the machine, it still came up with this error, even if I just try to touch a new empty file.
It is probably caused by running out of inodes, but I went ahead and created an "Image" which seems to create an AMI, but after launching an instance of the AMI the same problem persisted... probably because it is using the same EBS volume.
Question is: how do I snapshot the EBS volume and then connect a new volume to the AMI as the root fs?
You care correct that the "Create Image" command creates an Amazon Machine Image (AMI). If you start a new EC2 instance with this AMI, it will contain the same data as the machine that was imaged. That's why you are copying your exiting problem to the new instance.
Check your disk space with df -h to confirm that you have space available.
If you require more disk space, you can copy your disk to a larger volume as follows:
Option 1: If you already have an AMI of the volume:
Launch a new instance using the AMI, but expand the size of the volume in the Add Storage options
Option 2: If you want to retain the same instance:
Stop your instance
Create Snapshot of the EBS Volume
Create Volume from the Snapshot, specifying a larger storage size
Detach the original root volume
Attach the new volume in its place (keep the same Device identifier)
In both cases, after startup confirm that the partition has automatically expanded. If not, use the resize2fs command to extend the partition.
When you create an image of an ec2 instance, it takes snapshots of the volumes also. You can see this in "Images > AMIs" and snapshots information is visible in "Block Devices" column (By default, this column is not visible) of the table.
Now, if you are getting the "no disk space error", you need to increase the size of root volume. You can do that by following the link below:
http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-expand-volume.html
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.
I have ec2 instance set up where mysql DB is mounted on separate volume.
(as detailed in http://aws.amazon.com/articles/1663 )
I want to duplicate this instance set up where my application servers on duplicated instances share the DB volume which is attached to the already running ec2 instance.(I can specify mysql ip through configuration file)
Since almost every set up except the mysql ip is identical, i'd like to create an ami from the first instance and slightly modify to create 2nd,3rd instances.
The question is, the mount information stored in the first instance will take effect when I launch the 2nd instance.
I can elaborate the question,
1. I read that a volume can not be attached to more than one ec2 instance at the same time.
2. the running instance attaches/mount an volume to itself on start up.(so it seems)
3. if I were to create an ami from first instance and use that to initiate other instances, how would auto attach/mount information(which I assume, will be stored in the ami) will affect the other instances.
Eugene,
Mounting the same device to several servers is not possible, so you better forget about this option.
The best solution is to:
Create a copy of your master instance.
Detach the created mount volume. We are going to create an image from this new instance, and you don't want the useless drive copy to be re-created every time.
Change the settings that you need to change, in order to make this server rely on the remote (master) mysql server.
Once you are satisfied with the outcome, create an image from this instance.
Good luck!
Dotan