RDS Backup, Restore আর RDS Custom

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

• RDS-এর automated backup কীভাবে কাজ করে (প্রতিদিন একটা snapshot আর প্রতি ৫ মিনিটে transaction log) সেটা বুঝিয়ে বলতে, আর retention period ও backup window ঠিক করতে।
• Point-in-time restore (PITR) দিয়ে database-কে নির্দিষ্ট একটা সেকেন্ডে ফিরিয়ে আনতে, latest restorable time কী সেটা জানতে, আর প্রতিটা restore কেন নতুন endpoint সহ নতুন instance বানায় তা ব্যাখ্যা করতে।
• Restore-এর পর application-কে আবার জুড়ে দিতে: Route 53 CNAME, config বদল, বা নাম বদলের কৌশল দিয়ে।
• Manual snapshot ব্যবহার করতে: রেখে দেওয়া, অন্য Region-এ copy, অন্য account-এ share (encrypted হলেও), আর instance delete করলে কী টিকে থাকে তা জানতে।
• Compliance-এর জন্য বছরের পর বছর backup রাখার ব্যবস্থা সাজাতে: নিয়ম করে snapshot, AWS Backup আর S3-এ export।
• খরচ বাঁচাতে instance stop করবে নাকি snapshot নিয়ে delete করবে সেটা ঠিক করতে, আর S3 থেকে MySQL database restore করতে।
• Blue/Green Deployment দিয়ে major upgrade চালাতে, আর switchover, guardrail ও rollback বুঝিয়ে বলতে।
• RDS, RDS Custom আর EC2-তে নিজের database, এই তিনের মধ্যে বেছে নিতে, আর RDS Custom instance নিরাপদে নিজের মতো বদলাতে।

#Backup নিয়ে আলাদা একটা লেসন কেন

লেসন ৭.১-এ দেখেছ Multi-AZ আর read replica কীভাবে database-কে চালু রাখে। কিন্তু database-এর সবচেয়ে সাধারণ বিপদ থেকে এগুলোর কোনোটাই বাঁচায় না: মানুষ বা bug নিজেই data নষ্ট করে ফেলা। একটা DROP TABLE, WHERE ছাড়া একটা UPDATE, ভুল করে production-এ চালানো একটা migration script: Multi-AZ এই ভুলটাই কয়েক millisecond-এ standby-তে কপি করে দেয়, read replica-ও একটু পরেই একই কাজ করে। Data ফেরাতে পারে শুধু ভুলের আগের একটা backup।

RDS দুই রকম backup দেয়, আর এই অংশের প্রায় সব পরীক্ষার প্রশ্ন এই দুইয়ের পার্থক্য নিয়েই:

#Automated backup

#RDS প্রতিদিন কী করে

Automated backup চালু থাকলে RDS দুটো কাজ করে:

1. Backup window-এর সময় পুরো DB instance-এর প্রতিদিন একটা snapshot। এটা storage volume-এর snapshot (লেসন ৫.১-এর সেই EBS snapshot প্রযুক্তি), তাই এক-একটা database না, পুরো instance-টাই backup হয়। প্রথমটা পুরো কপি; পরেরগুলো incremental, শুধু বদলানো block রাখে।
2. Transaction log, প্রতি ৫ মিনিটে S3-এ তোলা হয়। Database যা কিছু বদলায়, সব তার transaction log-এ লেখে (MySQL-এ binlog, PostgreSQL-এ write-ahead log), আর RDS সেই log একটানা পাঠিয়ে রাখে।

শুধু snapshot দিয়ে তুমি বড়জোর ভোর ৩টায় ফিরতে পারো। বাকি ফাঁকটা পূরণ করে log: দুপুর ২:৩৭ আবার বানাতে RDS ভোর ৩টার snapshot থেকে শুরু করে, তারপর ২:৩৭:০০ পর্যন্ত log-এ লেখা প্রতিটা পরিবর্তন একটা একটা করে আবার চালায়, তারপর থামে। এটাই point-in-time recovery (PITR)।

#Retention period আর backup window

কয়েকটা নিয়ম যেখানে অনেকে ধরা খায়:

