My basic need is that I should be able to make new instance from my saved image for current running Centos with all settings.
I am thinking of two options:
Create the AMI from the any state
Create the snap shots of EBS
I am confused what is the differnece between them. Are they same or different?
Can I make new instances from EBS snapshots/?
Also, can I use AMI on my localhost to create the same OS?
There are two types of AMIs/instances: EBS boot and instance-store (sometimes referenced as S3-based). You are probably using EBS boot, so this answer will relate to that type.
An EBS boot AMI is an EBS snapshot of a boot EBS volume with some extra attributes including:
Registered as an AMI with an AMI id
AKI (kernel)
ARI (ramdisk)
architecture (e.g., 64-bit)
block device mappings (e.g., where volumes should be created/attached)
description, name
permissions (who is allowed to run the AMI)
If you create an AMI of the running instance, you should be able to start new instances in the same state. Make sure you test this process so that you know it works.
If you simply snapshot the EBS volume(s) of your running instance, you will be able to create volumes from those snapshots to access the configuration and data.
It is also possible to take an EBS snapshot of an EBS boot volume and register it as an EBS boot AMI so that you can run more instances starting with that state. When registering the AMI, you'll need to specify the correct AKI, architecture, and other meta-data in order for this to work, so research and practice before you trust this approach.
It took me a while to understand it as I am new with it, but here is a thing if you are using EBS backed:
If you want to start immediately create AMI Image( which creates image of OS and store data as EBS Snapshot), then the whole AMI Image contains current state of your instance which is installed OS which is all config and data files.
If you only take EBS snapshot, then for restore you need to launch new AMI, and you can attach this volume to it for just to access data. If your new AMI has different OS or upgraded may be few of your config won't work and you need to install your packages from scratch. So you should check this first.
In simple words EBS Snapshot can not be used as root volume unless you make and own its AMI image :-)
In brief, EBS boot AMI = EBS root volume snapshot + metadata
For better understanding, you can play it through hands on.
create an EBS snapshot for a particular running instance.
Find this snapshot.
Fill some meta data, and build image(AMI)
You did it. A brand new AMI has been created.
Related
We have a EBS volume from a previous T2 instance, which contains operating system, mysql installation, created users and all configurations.
For launching a new instance (T2), how to use
the pre-existing EBS volume as main bootable disk so that we have the operating system, apps and all configurations? This would save us days of time and efforts.
For a business application, should we choose T2 or T3?
As discussed you can perform the below steps to create an EC2 instance from a pre existing EBS volume.
Create a snapshot from the EBS volume.
Create an AMI from the same.
Look for the AMI in your private AMI.
Create the EC2 instance with desired instance-type from this AMI.
Also you need to care for the EBS volumes with this new EC2 instance with minimum EBS volume size etc.
Please let me know.
I am having trouble understanding when an EBS Snapshot vs an AMI Image would be optimal.
If for instance, I have an EC2 Instance that contains a LAMP stack, with data in the MySQL database, and some other basic files, would it be sufficient to back this up using an EBS Snapshot or do I need an AMI Image? I understand the AMI Image will also back up the Operating System. I am having trouble understanding whether it is necessary to back up the OS to ensure the MySQL data is backed up.
So take a snapshot if you only need the base volume taken as a backup. From this you can only create a new volume. This can also be used to migrate a volume from one AZ to another, or to move it to a different region.
Take an AMI for the following reasons:
Take a snapshot of the instance vs the volume, all volumes will have a snapshot taken.
To rollout in an auto scaling group as a prebaked image.
To duplicate a server
For your case (a MySQL data backup) a snapshot is enough as you’d restore this to a volume and attach to a new instance.
I created several snapshots from volumes of my instances months ago. Today I had to restore an instance based on a snapshot, but this instance does not contain any of my data, it is a clean version of Ubuntu, exactly as the first time I created the instance.
How do I restore my data?
thanks
In AWS there are two snapshot options:
1- Snapshot: You can use snapshots to capture a point-in-time state of your individual volumes.
2- Amazon Machine Image (AMI): You can use an AMI to capture a point-in-time state of your whole EC2 instance (VM), including all of its volumes.
So, difference is that snapshot is on individual volume level and AMI is the entire instance. Under the hood, AMI takes snapshots of all attached volumes and you can see those snapshots in the corresponding Snapshots page in AWS Management Console.
So to be clear, did you create an AMI from you Ubuntu instance and restored the same AMI? Or did you create a snapshot from one or more of its volumes? In that case, how did you restore it?
If you only take a snapshot of one or more of the volumes, after you restore your snapshots into new volumes attached to an instance, you should also remember to mount those volumes. But if you use an AMI, mounting may not be required, as long as you have added your volumes in the /etc/fstab.
How do I launch an EBS backed AMI as an instance store machine with out having to do too much hack? Also, more specifically, can I launch this using in an autoscaler?
I can answer the first part of your question. As far as I know you can not launch an EBS backed AMI as instance store machine. Instead what you can do is create an IS (instance store) backed AMI from the EBS backed running instance and use that to launch instance store backed instances.
The process of converting EBS backed instance to IS backed AMI not so straight forward. You need to start from a EBS backed paravirtual instance and after that I followed this answer for the conversion. To install AWS tools and command line utilities use this AWS tutorial.
I am trying to create a backup mechanism for our server, so that if my system crashes, I should be able to create the whole system by running a single script
After going through Amazon documentation, this is my understanding of creating a backup and restoring
Backup
Create a AMI Image (this can be updated monthly)
Create a snapshot (This can be done using a daily script creating a snapshot)
Restore (A script to)
Create an EBS instance using AMI
Attach the EBS volume to Instance created
Now my Questions are
Is it the best way to take a backup and restore?
Do we actually need to backup 2 things, AMI and EBS volume (using snapshot), Can we just keep snapshots?
I understand this cannot work for a local instance store instance, as there is no snapshot functionality. So how can I create a backup and restore process for local instance store instances?
As I could not find any better alternative, I am sticking with the initial approach.
For EBS
Backup:
Create a AMI Image (this can be updated monthly).
Create a snapshot (This can be done using a daily script creating a snapshot).
Restore (A script to)
Create an EBS instance using AMI.
Attach the EBS volume to Instance created.
For instance store, I am only keeping the application (no database), so no need to keep a backup of that.
EBS Snapshots are an excellent way to create backups.
You can perform frequent Snapshots of your EBS Volumes via scripts. Weekly, Daily, Hourly, or as frequently as your Credit Card will allow. The only limit is around how many simultaneous snapshots you can be doing - when you hit that, the EBS API will start giving back errors until a few of the in-flight operations complete.
Snapshots can also be copied from Region to Region in order to provide backup against a catastrophic event.
When you snapshot an EBS volume, that snapshot is of the entire volume. Even if it was created from an AMI, your snapshot contains everything you need to create a new instance of the volume. You can pretty easily try this yourself.
If your instances are Linux based, there is no need to create an AMI if you're taking snapshots. You can create the AMI on the fly, from the snapshots, when you need to recover. If you got that process automated, it's pretty easy to do.
In Windows there is a limitation not allowing to launch an EC2 instance from a snapshot, so AMIs must be used. There are ways to workaround that limitation: You can check out the this post I wrote in our company's blog:
http://www.n2ws.com/blog/3-ways-ec2-windows-backup-and-recovery.html
I would suggest to use Auto Scaling in addition to EBS snapshots. If Instance is dying because of Hardware failure or it's scheduled for retirement by Amazon, Auto Scaling will start new Instance automatically.
But in this case, you have to setup NAS for your dynamic data. Depending on Server Load, the number of running Instances will be different and all your scaling servers must mount NAS storage which is shared across them.
Your Database should be on separate server or servers as well. Or you might want to use Amazon RDS as it has great auto-backup / Point-In-Time-Restore features, but you have to pay extra for that.
1) Yes.Snapshot is best way to backup and restore EBS volumes.
2) Depends, if you have the root volume as EBS backed AMI, then you can snapshot them as well and improves the manageability
3) Rsync and AMI is the option available for instance store