EBS Volume আর Snapshot

এই লেসন শেষে তুমি যা পারবে

• block storage কী, আর EBS volume কেন একটা network disk যেটা একটাই Availability Zone-এ থাকে, তা বুঝিয়ে বলতে পারবে।
• একটা volume-এর পুরো জীবন ধরে হাঁটতে পারবে: create, attach, detach, stop/start, delete; আর snapshot দিয়ে সেটাকে অন্য AZ বা Region-এ নিতে পারবে।
• বিল কত আসবে আগেই বলতে পারবে: volume attach থাকুক বা না থাকুক, provisioned GiB-এর টাকা দিতে হয়; volume বড় করা যায় (Elastic Volumes), কিন্তু কখনো ছোট করা যায় না।
• delete on termination flag দিয়ে root আর data volume রাখা বা মোছা ঠিক করতে পারবে, আর “terminate করেছি, তবু বিল আসছে” সমস্যার কারণ ধরতে পারবে।
• incremental snapshot block ধরে ধরে কীভাবে কাজ করে, একটা snapshot মুছলে আসলে কী মোছে, আর consistent snapshot কীভাবে নিতে হয়, তা বোঝাতে পারবে।
• lazy loading, নিজে initialise করা, provisioned initialisation rate আর Fast Snapshot Restore (FSR)-এর মধ্যে ঠিকটা বেছে নিতে পারবে।
• Recycle Bin আর Snapshot Archive tier দিয়ে snapshot রক্ষা করতে আর খরচ কমাতে পারবে, আর Data Lifecycle Manager (DLM) বা AWS Backup দিয়ে পুরো কাজটা automate করতে পারবে।

#Instance-এর নিজের একটা disk লাগে কেন

একটা EC2 instance-এর CPU আছে, memory আছে, কিন্তু instance stop হলেই memory পুরো ফাঁকা হয়ে যায়। Operating system, তোমার application আর data রাখার জন্য এমন একটা জায়গা লাগে, যেটা জিনিস ধরে রাখে: একটা disk।

নিজের কম্পিউটারে এটা হলো C: drive, যেখানে Windows থাকে, আর D: drive, যেখানে গেম আর ফাইল থাকে। EC2-তে সাধারণ উত্তর হলো Amazon EBS volume (Elastic Block Store): একটা virtual hard disk, যেটা তুমি বানাও, instance-এ লাগাও, আর instance stop হলেও যার data মোছে না।

#Block, file আর object storage

AWS তিন রকম storage দেয়, আর পরীক্ষায় এগুলো আলাদা করে চিনতে হয়:

database আর boot disk-এর দরকার block device: operating system যেকোনো একটা block দ্রুত পড়তে পারে, বা সেই জায়গাতেই নতুন করে লিখতে পারে।

#EBS কেন network disk

তোমার instance যে physical host-এ চলে, EBS volume তার ভেতরে থাকে না। এটা থাকে একই Availability Zone-এর একঝাঁক storage server-এ, আর instance তার কাছে পৌঁছায় network দিয়ে। এই একটা সিদ্ধান্ত থেকেই EBS-এর প্রায় সব নিয়ম বেরিয়ে আসে:

• Persistent। instance stop হোক, অন্য host-এ সরুক বা নষ্ট হোক, data থেকে যায়, কারণ data কখনো ওই host-এ ছিলই না।
• খুলে নেওয়া যায়। কয়েক সেকেন্ডে volume detach করে আরেকটা instance-এ attach করা যায়।
• একটা AZ-এ আটকানো। storage server-গুলো একটা AZ-এ, তাই শুধু ওই AZ-এর instance-ই volume-টা ব্যবহার করতে পারে।
• একটু latency। প্রতিটা read আর write network পার হয়, তাই host-এর ভেতরে বসানো disk-এর চেয়ে latency সামান্য বেশি (ওই দ্রুত কিন্তু অস্থায়ী local disk হলো instance store, লেসন ৫.৩)।
• নিজের AZ-এর ভেতরে কপি রাখা। EBS নিজে থেকেই AZ-এর ভেতরে কয়েকটা server-এ তোমার volume-এর কপি রাখে, তাই একটা disk নষ্ট হলে data হারায় না। কিন্তু অন্য AZ-এ কপি রাখে না; সেটা তোমার কাজ, snapshot দিয়ে।

#একটা volume-এর জীবন

#Create, attach, ব্যবহার, detach, delete

সাধারণ ধাপগুলো:

1. Create

   একটা Availability Zone, GiB-এ size আর একটা volume type বেছে নাও (default gp3; type নিয়ে লেসন ৫.২)। খালি volume বানাতে পারো, অথবা snapshot থেকে restore করে বানাতে পারো।