• Retention ০ থেকে অন্য কিছু, বা অন্য কিছু থেকে ০ করলে outage হয়, কারণ RDS-কে পুরো backup ব্যবস্থা চালু বা বন্ধ করতে হয়। Read replica-র জন্য source-এ automated backup লাগে, তাই replica থাকলে ০ দেওয়া যায় না।
• Performance। Single-AZ instance-এ snapshot-এর সময় storage I/O অল্প সময়ের জন্য থেমে যেতে পারে (কয়েক সেকেন্ড, বড় আর ব্যস্ত volume-এ আরও বেশি), তাই window রাখো সবচেয়ে ফাঁকা সময়ে। Multi-AZ instance-এ backup নেওয়া হয় standby থেকে, ফলে primary-র গায়ে লাগে না (লেসন ৭.১)।
• Instance available থাকলেই কেবল backup চলে। Stop করা থাকলে automated backup হয় না, আর stop থাকার সময়টা retention-এর হিসাবে ধরা হয় না।

#Point-in-time restore আর latest restorable time

• Earliest restorable time (retention window-এর শুরু) থেকে latest restorable time পর্যন্ত যেকোনো সেকেন্ডে restore করা যায়।
• Latest restorable time সাধারণত শেষ ৫ মিনিটের মধ্যে থাকে, কারণ log এই হারেই S3-এ পৌঁছায়। Console-এ Automated backups-এর নিচে দেখা যায়, বা describe-db-instances-এ LatestRestorableTime হিসেবে।
• এখন যদি দুপুর ৩টা হয় আর শেষ upload ২:৫৫ পর্যন্ত ঢেকে থাকে, তাহলে ২:৫৮-তে restore চাইলে RDS না করে দেবে। ২:৫৫ বাছো।

#Restore সবসময় নতুন instance বানায়

এই লেসনের সবচেয়ে জরুরি পরীক্ষার কথা এটাই: restore কখনো তোমার চালু database-এর ওপর লেখে না। Automated backup থেকে (PITR) হোক বা manual snapshot থেকে, RDS একটা একদম নতুন DB instance বানায়, যার identifier নতুন, তাই endpoint-ও নতুন, যেমন prod-db-1437.c9xyz0example.us-east-1.rds.amazonaws.com।

AWS এমন করে কেন? নিরাপত্তার জন্য। ভাবো, ভুল backup-টা চালু production database-এর ওপর restore করে দিলে: ওই backup-এর পর যা লেখা হয়েছে সব চিরদিনের মতো শেষ। নতুন instance হলে আসলটা চলতেই থাকে, পাশে restore করা কপিটাও পাও, দুটো মিলিয়ে দেখতে পারো, দরকারি row-গুলোই শুধু ফেরত আনতে পারো, আর নিশ্চিত হলে পুরনোটা মুছে দাও।

Restore কী দেয়, আর কী দেয় না:

• নতুন instance পায় default parameter group আর option group (CLI-তে নিজেরগুলোর নাম দিয়ে দিতে পারো), আর security group তুমি বেছে দাও। এগুলো মিলিয়ে নাও, নইলে app connect-ই করতে পারবে না।
• অন্য instance class বাছতে পারো, কিন্তু storage কমাতে পারবে না।
• নতুন volume S3 থেকে lazy load হয়: সাথে সাথে ব্যবহার করা যায়, কিন্তু প্রতিটা block প্রথমবার পড়তে একটু ধীর, যতক্ষণ না পুরোটা নামে (লেসন ৫.১-এ snapshot থেকে বানানো EBS volume-এর মতোই)।
• সময় লাগে: database-এর আকার আর কত log চালাতে হবে তার ওপর মিনিট থেকে ঘণ্টা। Point-in-time restore তাৎক্ষণিক undo বোতাম না। (Aurora-র সেরকম একটা আছে, Backtrack, লেসন ৭.৩-এ।)

#Restore করা database-এ application-কে নিয়ে যাওয়া

Restore করা instance-এর endpoint নতুন, আর তোমার web application সেটা জানে না। ঠিক করার তিনটা উপায়:

