I am new to Amazon EC2 and just pulled down some Unix based image (I think it was an IBM image). It launched fine, worked great and was able to be stopped and snapshotted, all through the console. However, when I replicated the snapshot and launched a new image, albeit of a smaller size, the new image came up with errors. Is there something I need to do before snapshotting an image to make it restartable?
YOu should pause, the processes writing to the EBS volume, so that the EBS volume is in a consistent state.
Related
I accidentally took snapshot from volume (100GB) that was attached to running instance (as a ROOT device). The snapshot creation took over one hour! After that I created bigger (400GB) volume from that snapshot and everything went fine. Then I:
stopped the instance
detached the old 100GB device from my instance
attached the new 400GB volume to that instance
started the instance
Everything seemed OK in AWS control panel (server running and disk status was fine) but I could not connect to that instance via SSH nor HTTP. SSH error: connection refused. So I changed back to old 100GB disk and instance worked well.
My suggestion was that something went wrong because of taking snapshot from running instance. So I deleted the snapshot and took new snapshot from stopped instance (volume). This time the creation of snapshot took only 5 minutes. Then I just created new volume from that snapshot, attached it to instance and started.. still not working.
So my questions are:
Can it be possible that even when I delete the old snapshot the data of that snapshot was partially used when making new snapshot?
How can I backup my current volume if every time I take a snapshot it uses old corrupted data
All these things were done via AWS control panel.
THANKS!!
Can it be possible that even when I delete the old snapshot the data
of that snapshot was partially used when making new snapshot?
I don't think so. It could be that when you created the first snapshot there were some resources in contention when trying to create it. Thus it took longer. Amazon is not clear about all the resources that they are using under the hood. In a way is good and bad. Good because it takes away most complexities and bad well because you can't see what the hell is going on.
How can I backup my current volume if every time I take a snapshot it
uses old corrupted data
You can either stop your instance before taking the volume snapshot or you can just create an AMI (Image) with making sure that the no reboot option is not checked.
See below:
Does Creating an Image of an Amazon EC2 Linux instance cause any downtime? Can I image a running server?
Already answered correctly, but I wanted to add a couple of caveats:
--no-reboot, no guarantee: When you create an image of a AMI with EBS backed root device, you may opt for --no-reboot, but AWS warns about this. It does not guarantee integrity of the file system. If it's really busy instance and heavy RW operations going on, you may get a corrupted image.
Instance Store, no reboot: Creating an instance store backed image never required reboot to me. It's three simple steps -- bundle-image, upload to S3, and register the image without any rebooting in this whole process.
It is my opinion that No Reboot should prevent the image creation from rebooting.
If you are the api user, it also provides argument --no-reboot to do it.
What is the different between starting an AWS Image and Instances?
Example:
I do notice when I am running AWS image using boto, I can only stop the Image while running AWS instance using boto, I can only terminate.
Think of an EC2 instance as a single running server with CPU, memory, hard disk, networking, etc. Any changes you make to that instance affect only that instance.
Think of an AMI (Amazon Machine Image) as an exact copy of the root file system that gets copied to the hard disk when you start a new instance. The AMI is a hard disk sitting on a shelf. You make an exact copy of the hard disk on the shelf, install the new hard disk in a server, and turn the server on. You can do this for as many servers as you'd like to start without affecting the master copy.
The AMI defines the initial state of each instance. Each instance changes as it runs, but you can never change the original AMI once it has been created (other than to delete it).
There are more details that refine this conceptual model, but that's the basics.
Specific to the wording in your question:
Sometimes we say we're "starting an AMI" sometimes we say we're "starting an instance". We mean the same thing. We're really starting an instance using an AMI as the template.
We never say we're "stopping/terminating an image" or "stopping an ami" as, once started, it's really the instance that's running.
You can have one or more instances running that are derived from an image (AMI). Here is a good little tutorial, that's a bit old mind you, talking about how you can convert an Instance to an AMI ... which you can then redeploy one or many times:
http://webkist.wordpress.com/2010/03/16/creating-an-amazon-ec2-ebs-ami-from-a-running-instance/
What is an AMI: Amazon Machine Image
http://en.wikipedia.org/wiki/Amazon_Machine_Image
Technically, you can't start an AMI. You can start an instance that is derived from an AMI.
I am running a vanilla Windows install on Amazon EBS volume. The computer takes 10 minutes to boot, which may be understandable as 2 reboots are required. However, taking a snapshot is also a 10-15 minute process. Can anyone explain this? Any way to speed it up? I am a bit surprised, because I thought that snapshots are immediate replicas of the running EBS volume, in which case shouldn't they take just a couple of seconds to complete?
I will add that the console shows that "snapshot" is completed very quickly. But the "AMI" section is what seems to take 10-20 minutes. What's the difference? Is the snapshot available for use immediately, or do I need to wait for the AMI?
From the EBS product page:
Amazon EBS snapshots are incremental
backups, meaning that only the blocks
on the device that have changed since
your last snapshot will be saved. If
you have a device with 100 GBs of
data, but only 5 GBs of data has
changed since your last snapshot, only
the 5 additional GBs of snapshot data
will be stored back to Amazon S3.
Subsequent snapshots are fast because only the changed blocks need to be saved. So the time it takes scales with the amount of changes since the last snapshot.
Is the snapshot available for use
immediately, or do I need to wait for
the AMI?
Also from the product page:
New volumes created from existing
Amazon S3 snapshots load lazily in the
background. This means that once a
volume is created from a snapshot,
there is no need to wait for all of
the data to transfer from Amazon S3 to
your Amazon EBS volume before your
attached instance can start accessing
the volume and all of its data. If
your instance accesses a piece of data
which hasn’t yet been loaded, the
volume will immediately download the
requested data from Amazon S3, and
then will continue loading the rest of
the volume’s data in the background.
The creation of an AMI is a multiple-step process.
The Snapshot of the current machine is started (that's darn near instantaneous)
The snapshot copies the "changed blocks" from the base AMI to the snapshot lazily (that's pretty quick too)
The underlying Windows image is then prepared to be an AMI base image this starts with booting a "ghost" instance from the image with the snapshot as the disk image.
A SYSPREP is started to "reseal" the machine so it gets new machine SIDs.
The new image is then re-snapshotted
The AMI is marked "complete"
we're admitedly new to the ebs world. having set up a new production couchdb server on amazon ec2+ebs, we ran into an issue where about 7 hours worth of data simply disappeared. to the point where the couchdb logs have a gap in them for that very time frame. we know that things were working fine, then we started to experience issues and realized that our database had been reset to an empty state.
thoughts? opnions? conjectures?
the issue was that couchdb was starting up as a service, before the ebs was properly mounted. this caused the confusing behavoir.