Səssiz Qatil: Fəlakət Baş Verməzdən Əvvəl Zədələnmiş Məlumat Bazası Ehtiyat Nüsxələrini Necə Aşkar Etmək Olar

Məlumat bazasının idarə edilməsi və saytın etibarlılığı mühəndisliyi kimi yüksək riskli dünyada məşhur bir aksiom var: Şredingerin Ehtiyat Nüsxəsi. Hər hansı bir ehtiyat nüsxənin vəziyyəti onu bərpa etməyə çalışana qədər məlum deyil. O ana qədər, o, həm mükəmməl işlək, həm də tamamilə korlanmış vəziyyətdə olan kvant vəziyyətində mövcuddur.

DevOps mühəndisləri və DBA-lar (məlumat bazası administratorları) üçün aktiv insident zamanı kritik bir məlumat bazası ehtiyat nüsxəsinin korlandığını aşkar etmək ən dəhşətli ssenaridir. Bu, adi bir bərpa əməliyyatını fəlakətli məlumat itkisi hadisəsinə çevirir. Məlumat bütövlüyünün bu “səssiz qatili” çox vaxt nəzərdən qaçır, çünki ehtiyat nüsxə işləri əsas yük korlansa belə, tez-tez uğurlu Exit Code 0 hesabatı verir.

Bu əhatəli bələdçidə biz ehtiyat nüsxə korrupsiyasının anatomiyasını təhlil edəcək, məlumat bazasına xas doğrulama üsullarını araşdıracaq və istehsal mühitləri üçün avtomatlaşdırılmış, etibarlı bərpa xətlərini necə quracağımızı nümayiş etdirəcəyik.

Ehtiyat Nüsxə Korrupsiyasının Anatomiyası

Korrupsiyanı aşkar etmək üçün əvvəlcə onun necə baş verdiyini başa düşməlisiniz. Ehtiyat nüsxə korrupsiyası ümumiyyətlə iki kateqoriyaya bölünür: fiziki (infrastruktur səviyyəsində) və məntiqi (tətbiq səviyyəsində).

Fiziki Korrupsiya

Fiziki korrupsiya saxlama mühitindəki faktiki bitlər dəyişdirildikdə baş verir. Bu, mənbə diskindən oxuma prosesi zamanı, şəbəkə ötürülməsi zamanı və ya hədəf yaddaşda saxlanılarkən baş verə bilər.
* Bit Rot (Bit çürüməsi): Saxlama mühitinin tədricən pisləşməsi bitləri səssizcə dəyişə bilər.
* Ötürmə Xətaları: TCP-nin yoxlama cəmləri (checksums) olsa da, onlar çox zəifdir (16-bit). Yüksək ötürmə qabiliyyətinə malik mühitlər TCP-nin tuta bilmədiyi ötürmə zamanı səssiz məlumat korrupsiyası ilə qarşılaşa bilər.
* Saxlama Kontroleri Xətaları: RAID kontrolerlərində və ya SAN strukturlarındakı aparat səhvləri əməliyyat sisteminə uğur bildirişi göndərərkən zibil məlumatlar yaza bilər.

Məntiqi Korrupsiya

Məntiqi korrupsiya daha təhlükəlidir, çünki ehtiyat nüsxə faylının özü tamamilə bütövdür, lakin içindəki məlumatlar xarabdır.
* Zibil İçəri, Zibil Çölə (GIGO): Əgər canlı məlumat bazanızda korlanmış indeks və ya zədələnmiş səhifə varsa, ehtiyat nüsxə alətiniz həmin korlanmış səhifəni sədaqətlə kopyalaya bilər. Ehtiyat nüsxə işi uğurla başa çatır, lakin bərpa uğursuz olacaq və ya xarab məlumat bazası ilə nəticələnəcək.
* Tamamlanmamış Tranzaksiyalar: Məlumat bazasının I/O-sunu düzgün dondurmadan (məsələn, MySQL-də FLUSH TABLES WITH READ LOCK istifadə etmədən) götürülən fayl sistemi səviyyəsindəki snapshotlar zədələnmiş səhifələrə və bərpaolunmaz vəziyyətlərə səbəb olur.

Proaktiv Aşkarlama: Yoxlama Cəmləri və Kriptoqrafik Hashing