2. Attach

   একই AZ-এর একটা instance-এ /dev/sdf-এর মতো একটা device name দিয়ে attach করো। Nitro instance-এ এটা NVMe device হিসেবে দেখা যায় (/dev/nvme1n1)। instance চলা অবস্থাতেই attach করা যায়।

3. Format আর mount (শুধু খালি volume-এ)

   খালি volume একটা কাঁচা disk। একবার file system বানাও (mkfs), mount করো, আর /etc/fstab-এ লিখে রাখো, যাতে reboot-এর পরেও mount হয়। snapshot থেকে বানানো volume-এ file system আগে থেকেই থাকে।

4. Detach

   আগে operating system-এর ভেতরে unmount করো, তারপর detach করো। লেখা চলাকালীন detach করলে file system নষ্ট হয়ে যেতে পারে। root volume detach করা যায় শুধু instance stop থাকলে।

5. Delete

   আর না লাগলে মুছে দাও। বিল বন্ধ হয় কেবল তখনই।

#কয়টা volume, কয়টা instance

• একটা instance-এ অনেকগুলো volume থাকতে পারে: একটা root volume আর কয়েকটা data volume, ঠিক C:, D:, E:-এর মতো। সর্বোচ্চ কয়টা, সেটা instance type-এর ওপর নির্ভর করে; অনেক Nitro type-এ network interface, EBS volume আর NVMe instance store মিলিয়ে মোট ২৮টা attachment-এর একটা ভাগাভাগি সীমা থাকে, আর নতুন কিছু type-এ EBS-এর জন্য আলাদা, আরও বড় সীমা আছে।
• একটা volume একবারে একটাই instance-এ attach হয়, এটাই default। in-use volume আরেকটা instance-এ লাগাতে গেলে ব্যর্থ হবে, কারণ দুটো operating system একটা সাধারণ file system-এ একসাথে লিখলে সেটা নষ্ট হয়ে যায়। ব্যতিক্রম হলো EBS Multi-Attach (শুধু io1/io2, একই AZ, cluster বোঝে এমন software), যেটা লেসন ৫.২-এ আছে। অনেকগুলো instance-এর যদি একই ফাইল লাগে, উত্তর হলো EFS (লেসন ৫.৪)।

#Stop, start আর reboot-এর পরেও থাকে

#একটা Availability Zone-এ আটকানো

us-east-1a-তে বানানো volume শুধু us-east-1a-এর instance-এই লাগানো যায়। “AZ বদলাও” বলে কোনো বোতাম নেই। অন্য AZ-এ data লাগলে যেতে হয় snapshot-এর পথ ধরে, কারণ snapshot পুরো Region-এর জন্য জমা থাকে:

1. volume-এর একটা snapshot নাও।
2. snapshot থেকে যে AZ-এ চাও সেখানে নতুন volume বানাও (চাইলে একই সাথে size বা type বদলাতে পারো)।
3. নতুন volume-টা সেখানে attach করো, কাজ শেষ হলে পুরনোটা মুছে দাও।

অন্য Region-এ নিতে হলে একটা ধাপ বেশি: snapshot-টা ওই Region-এ কপি করো, তারপর কপি থেকে volume বানাও।

#Capacity আর বিল

#যতটা provision করো, ততটার টাকা

volume বানানোর সময় তুমি তার size বেছে নাও (type অনুযায়ী ১ GiB থেকে ৬৪ TiB পর্যন্ত), আর কিছু type-এ IOPS আর throughput-ও। বিল হয় provisioned size ধরে, প্রতি GiB-month হিসেবে, যতদিন volume-টা আছে:

• ৫০০ GiB-এর volume-এ মাত্র ২০ GiB ফাইল থাকলেও খরচ ভরা volume-এর সমান।
• available অবস্থার volume, যেটা কোথাও লাগানো নেই, তারও বিল attach করা volume-এর মতোই।
• instance stop করলে compute-এর বিল থামে, storage-এর বিল থামে না।

যেমন us-east-1-এ gp3-এর দাম মোটামুটি প্রতি GiB-month $0.08; ভুলে পড়ে থাকা একটা ৫০০ GiB volume প্রতি মাসে প্রায় $40 খেয়ে যায়, কোনো কাজ ছাড়াই। একই data-র snapshot-এর খরচ প্রতি GiB-month প্রায় $0.05, তাও শুধু আসলে লেখা block-গুলোর। তাই পরে লাগতে পারে এমন data রেখে দেওয়ার চেনা উপায় হলো “আগে snapshot, তারপর delete”।

