Oracle RMAN ব্যাকআপ ও রিকভারি: সম্পূর্ণ প্রোডাকশন গাইড ২০২৬

প্রতিটি Oracle DBA-কেই একসময় কোনো না কোনো রিকভারি পরিস্থিতির মুখোমুখি হতে হয় — একটি drop হয়ে যাওয়া টেবিল, একটি corrupt datafile, একটি স্টোরেজ ব্যর্থতা, একটি ransomware আক্রমণ, কিংবা এমন একটি মুহূর্ত যখন কেউ জিজ্ঞেস করেন "গতকাল সকাল ৯:৪৭-এর অবস্থায় ডেটাবেজটা কি রিস্টোর করে দিতে পারবেন?" সেই মুহূর্তটা আপনি কতটা ভালোভাবে সামলাবেন, তা পুরোপুরি নির্ভর করে সপ্তাহ বা মাস আগে নেওয়া সিদ্ধান্তগুলোর উপর — যখন আপনি আপনার RMAN ব্যাকআপ কৌশল কনফিগার করছিলেন। এই গাইডে একজন প্রোডাকশন Oracle DBA-এর RMAN সম্পর্কে জানা দরকার এমন সবকিছু আছে — ব্যাকআপ আর্কিটেকচারের মূল ধারণা থেকে শুরু করে বাস্তব রিকভারি পরিস্থিতি, ব্যাকআপ টেস্টিং এবং সেই মনিটরিং, যা নিশ্চিত করে যে আপনি সবচেয়ে খারাপ মুহূর্তে কখনও আবিষ্কার করবেন না যে আপনার ব্যাকআপ নষ্ট।

১. RMAN কী এবং কেন এটি গুরুত্বপূর্ণ

Oracle Recovery Manager (RMAN) হলো Oracle-এর নিজস্ব ব্যাকআপ ও রিকভারি টুল, যা প্রতিটি Oracle Database ইনস্টলেশনে অন্তর্নির্মিত। OS-স্তরের ফাইল কপি ব্যাকআপের বিপরীতে, RMAN Oracle-এর অভ্যন্তরীণ কাঠামো বোঝে — এটি কেবল পরিবর্তিত ব্লকগুলোই ব্যাকআপ করতে পারে, block স্তরে ব্যাকআপের নির্ভুলতা যাচাই করতে পারে, open ডেটাবেজ ব্যাকআপ সঠিকভাবে সামলাতে পারে, এবং point-in-time recovery-এর জন্য Oracle-এর redo log আর্কিটেকচারের সাথে ঘনিষ্ঠভাবে সংযুক্ত থাকে।

Oracle প্রোডাকশন ডেটাবেজের জন্য RMAN-ই কেন একমাত্র গ্রহণযোগ্য ব্যাকআপ পদ্ধতি, তার মূল কারণগুলো:

• Block-স্তরের সচেতনতা: RMAN ব্যাকআপের সময় corrupt ব্লক শনাক্ত ও রিপোর্ট করে — ফলে corruption সম্পর্কে আপনি জানতে পারেন ব্যাকআপের সময়, রিকভারির সময় নয়
• Incremental ব্যাকআপ: কেবল সেই ব্লকগুলোই ব্যাকআপ করে যা শেষ ব্যাকআপের পর পরিবর্তিত হয়েছে — বড় ডেটাবেজের জন্য ব্যাকআপের সময় ও স্টোরেজ নাটকীয়ভাবে কমায়
• Catalog: RMAN প্রতিটি backup piece, প্রতিটি archive log, প্রতিটি datafile ট্র্যাক করে — তাই আপনার কাছে কী আছে এবং রিকভারি সম্ভব কিনা তা আপনি সবসময় জানেন
• নির্ভুলতা যাচাই: RMAN VALIDATE বিদ্যমান ব্যাকআপ রিস্টোর না করেই তা পরীক্ষা করে — দরকারের আগেই নিশ্চিত করে যে সেগুলো ব্যবহারযোগ্য
• Data Guard সংযোগ: RMAN standby ডেটাবেজের সাথে নির্বিঘ্নে কাজ করে — standby-তে ব্যাকআপ নিন, primary-তে রিকভার করুন
• Compression ও encryption: কোনো অতিরিক্ত সফটওয়্যার খরচ ছাড়াই অন্তর্নির্মিত ব্যাকআপ compression ও encryption