CNAME পদ্ধতিতে record-এর TTL ছোট রাখো (যেমন ৬০ সেকেন্ড), নইলে client-রা কিছুক্ষণ cache-এ থাকা পুরনো endpoint-এই যেতে থাকবে। Endpoint-টা AWS Systems Manager Parameter Store বা Secrets Manager-এ রেখে app চালু হওয়ার সময় সেখান থেকে পড়া, এটা একই বুদ্ধি, শুধু এক ধাপ ওপরে।

#Manual snapshot

Manual snapshot (আরেক নাম DB snapshot) হলো যে snapshot তুমি নিজে চাও: console-এ, aws rds create-db-snapshot দিয়ে, কোনো script বা Lambda function থেকে, বা AWS Backup দিয়ে।

• তুমি না মোছা পর্যন্ত থাকে, retention-এ যা-ই দেওয়া থাকুক, আর instance delete করলেও টিকে থাকে।
• Restore হয় ঠিক যে মুহূর্তে নেওয়া হয়েছিল, সেখানে। Log নেই, তাই মাঝের কোনো সেকেন্ড বাছার সুযোগও নেই।
• Snapshot incremental (শুধু বদলানো block রাখে), তবু প্রতিটা আলাদাভাবে restore করা যায়।
• সীমা: default-এ প্রতি Region-এ ১০০টা manual snapshot (বাড়ানো যায়)। Automated backup এই হিসাবে পড়ে না।
• ঝুঁকির কাজের আগে (upgrade, বড় migration), instance delete করার আগে, আর যা কিছু ৩৫ দিনের বেশি রাখতে হবে, তার জন্য এটা ব্যবহার করো।

#Snapshot copy করা

copy-db-snapshot একটা snapshot থেকে নতুন snapshot বানায়:

• একই Region-এর ভেতরে: একটা automated snapshot-কে manual বানাতে (যাতে retention শেষ হলেও টিকে থাকে আর share করা যায়), বা encryption key বদলাতে।
• অন্য Region-এ: disaster recovery-র জন্য, বা অন্য Region-এ database চালু করতে। KMS key Region-এর ভেতরে আটকানো, তাই গন্তব্য Region-এর একটা key-এর নাম দাও, আর copy-টা সেটা দিয়ে নতুন করে encrypt হয়। কোনো Region-এ প্রথম copy পুরোটাই যায়; একই instance-এর পরের copy-গুলো incremental হতে পারে।
• Copy করার সময় unencrypted snapshot-কে encrypt করে নেওয়া যায়। চালু database encrypt করার এটাই সাধারণ পথ: snapshot, encrypted copy, restore (লেসন ৭.৪)।

#অন্য account-এর সাথে snapshot share করা

একটা manual snapshot সর্বোচ্চ ২০টা AWS account-এর সাথে share করা যায়, বা public করা যায় (শুধু unencrypted হলে, আর আসল data থাকলে কখনোই না)।

Key policy-র খুঁটিনাটি লেসন ৭.৪-এ। আরও দুটো সীমা: যে snapshot-এর option group-এ permanent বা persistent option আছে (যেমন Oracle বা SQL Server-এর transparent data encryption), সেটা share করা যায় না; আর Multi-AZ DB cluster-এর snapshot-ও share হয় না।

#Instance delete করলে কী টিকে থাকে

DB instance delete করার সময় screen (বা CLI flag) তিনটা প্রশ্ন করে, আর এর উত্তরই ঠিক করে পরে কী restore করতে পারবে:

1. Deletion protection

   Deletion protection চালু থাকলে delete call fail করে, যতক্ষণ না কেউ instance modify করে সেটা বন্ধ করে। প্রতিটা production database-এ এটা চালু রাখো: ভুল করে চালানো একটা delete-db-instance তখন দুই ধাপের একটা ইচ্ছাকৃত কাজ হয়ে যায়।

2. Final snapshot নেবে?

   Delete করার আগে RDS শেষ একটা manual snapshot নিতে পারে (--final-db-snapshot-identifier)। অন্য যেকোনো manual snapshot-এর মতোই এটা থাকে যতদিন না তুমি মোছো। CLI-তে স্পষ্ট করে বলতেই হয়: হয় final snapshot-এর নাম, নয় --skip-final-snapshot।

