அமைதியான கொலையாளி: பேரழிவு ஏற்படும் முன் சிதைந்த தரவுத்தள காப்புப்பிரதிகளை எவ்வாறு கண்டறிவது

தரவுத்தள நிர்வாகம் மற்றும் தள நம்பகத்தன்மை பொறியியல் (Site Reliability Engineering) போன்ற அதிக முக்கியத்துவம் வாய்ந்த துறையில், ஒரு புகழ்பெற்ற கொள்கை உள்ளது: ஷ்ரோடிங்கரின் காப்புப்பிரதி (Schrödinger’s Backup). ஒரு காப்புப்பிரதியை (backup) நீங்கள் மீட்டெடுக்க முயற்சிக்கும் வரை அதன் நிலை என்னவென்று தெரியாது. அந்த கணம் வரை, அது முழுமையாகச் செயல்படும் நிலையிலும், முற்றிலும் சிதைந்த நிலையிலும் ஒரே நேரத்தில் இருக்கும் ஒரு குவாண்டம் நிலையில் உள்ளது.

DevOps பொறியாளர்கள் மற்றும் தரவுத்தள நிர்வாகிகளுக்கு (DBAs), ஒரு முக்கியமான தரவுத்தள காப்புப்பிரதி சிதைந்துள்ளதை ஒரு சிக்கலின் போது கண்டறிவது மிகப்பெரிய கனவு போன்றது. இது ஒரு வழக்கமான மீட்பு நடவடிக்கையை பேரழிவுகரமான தரவு இழப்பாக மாற்றுகிறது. காப்புப்பிரதி பணிகள் பெரும்பாலும் Exit Code 0 என்று வெற்றிகரமாக முடிவடைந்ததாகக் காட்டும், ஆனால் உள்ளே இருக்கும் தரவு சிதைந்திருக்கும். இது தரவு ஒருமைப்பாட்டின் “அமைதியான கொலையாளி” (silent killer) என்று அழைக்கப்படுகிறது.

இந்த விரிவான வழிகாட்டியில், காப்புப்பிரதி சிதைவின் தன்மையை ஆராய்வோம், தரவுத்தளத்திற்குரிய சரிபார்ப்பு நுட்பங்களை அறிவோம், மேலும் உற்பத்தி சூழல்களுக்காக தானியங்கி, வலுவான மீட்பு குழாய்களை (restore pipelines) எவ்வாறு உருவாக்குவது என்பதைக் காண்போம்.

காப்புப்பிரதி சிதைவின் உடற்கூறியல்

சிதைவைக் கண்டறிய, அது எவ்வாறு நிகழ்கிறது என்பதை நீங்கள் முதலில் புரிந்துகொள்ள வேண்டும். காப்புப்பிரதி சிதைவு பொதுவாக இரண்டு வகைகளாகப் பிரிக்கப்படுகிறது: உடல் ரீதியானது (உள்கட்டமைப்பு நிலை) மற்றும் தர்க்கரீதியானது (பயன்பாட்டு நிலை).

உடல் ரீதியான சிதைவு (Physical Corruption)

சேமிப்பக ஊடகத்தில் உள்ள பிட்கள் மாற்றப்படும்போது உடல் ரீதியான சிதைவு ஏற்படுகிறது. இது மூல வட்டில் இருந்து படிக்கும்போதும், பிணைய பரிமாற்றத்தின் போதும் அல்லது இலக்கு சேமிப்பகத்தில் இருக்கும்போதும் நிகழலாம்.
* பிட் ராட் (Bit Rot): சேமிப்பக ஊடகத்தின் படிப்படியான சிதைவு பிட்களை அமைதியாக மாற்றக்கூடும்.
* பரிமாற்ற பிழைகள் (Transit Errors): TCP-யில் செக்சம்கள் (checksums) இருந்தாலும், அவை மிகவும் பலவீனமானவை (16-bit). அதிக தரவு பரிமாற்றம் நடக்கும் சூழல்களில், TCP-யால் கண்டறிய முடியாத அமைதியான தரவு சிதைவு ஏற்படலாம்.
* சேமிப்பக கட்டுப்பாட்டு பிழைகள் (Storage Controller Faults): RAID கன்ட்ரோலர்கள் அல்லது SAN ஃபேப்ரிக்குகளில் உள்ள வன்பொருள் பிழைகள், OS-க்கு வெற்றிகரமான செய்தியை அனுப்பிவிட்டு, தவறான தரவை எழுதக்கூடும்.