২. RMAN আর্কিটেকচার

RMAN অভ্যন্তরীণভাবে কীভাবে কাজ করে তা বোঝা আপনাকে এটি সঠিকভাবে কনফিগার করতে এবং দরকারের সময় সমস্যা সমাধানে সাহায্য করে।

২.১ মূল উপাদান

• Target database: যে Oracle ডেটাবেজটি ব্যাকআপ বা রিকভার করা হচ্ছে
• RMAN client: যে executable target-এর সাথে সংযোগ করে এবং কমান্ড জারি করে
• Recovery Catalog (ঐচ্ছিক তবে প্রস্তাবিত): একটি আলাদা Oracle ডেটাবেজ schema যা RMAN metadata সংরক্ষণ করে — ব্যাকআপ ইতিহাস, restore point, স্ক্রিপ্ট। catalog ছাড়া RMAN target ডেটাবেজের control file ব্যবহার করে, যা ডেটাবেজটি নিজেই হারিয়ে গেলে হারিয়ে যায়
• Media Management Layer (MML): tape library-এর ইন্টারফেস (Oracle Secure Backup, Veritas NetBackup, IBM Spectrum Protect)
• Fast Recovery Area (FRA): ব্যাকআপ, archive log, flashback log এবং control file autobackup-এর জন্য Oracle-পরিচালিত একটি ডিস্ক এলাকা

২.২ Recovery Catalog — কেন আপনার এটি দরকার

একটি আলাদা ডেটাবেজ রক্ষণাবেক্ষণের ঝামেলা বাঁচাতে অনেক প্রতিষ্ঠান recovery catalog বাদ দেয়। এটি একটি ভুল সাশ্রয়। catalog ছাড়া:

• যদি control file হারিয়ে যায় (এর সব কপিসহ), RMAN-এর কাছে ব্যাকআপের কোনো রেকর্ড থাকে না
• আপনি একাধিক ডেটাবেজের জন্য RMAN স্ক্রিপ্ট কেন্দ্রীয়ভাবে সংরক্ষণ করতে পারবেন না
• ঐতিহাসিক ব্যাকআপ ডেটা CONTROL_FILE_RECORD_KEEP_TIME প্যারামিটার পর্যন্ত সীমিত
• স্বয়ংক্রিয় রিকভারি প্রক্রিয়ার জন্য আপনি stored script ব্যবহার করতে পারবেন না

Recovery catalog ডেটাবেজটি ছোট হতে পারে — বেশিরভাগ পরিবেশের জন্য কয়েক গিগাবাইটই যথেষ্ট। বিনিয়োগ সামান্য; সংকটের সময় এর প্রতিদান উল্লেখযোগ্য।

-- Create recovery catalog schema
CREATE USER rman_catalog IDENTIFIED BY <strong_password>
  DEFAULT TABLESPACE rman_tbs
  QUOTA UNLIMITED ON rman_tbs;

GRANT RECOVERY_CATALOG_OWNER TO rman_catalog;

-- From RMAN client: create the catalog
RMAN> CONNECT CATALOG rman_catalog/<password>@catalog_db
RMAN> CREATE CATALOG;

-- Register target database
RMAN> CONNECT TARGET /
RMAN> REGISTER DATABASE;

৩. RMAN কনফিগারেশন সেরা অনুশীলন

একটিও ব্যাকআপ স্ক্রিপ্ট লেখার আগে RMAN সঠিকভাবে কনফিগার করুন। এই সেটিংসগুলো target ডেটাবেজে স্থায়ীভাবে প্রযোজ্য হয় এবং ডিফল্ট RMAN আচরণ নিয়ন্ত্রণ করে।

