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 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 have a bitnami instance working fine on my AWS console. I want to make a backup of it so that if I mess something up I can simply deploy an older backup.
I followed the instructions here:
https://docs.bitnami.com/aws/faq/administration/backup-restore-server/
So I have the snapshot created. But how do I get a bitnami instance running based off of that snapshop?
That page says:
This feature creates a new snapshot of the disk, which can later be used to restore the server to an earlier state.
To restore the snapshot, you can use "Create Volume" to create a new Amazon EBS Volume from the snapshot. You could then restore the system to the state of the snapshot with these steps:
Stop the instance
Detach the current EBS volume
Attach the new (restored) EBS volume with the same device identifier
Start the instance
However, if you wish to launch a totally new instance using the backup, then the easier backup method would be:
Use "Create Image" in the EC2 console to create an Amazon Machine Image (AMI)
Launch a new instance using that AMI
I want to back up the root device (mounted at /) of my t2.micro instance running Ubuntu. I think the instance is EBS-backed as it is a t2 instance. So I was going to take snapshots of my root device to back it up.
However, it is recommended that I detach the root device before I back it up. There are two problems with this:
I have to use umount to unmount it first, which may cause my instance to crash. What is a safe way to handle this?
I want to run these backups as a cron job on the instance itself, but if my instance's root device is unmounted, will the cron job even run?
A more general question is: what is the best way to do this?
A possible solution might be: use AWS Lambda and execute a Lambda function based on a schedule executing the following commands by the use of the AWS SDK:
Stop EC2 instance
Create EBS snapshot
Start EC2 instance
First, I would confirm that your root device is in fact EBS backed.
Here are the basic steps to confirm:
To determine the root device type of an instance using the console
Open the Amazon EC2 console.
In the navigation pane, click Instances, and select the instance.
Check the value of Root device type in the Description tab as follows:
If the value is ebs, this is an Amazon EBS-backed instance.
If the value is instance store, this is an instance store-backed instance.
(Source: http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/RootDeviceStorage.html#display-instance-root-device-type)
AWS states as a best practice is to use snapshots or a backup tool.
Regularly back up your instance using Amazon EBS snapshots or a backup
tool.
(Source: http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-best-practices.html)
AWS states in the documentation that root EBS volumes should be shutdown before taking a snapshot.
To create a snapshot for Amazon EBS volumes that serve as root
devices, you should stop the instance before taking the snapshot.
(Source: http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-creating-snapshot.html)
So depending on your RPO (Recovery Point Objective), as a general rule it is a good practice to separate your data from your root volume. Store data that you need to keep on a separate EBS volume and take snapshots on the second EBS volume. This way you never have to worry about the instance itself - if it bonks out just launch a new instance and attach your snapshot.
If you have a special case that prevents you from using EBS snapshots, try using a role for your instance(s) that have permissions to read/write data to S3 buckets using your cron job.
I wanted to take a pre-existing t2.medium EC2 instance and essentially clone it. Knowing no exact feature exists within AWS I scoured their documentation, asked people I know and came up with:
Create snapshot of said EC2 instance
Create AMI of snapshot
Build EC2 instance from AMI
When I went to build the new EC2 I was only given the option for a t1.micro OR m3.medium and above. I tried both (in and out of same region as original) and kept getting "insufficient data" under Status Checks.
Any ideas on what is going on here?
It sounds like you selected "paravirtual" as the virtualization type when you created the AMI, when you should have selected "hvm".
If you are doing this from the console you can create an AMI directly from the pre-existing EC2 instance, skipping the manual snapshot step, which should automatically use the correct settings for the AMI.