#Elastic Volumes দিয়ে volume বড় করা

Elastic Volumes দিয়ে তুমি একটা volume attach রেখে, ব্যবহার চলা অবস্থাতেই বদলাতে পারো: size বাড়ানো, type বদলানো (যেমন gp2 → gp3), বা IOPS আর throughput বদলানো।

• শুধু বাড়ানো যায়। volume কখনো ছোট করা যায় না। ছোট করতে চাইলে নতুন একটা ছোট volume বানাও, ফাইল ধরে ধরে data কপি করো, সেটায় চলে যাও, পুরনোটা মুছে দাও। snapshot থেকে ছোট volume-এ restore করলে হবে না: snapshot থেকে বানানো volume-কে snapshot-এর মূল volume-এর সমান বা তার চেয়ে বড় হতেই হবে।
• file system বাড়াও। volume বড় করার পরেও operating system পুরনো partition-ই দেখে। সেটা বাড়াতে হয় (growpart, তারপর ext4 হলে resize2fs, XFS হলে xfs_growfs; Windows-এ Disk Management)।
• State। একটা modification যায় modifying → optimizing → completed ধাপে। optimizing চলাকালীনই নতুন size ব্যবহার করা যায়।
• কতবার। জানুয়ারি ২০২৬ থেকে একটা volume যেকোনো ২৪ ঘণ্টায় সর্বোচ্চ ৪ বার modify করা যায়, প্রতিবার আগেরটা শেষ হওয়ার পর। (পুরনো বই-নোটে লেখা থাকে “দুটো modification-এর মাঝে ৬ ঘণ্টা অপেক্ষা”; সেই নিয়ম এখন ঢিলে করা হয়েছে।)

#Root আর বাড়তি volume: delete on termination

instance-এ লাগানো প্রতিটা volume-এর একটা flag আছে, DeleteOnTermination। instance terminate হলে (stop না) ওই volume-এর কী হবে, সেটা এই flag ঠিক করে।

launch-এর সময় শুরুর মানগুলো আসে AMI-এর block device mapping থেকে, আর তুমি সেগুলো বদলে দিতে পারো। পরে চালু instance-এও aws ec2 modify-instance-attribute দিয়ে flag বদলানো যায়। পরীক্ষার চেনা নিয়ম “root মোছে, বাড়তি volume থাকে” console-এর জন্য আর launch-এর পরে লাগানো volume-এর জন্য ঠিক; কিন্তু CLI-র run-instances দিয়ে যোগ করা data volume default-এ মুছে যায়, তাই launch-এর পর setting-টা একবার দেখে নিও।

এই default-গুলো থেকেই দুটো চেনা পরিস্থিতি আসে:

• “একজন admin EC2 instance terminate করেছে, তবু বিলে EBS-এর খরচ দেখাচ্ছে।” বাড়তি data volume-গুলোতে DeleteOnTermination = false ছিল, তাই সেগুলো available volume হয়ে টিকে গেছে, আর provisioned size ধরে বিল হচ্ছে। available অবস্থার volume খুঁজে বের করো, data লাগতে পারলে snapshot নাও, তারপর মুছে দাও।
• “instance terminate হওয়ার পরেও root volume রাখব কীভাবে?” root volume-এ DeleteOnTermination = false করে দাও, launch-এর সময় বা পরে modify-instance-attribute দিয়ে। terminate-এর পর root একটা available volume হয়ে থেকে যায়, যেটা আরেকটা instance-এ দ্বিতীয় disk হিসেবে লাগিয়ে পড়া যায়।

#Snapshot

#Snapshot কী

EBS snapshot হলো একটা volume-এর নির্দিষ্ট মুহূর্তের backup: snapshot শুরু করার মুহূর্তে প্রতিটা block যেমন ছিল, তার কপি।

• snapshot জমা থাকে Amazon S3-তে, AWS-এর নিজের সামলানো bucket-এ। S3 console-এ এগুলো দেখা যায় না, S3 API দিয়েও ধরা যায় না; কাজ করতে হয় EC2/EBS দিয়ে।
• snapshot-এর data Region-এর সব AZ-এ কপি করা থাকে, তাই এটা থেকে ওই Region-এর যেকোনো AZ-এ volume বানানো যায়।
• volume attach করা আর ব্যবহার চলা অবস্থাতেই snapshot নেওয়া যায়। EBS পেছনে data কপি করার সময় snapshot pending থাকে, আর এর মধ্যেও volume ব্যবহার করা যায়। শুধু snapshot শুরুর আগে লেখা data-টুকুই এতে থাকে।
• AWS নিজে থেকে কখনো snapshot নেয় না। EBS-এর backup নেওয়া তোমার দায়িত্ব, হাতে বা DLM / AWS Backup দিয়ে।