-- Connect to target and catalog
RMAN> CONNECT TARGET /
RMAN> CONNECT CATALOG rman_catalog/<password>@catalog_db

-- Retention policy: keep backups needed to recover to any point
-- in the last 7 days
CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS;

-- Automatic backup of control file and SPFILE after any structural change
CONFIGURE CONTROLFILE AUTOBACKUP ON;
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK
  TO '/backup/rman/%F';

-- Parallelism: use 4 channels for faster backup (match to CPU cores / storage throughput)
CONFIGURE DEVICE TYPE DISK PARALLELISM 4 BACKUP TYPE TO BACKUPSET;

-- Compression: MEDIUM is a good balance of speed and size reduction
CONFIGURE COMPRESSION ALGORITHM 'MEDIUM' AS OF RELEASE 'DEFAULT' OPTIMIZE FOR LOAD TRUE;

-- Backup optimization: skip files already backed up with same checkpoint
CONFIGURE BACKUP OPTIMIZATION ON;

-- Archive log deletion policy: delete logs after backed up 2 times
-- (once to FRA, once to secondary location)
CONFIGURE ARCHIVELOG DELETION POLICY TO BACKED UP 2 TIMES TO DISK;

-- Encryption (recommended for sensitive data)
CONFIGURE ENCRYPTION FOR DATABASE ON;
CONFIGURE ENCRYPTION ALGORITHM 'AES256';

৪. ব্যাকআপের ধরন এবং কখন কোনটি ব্যবহার করবেন

৪.১ Full Backup

একটি full backup ডেটাবেজের ব্যবহৃত প্রতিটি ব্লক কপি করে। এটি সবচেয়ে সম্পূর্ণ ব্যাকআপ, তবে সবচেয়ে বড় ও ধীরতমও। একটি প্রোডাকশন পরিবেশে বড় ডেটাবেজের জন্য প্রতি রাতে সত্যিকারের full backup নেওয়া প্রায়ই অবাস্তব। full backup-কে একটি incremental ব্যাকআপ কৌশলের ভিত্তি হিসেবে ব্যবহার করুন — একমাত্র ব্যাকআপের ধরন হিসেবে নয়।

৪.২ Incremental Level 0 Backup

একটি incremental level 0 কার্যত একটি full backup — এটি সব ব্যবহৃত ব্লক কপি করে — কিন্তু এটি পরবর্তী incremental level 1 ব্যাকআপগুলোর ভিত্তি হিসেবে কাজ করে। এই পার্থক্যটি গুরুত্বপূর্ণ কারণ RMAN একটি level 0-এর উপর level 1 incremental ব্যাকআপ প্রয়োগ করে ব্যাকআপটিকে আরও সাম্প্রতিক সময়ে roll forward করতে পারে, নতুন করে full backup না নিয়েই।

৪.৩ Incremental Level 1 Backup

একটি incremental level 1 কেবল সেই ব্লকগুলোই কপি করে যা শেষ level 0 বা level 1 ব্যাকআপের পর পরিবর্তিত হয়েছে। প্রোডাকশনে এটিই সবচেয়ে বেশি ব্যবহৃত incremental ধরন। মাঝারি দৈনিক পরিবর্তন হারযুক্ত একটি ডেটাবেজের জন্য একটি level 1 ব্যাকআপ সাধারণত level 0-এর আকারের ২–১৫%।

৪.৪ Incrementally Updated Backup (Block Change Tracking)

বড় প্রোডাকশন ডেটাবেজের জন্য সবচেয়ে দক্ষ কৌশল। Block Change Tracking চালু থাকলে, Oracle একটি ফাইল রক্ষণাবেক্ষণ করে যা ঠিক কোন কোন ব্লক পরিবর্তিত হয়েছে তা রেকর্ড করে — ফলে incremental ব্যাকআপের সময় পরিবর্তিত ব্লক শনাক্ত করতে RMAN-কে পুরো ডেটাবেজ স্ক্যান করার প্রয়োজন হয় না।