3. Automated backup রেখে দেবে?

   Default-এ automated backup instance-এর সাথেই মুছে যায় (CLI-তে --delete-automated-backups default)। Retain automated backups (--no-delete-automated-backups) বাছলে সেগুলো একটা retained backup হিসেবে থেকে যায়: বাকি window-এর যেকোনো সেকেন্ডে এখনো restore করা যায়, কিন্তু retention period শেষ হলেই মেয়াদ ফুরায়, আর ততদিন তার storage-এর টাকা দিতে হয়।

#Compliance-এর জন্য বছরের পর বছর রাখা

ব্যাংক, হাসপাতাল, শেয়ারবাজারে থাকা কোম্পানিকে প্রায়ই audit বা আইনের কারণে database backup ১ থেকে ৭ বছর রাখতে হয়। Automated backup দিয়ে এটা হয় না: তার সর্বোচ্চ retention ৩৫ দিন, তার পুরনোগুলো RDS নিজেই মুছে দেয়। তোমার হাতে যা আছে:

#টাকা বাঁচানো: stop, নাকি snapshot নিয়ে delete?

যে database মাঝে মাঝে লাগে, সেটাও চালু থাকলে প্রতি ঘণ্টায় টাকা কাটে।

তাহলে: এক রাত, এক weekend বা কয়েক দিনের জন্য stop করো। কয়েক সপ্তাহ বা মাস অলস থাকলে snapshot নিয়ে delete করো, দরকার হলে restore করো। (একটা scheduled job প্রতি ৭ দিনে আবার stop করে দিতে পারে, কিন্তু storage-এর টাকা তখনো কাটতে থাকে।) Slide-এ একেই “trick” বলা হয়েছে: stop করা database-ও storage-এর টাকা দেয়।

#Restore করার আরও উপায়

Slide-এ “S3 থেকে MySQL RDS restore” লেখা আছে tool-এর নাম ছাড়া, আর Percona XtraBackup-এর কথা আছে শুধু Aurora-র বেলায়। আসলে RDS for MySQL-এও এই কাজে Percona XtraBackup backup-ই লাগে; সাধারণ mysqldump file restore from S3 দিয়ে হয় না, সেটা একটা instance-এর ওপর চালিয়ে import করতে হয়। এই restore-এর Aurora সংস্করণ লেসন ৭.৩-এ।

#Blue/Green Deployment

Major version upgrade, বড় schema বদল, parameter বদল, production database-এ এগুলো ভয়ের কাজ: in-place major upgrade-এ database কিছুক্ষণ বন্ধ থাকে, আর নতুন version গোলমাল করলে তাড়াতাড়ি ফিরে আসার পথ থাকে না। Amazon RDS Blue/Green Deployment এর সমাধান করে একটা মিলিয়ে রাখা কপি দিয়ে:

1. বানাও

   RDS পুরো production সাজসজ্জা (Multi-AZ, read replica, storage setting, monitoring) একটা green environment-এ কপি করে। বানানোর সময়ই green-এর engine version upgrade করতে আর নতুন parameter group দিতে পারো। Blue হলো production; green default-এ read-only।

2. মিলিয়ে রাখো

   Blue-তে যা বদলায়, RDS সব green-এ পাঠায়। RDS for MySQL আর MariaDB ব্যবহার করে binlog replication, যেটা logical replication: change data capture (CDC)-এর একটা রূপ। RDS for PostgreSQL ব্যবহার করে physical replication, আর green যদি বড় major version-এ থাকে তাহলে logical replication।

3. পরীক্ষা করো

   App-এর একটা test copy green-এর নিজের endpoint-এ লাগাও: query চালাও, গতি দেখো, schema বদল পরীক্ষা করো (পারলে green read-only রাখো, কারণ সেখানে লিখলে replication ভেঙে যেতে পারে)।