AMI-ও একই কৌশলে তৈরি: EBS-backed instance থেকে AMI বানালে তার প্রতিটা volume-এর একটা করে snapshot নেওয়া হয় (লেসন ৪.৩)।

#Incremental: শুধু বদলানো block জমা হয়

একটা volume-এর প্রথম snapshot লেখা থাকা সব block কপি করে। ওই volume-এর পরের প্রতিটা snapshot শুধু আগেরটার পর থেকে বদলানো block জমা রাখে, আর বাকিগুলোর জন্য পুরনো snapshot-এর দিকে ইশারা করে। তবু প্রতিটা snapshot একটা সম্পূর্ণ restore point: যেকোনো একটা থেকে restore করলে ওই মুহূর্তের পুরো volume পাওয়া যায়।

১০০ GiB-এর একটা database volume নিয়ে হিসাবটা করে দেখি (সব block-এ লেখা আছে):

তিনটা পূর্ণ restore point, খরচ ৩০০ GiB না, মাত্র ১০৩ GiB। আরেকটা কথা: প্রথম snapshot শুধু লেখা block-গুলোই রাখে। ১০০ GiB-এর volume-এ ৩০ GiB data থাকলে প্রথম snapshot হবে মোটামুটি ৩০ GiB, ১০০ GiB না।

#একটা snapshot মুছলে আসলে কী হয়

তুমি যেকোনো snapshot, যেকোনো ক্রমে মুছতে পারো, আর বাকি প্রতিটা snapshot থেকে restore ঠিকই হবে। EBS শুধু সেই data মোছে, যেটা আর কোনো snapshot-এর লাগে না:

• snapshot 2 মুছলে (মাঝেরটা): snapshot 3-এর এখনও সোমবারের X1 লাগে, তাই সেই ১ GiB থেকে যায়, আর এখন থেকে তার বিল snapshot 3-এর ঘাড়ে। সোমবারের X2 আর কারও লাগে না (মঙ্গলবার সেটা আবার বদলেছে), তাই সেই ১ GiB মুছে যায়। storage ১০৩ থেকে ১০২ GiB হয়, ১০১ না।
• snapshot 1 মুছলে (সবচেয়ে পুরনোটা): কখনো না বদলানো ৯৮ GiB-এর দিকে এখনও snapshot 2 আর 3 ইশারা করছে, তাই সেটা থাকে। মুছে যায় শুধু রবিবারের X1 আর X2 (২ GiB): ১০৩ → ১০১ GiB।

তাই একটা snapshot মোছা বাকিগুলোর জন্য সবসময় নিরাপদ, তবে যত টাকা বাঁচবে ভাবছ, তার চেয়ে কম বাঁচতে পারে।

#Consistent snapshot কীভাবে পাবে

ব্যবহার চলা volume-এর snapshot-এ থাকে ঠিক ওই মুহূর্তে disk-এ যা ছিল সেটুকু। যে লেখা তখনও application-এর memory বা operating system-এর cache-এ বসে আছে, সেটা বাদ পড়ে। ফলটা crash-consistent: হঠাৎ server-এর বিদ্যুৎ চলে গেলে যে অবস্থা হতো, সেটাই। এখনকার বেশিরভাগ database আর journaling file system এ থেকে সামলে উঠতে পারে, কিন্তু এটা পরিষ্কার backup না।

application-consistent snapshot চাইলে:

• snapshot শুরুর সময়টায় লেখা থামাও আর flush করো: database-কে backup mode-এ নাও বা তার table flush করো, Linux-এ fsfreeze চালাও বা Windows-এ VSS ব্যবহার করো, snapshot শুরু করো, তারপর আবার চালু করো। snapshot request ফেরত এলেই freeze তুলে দিতে পারো; completed পর্যন্ত বসে থাকতে হয় না।
• অথবা instance stop করো (root volume-এর জন্য এটাই সেরা), বা volume unmount করে detach করো, snapshot নাও, তারপর আবার লাগাও।
• একটা instance-এর কয়েকটা volume হলে (যেমন data আর log আলাদা volume-এ), multi-volume snapshot নাও: একটা request-এই সবগুলোর snapshot একই মুহূর্তে হয়, সব volume জুড়ে crash-consistent।
• DLM প্রতিটা নির্ধারিত snapshot-এর আগে-পরে instance-এ pre আর post script চালাতে পারে (Systems Manager দিয়ে), যেগুলো application freeze করে আবার ছেড়ে দেয়।