Fiziki korrupsiyaya qarşı ilk müdafiə xətti kriptoqrafik doğrulamadır. Fayl ölçülərinə və ya dəyişdirilmə tarixlərinə etibar etmək kifayət deyil.

Məlumat Bazası Səviyyəsində Yoxlama Cəmlərinin Aktivləşdirilməsi

Müasir relyasiya məlumat bazası idarəetmə sistemləri (RDBMS) səhifə səviyyəsində yoxlama cəmlərini dəstəkləyir. Aktivləşdirildikdə, məlumat bazası hər səhifəni diskə yazmazdan əvvəl onun üçün yoxlama cəmi hesablayır. Səhifə oxunduqda (sorğu və ya ehtiyat nüsxə prosesi ilə), yoxlama cəmi təsdiqlənir.

PostgreSQL üçün klasterin işə salınması zamanı məlumat yoxlama cəmlərini aktivləşdirə bilərsiniz:

# Yoxlama cəmləri aktivləşdirilmiş yeni PostgreSQL klasterini işə salın
initdb --data-checksums -D /var/lib/postgresql/data

Qeyd: Əgər mövcud PostgreSQL klasteriniz varsa, onları oflayn rejimdə aktivləşdirmək üçün pg_checksums utilitindən istifadə edə bilərsiniz.

Microsoft SQL Server üçün PAGE_VERIFY-in CHECKSUM olaraq təyin olunduğundan əmin olun (müasir versiyalarda standartdır, lakin köhnə sistemlərdə yoxlamağa dəyər):

ALTER DATABASE [ProductionDB] SET PAGE_VERIFY CHECKSUM;
GO

Saxlanılan Ehtiyat Nüsxələrin Doğrulanması

Ehtiyat nüsxə saxlama hədəfinizə çatdıqdan sonra onun bütövlüyü kriptoqrafik olaraq yoxlanılmalıdır. CloudSave kimi müəssisə ehtiyat nüsxə platformaları ötürmə və saxlama zamanı ehtiyat nüsxə bloklarının SHA-256 heşlərini avtomatik hesablayır və yoxlayır. Əgər xüsusi skriptləri idarə edirsinizsə, bunu əl ilə tətbiq etməlisiniz:

# Ehtiyat nüsxə yaradıldıqdan sonra SHA-256 heşini yaradın
sha256sum prod_db_backup.tar.gz > prod_db_backup.tar.gz.sha256

# Saxlama serverində heşi yoxlayın
sha256sum -c prod_db_backup.tar.gz.sha256

Məlumat Bazasına Xas Doğrulama Üsulları

Müxtəlif məlumat bazası mühərrikləri ehtiyat nüsxə artefaktlarının bütövlüyünü yoxlamaq üçün yerli alətlər təklif edir.

PostgreSQL: pg_verifybackup

PostgreSQL 13-də təqdim edilən pg_verifybackup, pg_basebackup ilə götürülən fiziki ehtiyat nüsxələr üçün oyun dəyişdiricidir. O, ehtiyat nüsxə zamanı yaradılan backup_manifest faylını oxuyur və bütün faylların mövcud olduğunu və yoxlama cəmlərinin uyğunluğunu təsdiqləyir.

# Fiziki baza ehtiyat nüsxə qovluğuna qarşı yoxlamanı işə salın
pg_verifybackup /mnt/backups/postgres/base_backup_20231025/

Əgər məlumat fayllarının hər hansı birində bir bit belə dəyişibsə, pg_verifybackup fatal xəta verəcək və monitorinq sistemlərinizə DBA komandasını dərhal xəbərdar etməyə imkan verəcək.

Microsoft SQL Server: RESTORE VERIFYONLY

SQL Server, ehtiyat nüsxə faylını faktiki olaraq bərpa etmədən onun fiziki bütövlüyünü yoxlamaq üçün yerli bir əmr təqdim edir. O, ehtiyat nüsxə başlıqlarını yoxlayır və səhifə yoxlama cəmlərini təsdiqləyir (əgər onlar ehtiyat nüsxə zamanı aktivləşdirilibsə).

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

Xəbərdarlıq: RESTORE VERIFYONLY yalnız ehtiyat nüsxə faylının oxuna bilən olduğunu və fiziki yoxlama cəmlərinin uyğun olduğunu təsdiqləyir. O, məntiqi bütövlüyə zəmanət vermir. Məntiqi bütövlüyü təmin etmək üçün tam bərpa etməli və DBCC CHECKDB işə salmalısınız.

