AWS EC2: Restoring snapshot of an instance after upgrading instance size

Issue faced with Plesk Obsidian

Hosted an EC2 instance on AWS EC2. Plan t3.micro. Unable to access Plesk dashboard since yesterday. Getting the message:

Reply received:

What happens with Plesk Obsidian is apparently if there is a memory/resource deficiency, you might be unable to access Plesk admin dashboard. Also, all live websites might no more live. In such cases, it is pertinent to have a snapshot in place so that after changing the instance sizing from Instance Type, a snapshot can be restored.

Ideally, even without a snapshot, one should be able to accomplish by first stopping the instance, then upgrading (like I tried to do from t3.micro to t3a.medium), and finally starting the instance. In my case, even after raising from t3.micro to t3a.medium, I could not access Plesk admin dashboard and associated websites were still not live. Since, I had a snapshot (taken few days back), I decided to replace EC2 instance with the snapshot, which was successful.

Query raised to AWS Support:

intend to restart the above instance after migrating one of its snapshot. Earlier, I was unable to access Plesk admin dashboard as there was a shortage of memory space. So, decided to relaunch with a snapshot. Could not figure out which one of the two is the snapshot of i-0cf7dc9918291c1b1. 1. snap-094c6b4b5c37228e8 2. snap-0ddc9e7371852d2fd So, help regarding figuring out the snapshot needed. After that, could not succeed in knowing how to proceed. Do I need to create Volume for the snapshot. A guidance such that I am able to restore the snapsot of instance will be highly appreciated. I have been able to change the instance size but struck since then. Instance ID(s): i-0cf7dc9918291c1b1.

Reply from AWS Support:

Hello, Greetings for the day!

Thank you for contacting AWS Premium Support. I’m Pranitha from the EC2 Linux team and I will be assisting you with the case today.

I understand that you are unable to figure out the correct snapshot for the instance i-0cf7dc9918291c1b1 and require guidance on restoring the instance from the snapshot. Please correct me if I have misunderstood your concern.

Firstly, I looked up your account and as you mentioned I could see the below two snapshots in us-east-1 region:

1. snap-094c6b4b5c37228e8

2. snap-0ddc9e7371852d2fd

Furthermore, both the above snapshots were created from the same volume vol-069e47f515eeaea13. However, currently I see that the volume vol-069e47f515eeaea13 is unattached and is in available state. Upon checking the cloudtrail history, I was able to confirm that this volume was previously attached to the concerned instance i-0cf7dc9918291c1b1.

Hence, I can confirm that both the above snapshots belong to the instance i-0cf7dc9918291c1b1. Both the above snapshots were created around the same time with the most recent one being “snap-0ddc9e7371852d2fd” created on Mon Mar 15 2021 11:21:21 GMT+0530 (IST).

Therefore, you may launch a new EC2 instance from snapshot “snap-0ddc9e7371852d2fd” of the volume. For this you would need to first create an AMI from the snapshot and launch an instance from this AMI. Please refer to the below AWS documentation for steps to achieve the same: [+]https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/creating-an-ami-ebs.html#creating-launching-ami-from-snapshot

Alternatively, as the volume “vol-069e47f515eeaea13” is in available state, you may also opt to create a new EC2 instance and attach the volume to it as a secondary volume. [+]https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-attaching-volume.html

Either of these approaches would help you restore the data of the original instance on the newly launched instance.

I hope the above information helps. Incase you feel I have missed out on addressing your concern right, or if I can otherwise provide any additional assistance with regard to this matter, please do not hesitate to let me know, I’ll be happy to work ahead with you until everything is successfully addressed. Hope you have an amazing day ahead!

Last Updated on March 27, 2021 by Rajeev Bagra