-- Enable Block Change Tracking (recommended for databases > 100 GB)
ALTER DATABASE ENABLE BLOCK CHANGE TRACKING
  USING FILE '/backup/rman/change_tracking.ctf';

৫. প্রস্তাবিত প্রোডাকশন ব্যাকআপ কৌশল

ব্যাংক, ফার্মা কোম্পানি, ম্যানুফ্যাকচারার এবং সফটওয়্যার ফার্মে ১৮ বছর Oracle ব্যাকআপ কৌশল পরিচালনার পর, বেশিরভাগ প্রতিষ্ঠানের জন্য আমি এই প্রোডাকশন ব্যাকআপ সূচিটি সুপারিশ করি:

সূচি	ব্যাকআপের ধরন	এটি যা করে
রবিবার ০১:০০	Level 0 + Archive logs	সাপ্তাহিক full baseline — সপ্তাহের বৃহত্তম ব্যাকআপ
সোম–শনি ০১:০০	Level 1 + Archive logs	দৈনিক incremental — কেবল পরিবর্তিত ব্লক ব্যাকআপ করে
প্রতি ৪ ঘণ্টায়	Archive log backup	RPO ৪ ঘণ্টার নিচে নামায়; FRA ভরে যাওয়া ঠেকায়
যেকোনো DDL-এর পর	Control file autobackup	স্বয়ংক্রিয় — CONFIGURE CONTROLFILE AUTOBACKUP ON দ্বারা ট্রিগার হয়

-- Level 0 backup script (Sunday)
run {
  ALLOCATE CHANNEL ch1 DEVICE TYPE DISK FORMAT '/backup/rman/%d_%T_%U';
  ALLOCATE CHANNEL ch2 DEVICE TYPE DISK FORMAT '/backup/rman/%d_%T_%U';
  ALLOCATE CHANNEL ch3 DEVICE TYPE DISK FORMAT '/backup/rman/%d_%T_%U';
  ALLOCATE CHANNEL ch4 DEVICE TYPE DISK FORMAT '/backup/rman/%d_%T_%U';
  BACKUP AS COMPRESSED BACKUPSET INCREMENTAL LEVEL 0
    DATABASE PLUS ARCHIVELOG DELETE INPUT;
  BACKUP CURRENT CONTROLFILE;
  DELETE NOPROMPT OBSOLETE;
}

-- Level 1 backup script (Monday–Saturday)
run {
  ALLOCATE CHANNEL ch1 DEVICE TYPE DISK FORMAT '/backup/rman/%d_%T_%U';
  ALLOCATE CHANNEL ch2 DEVICE TYPE DISK FORMAT '/backup/rman/%d_%T_%U';
  BACKUP AS COMPRESSED BACKUPSET INCREMENTAL LEVEL 1
    DATABASE PLUS ARCHIVELOG DELETE INPUT;
  DELETE NOPROMPT OBSOLETE;
}

-- Archive log only backup (every 4 hours)
run {
  BACKUP ARCHIVELOG ALL NOT BACKED UP 1 TIMES DELETE INPUT;
}

৬. Fast Recovery Area (FRA)

Fast Recovery Area হলো ব্যাকআপ ও রিকভারি ফাইলের জন্য Oracle-পরিচালিত ডিস্ক স্পেস। এটি সঠিকভাবে কনফিগার করুন, তাহলে এটি ব্যাকআপ ব্যবস্থাপনা নাটকীয়ভাবে সহজ করে দেয়।

-- Set FRA location and size (size should be 2–3× database size minimum)
ALTER SYSTEM SET DB_RECOVERY_FILE_DEST = '/fra' SCOPE=BOTH;
ALTER SYSTEM SET DB_RECOVERY_FILE_DEST_SIZE = 500G SCOPE=BOTH;

-- Monitor FRA usage (alert when > 80% full)
SELECT NAME, SPACE_LIMIT/1024/1024/1024 AS SIZE_GB,
       SPACE_USED/1024/1024/1024 AS USED_GB,
       ROUND(SPACE_USED/SPACE_LIMIT*100,1) AS PCT_USED
FROM V$RECOVERY_FILE_DEST;