MySQL / InnoDB: Percona XtraBackup

MySQL mühitləri üçün fiziki ehtiyat nüsxələr çox vaxt Percona XtraBackup tərəfindən idarə olunur. Ehtiyat nüsxə prosesi faylların kopyalanmasından ibarətdir, lakin tranzaksiya jurnalları (redo logs) tətbiq olunana qədər ehtiyat nüsxə ardıcıl deyil. --prepare fazası daxili bütövlük yoxlaması kimi çıxış edir.

# Ehtiyat nüsxənin hazırlanması redo logları tətbiq edir. 
# Əgər ehtiyat nüsxə korlanıbsa, bu addım uğursuz olacaq.
xtrabackup --prepare --target-dir=/data/backups/mysql/

Qızıl Standart: Avtomatlaşdırılmış Bərpa Testi

Yoxlama cəmləri və doğrulama əmrləri lazımdır, lakin kifayət deyil. Ehtiyat nüsxənin işlək olduğunu sübut etməyin yeganə yolu onu bərpa etməkdir. Müasir DevOps mühitlərində bu proses tamamilə avtomatlaşdırılmalıdır.

Ehtiyat nüsxələrə kod kimi yanaşaraq, məlumat bazası bərpanız üçün CI/CD xətti qura bilərsiniz. Bu xətt müvəqqəti infrastruktur təmin etməli, bərpanı icra etməli, doğrulama sorğularını işə salmalı və mühiti silməlidir.

Avtomatlaşdırılmış Bərpa Xəttinin Qurulması

Aşağıda PostgreSQL məntiqi dump-unu yoxlamaq üçün cron işi və ya CI runner (GitLab CI və ya GitHub Actions kimi) tərəfindən gündəlik işə salına bilən Bash skripti nümunəsi verilmişdir.

#!/bin/bash
set -e

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

echo "[INFO] Avtomatlaşdırılmış Bərpa Testi Başlayır..."

# 1. Müvəqqəti PostgreSQL konteynerini işə salın
docker run --name $CONTAINER_NAME 
  -e POSTGRES_PASSWORD=testpass 
  -d postgres:15

# PostgreSQL-in hazır olmasını gözləyin
echo "[INFO] Məlumat bazasının işə düşməsi gözlənilir..."
until docker exec $CONTAINER_NAME pg_isready -U postgres; do
  sleep 2
done

# 2. Hədəf məlumat bazasını yaradın
docker exec $CONTAINER_NAME psql -U postgres -c "CREATE DATABASE $DB_NAME;"

# 3. Bərpanı icra edin
echo "[INFO] Ehtiyat nüsxə bərpa edilir..."
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. Məntiqi Doğrulama Sorğularını işə salın
echo "[INFO] Doğrulama sorğuları işə salınır..."
# İstifadəçilər cədvəlində 10.000-dən çox qeyd olub-olmadığını yoxlayın
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] Məntiqi doğrulama uğursuz oldu. Gözlənilən >10000 istifadəçi, tapılan $USER_COUNT"
    # Burada PagerDuty / Slack xəbərdarlığını işə salın
    exit 1
else
    echo "[SUCCESS] Məntiqi doğrulama uğurla keçdi. İstifadəçi sayı: $USER_COUNT"
fi

# 5. Müvəqqəti mühiti silin
echo "[INFO] Təmizləmə aparılır..."
docker rm -f $CONTAINER_NAME

echo "[INFO] Avtomatlaşdırılmış Bərpa Testi Uğurla Tamamlandı."

Nəyi Doğrulamalısınız?

Avtomatlaşdırılmış bərpa testi apararkən, sadəcə məlumat bazasının işə düşdüyünü yoxlamayın. Tətbiqə xas doğrulama sorğularını işə salın:
1. Sətir Sayları: Əsas cədvəllərin gözlənilən sətir sayına malik olduğundan əmin olun (məsələn, users cədvəli boş olmamalıdır).
2. Son Məlumatlar: Ehtiyat nüsxənin köhnə olmadığından əmin olmaq üçün son 24 saat ərzində yaradılmış qeydləri sorğulayın.
3. Referensial Bütövlük: Məntiqi korrupsiyanı göstərən yetim xarici açarları (orphaned foreign keys) yoxlamaq üçün skriptlər işə salın.