snapshot নিলে কি volume ধীর হয়ে যায়? snapshot যতক্ষণ pending থাকে, volume পুরোপুরি ব্যবহার করা যায়। SSD volume-এর একটা snapshot-এ গতি কমে, এমন কিছু AWS বলে না। তবে দুটো ক্ষেত্রে I/O-র ওপর চাপ পড়ে: একই volume-এর কয়েকটা snapshot একসাথে pending থাকলে সেগুলো শেষ না হওয়া পর্যন্ত volume-এর performance কমে যেতে পারে, আর st1 বা sc1 volume-এ snapshot চলার সময় throughput baseline-এ নেমে যেতে পারে। এ কারণেই course-এর slide বলে, application-এ যখন খুব traffic, তখন backup নিও না। DLM-এর snapshot কম ব্যস্ত সময়ে রাখো, আর একটার ঘাড়ে আরেকটা চাপিও না।

#Snapshot কপি আর share করা

• copy-snapshot দিয়ে অন্য Region-এ কপি করো: কপিটা ওই Region-এ একটা নতুন, আলাদা snapshot, যেটা থেকে সেখানকার যেকোনো AZ-এ volume বানানো যায়। cross-Region disaster recovery আর এক Region থেকে আরেক Region-এ workload সরানো, দুটোরই মূল এটা। কপি করার সময় encryption setting-ও বদলানো যায় (লেসন ৫.২)।
• নির্দিষ্ট AWS account-এর সাথে snapshot share করা যায়, বা public করা যায় (account-এর “block public access for snapshots” setting default-এ এটা আটকে রাখে)। encrypted snapshot-এ KMS key নিয়ে বাড়তি নিয়ম আছে, সেটা লেসন ৫.২-এ।
• Snapshot lock (governance বা compliance mode) একটা নির্দিষ্ট সময় পর্যন্ত snapshot মোছা একদম অসম্ভব করে দিতে পারে, নিয়ন্ত্রক সংস্থার WORM ধাঁচের retention-এর জন্য।

#Restore: lazy loading আর তা এড়ানোর উপায়

#Initialisation penalty

snapshot থেকে volume বানালে কয়েক সেকেন্ডেই সেটা available হয়ে যায়, শত শত GiB কপি হওয়ার অনেক আগেই। EBS এটা করে lazy loading দিয়ে: block-গুলো S3-তেই থাকে, আর প্রতিটা block নামানো হয় যখন সেটা প্রথমবার পড়া হয়। এর পাশাপাশি EBS পেছনে বাকিগুলোও নামাতে থাকে।

ফলে প্রতিটা block-এর প্রথম read ধীর (latency বেশি, IOPS কম), আর একই block দ্বিতীয়বার পড়লে দ্রুত। boot disk-এর জন্য এতে তেমন কিছু যায় আসে না; কিন্তু রাত ৩টায় restore করা production database-এর জন্য এর মানে প্রথম এক ঘণ্টা ধীর আর অনিশ্চিত। একদম নতুন খালি volume-এ এই সমস্যা নেই: শুরু থেকেই পূর্ণ গতি।

তোমার হাতে চারটা পথ:

#Fast Snapshot Restore খুঁটিয়ে

• FSR চালু করতে হয় প্রতি snapshot, প্রতি Availability Zone ধরে। চালু থাকা AZ-এ ওই snapshot থেকে বানানো volume তৈরির সময়েই পুরো initialised; অন্য যেকোনো AZ-এ সেটা আগের মতোই lazy loading।
• চালু করার পর snapshot যায় enabling → optimizing → enabled ধাপে। optimizing-এ মোটামুটি প্রতি TiB-এ ৬০ মিনিট লাগে।
• Volume creation credit ঠিক করে একসাথে কতগুলো পুরো initialised volume বানানো যাবে: প্রতি snapshot প্রতি AZ-এ একটা bucket, যেখানে সর্বোচ্চ ১০টা credit থাকে (বড় snapshot-এ আরও কম: ১০২৪ ÷ GiB-এ snapshot-এর size, তবে কমপক্ষে ১)। ১২৮ GiB-এর snapshot পায় ৮টা credit; ৫১২ GiB-এর snapshot মাত্র ২টা। bucket খালি হলে আবার না ভরা পর্যন্ত নতুন volume FSR ছাড়াই তৈরি হয়।
• সীমা: default-এ প্রতি Region-এ সর্বোচ্চ ৫টা snapshot-এ FSR, আর snapshot হতে হবে ১৬ TiB বা তার কম। যত ঘণ্টা চালু থাকে (কমপক্ষে এক ঘণ্টা), তত ঘণ্টার বিল, একটাও volume না বানালেও: ৩০ দিনের জন্য ৩টা AZ-এ ২টা snapshot, $0.75 হারে, মানে $3,240।
• volume আসলেই FSR পেল কি না, তা বোঝা যায় তার fastRestored field দেখে।

