নীরব ঘাতক: বিপর্যয় ঘটার আগেই কীভাবে দূষিত ডাটাবেস ব্যাকআপ শনাক্ত করবেন

ডেটাবেস অ্যাডমিনিস্ট্রেশন এবং সাইট রিলায়েবিলিটি ইঞ্জিনিয়ারিংয়ের উচ্চ-ঝুঁকিপূর্ণ জগতে একটি সুপরিচিত প্রবাদ আছে: শ্রোডিঞ্জারের ব্যাকআপ (Schrödinger’s Backup)। কোনো ব্যাকআপের অবস্থা ততক্ষণ পর্যন্ত অজানা থাকে যতক্ষণ না আপনি সেটি রিস্টোর করার চেষ্টা করেন। সেই মুহূর্ত পর্যন্ত, এটি একটি কোয়ান্টাম অবস্থায় থাকে—অর্থাৎ একই সাথে পুরোপুরি কার্যকর এবং সম্পূর্ণভাবে ক্ষতিগ্রস্ত।

ডেভঅপস (DevOps) ইঞ্জিনিয়ার এবং ডিবিএ (DBA)-দের জন্য, একটি সক্রিয় ইনসিডেন্টের সময় গুরুত্বপূর্ণ ডেটাবেস ব্যাকআপ ক্ষতিগ্রস্ত অবস্থায় পাওয়াটা সবচেয়ে ভয়াবহ পরিস্থিতি। এটি একটি সাধারণ রিকভারি অপারেশনকে বিপর্যয়কর ডেটা হারানোর ঘটনায় রূপান্তর করে। ডেটা ইন্টিগ্রিটির এই “নীরব ঘাতক” প্রায়শই অলক্ষ্যে থেকে যায়, কারণ ব্যাকআপ জবগুলো প্রায়শই সফল Exit Code 0 রিপোর্ট করে, এমনকি যখন মূল ডেটা ক্ষতিগ্রস্ত থাকে।

এই বিস্তারিত নির্দেশিকায়, আমরা ব্যাকআপ দুর্নীতির (corruption) গঠন বিশ্লেষণ করব, ডেটাবেস-নির্দিষ্ট ভ্যালিডেশন কৌশলগুলো অন্বেষণ করব এবং প্রোডাকশন এনভায়রনমেন্টের জন্য কীভাবে স্বয়ংক্রিয়, অভেদ্য রিস্টোর পাইপলাইন তৈরি করা যায় তা প্রদর্শন করব।

ব্যাকআপ দুর্নীতির গঠন

দুর্নীতি শনাক্ত করতে, আপনাকে প্রথমে বুঝতে হবে এটি কীভাবে ঘটে। ব্যাকআপ দুর্নীতি সাধারণত দুটি বিভাগে পড়ে: ফিজিক্যাল (ইনফ্রাস্ট্রাকচার-লেভেল) এবং লজিক্যাল (অ্যাপ্লিকেশন-লেভেল)।

ফিজিক্যাল দুর্নীতি

ফিজিক্যাল দুর্নীতি ঘটে যখন স্টোরেজ মিডিয়ামের প্রকৃত বিটগুলো পরিবর্তিত হয়। এটি সোর্স ডিস্ক থেকে পড়ার সময়, নেটওয়ার্ক ট্রানজিটের সময় বা টার্গেট স্টোরেজে থাকার সময় ঘটতে পারে।
* বিট রট (Bit Rot): স্টোরেজ মিডিয়ামের ধীরে ধীরে অবনতির ফলে বিটগুলো নীরবে পরিবর্তিত হতে পারে।
* ট্রানজিট এরর: যদিও টিসিপি (TCP)-তে চেকসাম থাকে, তবে সেগুলো অত্যন্ত দুর্বল (১৬-বিট)। হাই-থ্রুপুট এনভায়রনমেন্টে তারের মধ্য দিয়ে যাওয়ার সময় নীরব ডেটা দুর্নীতি হতে পারে যা টিসিপি ধরতে পারে না।
* স্টোরেজ কন্ট্রোলার ফল্ট: আরএআইডি (RAID) কন্ট্রোলার বা স্যান (SAN) ফ্যাব্রিকের হার্ডওয়্যার ত্রুটির কারণে ওএস (OS)-কে সফলতার রিপোর্ট দেওয়ার সময়ও ভুল ডেটা লেখা হতে পারে।