Ehtiyat Nüsxə Anomaliyaları üçün Monitorinq və Xəbərdarlıq

Fəlakət baş verməzdən əvvəl korrupsiyanı aşkar etmək güclü müşahidə qabiliyyəti tələb edir. İkili uğur/uğursuzluq vəziyyətlərindən kənara çıxaraq, anomaliyaları aşkar etmək üçün ehtiyat nüsxə işlərinizin metadata məlumatlarını izləməlisiniz.

Hevristik Monitorinq

Ehtiyat nüsxə metadata məlumatlarınızı Prometheus-a inteqrasiya edin və Grafana ilə vizuallaşdırın. Aşağıdakı hevristikalar üçün xəbərdarlıqlar qurun:
* Qəfil Ölçü Azalmaları: Əgər gündəlik ehtiyat nüsxəniz davamlı olaraq 500GB-dırsa və bugünkü ehtiyat nüsxə 50MB-dırsa, iş uğurla başa çata bilər (Exit Code 0), lakin çox güman ki, boş bir sxemi ehtiyat nüsxəyə alıb.
* Müddət Anomaliyaları: Normalda 2 saat çəkən ehtiyat nüsxə 5 dəqiqəyə bitərsə, nəsə ötürülüb. Əksinə, 10 saat çəkərsə, korrupsiyaya səbəb ola biləcək disk I/O pisləşməsi ola bilər.
* WAL/Arxiv Jurnalı Yığılması: Əgər məlumat bazanız Write-Ahead Logs (WAL) yaradır, lakin ehtiyat nüsxə sistemi onları kifayət qədər sürətlə arxivləşdirmirsə, Point-in-Time Recovery (PITR) zəncirinizdə boşluq riski yaranır.

Bütövlük Yoxlamaları ilə 3-2-1 Qaydasının Tətbiqi

Sənaye standartı olan 3-2-1 ehtiyat nüsxə qaydası (3 nüsxə, 2 fərqli media, 1 ofisdən kənar) yalnız bütün nüsxələr doğrulandıqda effektivdir.

CloudSave kimi müəssisə həllindən istifadə etmək əməliyyat yükünü kəskin şəkildə azaldır. Hər məlumat bazası qovşağı üçün mürəkkəb bash skriptləri yazmaq və saxlamaq əvəzinə, CloudSave 3-2-1 həyat dövrünü avtomatlaşdırmaq üçün birbaşa infrastrukturunuzla inteqrasiya olunur. O, dəyişməz yaddaş təmin edir—ransomware-dən qoruyur—və daxili, avtomatlaşdırılmış bərpa yoxlama cədvəllərinə malikdir. CloudSave avtomatik olaraq təcrid olunmuş sandbox mühitlərini işə sala, ehtiyat nüsxəni mount edə, xüsusi SQL doğrulama skriptlərinizi işə sala və sağlamlıq statusunu mərkəzi idarəetmə panelinizə qaytara bilər.

Nəticə

Korlanmış məlumat bazası ehtiyat nüsxələri biznesləri məhv edə bilən səssiz qatildir. Yalnız ehtiyat nüsxə skriptinin Exit Code 0-ına etibar etmək təhlükəli bir qumardır.

İstehsal mühitlərinizi həqiqətən qorumaq üçün dərin müdafiə strategiyasını mənimsəməlisiniz:
1. Məlumat bazası mühərrikinizdə səhifə səviyyəsində yoxlama cəmlərini aktivləşdirin.
2. Ehtiyat nüsxə yaradıldıqdan dərhal sonra yerli doğrulama alətlərindən (pg_verifybackup, RESTORE VERIFYONLY) istifadə edin.
3. Hevristik anomaliyalar üçün ehtiyat nüsxə metadata məlumatlarını (ölçü, müddət) izləyin.
4. Gündəlik əməliyyat xəttinizin bir hissəsi kimi avtomatlaşdırılmış, müvəqqəti bərpa testini tətbiq edin.

Passiv “yarat və unut” ehtiyat nüsxə zehniyyətindən aktiv “davamlı bərpa doğrulaması” modelinə keçməklə, fəlakət qaçılmaz olaraq baş verdikdə məlumatlarınızın hazır, etibarlı və tam bərpaolunmaz olmasını təmin edirsiniz.