FRA-এর ব্যবহার ৮০% ছাড়ালে একটি alert সেট করুন। একটি পূর্ণ FRA Oracle-কে archive log লিখতে বাধা দেয় — যা ডেটাবেজ থামিয়ে দেয়। অপরিকল্পিত প্রোডাকশন আউটেজের সবচেয়ে সাধারণ কারণগুলোর একটি এটি, যা পুরোপুরি প্রতিরোধযোগ্য।

৭. Archive Log ব্যবস্থাপনা

Archive log হলো ব্যাকআপগুলোর মধ্যকার সেতু। যেকোনো সময়ে রিকভার করতে হলে আপনার সর্বশেষ ব্যাকআপের পাশাপাশি সেই ব্যাকআপের পর তৈরি হওয়া সব archive log দরকার। archive log হারানো আপনার রিকভারির বিকল্পগুলো সীমিত করে দেয় — সম্ভবত সর্বশেষ ব্যাকআপ থেকে একটি full database restore পর্যন্ত, যেখানে সেই ব্যাকআপের পর করা সব ডেটা পরিবর্তন হারানো হিসেবে মেনে নিতে হয়।

৭.১ Archive Log ধরে রাখার নিয়ম

• আপনার রিকভারি উইন্ডো না বুঝে কখনও ম্যানুয়ালি archive log মুছবেন না
• ARCHIVELOG DELETION POLICY এমনভাবে সেট করুন যাতে RMAN কেবল সেই log-ই মোছে যা এটি নিরাপদে ব্যাকআপ করেছে
• archive log অন্তত ততক্ষণ ধরে রাখুন যতটা আপনার Data Guard standby-এর apply lag (Data Guard পরিবেশে)
• archive log তৈরির হার মনিটর করুন — হঠাৎ বৃদ্ধি অস্বাভাবিক কার্যকলাপ নির্দেশ করে (batch job, bulk load, বা সম্ভাব্য সমস্যা)

৭.২ Archive Log গন্তব্য মনিটরিং

-- Check archive log generation rate over last 7 days
SELECT TRUNC(COMPLETION_TIME,'DD') AS backup_date,
       COUNT(*) AS log_count,
       ROUND(SUM(BLOCKS*BLOCK_SIZE)/1024/1024/1024,2) AS size_gb
FROM V$ARCHIVED_LOG
WHERE COMPLETION_TIME > SYSDATE - 7
  AND STANDBY_DEST = 'NO'
GROUP BY TRUNC(COMPLETION_TIME,'DD')
ORDER BY 1;

৮. রিকভারি পরিস্থিতি — যখন কিছু ভুল হয়, তখন যে কমান্ডগুলো আপনার দরকার

তত্ত্ব মূল্যবান; রাত ২টায় রিকভারি কমান্ড অমূল্য। এখানে সবচেয়ে সাধারণ রিকভারি পরিস্থিতিগুলো সঠিক RMAN syntax-সহ দেওয়া হলো।

৮.১ সম্পূর্ণ ডেটাবেজ রিকভারি (মোট ক্ষতির পর)

-- Restore and recover the complete database
RMAN> STARTUP NOMOUNT;
RMAN> RESTORE CONTROLFILE FROM AUTOBACKUP;
RMAN> ALTER DATABASE MOUNT;
RMAN> RESTORE DATABASE;
RMAN> RECOVER DATABASE;
RMAN> ALTER DATABASE OPEN RESETLOGS;

৮.২ Point-in-Time Recovery (PITR)

যখন আপনার একটি নির্দিষ্ট সময়ে রিকভার করতে হয় তখন এটি ব্যবহৃত হয় — যেমন, একটি ক্ষতিকর bulk delete বা data corruption ঘটনার আগে।

-- Recover database to specific time (e.g., 09:47 AM yesterday)
RMAN> STARTUP MOUNT;
RMAN> SET UNTIL TIME "TO_DATE('2026-06-03 09:47:00','YYYY-MM-DD HH24:MI:SS')";
RMAN> RESTORE DATABASE;
RMAN> RECOVER DATABASE;
RMAN> ALTER DATABASE OPEN RESETLOGS;

