Elastic Disaster Recovery, AWS Backup আর Vault Lock

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

• AWS Elastic Disaster Recovery (DRS) কীভাবে অফিসের, অন্য cloud-এর বা অন্য AWS Region-এর server রক্ষা করে, বুঝিয়ে বলতে: replication agent, সারাক্ষণ চলা block-level replication, কম খরচের staging area, point-in-time snapshot, drill, recovery আর failback।
• DRS আসলে কতটা দেয় (RPO কয়েক সেকেন্ড, RTO কয়েক মিনিট, সাধারণত ৫ থেকে ২০), RPO কেন বেড়ে যায়, আর DRS কেন disaster recovery-র জন্য আর MGN কেন migration-এর জন্য, তা বলতে।
• একটা AWS Backup plan বানাতে: কত ঘন ঘন, কোন সময়ে, কত দিন রাখা, cold storage আর তার ৯০ দিনের নিয়ম, point-in-time restore-এর জন্য continuous backup, tag দিয়ে resource বাছাই, vault, অন্য Region আর অন্য account-এ কপি।
• পুরো organization জুড়ে কাজ করা অংশগুলো ব্যবহার করতে: AWS Organizations-এর backup policy, Backup Audit Manager আর restore testing।
• Vault Lock-এর governance mode আর compliance mode আলাদা করতে, কমপক্ষে ৭২ ঘণ্টার grace time বুঝিয়ে বলতে, আর কে কখন কী মুছতে পারবে আগে থেকেই বলে দিতে।
• পরীক্ষার কোনো ঘটনায় ঠিক tool বেছে নিতে: DRS, AWS Backup, Vault Lock, logically air-gapped vault, DLM, নাকি RDS আর S3-এর নিজস্ব backup।

#তিনটা আলাদা কাজ

লেসন ২৩.১-এ তুমি RPO (কতটা ডেটা হারানো চলবে) আর RTO (কতক্ষণ বন্ধ থাকা চলবে) আর চারটা DR কৌশল দেখেছ। এই লেসনে AWS-এর এমন তিনটা tool, যেগুলো লোকে প্রায়ই গুলিয়ে ফেলে, কারণ প্রত্যেকটা আলাদা একটা প্রশ্নের উত্তর দেয়:

DRS-এর কাজ ছোট RTO আর RPO। AWS Backup-এর কাজ ইতিহাস আর নিয়ম মানা। Vault Lock-এর কাজ ভরসা। একটা ভালো design-এ তিনটাই থাকে।

#AWS Elastic Disaster Recovery

#DRS জিনিসটা কী

AWS Elastic Disaster Recovery (DRS) হলো server-কে AWS-এ ফিরিয়ে আনার জন্য AWS-এর নিজস্ব service। এটা CloudEndure Disaster Recovery-র উত্তরসূরি: AWS ২০১৯ সালে CloudEndure কিনে নেয়, আর ২০২১ সালে নতুন করে DRS নামে চালু করে। তাই পুরোনো প্রশ্নে আর slide-এ এখনো পুরোনো নামটা দেখবে।

এটা রক্ষা করে:

• নিজের data centre বা server room-এর physical server।
• VMware vSphere বা Microsoft Hyper-V-তে চলা virtual machine।
• অন্য cloud-এর server (Azure, Google Cloud ইত্যাদি)।
• অন্য Availability Zone বা অন্য AWS Region-এর EC2 instance।

সাধারণত যা রক্ষা করা হয়: নিজে চালানো server-এ থাকা গুরুত্বপূর্ণ database (Oracle, SQL Server, MySQL), SAP-এর মতো বড় enterprise application, file server, আর এমন সব ব্যবসার app যাদের নিজের কোনো replication নেই। এটা পুরো disk কপি করে, তাই disk-এর ওপর কী চলছে তাতে তার কিছু যায় আসে না।

#কীভাবে কাজ করে

1. ১. Agent বসাও

   প্রতিটা source server-এ AWS Replication Agent বসাও। Reboot লাগে না, server-এর কাজ চলতেই থাকে। Agent server-টাকে তোমার AWS account-এর DRS-এ নিবন্ধন করে দেয়।

2. ২. Initial sync

   Agent প্রতিটা disk-এর প্রতিটা block পড়ে TCP দিয়ে (পথে encrypt করা অবস্থায়) তোমার বেছে দেওয়া staging area subnet-এর replication server-এ পাঠায়। তারা block-গুলো একই সাইজের EBS staging volume-এ লেখে। ধীর লাইনে ২ TB-র একটা disk কপি হতে কয়েক দিন লাগতে পারে, তাই দরকারের অনেক আগেই শুরু করতে হয়।

3. ৩. সারাক্ষণ block-level replication

   এরপর থেকে source যে block-ই লেখে, সাথে সাথে কপি হয়ে যায়। Block level মানে file আর database-এর নিচের স্তর: যেকোনো application-এর জন্য কাজ করে, আর কপিটা crash-consistent (হঠাৎ বিদ্যুতের তার টেনে খুলে ফেলার মতো: disk-এ যা ছিল তা আছে, শুধু memory-তে যা ছিল তা নেই)।