தர்க்கரீதியான சிதைவு (Logical Corruption)

தர்க்கரீதியான சிதைவு மிகவும் ஆபத்தானது, ஏனெனில் காப்புப்பிரதி கோப்பு அப்படியே இருக்கும், ஆனால் உள்ளே இருக்கும் தரவு சிதைந்திருக்கும்.
* குப்பை உள்ளே, குப்பை வெளியே (GIGO): உங்கள் நேரடி தரவுத்தளத்தில் சிதைந்த குறியீட்டு (index) அல்லது சிதைந்த பக்கம் இருந்தால், உங்கள் காப்புப்பிரதி கருவி அதை அப்படியே நகலெடுக்கும். காப்புப்பிரதி பணி வெற்றிபெறும், ஆனால் மீட்டெடுக்கும்போது தரவுத்தளம் வேலை செய்யாது.
* முழுமையற்ற பரிவர்த்தனைகள்: தரவுத்தள I/O-வை முறையாக முடக்காமல் (உதாரணமாக, MySQL-இல் 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 ஒரு பிழையை ஏற்படுத்தும், இது உங்கள் கண்காணிப்பு அமைப்புகள் DBA குழுவை உடனடியாக எச்சரிக்க உதவும்.

Microsoft SQL Server: RESTORE VERIFYONLY

SQL Server ஒரு காப்புப்பிரதி கோப்பை மீட்டெடுக்காமலேயே அதன் உடல் ஒருமைப்பாட்டைச் சரிபார்க்க ஒரு கட்டளையை வழங்குகிறது. இது காப்புப்பிரதி தலைப்புகளைச் சரிபார்த்து, பக்க செக்சம்களை உறுதிப்படுத்துகிறது.

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

எச்சரிக்கை: RESTORE VERIFYONLY என்பது காப்புப்பிரதி கோப்பு படிக்கக்கூடியது மற்றும் உடல் செக்சம்கள் பொருந்துகின்றன என்பதை மட்டுமே உறுதிப்படுத்துகிறது. இது தர்க்கரீதியான ஒருமைப்பாட்டிற்கு உத்தரவாதம் அளிக்காது. தர்க்கரீதியான ஒருமைப்பாட்டை உறுதிப்படுத்த, நீங்கள் முழுமையாக மீட்டெடுத்து DBCC CHECKDB-ஐ இயக்க வேண்டும்.

MySQL / InnoDB: Percona XtraBackup

MySQL சூழல்களுக்கு, உடல் ரீதியான காப்புப்பிரதிகள் பெரும்பாலும் Percona XtraBackup மூலம் கையாளப்படுகின்றன. காப்புப்பிரதி செயல்முறை கோப்புகளை நகலெடுப்பதைக் கொண்டுள்ளது, ஆனால் பரிவர்த்தனை பதிவுகள் (redo logs) பயன்படுத்தப்படும் வரை காப்புப்பிரதி சீராக இருக்காது. --prepare கட்டம் ஒரு உள்ளமைக்கப்பட்ட ஒருமைப்பாடு சரிபார்ப்பாக செயல்படுகிறது.

# காப்புப்பிரதியைத் தயாரிப்பது redo logs-ஐப் பயன்படுத்துகிறது. 
# காப்புப்பிரதி சிதைந்திருந்தால், இந்த படி தோல்வியடையும்.
xtrabackup --prepare --target-dir=/data/backups/mysql/

தங்கத் தரம்: தானியங்கி மீட்பு சோதனை

செக்சம்கள் மற்றும் சரிபார்ப்புக் கட்டளைகள் அவசியம், ஆனால் அவை மட்டும் போதாது. ஒரு காப்புப்பிரதி செயல்படும் என்பதை நிரூபிக்க ஒரே வழி அதை மீட்டெடுப்பதே ஆகும். நவீன DevOps சூழல்களில், இந்த செயல்முறை முழுமையாக தானியக்கமாக்கப்பட வேண்டும்.

காப்புப்பிரதிகளை குறியீடாகக் கருதுவதன் மூலம், உங்கள் தரவுத்தள மீட்புக்காக ஒரு CI/CD குழாயை உருவாக்கலாம். இந்த குழாய் தற்காலிக உள்கட்டமைப்பை உருவாக்கி, மீட்டெடுப்பைச் செய்து, சரிபார்ப்பு வினவல்களை இயக்கி, சூழலை நீக்க வேண்டும்.

தானியங்கி மீட்பு குழாயை உருவாக்குதல்

PostgreSQL தர்க்கரீதியான டம்பை (logical dump) சரிபார்க்க, தினசரி கிரான் ஜாப் (cron job) அல்லது CI ரன்னர் (GitLab CI அல்லது GitHub Actions போன்றவை) மூலம் தூண்டக்கூடிய ஒரு Bash ஸ்கிரிப்ட் உதாரணம் கீழே உள்ளது.

#!/bin/bash
set -e

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

echo "[INFO] தானியங்கி மீட்பு சோதனை தொடங்குகிறது..."

# 1. தற்காலிக 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

# 2. இலக்கு தரவுத்தளத்தை உருவாக்கவும்
docker exec $CONTAINER_NAME psql -U postgres -c "CREATE DATABASE $DB_NAME;"

# 3. மீட்டெடுப்பைச் செய்யவும்
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

# 4. தர்க்கரீதியான சரிபார்ப்பு வினவல்களை இயக்கவும்
echo "[INFO] சரிபார்ப்பு வினவல்கள் இயக்கப்படுகின்றன..."
# பயனர்கள் அட்டவணையில் 10,000-க்கும் மேற்பட்ட பதிவுகள் உள்ளனவா என்று சரிபார்க்கவும்
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

# 5. தற்காலிக சூழலை நீக்கவும்
echo "[INFO] சுத்தம் செய்யப்படுகிறது..."
docker rm -f $CONTAINER_NAME

echo "[INFO] தானியங்கி மீட்பு சோதனை வெற்றிகரமாக முடிந்தது."

நீங்கள் எதைச் சரிபார்க்க வேண்டும்?

தானியங்கி மீட்பு சோதனையைச் செய்யும்போது, தரவுத்தளம் தொடங்குகிறதா என்று மட்டும் பார்க்காதீர்கள். பயன்பாட்டிற்குரிய சரிபார்ப்பு வினவல்களை இயக்கவும்:
1. வரிசை எண்ணிக்கை (Row Counts): முக்கிய அட்டவணைகளில் எதிர்பார்க்கப்படும் வரிசைகள் உள்ளனவா என்பதை உறுதிப்படுத்தவும் (எ.கா., users அட்டவணை காலியாக இருக்கக்கூடாது).
2. சமீபத்திய தரவு: காப்புப்பிரதி பழையதாக இல்லை என்பதை உறுதிப்படுத்த, கடந்த 24 மணிநேரத்தில் உருவாக்கப்பட்ட பதிவுகளைத் தேடவும்.
3. குறிப்பு ஒருமைப்பாடு (Referential Integrity): கைவிடப்பட்ட ஃபாரின் கீகளை (orphaned foreign keys) சரிபார்க்க ஸ்கிரிப்ட்களை இயக்கவும், இவை தர்க்கரீதியான சிதைவைக் குறிக்கின்றன.

காப்புப்பிரதி முரண்பாடுகளுக்கான கண்காணிப்பு மற்றும் எச்சரிக்கை

பேரழிவு ஏற்படுவதற்கு முன்பே சிதைவைக் கண்டறிய வலுவான கண்காணிப்பு தேவை. வெற்றிகரமான/தோல்வியடைந்த நிலைகளைத் தாண்டி, முரண்பாடுகளைக் கண்டறிய உங்கள் காப்புப்பிரதி பணிகளின் மெட்டாடேட்டாவைக் கண்காணிக்க வேண்டும்.

ஹூரிஸ்டிக் கண்காணிப்பு (Heuristic Monitoring)

உங்கள் காப்புப்பிரதி மெட்டாடேட்டாவை Prometheus-இல் ஒருங்கிணைத்து Grafana மூலம் காட்சிப்படுத்தவும். பின்வரும் முரண்பாடுகளுக்கு எச்சரிக்கைகளை அமைக்கவும்:
* திடீர் அளவு குறைப்பு: உங்கள் தினசரி காப்புப்பிரதி வழக்கமாக 500GB இருந்தால், இன்று 50MB ஆக இருந்தால், பணி வெற்றிகரமாக முடிந்திருக்கலாம் (Exit Code 0), ஆனால் அது காலியான ஸ்கீமாவை காப்புப்பிரதி எடுத்திருக்கலாம்.
* கால அளவு முரண்பாடுகள்: வழக்கமாக 2 மணிநேரம் எடுக்கும் காப்புப்பிரதி 5 நிமிடங்களில் முடிந்தால், ஏதோ விடுபட்டுள்ளது. மாறாக, 10 மணிநேரம் எடுத்தால், வட்டு I/O சிதைவு இருக்கலாம்.
* WAL/ஆர்க்கிவ் லாக் குவிப்பு: உங்கள் தரவுத்தளம் Write-Ahead Logs (WAL)-ஐ உருவாக்குகிறது, ஆனால் காப்புப்பிரதி அமைப்பு அவற்றை வேகமாக ஆர்க்கிவ் செய்யவில்லை என்றால், உங்கள் Point-in-Time Recovery (PITR) சங்கிலியில் இடைவெளி ஏற்படும் அபாயம் உள்ளது.

ஒருமைப்பாடு சோதனைகளுடன் 3-2-1 விதியைச் செயல்படுத்துதல்

தொழில்துறை தரமான 3-2-1 காப்புப்பிரதி விதி (3 தரவு பிரதிகள், 2 வெவ்வேறு ஊடகங்கள், 1 வெளியூர்) அனைத்து பிரதிகளும் சரிபார்க்கப்பட்டால் மட்டுமே பயனுள்ளதாக இருக்கும்.

இங்குதான் CloudSave போன்ற நிறுவன தீர்வுகள் செயல்பாட்டுச் சுமையைக் குறைக்கின்றன. ஒவ்வொரு தரவுத்தள முனைக்கும் சிக்கலான பாஷ் ஸ்கிரிப்ட்களை எழுதுவதற்குப் பதிலாக, CloudSave உங்கள் உள்கட்டமைப்புடன் நேரடியாக ஒருங்கிணைந்து 3-2-1 வாழ்க்கைச் சுழற்சியைத் தானியக்கமாக்குகிறது. இது ransomware-க்கு எதிராகப் பாதுகாக்கும் மாற்ற முடியாத சேமிப்பகத்தை வழங்குகிறது மற்றும் உள்ளமைக்கப்பட்ட, தானியங்கி மீட்பு சரிபார்ப்பு அட்டவணைகளைக் கொண்டுள்ளது. CloudSave தானாகவே தனிமைப்படுத்தப்பட்ட சூழல்களை உருவாக்கி, காப்புப்பிரதியை மவுண்ட் செய்து, உங்கள் தனிப்பயன் SQL சரிபார்ப்பு ஸ்கிரிப்ட்களை இயக்கி, ஆரோக்கிய நிலையை உங்கள் டாஷ்போர்டிற்குத் தெரிவிக்கும்.

முடிவு

சிதைந்த தரவுத்தள காப்புப்பிரதிகள் வணிகங்களை அழிக்கக்கூடிய அமைதியான கொலையாளிகள். ஒரு காப்புப்பிரதி ஸ்கிரிப்ட்டின் Exit Code 0-ஐ மட்டும் நம்புவது ஆபத்தான சூதாட்டமாகும்.

உங்கள் உற்பத்தி சூழல்களை உண்மையாகப் பாதுகாக்க, நீங்கள் ஆழமான பாதுகாப்பு உத்தியைப் பின்பற்ற வேண்டும்:
1. உங்கள் தரவுத்தள இயந்திரத்தில் பக்க-அளவிலான செக்சம்களை இயக்கவும்.
2. காப்புப்பிரதி உருவாக்கிய உடனேயே சொந்த சரிபார்ப்புக் கருவிகளை (pg_verifybackup, RESTORE VERIFYONLY) பயன்படுத்தவும்.
3. காப்புப்பிரதி மெட்டாடேட்டாவை (அளவு, காலம்) முரண்பாடுகளுக்காகக் கண்காணிக்கவும்.
4. உங்கள் தினசரி செயல்பாட்டு குழாயின் ஒரு பகுதியாக தானியங்கி, தற்காலிக மீட்பு சோதனையைச் செயல்படுத்தவும்.

செயலற்ற “செய்துவிட்டு மறக்கும்” காப்புப்பிரதி மனநிலையிலிருந்து, “தொடர்ச்சியான மீட்பு சரிபார்ப்பு” மாதிரிக்கு மாறுவதன் மூலம், பேரழிவு ஏற்படும் போது உங்கள் தரவு தயாராகவும், நம்பகமானதாகவும், முழுமையாக மீட்கக்கூடியதாகவும் இருப்பதை உறுதி செய்கிறீர்கள்.