লজিক্যাল দুর্নীতি

লজিক্যাল দুর্নীতি সম্ভবত বেশি বিপজ্জনক কারণ ব্যাকআপ ফাইলটি অক্ষত থাকে, কিন্তু ভেতরের ডেটা নষ্ট থাকে।
* গার্বেজ ইন, গার্বেজ আউট (GIGO): যদি আপনার লাইভ ডেটাবেসে একটি ক্ষতিগ্রস্ত ইনডেক্স বা টর্ন পেজ থাকে, তবে আপনার ব্যাকআপ টুলটি বিশ্বস্ততার সাথে সেই ক্ষতিগ্রস্ত পেজটিই কপি করবে। ব্যাকআপ জব সফল হবে, কিন্তু রিস্টোর ব্যর্থ হবে বা একটি অকেজো ডেটাবেস তৈরি হবে।
* অসম্পূর্ণ ট্রানজ্যাকশন: ডেটাবেস আই/ও (I/O) সঠিকভাবে ফ্রিজ না করে ফাইল-সিস্টেম লেভেলের স্ন্যাপশট নিলে (যেমন: মাইএসকিউএল-এ FLUSH TABLES WITH READ LOCK ব্যবহার না করা) টর্ন পেজ এবং রিকভারি অযোগ্য অবস্থার সৃষ্টি হয়।

প্রোঅ্যাক্টিভ ডিটেকশন: চেকসাম এবং ক্রিপ্টোগ্রাফিক হ্যাশিং

ফিজিক্যাল দুর্নীতির বিরুদ্ধে সুরক্ষার প্রথম ধাপ হলো ক্রিপ্টোগ্রাফিক ভ্যালিডেশন। ফাইলের আকার বা পরিবর্তনের তারিখের ওপর নির্ভর করা যথেষ্ট নয়।

ডেটাবেস-লেভেল চেকসাম সক্ষম করা

আধুনিক রিলেশনাল ডেটাবেস ম্যানেজমেন্ট সিস্টেম (RDBMS) পেজ-লেভেল চেকসাম সমর্থন করে। এটি সক্ষম থাকলে, ডেটাবেস ডিস্কে লেখার আগে প্রতিটি পেজের জন্য একটি চেকসাম গণনা করে। যখন পেজটি পড়া হয় (কোয়েরি বা ব্যাকআপ প্রক্রিয়ার মাধ্যমে), তখন চেকসাম যাচাই করা হয়।

PostgreSQL-এর জন্য, আপনি ক্লাস্টার ইনিশিয়ালাইজেশনের সময় ডেটা চেকসাম সক্ষম করতে পারেন:

# চেকসাম সক্ষম করে একটি নতুন PostgreSQL ক্লাস্টার ইনিশিয়ালাইজ করুন
initdb --data-checksums -D /var/lib/postgresql/data

দ্রষ্টব্য: যদি আপনার বিদ্যমান PostgreSQL ক্লাস্টার থাকে, তবে আপনি অফলাইনে সেগুলো সক্ষম করতে pg_checksums ইউটিলিটি ব্যবহার করতে পারেন।

Microsoft SQL Server-এর জন্য, নিশ্চিত করুন যে PAGE_VERIFY-কে CHECKSUM-এ সেট করা আছে (আধুনিক ভার্সনে এটি ডিফল্ট, তবে পুরনো সিস্টেমে যাচাই করা উচিত):

ALTER DATABASE [ProductionDB] SET PAGE_VERIFY CHECKSUM;
GO

স্টোরেজে ব্যাকআপ যাচাইকরণ