4. ৪. Point-in-time snapshot

   DRS একটা নির্দিষ্ট নিয়মে staging volume থেকে EBS snapshot বানায়: default হিসেবে শেষ এক ঘণ্টায় প্রতি ১০ মিনিটে একটা, শেষ ২৪ ঘণ্টায় প্রতি ঘণ্টায় একটা, আর শেষ ৭ দিনে প্রতিদিন একটা। বদলানো যায় শুধু daily-গুলোর retention, ১ থেকে ৩৬৫ দিন।

5. ৫. Drill বা recovery

   Drill যেকোনো point in time থেকে পরীক্ষার কপি চালু করে, replication চলতেই থাকে। Recovery চালু করে আসল জিনিস: DRS volume-গুলোকে এমনভাবে convert করে যাতে EC2-তে নিজে থেকে boot হয়, আর তোমার launch settings (instance type, subnet, security group, IP) অনুযায়ী পুরো সাইজের recovery instance চালু করে।

6. ৬. Failback

   আসল জায়গা ঠিক হয়ে গেলে DRS recovery instance-কে উল্টো দিকে replicate করে (অফিসের জন্য DRS Failback Client দিয়ে, EC2 source হলে আসল Region-এ), আর একটা পরিকল্পিত সময়ে তুমি নিজের জায়গায় ফিরে যাও।

#খরচ কম কেন: staging area

Notes-এ যে খরচের কথাটা নেই: staging area-তে পুরো সাইজের কোনো server চলে না। তুমি টাকা দাও:

• DRS fee-র জন্য: প্রতি source server-এ ঘণ্টায় ০.০২৮ USD (মাসে প্রায় ২০ USD), সব Region-এ একই। এর মধ্যেই replication, drill, recovery launch আর point-in-time recovery ধরা।
• Replication server-এর জন্য: ছোট instance (default t3.small), প্রতিটা ১৫টা পর্যন্ত source disk সামলায়। DRS নিজেই এগুলো চালু-বন্ধ করে।
• EBS staging volume (প্রতিটা source disk-এর জন্য একটা, একই সাইজ, সাধারণত সস্তা type) আর point in time-এর EBS snapshot-এর জন্য।
• পুরো EC2 আর EBS-এর জন্য শুধু drill আর recovery instance চলার সময়টুকুতে।

হিসাব করে দেখি। Hospital-এর ২০টা server-এ DRS fee মাসে মোটামুটি ২০ × ২০ = ৪০০ USD, সাথে দুটো t3.small replication server আর প্রায় ৬ TB-র কম খরচের staging volume আর snapshot। পুরো সাইজের server warm standby হিসেবে সারাক্ষণ চালু রাখলে মাসে কয়েক হাজার ডলার লাগত; DRS-এ বন্যার দিন পর্যন্ত সেগুলোর খরচ শূন্য। লেসন ২৩.১-এর ভাষায়, DRS প্রায় pilot light-এর দামে প্রায় warm standby-র মতো দ্রুত recovery দেয়।

#সংখ্যায় RPO আর RTO

• RPO: কয়েক সেকেন্ড। AWS বলে crash-consistent RPO সেকেন্ডের ঘরে (তাদের user guide-এ এমনকি “typically sub-second” কথাটাও আছে)। মাপা হয় এভাবে: staging area-তে নিরাপদে পৌঁছানো সবচেয়ে নতুন block-টা কতটা পুরোনো।
• RTO: কয়েক মিনিট, সাধারণত ৫ থেকে ২০। বেশিরভাগটাই boot হওয়ার সময়: গড়ে recover করা Linux server ৫ মিনিটের মতো, Windows ২০ মিনিটের মতো সময়ে boot হয়। বড় instance type আর দ্রুত volume দিলে তাড়াতাড়ি boot হয়।
• RPO কোনো প্রতিশ্রুতি না। এটা টেকে যতক্ষণ বাইরে যাওয়ার লাইন, AWS-এ ঢোকার পথ আর staging area লেখার গতির সাথে তাল রাখতে পারে। ১০টা server প্রত্যেকে সেকেন্ডে ১০ MB লিখলে সেকেন্ডে প্রায় ১০০ MB upload bandwidth লাগবে। হঠাৎ চাপ বাড়লে জমে থাকা ডেটা বাড়ে, সাথে RPO-ও, আর replication ধরে ফেললে আবার সেকেন্ডে নেমে আসে।
• Memory replicate হয় না। Application যে ডেটা শুধু RAM-এ রেখেছে, বিদ্যুৎ চলে যাওয়ার মতোই সেটা হারায়।

#Point in time আর ransomware

Replication খুব বিশ্বস্ত: ransomware যখন একটা disk encrypt করে, DRS কয়েক সেকেন্ডের মধ্যে সেই encrypt করা block-গুলোও replicate করে ফেলে। সবশেষ ডেটা তখন অকেজো। বাঁচায় point-in-time snapshot: তুমি আক্রমণের আগে নেওয়া একটা snapshot থেকে recovery launch করো।

