AWS : Attaching a volume to an instance
Image source : Overview of the Creation Process for Amazon EBS-Backed AMIs
After writing data to an Amazon EBS volume, we can periodically create a snapshot of the volume to use as a baseline for new volumes or for data backup. If we make periodic snapshots of a volume, the snapshots are incremental so that only the blocks on the device that have changed after our last snapshot are saved in the new snapshot. Even though snapshots are saved incrementally, the snapshot deletion process is designed so that you need to retain only the most recent snapshot in order to restore the volume.
We can create an AMI using the AWS Management Console:
- In the navigation pane, click Instances and select instance. Click Actions, select Image, and then click Create Image.
- In the Create Image dialog box, specify the following, and then click Create Image.
- A unique name for the image.
- A description of the image, up to 255 characters.
- By default, Amazon EC2 shuts down the instance, takes snapshots of any attached volumes, creates and registers the AMI, and then reboots the instance. We need to select "No reboot" if we don't want our instance to be shut down.
If "No reboot" is selected, we can't guarantee the file system integrity of the created image.
- We can modify the root volume, Amazon EBS volumes, and instance store volumes as follows:
- To change the size of the root volume, locate the Root volume in the Type column, and fill in the Size field.
- To suppress an Amazon EBS volume specified by the block device mapping of the AMI used to launch the instance, locate the EBS volume in the list and click Delete.
- To add an Amazon EBS volume, click Add New Volume, select EBS from the Type list, and fill in the fields. When we launch an instance from our new AMI, these additional volumes are automatically attached to the instance. Empty volumes must be formatted and mounted. Volumes based on a snapshot must be mounted.
- To suppress an instance store volume specified by the block device mapping of the AMI used to launch the instance, locate the volume in the list and click Delete.
- To add an instance store volume, click Add New Volume, select Instance Store from the Type list, and select a device name from the Device list. When welaunch an instance from our new AMI, these additional volumes are automatically initialized and mounted. These volumes don't contain data from the instance store volumes of the running instance from our base AMI.
- Click AMIs in the navigation pane to view the status of our AMI. While the new AMI is being created, its status is pending. This process typically takes a few minutes to finish, and then the status of our AMI is available.
- Click Snapshots in the navigation pane to view the snapshot that was created for the new AMI. When we launch an instance from this AMI, we use this snapshot to create its root device volume.
We can take a snapshot of an attached volume that is in use. However, snapshots only capture data that has been written to our Amazon EBS volume at the time the snapshot command is issued. This might exclude any data that has been cached by any applications or the operating system. If we can pause any file writes to the volume long enough to take a snapshot, our snapshot should be complete. However, if we can't pause all file writes to the volume, we should unmount the volume from within the instance, issue the snapshot command, and then remount the volume to ensure a consistent and complete snapshot. We can remount and use our volume while the snapshot status is pending.
To create a snapshot for Amazon EBS volumes that serve as root devices, we should stop the instance before taking the snapshot.
To unmount the volume in Linux, use the following command:
umount -d device_name
Where device_name is the device name (for example, /dev/sdh)
Note: If we want to create an image (AMI) from our running instance, but can't afford to have it reboot and be out of service for a few minutes, we can specify the no-reboot option.
There is a small risk of the new AMI having a corrupt file system in the rare event that the snapshot was created while the file system on the boot volume was being modified in an unstable state, but I haven't heard of anybody actually getting bit by this.
If it is important, test the new AMI before depending on it for future use.
AWS (Amazon Web Services)
Ph.D. / Golden Gate Ave, San Francisco / Seoul National Univ / Carnegie Mellon / UC Berkeley / DevOps / Deep Learning / Visualization