একবার ব্যাকআপ আপনার স্টোরেজ টার্গেটে পৌঁছালে, এর ইন্টিগ্রিটি ক্রিপ্টোগ্রাফিকভাবে যাচাই করতে হবে। ক্লাউডসেভ (CloudSave)-এর মতো এন্টারপ্রাইজ ব্যাকআপ প্ল্যাটফর্মগুলো ট্রানজিট এবং স্টোরেজে থাকার সময় স্বয়ংক্রিয়ভাবে ব্যাকআপ ব্লকের SHA-256 হ্যাশ গণনা এবং যাচাই করে। আপনি যদি কাস্টম স্ক্রিপ্ট পরিচালনা করেন, তবে আপনাকে এটি ম্যানুয়ালি বাস্তবায়ন করতে হবে:

# ব্যাকআপ তৈরির পর SHA-256 হ্যাশ তৈরি করুন
sha256sum prod_db_backup.tar.gz > prod_db_backup.tar.gz.sha256

# স্টোরেজ সার্ভারে হ্যাশ যাচাই করুন
sha256sum -c prod_db_backup.tar.gz.sha256

ডেটাবেস-নির্দিষ্ট ভ্যালিডেশন কৌশল

বিভিন্ন ডেটাবেস ইঞ্জিন তাদের ব্যাকআপ আর্টিফ্যাক্টগুলোর ইন্টিগ্রিটি যাচাই করার জন্য নেটিভ টুল অফার করে।

PostgreSQL: pg_verifybackup

PostgreSQL 13-এ প্রবর্তিত, pg_verifybackup হলো pg_basebackup দিয়ে নেওয়া ফিজিক্যাল ব্যাকআপের জন্য একটি গেম-চেঞ্জার। এটি ব্যাকআপের সময় তৈরি backup_manifest ফাইলটি পড়ে এবং যাচাই করে যে সমস্ত ফাইল উপস্থিত আছে এবং তাদের চেকসাম মিলে যাচ্ছে কি না।

# একটি ফিজিক্যাল বেস ব্যাকআপ ডিরেক্টরির বিপরীতে ভেরিফিকেশন চালান
pg_verifybackup /mnt/backups/postgres/base_backup_20231025/

যদি ডেটা ফাইলগুলোর কোনো একটিতে একটি বিটও পরিবর্তিত হয়, তবে pg_verifybackup একটি ফ্যাটাল এরর দেবে, যা আপনার মনিটরিং সিস্টেমকে অবিলম্বে ডিবিএ টিমকে সতর্ক করার সুযোগ দেবে।

Microsoft SQL Server: RESTORE VERIFYONLY

এসকিউএল সার্ভার একটি ব্যাকআপ ফাইল রিস্টোর না করেই তার ফিজিক্যাল ইন্টিগ্রিটি যাচাই করার জন্য একটি নেটিভ কমান্ড প্রদান করে। এটি ব্যাকআপ হেডার পরীক্ষা করে এবং পেজ চেকসাম যাচাই করে (যদি ব্যাকআপের সময় সেগুলো সক্ষম করা থাকে)।

RESTORE VERIFYONLY 
FROM DISK = 'Z:BackupsProdDB_Full.bak' 
WITH CHECKSUM;

সতর্কতা: RESTORE VERIFYONLY শুধুমাত্র নিশ্চিত করে যে ব্যাকআপ ফাইলটি পড়া যাচ্ছে এবং ফিজিক্যাল চেকসাম মিলেছে। এটি লজিক্যাল ইন্টিগ্রিটির নিশ্চয়তা দেয় না। লজিক্যাল ইন্টিগ্রিটি নিশ্চিত করতে, আপনাকে অবশ্যই একটি সম্পূর্ণ রিস্টোর করতে হবে এবং DBCC CHECKDB চালাতে হবে।

MySQL / InnoDB: Percona XtraBackup