দুটো ফাঁদ:

• কোনো point না বেছে recovery শুরু করলে সবশেষ ডেটা নেওয়া হয় (DRS আগে একটা নতুন snapshot-ও নিয়ে নেয়)। বন্যার পরে সেটাই ঠিক; ransomware-এর পরে সেটা encrypt করা file-গুলোই ফিরিয়ে আনে।
• Default retention ছোট। Daily point থাকে ৭ দিন। এর চেয়ে বেশি দিন লুকিয়ে থাকা ransomware DRS-এ কোনো পরিষ্কার point রাখে না। Daily retention বাড়াও (৩৬৫ দিন পর্যন্ত, EBS খরচ বাড়বে), আর সবচেয়ে জরুরি, দীর্ঘ মেয়াদের backup রাখো AWS Backup-এ Vault Lock সহ, এই লেসনের পরের অংশে যেমন আছে।

#Drill, recovery আর failback-এর খুঁটিনাটি

• Drill কিছু থামায় না। Replication থামে না, ধীরও হয় না, তাই RPO-তে প্রভাব নেই। Drill চালাও আলাদা একটা test VPC বা subnet-এ, যাতে তার কপিগুলো কখনো production-এর সাথে কথা না বলে। শেষে terminate করো; পুরো EC2-র দাম লাগে শুধু যতক্ষণ চলে।
• Launch settings-ই RTO ঠিক করে। Instance type ঠিক সাইজের রাখো, subnet, security group আর private IP বেছে রাখো, আর হালনাগাদ রাখো। দুর্যোগের দিন ভুল subnet ধরা পড়লে boot-এর চেয়ে বেশি সময় নষ্ট হয়।
• Recovery “most recent data” বা যেকোনো point in time থেকে হতে পারে। কয়েকটা server একসাথে একই point in time থেকে launch করা যায়, যাতে কয়েক স্তরের application একটা মিল থাকা অবস্থায় ফিরে আসে।
• Failback দিক উল্টে দেয়: recovery instance আসল server (বা Region)-এ replicate করে, তারপর পরিকল্পিত সময়ে cutover, আর স্বাভাবিক দিকে replication আবার শুরু।

#DRS, MGN, AWS Backup নাকি pilot light?

#AWS Backup

#কেন্দ্রীয় একটা backup service কেন দরকার

AWS Backup আসার আগে প্রতিটা service-এর নিজের backup ব্যবস্থা ছিল: EBS snapshot আর DLM (লেসন ৫.১), RDS-এর automated backup আর manual snapshot (লেসন ৭.২), DynamoDB-র on-demand backup, EFS-এর নিজের backup, FSx-এর backup। প্রত্যেকটার আলাদা schedule, আলাদা retention, আলাদা console, আর সাধারণত সেগুলো জোড়া লাগাতে কয়েকটা script। ৩০টা account-এর একটা কোম্পানিতে মানে শত শত setting, যেগুলো কেউ audit করতে পারে না।

AWS Backup হলো একটা fully managed, কেন্দ্রীয় service, যেটা এক জায়গা থেকে অনেক AWS service-এর backup স্বয়ংক্রিয়ভাবে চালায় আর সামলায়: একটাই policy-র ভাষা, কোনো custom script নেই, আর auditor-এর জন্য একটাই report।

#কোন কোন resource সমর্থিত

তালিকাটা প্রতি বছর বড় হয়। ২০২৬ সালে AWS Backup সমর্থন করে:

প্রতিটা feature প্রতিটা resource-এ চলে না: cold storage, continuous backup, cross-account copy আর restore testing-এর প্রত্যেকটার আলাদা সমর্থন-তালিকা AWS documentation-এ আছে। Slide-এ ছোট, পুরোনো একটা তালিকা আছে; পরীক্ষা সাধারণগুলোই ব্যবহার করে: EC2, EBS, S3, RDS, Aurora, DynamoDB, DocumentDB, Neptune, EFS, FSx আর Storage Gateway।

#Backup plan

Backup plan হলো নিয়মের বই। এতে এক বা একাধিক backup rule থাকে; প্রতিটা rule ঠিক করে:

• কত ঘন ঘন: প্রতি ঘণ্টায়, প্রতি ১২ ঘণ্টায়, রোজ, সাপ্তাহিক, মাসিক, বা একটা cron expression (snapshot backup সবচেয়ে ঘন হলে ঘণ্টায় একবার)।
• Backup window: job কখন শুরু হতে পারবে (console-এর default ০০:৩০, ৮ ঘণ্টার মধ্যে শুরু, ৭ দিনের মধ্যে শেষ)। Database service তাদের maintenance window চলার সময় বা ঠিক আগে backup শুরু করতে পারে না।
• Lifecycle: কবে cold storage-এ সরবে (কখনো না, বা N দিন পরে) আর কবে মুছবে (মোট retention, ১ দিন থেকে ১০০ বছর, বা চিরকাল)।
• Target vault: recovery point কোথায় জমা হবে।
• Copy action: প্রতিটা recovery point অন্য Region আর/বা অন্য account-এ কপি করা, নিজের lifecycle সহ।
• Continuous backup: একটা checkbox, যেটা সমর্থিত service-এ point-in-time restore-এর জন্য সারাক্ষণ পরিবর্তনের log রাখে।