৮.৩ Tablespace Point-in-Time Recovery (TSPITR)

ডেটাবেজের বাকি অংশ স্পর্শ না করে একটি একক tablespace-কে নির্দিষ্ট সময়ে রিকভার করুন — যখন data corruption নির্দিষ্ট টেবিলে সীমাবদ্ধ থাকে তখন উপযোগী।

-- Recover a single tablespace to a point in time
RMAN> RECOVER TABLESPACE erp_data
  UNTIL TIME "TO_DATE('2026-06-03 09:47:00','YYYY-MM-DD HH24:MI:SS')"
  AUXILIARY DESTINATION '/tmp/tspitr_aux';

৮.৪ একক Datafile রিকভারি

-- Take datafile offline, restore, recover, bring back online
SQL> ALTER DATABASE DATAFILE '/oradata/erp/erp_data01.dbf' OFFLINE;
RMAN> RESTORE DATAFILE '/oradata/erp/erp_data01.dbf';
RMAN> RECOVER DATAFILE '/oradata/erp/erp_data01.dbf';
SQL> ALTER DATABASE DATAFILE '/oradata/erp/erp_data01.dbf' ONLINE;

৮.৫ Block-স্তরের রিকভারি

datafile-এর বাকি অংশ স্পর্শ না করে নির্দিষ্ট corrupt ডেটাবেজ ব্লক রিকভার করুন — corruption যখন কয়েকটি ব্লকে সীমাবদ্ধ, তখন এটিই দ্রুততম রিকভারি বিকল্প।

-- Identify corrupt blocks
SELECT FILE#, BLOCK#, BLOCKS, CORRUPTION_TYPE
FROM V$DATABASE_BLOCK_CORRUPTION;

-- Recover only the corrupt blocks
RMAN> BLOCKRECOVER CORRUPTION LIST;

৮.৬ একটি Drop হওয়া টেবিল রিকভার করা (Flashback)

যদি Flashback Database চালু থাকে এবং drop হওয়া টেবিলটি flashback retention উইন্ডোর মধ্যে থাকে, তাহলে RMAN-এর পরিবর্তে Flashback Table ব্যবহার করুন — এটি দ্রুততর এবং ডেটাবেজ offline নেওয়ার প্রয়োজন হয় না।

-- Flashback a dropped table (much faster than RMAN for this scenario)
FLASHBACK TABLE erp.products TO TIMESTAMP
  TO_TIMESTAMP('2026-06-03 09:47:00','YYYY-MM-DD HH24:MI:SS');

-- Or if table was dropped with PURGE (no recycle bin):
-- Use RMAN TSPITR or full PITR

৯. আপনার ব্যাকআপ টেস্ট করা — সবচেয়ে গুরুত্বপূর্ণ যে কাজটি আপনি করছেন না

যে ব্যাকআপ কখনও টেস্ট করা হয়নি সেটি ব্যাকআপ নয় — সেটি একটি অনুমান। আমি এমন প্রতিষ্ঠান দেখেছি যারা আবিষ্কার করেছে তাদের ব্যাকআপ সপ্তাহের পর সপ্তাহ নীরবে ব্যর্থ হচ্ছিল, ঠিক যখন তাদের সত্যিই সেটি দরকার হয়েছিল তখনই। ব্যাকআপ job সফল বলে রিপোর্ট করেছিল; RMAN একটি পূর্ণ ডিস্কে লিখছিল আর সেই লেখাগুলো নীরবে বাতিল হচ্ছিল। ব্যাকআপ ফাইলগুলো ছিল কিন্তু অব্যবহারযোগ্য।

প্রোডাকশন ব্যাকআপ টেস্টিং সূচি আমি যা সুপারিশ করি:

৯.১ সাপ্তাহিক — RMAN VALIDATE