MySQL এনভায়রনমেন্টের জন্য, ফিজিক্যাল ব্যাকআপ প্রায়শই Percona XtraBackup দ্বারা পরিচালিত হয়। ব্যাকআপ প্রক্রিয়ায় ফাইল কপি করা অন্তর্ভুক্ত, কিন্তু ট্রানজ্যাকশন লগ (redo logs) প্রয়োগ না করা পর্যন্ত ব্যাকআপটি সামঞ্জস্যপূর্ণ হয় না। --prepare ধাপটি একটি বিল্ট-ইন ইন্টিগ্রিটি চেক হিসেবে কাজ করে।

# ব্যাকআপ প্রস্তুত করার সময় রিডু লগ প্রয়োগ করা হয়। 
# যদি ব্যাকআপ ক্ষতিগ্রস্ত হয়, তবে এই ধাপটি ব্যর্থ হবে।
xtrabackup --prepare --target-dir=/data/backups/mysql/

গোল্ড স্ট্যান্ডার্ড: স্বয়ংক্রিয় রিস্টোর টেস্টিং

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

ব্যাকআপকে কোড হিসেবে বিবেচনা করে, আপনি আপনার ডেটাবেস রিস্টোরের জন্য একটি সিআই/সিডি (CI/CD) পাইপলাইন তৈরি করতে পারেন। এই পাইপলাইনটি অস্থায়ী ইনফ্রাস্ট্রাকচার তৈরি করবে, রিস্টোর সম্পাদন করবে, ভ্যালিডেশন কোয়েরি চালাবে এবং এনভায়রনমেন্টটি মুছে ফেলবে।

স্বয়ংক্রিয় রিস্টোর পাইপলাইন তৈরি

নিচে একটি ব্যাশ স্ক্রিপ্টের উদাহরণ দেওয়া হলো যা একটি পোস্টগ্রেএসকিউএল লজিক্যাল ডাম্প যাচাই করার জন্য ক্রন জব বা সিআই রানার (যেমন GitLab CI বা GitHub Actions) দ্বারা প্রতিদিন ট্রিগার করা যেতে পারে।

#!/bin/bash
set -e

BACKUP_FILE="/mnt/storage/prod_db_latest.dump"
DB_NAME="prod_db"
CONTAINER_NAME="pg_restore_test"

echo "[INFO] স্বয়ংক্রিয় রিস্টোর টেস্ট শুরু হচ্ছে..."

# ১. একটি অস্থায়ী PostgreSQL কন্টেইনার চালু করুন
docker run --name $CONTAINER_NAME 
  -e POSTGRES_PASSWORD=testpass 
  -d postgres:15

# PostgreSQL প্রস্তুত হওয়ার জন্য অপেক্ষা করুন
echo "[INFO] ডেটাবেস ইনিশিয়ালাইজ হওয়ার জন্য অপেক্ষা করা হচ্ছে..."
until docker exec $CONTAINER_NAME pg_isready -U postgres; do
  sleep 2
done

# ২. টার্গেট ডেটাবেস তৈরি করুন
docker exec $CONTAINER_NAME psql -U postgres -c "CREATE DATABASE $DB_NAME;"

# ৩. রিস্টোর সম্পাদন করুন
echo "[INFO] ব্যাকআপ রিস্টোর করা হচ্ছে..."
docker cp $BACKUP_FILE $CONTAINER_NAME:/tmp/backup.dump
docker exec $CONTAINER_NAME pg_restore -U postgres -d $DB_NAME -1 /tmp/backup.dump

# ৪. লজিক্যাল ভ্যালিডেশন কোয়েরি চালান
echo "[INFO] ভ্যালিডেশন কোয়েরি চালানো হচ্ছে..."
# চেক করুন ইউজার টেবিলে ১০,০০০-এর বেশি রেকর্ড আছে কি না
USER_COUNT=$(docker exec $CONTAINER_NAME psql -U postgres -d $DB_NAME -t -c "SELECT COUNT(*) FROM users;")

if [ "$USER_COUNT" -lt 10000 ]; then
    echo "[ERROR] লজিক্যাল ভ্যালিডেশন ব্যর্থ হয়েছে। প্রত্যাশিত >10000 ইউজার, পাওয়া গেছে $USER_COUNT"
    # এখানে PagerDuty / Slack অ্যালার্ট ট্রিগার করুন
    exit 1