Backup on demand-ও চালানো যায়, আর একটা plan-এ কয়েকটা rule থাকতে পারে, যেমন রোজের backup ৩৫ দিন আর মাসিক backup ১ বছর। দুটো rule একই window-তে পড়লে AWS Backup বেশি retention-ওয়ালাটা রাখে।

#Resource বাছাই: tag বা ID দিয়ে

Plan resource রক্ষা করে একটা resource assignment (backup selection) দিয়ে: tag দিয়ে (যেমন backup=daily tag থাকা সব resource, service যা-ই হোক), resource type দিয়ে, বা নির্দিষ্ট ARN দিয়ে, দরকারে কিছু বাদ দিয়ে। Tag সবচেয়ে ভালোভাবে বড় হয়: ঠিক tag দেওয়া নতুন database প্রথম রাত থেকেই সুরক্ষিত। উল্টো দিকটা: tag ছাড়া resource চুপচাপ বাদ পড়ে যায়।

#Backup vault

Backup vault হলো সেই পাত্র, যেখানে recovery point জমা থাকে:

• প্রতিটা vault-এর একটা KMS key থাকে (লেসন ২১.২), যেটা দিয়ে সেইসব service-এর backup encrypt হয় যেগুলো AWS Backup পুরোপুরি নিজে সামলায় (যেমন EFS, advanced features চালু DynamoDB, S3, Timestream, VMware)। বাকি service-এ (EBS, RDS, Aurora ইত্যাদি) backup source resource-এর encryption-ই ধরে রাখে।
• প্রতিটা vault-এ একটা vault access policy থাকতে পারে: একটা resource-based policy, যেমন break-glass role ছাড়া সবার জন্য recovery point মোছা নিষেধ, বা অন্য একটা account-কে এতে কপি করার অনুমতি।
• প্রতিটা account-এর প্রতিটা Region-এ একটা Default vault থাকে, AWS managed key aws/backup দিয়ে encrypt করা। যা অন্য account-এ কপি হবে, তার জন্য customer managed key সহ নিজের vault ব্যবহার করো।

#Cold storage আর ৯০ দিনের নিয়ম

প্রতিটা backup শুরু হয় warm storage-এ। লম্বা সময় রাখার জন্য সস্তা cold storage tier-এ সরানো যায়, কিন্তু:

• Cold storage-এ যাওয়া backup সেখানে কমপক্ষে ৯০ দিন থাকতেই হবে। তাই AWS Backup চায় মোট retention ≥ transition-এর দিন + ৯০। “৩০ দিন পরে cold, ৩৫ দিন রাখো” ফিরিয়ে দেওয়া হয়; “৩০ দিন পরে cold, ১২০ দিন রাখো” মেনে নেওয়া হয়।
• Cold storage আছে শুধু কিছু resource type-এর জন্য: EFS, EBS (EBS Snapshot Archive দিয়ে, মাসিক বা তার চেয়ে কম ঘন backup-এর জন্য), advanced features চালু DynamoDB, Timestream, EC2-তে SAP HANA, VMware VM আর CloudFormation। RDS আর Aurora-র snapshot warm-এই থাকে।
• AWS বলে backup কমপক্ষে ৮ দিন warm রাখো: incremental backup-এর ভিত্তি হিসেবে একটা পুরো warm backup লাগে।
• Cold tier-এ চলে যাওয়া backup অন্য account-এ কপি করা যায় না।

ফাঁদটা নিজে হাতে দেখো:

#Continuous backup আর point-in-time restore

সমর্থিত service-এ (RDS, Aurora, S3 আর EC2-তে SAP HANA) continuous backup চালু করা rule একটা snapshot-এর ওপর সারাক্ষণ পরিবর্তনের log রাখে, তাই retention-এর মধ্যে যেকোনো সেকেন্ডে restore করা যায়। Continuous retention ১ থেকে ৩৫ দিন। Continuous backup অন্য Region বা account-এ কপি করলে সেটা সাধারণ snapshot হয়ে যায়, point-in-time restore থাকে না। আরও লম্বা ইতিহাসের জন্য snapshot backup-এর আরেকটা rule যোগ করো।

Slide-এর “supports PITR for supported services” কথাটা এটাকেই বোঝায়; service-এর নিজস্ব PITR, যেটা তুমি আগেই জানো (RDS automated backup, DynamoDB PITR, লেসন ৭.২), একই ধারণা, শুধু আলাদা জায়গা থেকে চালানো।

#অন্য Region আর অন্য account-এ কপি