#Snapshot রক্ষা করা আর খরচ কমানো

#EBS Snapshot Archive

snapshot সাধারণত থাকে standard tier-এ। archive tier সেই snapshot-গুলোর জন্য, যেগুলো মাসের পর মাস বা বছরের পর বছর রাখতে হয়, কিন্তু restore প্রায় কখনোই লাগে না: project শেষের snapshot, মাসিক বা বাৎসরিক compliance snapshot।

• storage সর্বোচ্চ ৭৫% সস্তা (us-east-1-এ প্রতি GB-month $0.05-এর বদলে প্রায় $0.0125), সাথে restore করলে প্রতি GB-এ একটা retrieval খরচ।
• archive করা snapshot একটা full snapshot-এ (সব block সহ) রূপান্তরিত হয়, তাই যে incremental snapshot থেকে এসেছে, তার চেয়ে বড় হতে পারে। এজন্য একটা volume-এর রোজকার incremental snapshot archive করলে খরচ উল্টো বাড়তে পারে; archive করো মাসিক বা বাৎসরিক snapshot।
• কমপক্ষে ৯০ দিন। তার আগে মুছলে বা স্থায়ীভাবে restore করলে ৯০ দিনের বাকি সময়ের টাকাও দিতে হয়।
• Restore-এ ৭২ ঘণ্টা পর্যন্ত লাগে (অনেকে বলে ২৪ থেকে ৭২ ঘণ্টা), standard tier-এ, কয়েক দিনের জন্য temporary বা স্থায়ীভাবে।
• archived থাকা অবস্থায় এটা থেকে volume বানানো, কপি করা, share করা বা FSR চালু করা যায় না। আগে restore করতে হবে।

#Recycle Bin

Recycle Bin মুছে ফেলা EBS snapshot, EBS-backed AMI আর EBS volume ধরে রাখে, যাতে ভুল করে বা খারাপ উদ্দেশ্যে মোছা জিনিস ফেরত আনা যায়।

• প্রতি Region-এ retention rule বানাতে হয়: tag-level (নির্দিষ্ট tag থাকা resource রক্ষা করে) বা Region-level (ওই Region-এ ওই ধরনের সব resource রক্ষা করে, চাইলে exclusion tag দিয়ে কিছু বাদ দিয়ে)।
• কতদিন রাখা যায়: snapshot আর AMI ১ থেকে ৩৬৫ দিন, volume ১ থেকে ৭ দিন।
• rule-এর সাথে মেলে এমন resource মুছলে সেটা হারিয়ে না গিয়ে Recycle Bin-এ যায়। retention-এর মধ্যে যেকোনো সময় একই ID সহ restore করা যায়। সময় পেরোলে চিরতরে মুছে যায়।
• feature-টার নিজের কোনো খরচ নেই; bin-এ থাকা snapshot-এর বিল হয় তার সাধারণ snapshot (বা archive) হারে।
• Rule lock: একটা Region-level rule (exclusion tag ছাড়া) lock করা যায়, সাথে ৭ থেকে ৩০ দিনের unlock delay। lock করা rule বদলানো বা মোছা যায় না, admin-ও পারে না; unlock করার পরেও delay শেষ না হওয়া পর্যন্ত rule চালু থাকে। চুরি যাওয়া credential বা ransomware যদি আগে নিরাপত্তার জালটাই সরাতে চায়, এটা তাদের আটকায়।

#Backup automate করা

#Amazon Data Lifecycle Manager

Amazon Data Lifecycle Manager (DLM) নির্দিষ্ট সময় পরপর EBS snapshot (আর EBS-backed AMI) বানায়, রাখে, কপি করে আর মোছে, কোনো বাড়তি খরচ ছাড়াই:

• একটা policy tag দেখে volume বা instance বেছে নেয় (যেমন backup=daily)। instance বেছে নিলে পাওয়া যায় multi-volume, crash-consistent snapshot set।
• একটা policy-তে সর্বোচ্চ ৪টা schedule (দৈনিক, সাপ্তাহিক, মাসিক, বাৎসরিক বা cron expression)।
• Retention সংখ্যা দিয়ে (শেষ ১ থেকে ১,০০০টা রাখো) বা বয়স দিয়ে; সবচেয়ে পুরনোটা আপনা-আপনি মুছে যায়।
• প্রতিটা schedule snapshot সর্বোচ্চ ৩টা অন্য Region-এ কপি করতে পারে, অন্য account-এর সাথে share করতে পারে, FSR চালু করতে পারে, আর snapshot archive করতে পারে (মাসিক বা তার চেয়ে লম্বা schedule-এ)।
• application-consistent snapshot-এর জন্য pre আর post script।
• DLM শুধু নিজের বানানো snapshot-গুলোই সামলায়।

