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).
Related
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.
I understand that EBS volumes that are restored from snapshots need to be initialized.
Let's say I create an AMI from an EBS snapshot(s).
When I launch a new instance using that AMI, will I need to initialize each volume before I get consistent latency?
When you create an instance from AMI which has EBS based volumes as storage, your instance creates new volume from this volume and continues with launch.
When you use snapshots as source to launch your instance, AWS need to pull these snapshots and write it to volume and then continue with the launch. In this case, pull storage blocks from S3 and write to volume will be the latency some users want to avoid. This is the case where pre-warming is suggested by AWS.
I have several AMIs that developers use to spin up instances. These AMI do not have "delete on termination" set on all their EBS volumes. At times terminating instances launched using these AMIs has the unintended consequence of leaving behind orphan EBS volumes. Unfortunately, "blessing" a new AMI for general use is quite an ordeal. Is it possible to edit an existing AMI to turn on "delete on termination" or is the only way forward to create a new AMI with the proper settings?
It is not possible to modify the "Delete on termination" value on an existing AMI.
So you have 2 choices:
Launch an EC2 instance from your AMI and produce a new AMI with the appropriate "Delete on Terminate" value, or
Modify the value when you launch the new EC2 instance.
Once the instance is running you can call modifyAttribute (modify-instance-attribute in the CLI) on the attribute blockDeviceMapping.
aws ec2 modify-instance-attribute --instance-id i-a3ef245 --block-device-mappings "[{\"DeviceName\": \"/dev/sda\",\"Ebs\":{\"DeleteOnTermination\":false}}]"
You can see an example here: http://www.petewilcock.com/how-to-modify-deletion-on-termination-flag-for-ebs-volume-on-running-ec2-instance/
There is no such features.
In addition, I think you misundestand the purpose of AWS web console EC2 EBS Volumes vs snapshot.
When you launch an instances, a EBS Volume is assign to the instance(if it is a EBS base instance like t2., c3.) , once you terminate it, that assoicated volume will be deleted.
Unless you create a EBS volumes that attach to a instances, that is another story. An attached volumes will stay even the instance it attached to is deleted, this is intended design as EBS volumes is network storage anyway, it should allow you to detach/attach to different instances dynamically.
On the other hand, your user may create snapshot(s) for their instances, which store under the Snapshot portion. This is part that will stay, even you terminate the original instance. Once you deleted the original instance, the volume it point do will be "orphaned".
It is a good practice to create a snapshot for instance as backup, but it will go wilds if you don't have a standard policy to handle it. No automation can help a process nature issues.
You MUST enforce a policy and standard for your developer to follow as well, e.g. backup cycle, tag for snapshot, etc.
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