• Cross-Region copy একটা Region-এর বিভ্রাট থেকে বাঁচায়: copy action প্রতিটা recovery point অন্য Region-এর একটা vault-এ পাঠায়, সেখানে সেই vault-এর key দিয়ে আবার encrypt হয়।
• Cross-account copy বাঁচায় account বেহাত বা মুছে যাওয়া থেকে। নিয়ম: দুটো account-ই একই AWS Organization-এ থাকতে হবে; management account-কে একবার cross-account backup চালু করতে হবে; destination vault-এর access policy-তে কপির অনুমতি থাকতে হবে, আর সেটা default vault হতে পারবে না; যেসব resource AWS Backup পুরোপুরি সামলায় না, সেগুলো এমন customer managed key দিয়ে encrypt থাকতে হবে যা destination account-এর সাথে share করা (aws/rds-এর মতো AWS managed key share করা যায় না)। “অন্য account-এ restore” মানে সবসময় আগে কপি, তারপর সেখানে restore।
• ভালো একটা ধরন হলো আলাদা OU-তে একটা নিবেদিত backup account, যার SCP organizations:LeaveOrganization আর তার vault মোছা নিষেধ করে।

#পুরো organization জুড়ে backup policy

AWS Organizations-এর backup policy দিয়ে (লেসন ২০.১) management account (বা delegated administrator) root, কোনো OU বা account-এ একটা backup plan জুড়ে দেয়। তখন প্রতিটা member account সেই plan আপনাআপনি পায়, আগামী বছর বানানো account-ও, আর স্থানীয় admin সেটা বদলাতে পারে না। Cross-account monitoring-এর সাথে মিলে কেন্দ্রীয় team organization-এর প্রতিটা backup job দেখতে পায়।

#Backup Audit Manager আর restore testing

• Backup Audit Manager তোমার backup-কে control-এর সাথে মিলিয়ে দেখে, control-গুলো framework-এ সাজানো: “resource-গুলো backup plan দিয়ে সুরক্ষিত”, “backup কমপক্ষে রোজ আর retention কমপক্ষে ৩৫ দিন”, “recovery point encrypt করা”, “backup অন্য Region বা account-এ কপি হয়”, “vault-এ তালা আছে”, “restore-এর সময় লক্ষ্যের মধ্যে”। ভেতরে এটা AWS Config ব্যবহার করে (লেসন ১৯.৭), আর রোজ S3-এ report বানায়, যেটা তুমি auditor-কে দাও।
• Restore testing (২০২৩ সালের শেষে চালু) প্রমাণ করে যে backup সত্যিই restore হয়। একটা restore testing plan নিয়ম ধরে চলে, একটা সময়সীমার মধ্যে থেকে সবশেষ বা এলোমেলো একটা recovery point বাছে, backup থেকে setting আন্দাজ করে restore করে, তোমাকে যাচাই করতে দেয় (যেমন EventBridge-এর চালানো Lambda function row গোনে), কত সময় লাগল লিখে রাখে, আর শেষে restore করা resource মুছে দেয়।

#AWS Backup Vault Lock

#Backup vault-এর জন্য WORM

Vault Lock একটা backup vault-কে WORM (write once, read many) অবস্থায় নিয়ে যায়। একবার vault-এ তালা পড়লে:

• কোনো user, root user সহ, মেয়াদ শেষের আগে recovery point মুছতে বা তার lifecycle ছোট করতে পারে না। IAM যা-ই বলুক, AWS Backup call ফিরিয়ে দেয়।
• ঐচ্ছিক minimum আর maximum retention (দিনে; minimum কমপক্ষে ১, maximum ৩৬,৫০০ পর্যন্ত) সীমার বাইরের retention-ওয়ালা নতুন backup আর copy job ফিরিয়ে দেয়। Vault-এ আগে থেকে থাকা recovery point নিজের পুরোনো lifecycle-এই চলে।
• মেয়াদ শেষ হওয়া recovery point স্বাভাবিকভাবেই মুছে যায়। Lock retention মানতে বাধ্য করে; কখনো বাড়ায় না।

এটা হলো ভুলবশত বা খারাপ উদ্দেশ্যে মোছা আর retention ছোট করে দেওয়া থেকে বাঁচার বাড়তি স্তর: ransomware দলগুলো আগে backup মোছে, যাতে টাকা দেওয়া ছাড়া উপায় না থাকে। Record রাখার আইনও এতে মেটে: AWS Backup Vault Lock-কে Cohasset Associates SEC 17a-4 আর FINRA-র record রাখার নিয়মের জন্য যাচাই করেছে। Vault Lock-এর আলাদা কোনো দাম নেই; তালা দেওয়া backup যতটা storage নেয়, শুধু তার দাম।

#Governance mode বনাম compliance mode

Notes শুধু বলে “root-ও মুছতে পারবে না”। এটা দুটো mode-এর একটাতে সত্যি, তাও একটা অপেক্ষার সময়ের পরে:

API-তে ChangeableForDays ছাড়া lock মানে governance mode; সহ দিলে compliance mode। Grace time-এর মধ্যে ভুল retention ঠিক করা বা lock মুছে ফেলা যায়; lock date-এর পরে vault আর তার lock অপরিবর্তনীয়।

AWS documentation-এর দুটো সতর্কবার্তা:

• Compliance vault-এ যে recovery point-এর retention “always”, সেটা কখনোই মোছা যায় না, আর চিরকাল তার bill আসে।
• AWS account বন্ধ করলে ৯০ দিনের post-closure সময়ের পরে vault-এর ভেতরের জিনিস মুছে যায়, তালা থাক বা না থাক।

এবার নিয়মগুলো নিজে পরীক্ষা করো: mode, সময়, কে চাইছে আর কী চাইছে বেছে নাও।

#Backup Vault Lock, S3 Object Lock আর Glacier Vault Lock

কাছাকাছি নামের তিনটা WORM সুবিধা (লেসন ১০.৯-এ S3-এর দুটো শেখানো হয়েছে):

#Logically air-gapped vault

Logically air-gapped vault (আগস্ট ২০২৪ থেকে সবার জন্য চালু) হলো সবচেয়ে খারাপ অবস্থার জন্য একটা বিশেষ ধরনের vault: পুরো account-টাই বেহাত বা বন্ধ।

• এতে সবসময় compliance mode-এর Vault Lock থাকে, default হিসেবে AWS owned key দিয়ে encrypt করা (চাইলে customer managed key)।
• এর ভেতরের জিনিস AWS Resource Access Manager দিয়ে অন্য account-এর সাথে share করা যায়, তাই একটা পরিষ্কার recovery account আগে কপি না করেই সরাসরি এখান থেকে restore করতে পারে। এতে আক্রমণের পরের RTO কমে।
• জুন ২০২৫ থেকে এটা multi-party approval (MPA)-এর সাথে কাজ করে: আলাদা একটা recovery organization-এর একদল অনুমোদনকারী ভোট দিয়ে vault-এ ঢোকার অনুমতি দিতে পারেন, মালিক account বন্ধ হয়ে গেলেও।

Associate পরীক্ষায় “backup অপরিবর্তনীয় করো”-র উত্তর এখনো Vault Lock (compliance mode); air-gapped vault একই ধারণার নতুন, আরও শক্ত রূপ।

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

• DRS-এর RPO বেড়ে কয়েক মিনিট বা ঘণ্টা: upload bandwidth, replication server বা staging volume লেখার গতির সাথে পারছে না। সর্বোচ্চ লেখার চাপ ধরে লাইন মাপো, বড় replication server দাও, lag-এর ওপর alarm রাখো।
• Recovery ভুল subnet-এ বা খুব ছোট instance type-এ launch হলো: launch settings কেউ কখনো দেখেনি। প্রতি তিন মাসে drill করো।
• Recovery-র সাথে ransomware-ও ফিরে এল: recovery “most recent data” থেকে হয়েছে। আক্রমণের আগের point in time বাছো, আর আক্রান্ত source আলাদা করে ফেলো।
• DRS-এ কোনো পরিষ্কার point নেই: আক্রমণ ৭ দিনের daily retention-এর চেয়ে পুরোনো। Retention বাড়াও, আর তালা দেওয়া vault-এ AWS Backup-এর কপি রাখো।
• নতুন একটা resource-এর কোনো backup নেই: tag দেওয়া হয়নি। Resource type দিয়ে বাছো, tag বাধ্যতামূলক করো, Organizations থেকে backup policy চাপাও, Backup Audit Manager-এ চোখ রাখো।
• Backup plan ফিরিয়ে দিল: retention cold transition + ৯০ দিনের কম, বা continuous retention ৩৫ দিনের বেশি।
• Cross-account copy ব্যর্থ: resource AWS managed key দিয়ে encrypt, source key share করা হয়নি, destination vault-এর access policy backup:CopyIntoBackupVault দেয় না, destination default vault, management account-এ cross-account backup চালু করা হয়নি, বা backup আগেই cold storage-এ চলে গেছে।
• তালা দেওয়া vault-এ backup job ব্যর্থ: তাদের retention vault lock-এর minimum বা maximum-এর বাইরে।
• Vault Lock থাকা সত্ত্বেও backup মুছে গেল: governance mode, আর permission থাকা কেউ lock সরিয়েছে। Compliance mode বা একটা SCP ব্যবহার করো।
• এমন storage bill যা আর কমানো যায় না: lock date-এর পরে compliance vault-এ ভুল করে “চিরকাল রাখো” বা খুব লম্বা retention।
• দুর্যোগের দিন restore ব্যর্থ: restore role-এর KMS permission নেই, subnet আর নেই, বা backup কখনো পরীক্ষাই করা হয়নি। Restore testing এগুলো শান্ত এক রবিবারেই ধরে ফেলে।

#System design-এ DRS আর AWS Backup