ব্যাকআপ ফাইলগুলো পড়া যাচ্ছে ও সম্পূর্ণ কিনা তার একটি অ-ধ্বংসাত্মক পরীক্ষা। কয়েক মিনিট লাগে। প্রতিটি ব্যাকআপের পর স্বয়ংক্রিয়ভাবে চলা উচিত।

-- Validate all backups (run weekly)
RMAN> VALIDATE BACKUPSET ALL;
RMAN> VALIDATE DATABASE;

৯.২ মাসিক — বিকল্প স্থানে টেস্ট রিস্টোর

ডেটাবেজটি একটি আলাদা সার্ভার বা ডিরেক্টরিতে রিস্টোর করুন। নিশ্চিত করুন আপনি OPEN RESETLOGS পর্যায়ে পৌঁছাতে পারছেন। সময়টি নথিভুক্ত করুন — এটিই আপনার প্রকৃত RTO, কোনো অনুমান নয়।

-- Restore to alternate location (test only — do not open with RESETLOGS on production)
RMAN> SET DBID <target_dbid>;
RMAN> STARTUP NOMOUNT;
RMAN> RESTORE CONTROLFILE FROM '/backup/rman/c-<dbid>-<date>-00';
RMAN> ALTER DATABASE MOUNT;
RMAN> SET NEWNAME FOR DATABASE TO '/restore_test/oradata/%b';
RMAN> RESTORE DATABASE;
RMAN> RECOVER DATABASE;
-- Verify up to OPEN RESETLOGS point then shut down without opening

৯.৩ ত্রৈমাসিক — সম্পূর্ণ DR মহড়া

সম্পূর্ণ ডেটাবেজটি DR পরিবেশে রিস্টোর করুন, অ্যাপ্লিকেশন সংযোগসহ। যাচাই করুন যে অ্যাপ্লিকেশন সংযুক্ত হচ্ছে এবং মূল লেনদেনগুলো কাজ করছে। একজন QA সাক্ষীর সাথে মহড়াটি sign off করুন (validated পরিবেশে বাধ্যতামূলক)। অর্জিত RTO বনাম লক্ষ্য RTO নথিভুক্ত করুন।

১০. RMAN মনিটরিং — প্রতিদিন কী দেখবেন

-- 1. Check last backup status (run this every morning)
SELECT SESSION_KEY, INPUT_TYPE, STATUS,
       TO_CHAR(START_TIME,'DD-MON-YYYY HH24:MI') AS start_time,
       TO_CHAR(END_TIME,'DD-MON-YYYY HH24:MI') AS end_time,
       ELAPSED_SECONDS/60 AS duration_min
FROM V$RMAN_BACKUP_JOB_DETAILS
WHERE START_TIME > SYSDATE - 2
ORDER BY START_TIME DESC;

-- 2. Check FRA usage
SELECT NAME,
       ROUND(SPACE_LIMIT/1024/1024/1024,1) AS limit_gb,
       ROUND(SPACE_USED/1024/1024/1024,1) AS used_gb,
       ROUND(SPACE_USED/SPACE_LIMIT*100,1) AS pct_used
FROM V$RECOVERY_FILE_DEST;

-- 3. Check for any backup failures
SELECT OBJECT_TYPE, STATUS, COMPLETION_TIME, OUTPUT_BYTES/1024/1024 AS mb
FROM V$BACKUP_SET_DETAILS
WHERE COMPLETION_TIME > SYSDATE - 1
ORDER BY COMPLETION_TIME DESC;

-- 4. Verify archive logs are being backed up
SELECT MAX(COMPLETION_TIME) AS last_archlog_backup
FROM V$ARCHIVED_LOG
WHERE BACKUP_COUNT > 0;

১১. প্রোডাকশনে সাধারণ RMAN ভুল

