Ashutosh Mallick

Posted on Jan 31, 2022

Configuring EBS volume (Extending and reducing volume, Concept of snapshots)

#devops #aws #cloud

In the last blog we talked about AWS Block storage, EBS to be specific. We also discussed the types, uses of EBS volume, how to attach it to an instance and how to mount it in a disk.
Let's move further and discuss about resizing, reducing the volume and some more interesting facts about EBS volume.

Now go to volumes in aws console. Select the EBS volume we created "Extra-vol" and select modify volume. Change the volume size from (15GB to 20GB). -Now go to xshell for your instance "Test-1" and t ype "resize2fs /dev/xvdf" command to resize your volume from 15 to 20 GB.
In xshell prompt you can list the volume attached with your instance by typing "df -h". You can see the 20GB vol. listed over there.

Attaching volume to different instances

For attaching volume (20GB) to another instance we've to first unmount "Extra-vol" from "Test-1" instance.
We should never go for forced detaching of volume. Rather we should first unmount it as per the best industrial practices.
To unmount the vol, go to the root folder and then type "umount /india" or "umount /dev/xvdf" any of these two will do. -Now detach the "Extra-vol" from "Test-1" server and create another instance in same region as that of the EBS volume (say "Test-2" server in ap-south-1a region).
Connect the "Test-2" server via SSH. Attach "Extra-vol" to "Test-2". Verify the same by typing "lsblk" in xshell prompt. -Now mount the EBS volume by creating a directory in Test-2 console(We don't have to format the disk again as it was formatted once).
Now create another instance "Test-3" in another region (ap-south-1b). Now let's unmount and detach the volume from Test-2 and attach it to Test-3.
To unmount follow the same procedure as discussed earlier. Go to root folder and type umount /dev/xvdf. Now detach the volume from "Test-2" server.
Now the challenge is how to attach "Extra-vol" to "Test-3". Because, the server and volume belong to different regions. Hence, we take the help of snapshots in this case.

You can back up the data on your Amazon EBS volumes to Amazon S3 by taking point-in-time snapshots.
Snapshots are incremental backups, which means that only the blocks on the device that have changed after your most recent snapshot are saved. This minimizes the time required to create the snapshot and saves on storage costs by not duplicating data.
Each snapshot contains all of the information that is needed to restore your data (from the moment when the snapshot was taken) to a new EBS volume.

When you create an EBS volume based on a snapshot, the new volume begins as an exact replica of the original volume that was used to create the snapshot.
The replicated volume loads data in the background so that you can begin using it immediately. If you access data that hasn't been loaded yet, the volume immediately downloads the requested data from Amazon S3, and then continues loading the rest of the volume's data in the background.

Charges for your snapshots are based on the amount of data stored. Because snapshots are incremental, deleting a snapshot might not reduce your data storage costs.
Data referenced exclusively by a snapshot is removed when that snapshot is deleted, but data referenced by other snapshots is preserved.
Now let's go back to aws console and create a snapshot for the EBS volume. Name the snapshot as (Extra-vol-snapshot).

-Now create volume "New-vol" from snapshot that you've created in the earlier step. remember that we've to create the volume in the same region as that of "Test-3" server i.e, in ap-south-1b region.
Attach the "New-vol" to the server "Test-3". In Test-3 console mount the volume.

You can list the volumes in the disk by "df-h". Now go inside "india" directory and type "ls". You can see the 100 files that you created earlier are present.
Now let's create another volume say 1GB under the name "Reduced-vol". Deploy the volume in same region as that of "Test-3" server.
Now attach the "Reduced-vol" to "Test-3" server. Mount the volume to a disk you've created (say software).
Now let's sync all the files present in "india" directory to "software" directory by using the command "rsync -aHAXxSP /india/ /software".
Now type ls inside the software directory. You can see all the 100 files listed over there that you created earlier.
After you're done with testing, unmount the volume , detach it from "Test-3" server. After checking the above steps you can delete the EBS volumes and the snapshots you've created in ealier steps and terminate the "Test-3" server.

You can use Amazon Data Lifecycle Manager to automate the creation, retention, and deletion of EBS snapshots and EBS-backed AMIs. When you automate snapshot and AMI management, it helps you to:
Protect valuable data by enforcing a regular backup schedule.
Create standardized AMIs that can be refreshed at regular intervals.
Retain backups as required by auditors or internal compliance.
Reduce storage costs by deleting outdated backups.
Create disaster recovery backup policies that back up data to isolated accounts.

Snapshots

Snapshots are the primary means to back up data from your EBS volumes. Snapshots are incremental, containing only the volume data that changed since the previous snapshot.
When you delete one snapshot in a series of snapshots for a volume, only the data that's unique to that snapshot is removed. The rest of the captured history of the volume is preserved.

EBS-backed AMIs

An Amazon Machine Image (AMI) provides the information that's required to launch an instance. You can launch multiple instances from a single AMI when you need multiple instances with the same configuration.
Amazon Data Lifecycle Manager supports EBS-backed AMIs only. EBS-backed AMIs include a snapshot for each EBS volume that's attached to the source instance.
Now let's enable a Lifecycle manager policy. First create an instance(Test-server).
For lifecycle manager select type of backup. Here I'll take the instance backup. Under policy description, type "My-backup-policy". Keep policy status "enabled".
Now set the frequency of backup as per your convenience such as: Daily, weekly or monthly. Set the UTC time and expire time.
Establishing lifecycle manager will help you to store the data of "Test-server" in RDS database for easier queries. Hence, even if your server gets corrupted, backup will be always available in RDS.

Thank You. :)