• স্তরে স্তরে সাজাও। নিজস্ব replication নেই এমন গুরুত্বপূর্ণ server-এর ছোট RTO আর RPO-র জন্য DRS; সবকিছুর ইতিহাসের (৩৫ দিন, ১ বছর, ৭ বছর) জন্য AWS Backup; আর আক্রমণকারীর হাত থেকে সেই ইতিহাস বাঁচাতে Vault Lock আর আলাদা account।
• আলাদা account আর Region। Production এক account-এ, backup-এর কপি অন্য Region-এর একটা backup account-এ, আর সবচেয়ে খারাপ অবস্থার জন্য একটা recovery account-এর সাথে share করা logically air-gapped vault।
• আগে least privilege, তারপর তালা। অল্প কয়েকজনই backup মুছতে পারবে; একটা SCP vault lock সরানো আর organization ছেড়ে যাওয়া নিষেধ করে; আইনের আওতার সবকিছুর জন্য compliance mode।
• Customer managed key দিয়ে encrypt করো, যেটা backup account-এর সাথে share করা, যাতে account-এর বাইরে কপি আর restore কাজ করে।
• পরীক্ষা করো, আবারও করো। প্রতি তিন মাসে সময় মেপে runbook ধরে DRS drill; প্রতি সপ্তাহে restore testing; প্রতি মাসে Backup Audit Manager report; কোনো ঘটনার পরে restore করার আগে GuardDuty দিয়ে backup-এর malware scan (লেসন ২১.৭)।
• নিজস্ব feature-ও দরকারি। AWS-এ বানানো ডেটার জন্য Aurora Global Database, DynamoDB global table আর S3 replication আরও কম RPO দেয় (লেসন ২৩.১); আর replication যেসব মোছা বা নষ্ট হওয়া বিশ্বস্তভাবে কপি করে ফেলত, তার থেকে বাঁচায় AWS Backup আর Vault Lock।

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

এই command-গুলো ap-southeast-1-এ AWS CLI v2 দিয়ে; ID-গুলো উদাহরণ। DRS-কে console-এ একবার initialize করতে হয়, আর resource থাকা পর্যন্ত দুটো service-এই খরচ হয়।

# --- Elastic Disaster Recovery ---
# 1. On the source server (Linux): install the replication agent
wget -O ./aws-replication-installer-init https://aws-elastic-disaster-recovery-ap-southeast-1.s3.ap-southeast-1.amazonaws.com/latest/linux/aws-replication-installer-init
sudo chmod +x aws-replication-installer-init && sudo ./aws-replication-installer-init --region ap-southeast-1

# 2. Check replication state and lag
aws drs describe-source-servers --query "items[].{id:sourceServerID,state:dataReplicationInfo.dataReplicationState,lag:dataReplicationInfo.lagDuration}"
# [ { "id": "s-1234567890abcdef0", "state": "CONTINUOUS", "lag": "PT2S" } ]

# 3. List points in time and launch a drill from one before the incident
aws drs describe-recovery-snapshots --source-server-id s-1234567890abcdef0 --order DESC
# { "items": [ { "snapshotID": "pit-0a1b2c3d4e5f67890", "timestamp": "2026-10-31T20:00:00Z", ... } ] }
aws drs start-recovery --is-drill \
  --source-servers sourceServerID=s-1234567890abcdef0,recoverySnapshotID=pit-0a1b2c3d4e5f67890

# 4. Real recovery later (same command without --is-drill), then failback
aws drs start-failback-launch --recovery-instance-ids i-0abcd1234example

# --- AWS Backup ---
# 5. A plan: daily at 02:00 Dhaka time (20:00 UTC), cold after 30 days, keep 120, copy to Mumbai backup account
cat > plan.json <<'EOF'
{ "BackupPlanName": "erp-daily",
  "Rules": [ { "RuleName": "daily-0200", "TargetBackupVaultName": "prod-vault",
    "ScheduleExpression": "cron(0 20 * * ? *)", "StartWindowMinutes": 60, "CompletionWindowMinutes": 480,
    "Lifecycle": { "MoveToColdStorageAfterDays": 30, "DeleteAfterDays": 120 },
    "CopyActions": [ { "DestinationBackupVaultArn": "arn:aws:backup:ap-south-1:444455556666:backup-vault:dr-vault",
      "Lifecycle": { "DeleteAfterDays": 120 } } ] } ] }
EOF
aws backup create-backup-plan --backup-plan file://plan.json
# { "BackupPlanId": "1a2b3c4d-5678-90ab-cdef-111122223333", "VersionId": "..." }

# 6. Assign every resource tagged backup=daily
aws backup create-backup-selection --backup-plan-id 1a2b3c4d-5678-90ab-cdef-111122223333 \
  --backup-selection '{"SelectionName":"tagged-daily","IamRoleArn":"arn:aws:iam::111122223333:role/service-role/AWSBackupDefaultServiceRole","ListOfTags":[{"ConditionType":"STRINGEQUALS","ConditionKey":"backup","ConditionValue":"daily"}]}'