#AWS Backup

AWS Backup হলো অনেক service জুড়ে কাজ করার উপায়: EBS, EC2, RDS, Aurora, DynamoDB, EFS, FSx, S3 আর আরও অনেক কিছুর জন্য একটাই backup plan আর একটাই console, সাথে backup vault, cross-account আর cross-Region কপি, audit report আর Vault Lock।

#কোথায় গোলমাল হয়

#System design-এ EBS আর snapshot

• storage আর compute আলাদা রাখো। data EBS-এ রাখলে instance বদলানো যায় (নতুন type, নষ্ট host), আর volume আবার লাগিয়ে দেওয়া যায়। এই কারণেই “stop-এর পরেও data রাখো” আর “instance-এর মধ্যে volume সরাও”-এর উত্তর EBS, instance store না।
• Backup আর RPO। কত ঘন ঘন snapshot নিচ্ছ, সেটাই ঠিক করে recovery point objective (RPO): প্রতি ৪ ঘণ্টায় snapshot মানে সর্বোচ্চ ৪ ঘণ্টার data হারানো। এর চেয়ে কম RPO লাগলে শুধু snapshot-এ হবে না, database-এর নিজের replication লাগবে।
• AZ নষ্ট হলে। volume তার AZ-এর সাথেই মরে। snapshot পুরো Region-এর, তাই অন্য AZ-এ আবার গড়ে তোলা যায়; দ্রুত ফিরতে চাইলে দ্বিতীয় AZ-এ একটা replica চালিয়ে রাখো।
• Region নষ্ট হলে, DR। snapshot দ্বিতীয় একটা Region-এ কপি করে রাখো (DLM নিজেই করে দেয়); সেখানে FSR চালু রেখে restore করলে recovery-র সময় (RTO) কমে।
• দ্রুত scale-out। data একটা snapshot বা AMI-তে ভরে রাখো, তা থেকে অনেকগুলো instance চালু করো; FSR থাকলে নতুন volume প্রথম সেকেন্ড থেকেই দ্রুত।
• Test-এর জন্য clone। গত রাতের production snapshot restore করো (বা একই AZ-এ copy-volumes ব্যবহার করো), production না ছুঁয়েই tester-রা আসল data পাবে।
• খরচের পরিচ্ছন্নতা। volume-এ tag দাও, available volume দেখলেই alert, standard tier-এ retention ছোট রাখো আর লম্বা সময়ের snapshot archive করো।

#নিজে করে দেখো

# 1. Create a 10 GiB gp3 volume in the instance's AZ, attach it, check the state
VOL=$(aws ec2 create-volume --availability-zone us-east-1a --size 10 --volume-type gp3 \
  --tag-specifications 'ResourceType=volume,Tags=[{Key=backup,Value=daily}]' \
  --query VolumeId --output text)
aws ec2 wait volume-available --volume-ids $VOL
aws ec2 attach-volume --volume-id $VOL --instance-id $ID --device /dev/sdf
aws ec2 describe-volumes --volume-ids $VOL --query "Volumes[0].[State,AvailabilityZone,Attachments[0].DeleteOnTermination]"

# 2. On the instance: format and mount the empty volume (Nitro shows it as NVMe)
lsblk
sudo mkfs -t xfs /dev/nvme1n1
sudo mkdir /data && sudo mount /dev/nvme1n1 /data

# 3. Keep the root volume after termination (change the flag on a running instance)
aws ec2 modify-instance-attribute --instance-id $ID \
  --block-device-mappings '[{"DeviceName":"/dev/xvda","Ebs":{"DeleteOnTermination":false}}]'

# 4. Grow the volume to 20 GiB while it is in use, then extend the file system
aws ec2 modify-volume --volume-id $VOL --size 20
aws ec2 describe-volumes-modifications --volume-ids $VOL --query "VolumesModifications[0].ModificationState"
sudo xfs_growfs -d /data

# 5. Snapshot (freeze writes for consistency), then move the data to us-east-1b
sudo fsfreeze -f /data
SNAP=$(aws ec2 create-snapshot --volume-id $VOL --description "data before move" \
  --query SnapshotId --output text)
sudo fsfreeze -u /data
aws ec2 wait snapshot-completed --snapshot-ids $SNAP
aws ec2 create-volume --snapshot-id $SNAP --availability-zone us-east-1b --volume-type gp3