4. Switch over করো

   RDS guardrail চালায়, দুই দিকেই write বন্ধ করে, connection কেটে দেয়, green সব পরিবর্তন পেয়ে যাওয়া পর্যন্ত অপেক্ষা করে, তারপর নাম আর endpoint অদলবদল করে: green হয় prod-db, blue হয় prod-db-old1। Application-এ কিছুই বদলাতে হয় না। সাধারণত এক মিনিটের কম লাগে, কোনো data হারায় না।

জানার মতো খুঁটিনাটি:

• Guardrail switchover আটকে দেয় যদি replication ঠিক না থাকে, timeout-এর তুলনায় replica lag বেশি হয়, বা blue-তে লম্বা write বা DDL চলতে থাকে (আর PostgreSQL logical replication-এ, blue-তে DDL-এর মতো অসমর্থিত বদল হলে)। Guardrail আটকালে কিছুই বদলায় না।
• Switchover timeout: ৩০ থেকে ৩,৬০০ সেকেন্ড, default ৩০০। এর বেশি লাগলে সব আগের অবস্থায় ফেরত যায়, দুটো environment যেমন ছিল তেমনই থাকে।
• Switchover-এর আগে rollback সহজ: Blue/Green Deployment (আর green instance-গুলো) মুছে দাও। Production-এ কেউ হাতই দেয়নি।
• Switchover-এর পরে নিজে থেকে ফিরে যাওয়ার ব্যবস্থা নেই: দুইয়ের মধ্যে replication বন্ধ হয়ে যায়, আর পুরনো blue instance-গুলো থেকে যায় (read-only, বিল চলতে থাকে), যতক্ষণ না তুমি মোছো।
• Client-এর DNS cache ছোট রাখো (RDS ৫ সেকেন্ডের TTL ব্যবহার করে); RDS Proxy আর AWS-এর smart driver DNS-এর চেয়ে তাড়াতাড়ি switch টের পায়।
• কোন engine-এ চলে: RDS for MySQL, MariaDB আর PostgreSQL, সাথে Aurora MySQL আর Aurora PostgreSQL (লেসন ৭.৩)। RDS for Oracle, SQL Server বা Db2-তে না।

#RDS Custom

#সমস্যা: RDS তোমাকে server-এ ঢুকতে দেয় না

সাধারণ RDS তোমার database চালায় একটা AWS-এর নিজের account-এর EC2 instance-এ। তুমি পাও একটা database endpoint, আর কিছু না: SSH নেই, operating system-এ ঢোকার পথ নেই, root নেই, আর database-এর কিছু উঁচু ক্ষমতার procedure-ও বন্ধ। ঠিক এই কারণেই AWS তোমার হয়ে সব patch, backup আর মেরামত করতে পারে।

কিছু application এভাবে চলতে পারে না। কেনা ব্যবসায়িক software (accounting suite, ব্যাংকের core system) প্রায়ই চায় database server-এ vendor-এর একটা agent বসানো, নির্দিষ্ট একটা OS বা database patch, বিশেষ file system setting, বা এমন কোনো database feature যার জন্য RDS যে ক্ষমতা দেয় না সেটা লাগে। RDS Custom আসার আগে একটাই পথ ছিল: EC2 বা on-premises-এ নিজে database চালাও, আর সব administration নিজে করো।

#RDS Custom কী

Amazon RDS Custom একটা managed database service, শুধু Oracle আর Microsoft SQL Server-এর জন্য, যেটা নিচের operating system আর database-এ administrator-এর অধিকার দেয়:

• EC2 instance আর তার EBS volume থাকে তোমার নিজের account-এ। Connect করো SSM Session Manager বা SSH দিয়ে (Oracle), বা RDP দিয়ে (SQL Server)।
• RDS Custom তবুও setup, backup আর PITR, monitoring আর instance recovery নিজে চালায় (host খারাপ হলে reboot করে বা বদলে দেয়)।
• Software আর agent বসাতে পারো, নিজের patch লাগাতে পারো, setting বদলাতে পারো, native feature চালু করতে পারো।
• License: Oracle-এ নিজের license (BYOL), নিজের installation media সহ। SQL Server-এ license included, বা নিজের media আনা যায়।

#Automation pause করা

