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.
Related
I have created some EBS backups over the years, but I can't remember if they were volume or instance backups. Is there some way to tell by looking at one or more field(s) in the list, e.g., at https://ap-southeast-1.console.aws.amazon.com/ec2/v2/home?region=ap-southeast-1#Snapshots:sort=desc:startTime, or in the detailed "description" when I click on one of the snapshots? (the detailed description looking as in the snapshot below, for example) Unfortunately, there isn't a field that says "EBS backup type" that takes a value of "instance" or "volume". As indicated in this stackoverflow question, for example, both types are stored as "EBS Snapshots", so as I understand it then, both will appear mixed together in the same list of EBS snapshots.
Most of the previous questions, e.g., this stackoverflow question, or other pages I've found from searching, have been about the differences between volume and instance backups, and how one might choose one or the other. However, I'm not asking about that, but just if there is any way I can tell what type my previous backups are. Or do I just have to tag the type myself or put it as part of the description string?
UPDATE
From looking at the VolumeID of the snapshot (vol-0565abe0e54ad4adf in the image, for example), I'm guessing that if an existing ec2 instance is using that volume, then that particular snapshot was an instance snapshot? But it could also have been a volume snapshot of that volume?
UPDATE 2
It appears there is some confusion regarding what I'm referring to (from the answers and comments posted so far). I'm not using DLM, but the EC2 console (see image below, and "Snapshot" is the place I navigate to.
Then, when I click on "Create snapshot", I see the following, which shows the options of volume and instance (the first question). This may be a new option, as I don't remember seeing it before.
An EBS snapshot is a backup of a single EBS volume. The EBS snapshot contains all the data stored on the EBS volume at the time the EBS snapshot was created.
An AMI image is a backup of an entire EC2 instance. Associated with an AMI image are EBS snapshots. Those EBS snapshots are the backups of the individual EBS volumes attached to the EC2 instance at the time the AMI image was created.
To get Snapshots associated with still running Volumes, attempt to match their VolumeID with the VolumeID of still running Volumes. Output the SnapshotID of matches.
A snapshot is performed on a single volume, these will always be a backup of the individual volume rather than th complete ec2 instance.
To restore this snapshot, you would restore it to create a new EBS volume that could then be attached to an EC2 instance.
If however your instance is running a single volume you can go one step further. Instead of launching as an EBS volume you can instead create an AMI from the snapshot. This AMI can then be used to launch further instances using the base image taking from the snapshot.
I suspect you are using Data Lifecycle Manager (DLM), not exactly AWS Backup, because you are getting snapshots, AWS Backup work with vault, so you would not see snapshot.
If this is the case, DLM only work with volumes, so you only get backup of your volumes, not instances.
With AWS Backup you can have both, backup of your volumes and/or backup of your instances.
They will be contained inside a vault when backup happens, when necessary you will need to restore it from vault, which will gives you an AMI or a volumes, depending on which kind of backup you did.
Thanks for your update!
I got your point, the instance option there is just a helper to facilitate your life, imagine that you have an instance with 2 volumes and you want to create a snapshot of both volumes, in this case you could go to this screen and create one
snapshot each time (refering volume id on each time), or you can do it once refering the instance id and console will get both volumes for you and create both snapshots.
Doesn't matter which option you choose there, it will just create snapshot from volume, it will not do anything about your instance. If you want you can add a tag in your snapshot to refer to your instance, but it is just a meta-data.
So in your case you are just creating "backups" of your volumes!
If you lose your volume you can restore it, but if you lose your instance you will have to recreate your instance again (with all details) manually.
If you want to create a "backup" from your instance you need to create an image, which will give you and AMI, not a snapshot.
AMI will "backup" your instance details and will create a snapshot from all instance volumes (not ephemeral ones).
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.
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.
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
I have two amazon ec2 instances, (1) using SLES and running my current site, and (2) a new one using Amazon Linux. I am simply trying to move my site from the SLES and then retire it.
I have a 100GB EBS volume attached to the SLES server of which only about 20GB is actually used. What's the best way to bring the data over to the new instance?
create a new EBS volume of about 30GB and attach to new instance, use unix cp?
create a new EBS volume of about 30GB and attach to new instance, temporarily also attach the 100GB original volume the new instance, use unix cp?
something smarter/simpler, such as create a snapshot(?) of the 100GB EBS volume, somehow? create a new 30GB EBS volume out of it, and then attach that to the new instance? The extra benefit will be that I won't have to take down my site
Thanks a lot
It is easy to increase the size of a target volume, but the only way you're going to be able to make it smaller is to create a blank volume of the size you want. Then, either mount the new one to the old instance and do a copy or detach the old volume and reattach it to the new and do a copy. Basically, of the options you listed, only the first and second ones would work. The reason making a snapshot won't work is because creating a snapshot from a volume makes the snapshot the same size as the volume it was created from. You would get an error trying to create a volume from snapshot that is smaller than the original.