# 6. Copy the snapshot to another Region for disaster recovery
aws ec2 copy-snapshot --region eu-west-1 --source-region us-east-1 \
  --source-snapshot-id $SNAP --description "DR copy"

# 7. Fast Snapshot Restore in one AZ, then check it (and remember to disable it: it bills hourly)
aws ec2 enable-fast-snapshot-restores --availability-zones us-east-1a --source-snapshot-ids $SNAP
aws ec2 describe-fast-snapshot-restores --filters Name=snapshot-id,Values=$SNAP
aws ec2 disable-fast-snapshot-restores --availability-zones us-east-1a --source-snapshot-ids $SNAP

# 8. Or initialise a restored volume yourself by reading every block once
sudo fio --filename=/dev/nvme2n1 --rw=read --bs=1M --iodepth=32 \
  --ioengine=libaio --direct=1 --name=volume-initialize

# 9. Archive a snapshot, and later restore it for 7 days
aws ec2 modify-snapshot-tier --snapshot-id $SNAP --storage-tier archive
aws ec2 restore-snapshot-tier --snapshot-id $SNAP --temporary-restore-days 7

# 10. Recycle Bin: keep deleted snapshots for 14 days, delete one, get it back
aws rbin create-rule --resource-type EBS_SNAPSHOT \
  --retention-period RetentionPeriodValue=14,RetentionPeriodUnit=DAYS
aws ec2 delete-snapshot --snapshot-id $SNAP
aws ec2 list-snapshots-in-recycle-bin
aws ec2 restore-snapshot-from-recycle-bin --snapshot-id $SNAP

# 11. Find orphaned volumes that are billed but attached to nothing
aws ec2 describe-volumes --filters Name=status,Values=available \
  --query "Volumes[].[VolumeId,Size,CreateTime]" --output table

#সারসংক্ষেপ

মূল কথাগুলো

• EBS হলো network দিয়ে লাগানো block storage: একটা virtual disk, যেটা stop, start আর reboot-এর পরেও থাকে, আর খুলে আবার লাগানো যায়। মাথায় রাখো “network-এর পেনড্রাইভ”।
• volume থাকে একটা AZ-এ, আর শুধু সেই AZ-এর instance-এই লাগে। সরাতে হলে: snapshot → নতুন AZ-এ volume বানাও; অন্য Region হলে: snapshot → কপি → volume বানাও।
• default-এ একটা volume ↔ একটা instance, কিন্তু একটা instance ↔ অনেক volume। Multi-Attach (io1/io2) লেসন ৫.২-এ।
• volume যতদিন আছে, attach থাকুক বা না থাকুক, provisioned GiB-এর টাকা দিতে হয়। Elastic Volumes দিয়ে চালু অবস্থাতেই size বাড়ানো আর type/IOPS বদলানো যায়, ২৪ ঘণ্টায় ৪ বার পর্যন্ত; volume কখনো ছোট হয় না, আর file system নিজে বাড়াতে হয়।
• Delete on termination: default-এ root true, বাড়তি volume false; launch-এ বা চালু instance-এ বদলানো যায়। টিকে থাকা volume টাকা খেতেই থাকে।
• Snapshot নির্দিষ্ট মুহূর্তের, জমা থাকে চোখের আড়ালের S3-তে, Region-এর যেকোনো AZ-এ কাজে লাগে, incremental, আর প্রতিটা একটা সম্পূর্ণ restore point। যেকোনো snapshot মোছা বাকিগুলোর জন্য নিরাপদ; শুধু কারও কাজে না লাগা block মোছে।
• ব্যবহার চলা volume-এর snapshot crash-consistent; application consistency চাইলে freeze/flush, stop বা detach।
• restore করা volume lazy loading করে: সমাধান FSR (প্রতি snapshot প্রতি AZ, ঘণ্টা ধরে খরচ, credit), fio/dd দিয়ে initialise, বা provisioned initialisation rate।
• Snapshot Archive: সর্বোচ্চ ৭৫% সস্তা, full snapshot, কমপক্ষে ৯০ দিন, restore-এ ৭২ ঘণ্টা পর্যন্ত। Recycle Bin: মোছা snapshot (১–৩৬৫ দিন) আর volume (১–৭ দিন) ফেরত আনো; Region-level rule lock করো (৭–৩০ দিনের unlock delay)।
• automate করো DLM (EBS, tag, schedule, retention, cross-Region কপি, archive) বা AWS Backup (অনেক service, কেন্দ্রীয় policy) দিয়ে।

নিজেকে যাচাই করো: EBS volume আর snapshot৩০টি প্রশ্ন