RDS Custom-এর automation host-এর ওপর নজর রাখে আর অপ্রত্যাশিত কিছু দেখলে “মেরামত” করে। ও নজর রাখার সময় তুমি file বা package বদলালে সে তোমার বদলটাকেই গোলমাল ভাবতে পারে। তাই নিয়ম হলো:

1. আগে একটা DB snapshot নাও, যাতে ফিরে আসা যায়।
2. Automation pause করো (--automation-mode all-paused), default ৬০ মিনিট, সর্বোচ্চ ১,৪৪০ মিনিট (২৪ ঘণ্টা)। চলতি pause বাড়ানোও যায়।
3. Connect করো (Session Manager বা SSH/RDP) আর নিজের মতো বদলাও।
4. Full automation আবার চালু করো (--automation-mode full), বা pause-এর সময় ফুরালে নিজে থেকেই চালু হয়ে যাবে।

Slide-এ একে বলা হয়েছে “automation mode de-activate করা”; AWS বলে automation pause করা।

তোমার কোনো বদল যদি instance-কে RDS Custom যতটুকু সামলাতে পারে তার বাইরে (তার support perimeter-এর বাইরে) নিয়ে যায়, status হয়ে যায় unsupported-configuration, যতক্ষণ না তুমি নিজে ঠিক করো।

#Shared responsibility তোমার দিকে সরে আসে

যত বেশি বদলাতে পারবে, তত বেশি ভাঙতেও পারবে: RDS Custom-এ তোমার বদলগুলো ঠিকঠাক চলছে কিনা, সেটা দেখা তোমারই কাজ।

#RDS, RDS Custom, নাকি EC2?

#System design-এ backup কোথায় বসে

• Backup হলো শেষ প্রতিরক্ষা। Multi-AZ hardware আর AZ বিপদ থেকে বাঁচায়, read replica read বাড়ায়, কিন্তু মানুষের ভুল আর data নষ্ট হওয়া ঠিক করতে পারে শুধু backup। তিনটাই ব্যবহার করো।
• আগে RPO আর RTO ঠিক করো। PITR দেয় মোটামুটি ৫ মিনিটের RPO; RTO হলো restore-এর সময় (database বড় হলে মিনিট থেকে ঘণ্টা) আর app সরানোর সময়। নিয়মিত restore করে দেখো আর সময় মাপো: যে backup কখনো পরীক্ষা করোনি, সেটা একটা আশা, পরিকল্পনা না।
• Database-এর সামনে নিজের একটা নাম রাখো (Route 53 CNAME বা একটা secret), যাতে restore বা migration মানে শুধু একটা record বদল।
• Production checklist: retention ৭–৩৫ দিন, backup window সবচেয়ে ফাঁকা সময়ে, deletion protection চালু, delete-এ final snapshot, snapshot কখনো share করতে হলে customer managed key দিয়ে encryption, DR-এর জন্য cross-Region copy বা automated backup replication, compliance-এর জন্য Vault Lock সহ AWS Backup।
• বদল Blue/Green দিয়ে: major upgrade আর ঝুঁকির parameter বদল in-place না করে Blue/Green Deployment দিয়ে করো।
• বিলের দিকে চোখ রাখো: database-এর আকারের বেশি backup storage, delete করা instance-এর retained backup, ভুলে যাওয়া manual snapshot, আর switchover-এর পর পড়ে থাকা পুরনো blue instance, সবকিছুরই টাকা লাগে।

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

DB=prod-db

# 1. Retention 14 days and a backup window at 03:00 UTC (applied now)
aws rds modify-db-instance --db-instance-identifier $DB \
  --backup-retention-period 14 --preferred-backup-window 03:00-03:30 \
  --deletion-protection --apply-immediately

# 2. See the PITR window
aws rds describe-db-instances --db-instance-identifier $DB \
  --query "DBInstances[0].[BackupRetentionPeriod,LatestRestorableTime]"
aws rds describe-db-instance-automated-backups --db-instance-identifier $DB \
  --query "DBInstanceAutomatedBackups[0].RestoreWindow"