else
    echo "[SUCCESS] লজিক্যাল ভ্যালিডেশন সফল। ইউজারের সংখ্যা: $USER_COUNT"
fi

# ৫. অস্থায়ী এনভায়রনমেন্ট মুছে ফেলুন
echo "[INFO] ক্লিনআপ করা হচ্ছে..."
docker rm -f $CONTAINER_NAME

echo "[INFO] স্বয়ংক্রিয় রিস্টোর টেস্ট সফলভাবে সম্পন্ন হয়েছে।"

আপনার কী যাচাই করা উচিত?

স্বয়ংক্রিয় রিস্টোর টেস্টিং করার সময়, শুধুমাত্র ডেটাবেস চালু হচ্ছে কি না তা পরীক্ষা করবেন না। অ্যাপ্লিকেশন-নির্দিষ্ট ভ্যালিডেশন কোয়েরি চালান:
১. রো কাউন্ট (Row Counts): নিশ্চিত করুন যে মূল টেবিলগুলোতে প্রত্যাশিত সংখ্যক সারি আছে (যেমন, users টেবিল খালি থাকা উচিত নয়)।
২. সাম্প্রতিক ডেটা: গত ২৪ ঘণ্টায় তৈরি রেকর্ডগুলোর জন্য কোয়েরি করুন যাতে নিশ্চিত হওয়া যায় যে ব্যাকআপটি পুরনো নয়।
৩. রেফারেন্সিয়াল ইন্টিগ্রিটি: অনাথ ফরেন কি (orphaned foreign keys) চেক করার জন্য স্ক্রিপ্ট চালান, যা লজিক্যাল দুর্নীতির ইঙ্গিত দেয়।

ব্যাকআপ অসংগতির জন্য মনিটরিং এবং অ্যালার্ট

বিপর্যয় ঘটার আগেই দুর্নীতি শনাক্ত করার জন্য শক্তিশালী পর্যবেক্ষণ প্রয়োজন। বাইনারি সাফল্য/ব্যর্থতা অবস্থার বাইরেও, অসংগতি শনাক্ত করতে আপনার ব্যাকআপ জবের মেটাডেটা মনিটর করা উচিত।

হিউরিস্টিক মনিটরিং

আপনার ব্যাকআপ মেটাডেটাকে প্রমিথিউস (Prometheus)-এ ইন্টিগ্রেট করুন এবং গ্রাফানা (Grafana)-তে ভিজ্যুয়ালাইজ করুন। নিম্নলিখিত হিউরিস্টিকগুলোর জন্য অ্যালার্ট সেট করুন:
* হঠাৎ আকার কমে যাওয়া: যদি আপনার প্রতিদিনের ব্যাকআপ সাধারণত ৫০০ জিবি হয় এবং আজকের ব্যাকআপ ৫০ এমবি হয়, তবে জবটি সফলভাবে সম্পন্ন হতে পারে (Exit Code 0), কিন্তু সম্ভবত এটি একটি খালি স্কিমা ব্যাকআপ করেছে।
* সময়কাল অসংগতি: যদি একটি ব্যাকআপ যা সাধারণত ২ ঘণ্টা সময় নেয় তা ৫ মিনিটে শেষ হয়ে যায়, তবে কিছু বাদ পড়েছে। বিপরীতভাবে, যদি এটি ১০ ঘণ্টা নেয়, তবে আপনার ডিস্ক আই/ও অবনতি হতে পারে যা দুর্নীতির দিকে নিয়ে যেতে পারে।
* WAL/আর্কাইভ লগ জমা হওয়া: যদি আপনার ডেটাবেস রাইট-অহেড লগ (WAL) তৈরি করে কিন্তু ব্যাকআপ সিস্টেম সেগুলো যথেষ্ট দ্রুত আর্কাইভ না করে, তবে আপনি আপনার পয়েন্ট-ইন-টাইম রিকভারি (PITR) চেইনে একটি ফাঁক তৈরির ঝুঁকিতে থাকবেন।