# 7. An on-demand backup and a manual cross-account copy
aws backup start-backup-job --backup-vault-name prod-vault \
  --resource-arn arn:aws:rds:ap-southeast-1:111122223333:db:erp-db \
  --iam-role-arn arn:aws:iam::111122223333:role/service-role/AWSBackupDefaultServiceRole \
  --lifecycle DeleteAfterDays=35
aws backup start-copy-job --source-backup-vault-name prod-vault \
  --recovery-point-arn arn:aws:rds:ap-southeast-1:111122223333:snapshot:awsbackup:job-0123abcd \
  --destination-backup-vault-arn arn:aws:backup:ap-south-1:444455556666:backup-vault:dr-vault \
  --iam-role-arn arn:aws:iam::111122223333:role/service-role/AWSBackupDefaultServiceRole

# 8. Vault Lock: governance (no --changeable-for-days) or compliance (with it)
aws backup put-backup-vault-lock-configuration --backup-vault-name prod-vault \
  --min-retention-days 7 --max-retention-days 400 --changeable-for-days 3
aws backup describe-backup-vault --backup-vault-name prod-vault
# { "Locked": true, "MinRetentionDays": 7, "MaxRetentionDays": 400, "LockDate": "2026-11-04T09:00:00Z", ... }

# 9. A logically air-gapped vault and a weekly restore test
aws backup create-logically-air-gapped-backup-vault --backup-vault-name lag-vault \
  --min-retention-days 7 --max-retention-days 400
aws backup create-restore-testing-plan --restore-testing-plan '{"RestoreTestingPlanName":"weekly_erp","ScheduleExpression":"cron(0 21 ? * SAT *)","RecoveryPointSelection":{"Algorithm":"RANDOM_WITHIN_WINDOW","IncludeVaults":["*"],"RecoveryPointTypes":["SNAPSHOT"],"SelectionWindowDays":30}}'

তালা দেওয়া vault-এ aws backup delete-recovery-point দিয়ে একটা recovery point মোছার চেষ্টা করো: administrator হয়েও access denied error পাবে। ৩ দিনের grace time-এর মধ্যেই aws backup delete-backup-vault-lock-configuration দিয়ে lock মুছে ফেলো, নইলে সেটা থেকেই যাবে।

#সারসংক্ষেপ

মূল কথাগুলো

• DRS (আগের নাম CloudEndure Disaster Recovery): physical, VMware, Hyper-V, অন্য cloud বা EC2 server-এ agent → কম খরচের staging area-তে (ছোট replication server + EBS) সারাক্ষণ block-level replication → point-in-time snapshot (১০ মিনিট / ১ ঘণ্টা / রোজ, daily default ৭ দিন, ৩৬৫ পর্যন্ত) → replication না থামিয়ে drill → পুরো সাইজের EC2-তে recovery → failback। RPO কয়েক সেকেন্ড, RTO কয়েক মিনিট (সাধারণত ৫ থেকে ২০), প্রতি server-ঘণ্টায় প্রায় ০.০২৮ USD।
• Bandwidth বা staging তাল না রাখতে পারলে DRS-এর RPO বাড়ে। Ransomware-এর পরে আক্রমণের আগের point in time থেকে launch করো, কখনো “most recent data” থেকে না।
• DRS = disaster recovery; MGN = migration। একই প্রযুক্তি, আলাদা কাজ।
• AWS Backup: EC2, EBS, S3, RDS, Aurora, DynamoDB, DocumentDB, Neptune, EFS, FSx, Storage Gateway, Redshift, VMware সহ অনেক কিছুর কেন্দ্রীয়, fully managed backup। Backup plan (কত ঘন ঘন, window, lifecycle, copy), tag দিয়ে বাছাই, KMS key আর access policy সহ vault।
• Cold storage: মোট retention ≥ transition + ৯০ দিন; শুধু কিছু resource-এ। Continuous backup (RDS, Aurora, S3, SAP HANA): PITR, ১ থেকে ৩৫ দিন।
• Region-এর DR-এর জন্য cross-Region copy; একই organization-এর মধ্যে, share করা customer managed key দিয়ে cross-account copy। Backup policy সব account-এ plan পৌঁছে দেয়; Backup Audit Manager নিয়ম মানা প্রমাণ করে; restore testing restore প্রমাণ করে।
• Vault Lock = backup vault-এর জন্য WORM। Governance: recovery point সুরক্ষিত, কিন্তু IAM permission থাকলে lock সরানো যায়। Compliance: grace time (≥ ৭২ ঘণ্টা)-এর পরে কেউ, root বা AWS-ও না, lock সরাতে বা আগেভাগে মুছতে পারে না। Min/max retention সীমার বাইরের job ফিরিয়ে দেয়।
• Logically air-gapped vault: compliance-এ তালা দেওয়া, recovery account-এর সাথে share করা যায়, সবচেয়ে খারাপ অবস্থার জন্য MPA।

নিজেকে যাচাই করো: Elastic Disaster Recovery, AWS Backup আর Vault Lock৩০টি প্রশ্ন