# 3. Point-in-time restore to 14:37 into a NEW instance
aws rds restore-db-instance-to-point-in-time \
  --source-db-instance-identifier $DB \
  --target-db-instance-identifier prod-db-1437 \
  --restore-time 2026-10-25T14:37:00Z \
  --db-parameter-group-name prod-params --vpc-security-group-ids sg-0abc1234def567890
aws rds wait db-instance-available --db-instance-identifier prod-db-1437

# 4. Swing the CNAME the app uses to the new endpoint
NEW=$(aws rds describe-db-instances --db-instance-identifier prod-db-1437 \
  --query "DBInstances[0].Endpoint.Address" --output text)
aws route53 change-resource-record-sets --hosted-zone-id Z0123456789EXAMPLE \
  --change-batch "{\"Changes\":[{\"Action\":\"UPSERT\",\"ResourceRecordSet\":{\"Name\":\"db.shop.example\",\"Type\":\"CNAME\",\"TTL\":60,\"ResourceRecords\":[{\"Value\":\"$NEW\"}]}}]}"

#    ...or the rename trick
aws rds modify-db-instance --db-instance-identifier prod-db --new-db-instance-identifier prod-db-old --apply-immediately
aws rds modify-db-instance --db-instance-identifier prod-db-1437 --new-db-instance-identifier prod-db --apply-immediately

# 5. Manual snapshot, copy to another Region, share with another account
aws rds create-db-snapshot --db-instance-identifier $DB --db-snapshot-identifier snap-0601
aws rds copy-db-snapshot --region eu-west-1 \
  --source-db-snapshot-identifier arn:aws:rds:us-east-1:111122223333:snapshot:snap-0601 \
  --target-db-snapshot-identifier snap-0601-dr --kms-key-id alias/rds-dr
aws rds modify-db-snapshot-attribute --db-snapshot-identifier snap-0601 \
  --attribute-name restore --values-to-add 444455556666

# 6. Cross-Region automated backup replication (PITR in eu-west-1)
aws rds start-db-instance-automated-backups-replication --region eu-west-1 \
  --source-db-instance-arn arn:aws:rds:us-east-1:111122223333:db:prod-db \
  --backup-retention-period 7 --kms-key-id alias/rds-dr

# 7. Export a snapshot to S3 as Parquet for Athena
aws rds start-export-task --export-task-identifier snap-0601-export \
  --source-arn arn:aws:rds:us-east-1:111122223333:snapshot:snap-0601 \
  --s3-bucket-name shop-db-exports --iam-role-arn arn:aws:iam::111122223333:role/rds-s3-export \
  --kms-key-id alias/exports

# 8. Delete safely: final snapshot, keep automated backups
aws rds modify-db-instance --db-instance-identifier old-db --no-deletion-protection --apply-immediately
aws rds delete-db-instance --db-instance-identifier old-db \
  --final-db-snapshot-identifier old-db-final --no-delete-automated-backups

# 9. Stop a dev database (it starts again by itself after 7 days)
aws rds stop-db-instance --db-instance-identifier dev-db --db-snapshot-identifier dev-db-before-stop

# 10. Restore an on-premises MySQL backup made with Percona XtraBackup
xtrabackup --backup --user=admin --password=... --stream=xbstream \
  --target-dir=/backup | split -d --bytes=500MB - /backup/full.xbstream
aws s3 cp /backup/ s3://shop-mysql-import/full/ --recursive
aws rds restore-db-instance-from-s3 --db-instance-identifier shop-mysql \
  --db-instance-class db.m6g.large --engine mysql --allocated-storage 200 \
  --master-username admin --manage-master-user-password \
  --source-engine mysql --source-engine-version 8.0.36 \
  --s3-bucket-name shop-mysql-import --s3-prefix full \
  --s3-ingestion-role-arn arn:aws:iam::111122223333:role/rds-s3-import

# 11. Blue/Green: upgrade MySQL 8.0 -> 8.4, then switch over with a 10-minute timeout
aws rds create-blue-green-deployment --blue-green-deployment-name prod-84 \
  --source arn:aws:rds:us-east-1:111122223333:db:prod-db \
  --target-engine-version 8.4.6 --target-db-parameter-group-name prod-params-84