ইন্টিগ্রিটি চেকসহ ৩-২-১ নিয়ম বাস্তবায়ন

শিল্প-মানসম্মত ৩-২-১ ব্যাকআপ নিয়ম (ডেটার ৩টি কপি, ২টি ভিন্ন মিডিয়া, ১টি অফসাইট) তখনই কার্যকর হয় যদি সব কপি যাচাই করা থাকে।

এখানেই ক্লাউডসেভ (CloudSave)-এর মতো এন্টারপ্রাইজ সলিউশন ব্যবহার করা অপারেশনাল ওভারহেড ব্যাপকভাবে হ্রাস করে। প্রতিটি ডেটাবেস নোডের জন্য জটিল ব্যাশ স্ক্রিপ্ট লেখা এবং রক্ষণাবেক্ষণ করার পরিবর্তে, ক্লাউডসেভ ৩-২-১ লাইফসাইকেল স্বয়ংক্রিয় করতে সরাসরি আপনার ইনফ্রাস্ট্রাকচারের সাথে ইন্টিগ্রেট হয়। এটি ইমিউটেবল স্টোরেজ প্রদান করে—র‍্যানসমওয়্যার থেকে রক্ষা করে—এবং এতে বিল্ট-ইন, স্বয়ংক্রিয় রিস্টোর ভেরিফিকেশন শিডিউল রয়েছে। ক্লাউডসেভ স্বয়ংক্রিয়ভাবে আইসোলেটেড স্যান্ডবক্স এনভায়রনমেন্ট চালু করতে পারে, ব্যাকআপ মাউন্ট করতে পারে, আপনার কাস্টম এসকিউএল ভ্যালিডেশন স্ক্রিপ্ট চালাতে পারে এবং আপনার কেন্দ্রীয় ড্যাশবোর্ডে স্বাস্থ্যের অবস্থা রিপোর্ট করতে পারে।

উপসংহার

ক্ষতিগ্রস্ত ডেটাবেস ব্যাকআপ একটি নীরব ঘাতক যা ব্যবসা ধ্বংস করতে পারে। শুধুমাত্র একটি ব্যাকআপ স্ক্রিপ্টের Exit Code 0-এর ওপর নির্ভর করা একটি বিপজ্জনক জুয়া।

আপনার প্রোডাকশন এনভায়রনমেন্টকে সত্যিকার অর্থে রক্ষা করতে, আপনাকে অবশ্যই একটি ডিফেন্স-ইন-ডেপথ কৌশল গ্রহণ করতে হবে:
১. আপনার ডেটাবেস ইঞ্জিনের মধ্যে পেজ-লেভেল চেকসাম সক্ষম করুন।
২. ব্যাকআপ তৈরির পরপরই নেটিভ ভেরিফিকেশন টুল (pg_verifybackup, RESTORE VERIFYONLY) ব্যবহার করুন।
৩. হিউরিস্টিক অসংগতির জন্য ব্যাকআপ মেটাডেটা (আকার, সময়কাল) মনিটর করুন।
৪. আপনার দৈনিক অপারেশনাল পাইপলাইনের অংশ হিসেবে স্বয়ংক্রিয়, অস্থায়ী রিস্টোর টেস্টিং বাস্তবায়ন করুন।

একটি প্যাসিভ “ফায়ার অ্যান্ড ফরগেট” ব্যাকআপ মানসিকতা থেকে একটি সক্রিয় “কন্টিনিউয়াস রিস্টোর ভ্যালিডেশন” মডেলে স্থানান্তরিত হওয়ার মাধ্যমে, আপনি নিশ্চিত করেন যে যখন অনিবার্য বিপর্যয় আসবে, তখন আপনার ডেটা প্রস্তুত, নির্ভরযোগ্য এবং পুরোপুরি পুনরুদ্ধারযোগ্য থাকবে।