• Recovery catalog নেই: control file-ই ব্যাকআপের একমাত্র রেকর্ড — এটি হারালে ব্যাকআপ ইতিহাসও হারিয়ে যায়
• ডেটাবেজের একই সার্ভারে ব্যাকআপ নেওয়া: একটি সার্ভার ব্যর্থতা একসাথে ডেটাবেজ ও ব্যাকআপ দুটোই নিয়ে নেয়
• Archive log ব্যাকআপ নেই: archive log ছাড়া full database backup মানে রিকভারি কেবল ব্যাকআপ পয়েন্ট পর্যন্ত পৌঁছাতে পারে, তার বেশি নয়
• FRA মনিটর করা হয় না: FRA নীরবে ভরে যায়, archive log লেখা থামে, ডেটাবেজ থেমে যায়
• ব্যাকআপ কখনও টেস্ট করা হয়নি: সবচেয়ে খারাপ মুহূর্তে আবিষ্কার হয় যে রিকভারি নষ্ট
• ব্যবসায়িক সময়ে RMAN job চালানো: ব্যাকআপ I/O প্রোডাকশন পারফরম্যান্স নষ্ট করে — সবচেয়ে কম কার্যকলাপের সময়ে ব্যাকআপ সূচি করুন
• Offsite কপি নেই: অন-সাইট ব্যাকআপ আগুন, বন্যা বা ransomware থেকে সুরক্ষা দেয় না, যেখানে ব্যাকআপ সার্ভারও encrypt হয়ে যেতে পারে
• ব্যাকআপ শেষ হওয়ার আগে archive log-এ DELETE INPUT: ব্যাকআপ মাঝপথে ব্যর্থ হলে archive log চলে যায় এবং রিকভারি উইন্ডোতে একটি ফাঁক তৈরি হয়

১২. RMAN এবং Oracle Data Guard — Standby-তে ব্যাকআপ নেওয়া

যদি আপনার Oracle Data Guard থাকে, তাহলে আপনার একটি উল্লেখযোগ্য ব্যাকআপ অপ্টিমাইজেশনের সুযোগ আছে: primary-এর পরিবর্তে physical standby থেকে RMAN ব্যাকআপ নিন। এটি প্রোডাকশন সিস্টেম থেকে ব্যাকআপ I/O পুরোপুরি সরিয়ে দেয়।

-- Connect RMAN to standby for backup (offloads primary)
RMAN> CONNECT TARGET sys@primary_db
RMAN> CONNECT AUXILIARY sys@standby_db

-- Back up on standby, usable for primary recovery
RMAN> BACKUP AS COMPRESSED BACKUPSET
        DEVICE TYPE DISK
        DATABASE
        PLUS ARCHIVELOG;

RMAN Data Guard সম্পর্কটি বোঝে এবং জানে যে standby-তে নেওয়া ব্যাকআপ primary ডেটাবেজ রিকভার করার জন্য বৈধ। Oracle DBA অনুশীলনে এটি সবচেয়ে কম ব্যবহৃত অপ্টিমাইজেশনগুলোর একটি।

শেষ কথা

ব্যাকআপ হলো DBA-এর সবচেয়ে মৌলিক দায়িত্ব — এবং সবচেয়ে বেশি অবহেলিত বিনিয়োগ। প্রতিটি ডেটাবেজ অ্যাডমিনিস্ট্রেটর জানেন তাঁদের একটি শক্ত ব্যাকআপ কৌশল থাকা উচিত। অনেক কম মানুষই আসলে সেটি end-to-end টেস্ট করেছেন, একটানা মনিটর করেছেন এবং ব্যবসার প্রকৃত প্রয়োজনের বিপরীতে রিকভারি সময় নিশ্চিত করেছেন।

যে DBA তাঁর রিকভারি টেস্ট করেছেন আর যিনি করেননি — তাঁদের মধ্যে পার্থক্য একটি স্বাভাবিক দিনে বোঝা যায় না। যেদিন কিছু ভুল হয়, সেদিন তা খুব স্পষ্ট হয়ে ওঠে। আপনার ব্যাকআপ টেস্ট করুন। আপনার FRA মনিটর করুন। archive log নিরাপদে ব্যাকআপ করে রাখুন। আর যদি Data Guard থাকে, ব্যাকআপ I/O-এর জন্য standby ব্যবহার করুন — আপনার primary ডেটাবেজ এর জন্য আপনাকে ধন্যবাদ জানাবে।