aws rds describe-blue-green-deployments --query "BlueGreenDeployments[].[BlueGreenDeploymentIdentifier,Status]"
aws rds switchover-blue-green-deployment \
  --blue-green-deployment-identifier bgd-1234567890abcdef --switchover-timeout 600

# 12. RDS Custom: pause automation for 2 hours, connect, resume
aws rds modify-db-instance --db-instance-identifier erp-oracle \
  --automation-mode all-paused --resume-full-automation-mode-minutes 120
aws ssm start-session --target i-0abc1234def567890
aws rds modify-db-instance --db-instance-identifier erp-oracle --automation-mode full

আর এই লেসন যে দুর্ঘটনা নিয়ে, সেটা SQL-এ। অন্য কিছু করার আগে সময়টা লিখে রাখো:

SELECT NOW();               -- 2026-10-25 14:38:12: the mistake happened just now
DROP TABLE orders;          -- the mistake
-- Restore to 14:37:59 (step 3 above), then copy only the lost table back if production
-- has received new, good writes since:
--   mysqldump -h prod-db-1437... shop orders | mysql -h prod-db... shop

#সারসংক্ষেপ

মূল কথাগুলো

• Automated backup = backup window-এ প্রতিদিন একটা snapshot + প্রতি ৫ মিনিটে transaction log → window-এর যেকোনো সেকেন্ডে PITR, latest restorable time (মোটামুটি ৫ মিনিট আগে) পর্যন্ত।
• Retention ০–৩৫ দিন; ০ দিলে automated backup বন্ধ। Default ৭ দিন (console), ১ দিন (CLI/API)। Multi-AZ instance backup নেয় standby থেকে।
• প্রতিটা restore নতুন endpoint সহ নতুন instance বানায়। App-কে নিয়ে যাও config বদলে, Route 53 CNAME বদলে (code বদল ছাড়া), বা instance-এর নাম বদলে।
• Manual snapshot তুমি না মোছা পর্যন্ত থাকে, instance delete হলেও টেকে, আর ঠিক তার মুহূর্তেই restore হয়। অন্য Region-এ copy করো (গন্তব্যের key দিয়ে নতুন করে encrypt হয়), ২০টা account-এর সাথে share করো; automated snapshot আগে copy করতে হয়; aws/rds দিয়ে encrypted snapshot share হয় না, customer managed key লাগে।
• Instance delete করলে automated backup মুছে যায়, যদি না retain করো (তবু retention শেষ হওয়া পর্যন্ত)। অনির্দিষ্টকাল রাখতে final snapshot নাও। Deletion protection চালু রাখো।
• ৩৫ দিনের বেশি compliance → AWS Backup plan (Vault Lock সহ) বা নিয়ম করে manual snapshot। S3-এ export (Parquet) analytics-এর জন্য, restore-এর জন্য না।
• Stop করা instance-ও storage-এর টাকা দেয় আর ৭ দিন পর নিজে চালু হয়ে যায়; অনেকদিন অলস থাকলে snapshot নিয়ে delete করো।
• আরও restore: cross-Region automated backup replication (অন্য Region-এ PITR) আর Percona XtraBackup দিয়ে S3 থেকে MySQL।
• Blue/Green Deployment (RDS MySQL, MariaDB, PostgreSQL): upgrade আর বদলের জন্য একটা মিলিয়ে রাখা green কপি, guardrail, switchover সাধারণত এক মিনিটের কম, timeout default ৩০০ সেকেন্ড আর পেরোলে নিজে থেকে rollback; পিছু হটতে green মুছে দাও।
• RDS Custom (শুধু Oracle আর SQL Server): Session Manager, SSH বা RDP দিয়ে OS আর database-এ ঢোকা যায়; snapshot, automation pause (default ৬০ মিনিট, সর্বোচ্চ ২৪ ঘণ্টা), বদল, resume; দায়িত্বের বেশি অংশ তোমার। অন্য engine-এ OS access লাগলে → EC2।

নিজেকে যাচাই করো: RDS backup, restore আর RDS Custom৩০টি প্রশ্ন