Լուռ մարդասպանը. ինչպե՞ս հայտնաբերել տվյալների բազայի վնասված կրկնօրինակները նախքան աղետը

Տվյալների բազայի կառավարման և կայքի հուսալիության ինժեներիայի բարձր պատասխանատվություն պահանջող աշխարհում գոյություն ունի մի հայտնի աքսիոմ՝ Շրյոդինգերի պահուստային պատճենը (Schrödinger’s Backup): Ցանկացած պահուստային պատճենի վիճակն անհայտ է, քանի դեռ չեք փորձել այն վերականգնել: Մինչ այդ պահը այն գոյություն ունի քվանտային վիճակում՝ լինելով միաժամանակ և՛ կատարյալ պիտանի, և՛ ամբողջությամբ վնասված:

DevOps ինժեներների և տվյալների բազայի ադմինիստրատորների (DBA) համար ակտիվ միջադեպի ժամանակ պարզելը, որ տվյալների բազայի կարևոր պահուստային պատճենը վնասված է, վերջնական մղձավանջային սցենար է: Այն վերածում է սովորական վերականգնման գործընթացը տվյալների կորստի աղետալի դեպքի: Տվյալների ամբողջականության այս «լուռ մարդասպանը» հաճախ աննկատ է մնում, քանի որ պահուստավորման առաջադրանքները հաճախ հաղորդում են հաջող Exit Code 0, նույնիսկ երբ հիմքում ընկած տվյալները վնասված են:

Այս համապարփակ ուղեցույցում մենք կվերլուծենք պահուստային պատճենների վնասվածության անատոմիան, կուսումնասիրենք տվյալների բազայի համար նախատեսված վավերացման տեխնիկաները և ցույց կտանք, թե ինչպես կառուցել ավտոմատացված, անխոցելի վերականգնման խողովակաշարեր (pipelines) արտադրական միջավայրերի համար:

Պահուստային պատճենների վնասվածության անատոմիան

Վնասվածությունը հայտնաբերելու համար նախ պետք է հասկանալ, թե ինչպես է այն առաջանում: Պահուստային պատճենների վնասվածությունը սովորաբար բաժանվում է երկու կատեգորիայի՝ ֆիզիկական (ենթակառուցվածքային մակարդակ) և տրամաբանական (հավելվածի մակարդակ):

Ֆիզիկական վնասվածություն

Ֆիզիկական վնասվածությունը տեղի է ունենում, երբ պահեստավորման միջավայրի իրական բիթերը փոխվում են: Սա կարող է տեղի ունենալ սկավառակից ընթերցման գործընթացում, ցանցով փոխանցման ժամանակ կամ թիրախային պահեստում պահվելիս:
* Բիթերի քայքայում (Bit Rot): Պահեստավորման միջավայրի աստիճանական քայքայումը կարող է լուռ փոխել բիթերը:
* Փոխանցման սխալներ: Թեև TCP-ն ունի ստուգաթվեր (checksums), դրանք հայտնի են իրենց թուլությամբ (16-բիթանոց): Բարձր թողունակությամբ միջավայրերը կարող են ցանցով տվյալների լուռ կոռուպցիա ունենալ, որը TCP-ն չի հայտնաբերում:
* Պահեստավորման կառավարչի անսարքություններ: RAID կառավարիչների կամ SAN ցանցերի ծրագրային սխալները կարող են աղբ տվյալներ գրել՝ օպերացիոն համակարգին հաղորդելով հաջողության մասին:

Տրամաբանական վնասվածություն

Տրամաբանական վնասվածությունը, թերևս, ավելի վտանգավոր է, քանի որ պահուստային ֆայլն ինքնին կատարյալ անվնաս է, բայց դրա ներսում եղած տվյալները՝ կոտրված:
* Աղբ մուտքում, աղբ ելքում (GIGO): Եթե ձեր աշխատանքային տվյալների բազան ունի վնասված ինդեքս կամ վնասված էջ, ձեր պահուստավորման գործիքը կարող է հավատարմորեն պատճենել այդ վնասված էջը: Պահուստավորման առաջադրանքը հաջողվում է, բայց վերականգնումը կձախողվի կամ կստեղծի կոտրված տվյալների բազա:
* Անավարտ գործարքներ: Ֆայլային համակարգի մակարդակի պատկերները (snapshots), որոնք արվել են առանց տվյալների բազայի 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 խողովակաշար ձեր տվյալների բազայի վերականգնումների համար: Այս խողովակաշարը պետք է տրամադրի ժամանակավոր ենթակառուցվածք, իրականացնի վերականգնումը, գործարկի վավերացման հարցումներ և հեռացնի միջավայրը:

Ավտոմատացված վերականգնման խողովակաշարի կառուցում

Ստորև բերված է Bash սկրիպտի օրինակ, որը կարող է ամեն օր գործարկվել cron job-ի կամ CI runner-ի (օրինակ՝ GitLab CI կամ GitHub Actions) կողմից՝ PostgreSQL տրամաբանական դամփը վավերացնելու համար.

#!/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] Վավերացման հարցումների գործարկում..."
# Ստուգել, արդյոք users աղյուսակն ունի 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): Գործարկեք սկրիպտներ՝ որբացած արտաքին բանալիները ստուգելու համար, որոնք վկայում են տրամաբանական վնասվածության մասին:

Մոնիտորինգ և ծանուցում պահուստային պատճենների անոմալիաների համար

Աղետից առաջ վնասվածությունը հայտնաբերելը պահանջում է հուսալի դիտարկելիություն: Բացի հաջող/ձախողված վիճակներից, դուք պետք է մոնիտորինգի ենթարկեք ձեր պահուստավորման առաջադրանքների մետատվյալները՝ անոմալիաները հայտնաբերելու համար:

Էվրիստիկ մոնիտորինգ

Ինտեգրեք ձեր պահուստավորման մետատվյալները Prometheus-ի հետ և վիզուալացրեք դրանք Grafana-ի միջոցով: Սահմանեք ծանուցումներ հետևյալ էվրիստիկաների համար.
* Չափի հանկարծակի նվազում. Եթե ձեր ամենօրյա պահուստային պատճենը կայուն 500 ԳԲ է, իսկ այսօրվանը՝ 50 ՄԲ, ապա առաջադրանքը կարող է հաջողությամբ ավարտված լինել (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-ի նման ձեռնարկատիրական լուծումը կտրուկ նվազեցնում է գործառնական ծախսերը: Փոխանակ յուրաքանչյուր տվյալների բազայի հանգույցի համար բարդ bash սկրիպտներ գրելու և պահպանելու, CloudSave-ը անմիջականորեն ինտեգրվում է ձեր ենթակառուցվածքին՝ 3-2-1 կենսացիկլը ավտոմատացնելու համար: Այն տրամադրում է անփոփոխելի պահեստավորում՝ պաշտպանելով ransomware-ից, և ունի ներկառուցված, ավտոմատացված վերականգնման վավերացման ժամանակացույցեր: CloudSave-ը կարող է ավտոմատ կերպով գործարկել մեկուսացված sandbox միջավայրեր, տեղադրել պահուստային պատճենը, գործարկել ձեր հատուկ SQL վավերացման սկրիպտները և առողջության կարգավիճակի մասին հաշվետվություն ուղարկել ձեր կենտրոնական վահանակին:

Եզրակացություն

Տվյալների բազայի վնասված պահուստային պատճենները լուռ մարդասպան են, որոնք կարող են ոչնչացնել բիզնեսը: Միայն պահուստավորման սկրիպտի Exit Code 0-ի վրա հույս դնելը վտանգավոր խաղ է:

Ձեր արտադրական միջավայրերը իսկապես պաշտպանելու համար դուք պետք է որդեգրեք խորը պաշտպանության ռազմավարություն.
1. Միացրեք էջի մակարդակի ստուգաթվերը ձեր տվյալների բազայի շարժիչում:
2. Օգտագործեք ներկառուցված վավերացման գործիքներ (pg_verifybackup, RESTORE VERIFYONLY) պահուստավորման ստեղծումից անմիջապես հետո:
3. Մոնիտորինգի ենթարկեք պահուստավորման մետատվյալները (չափը, տևողությունը) էվրիստիկ անոմալիաների համար:
4. Իրականացրեք ավտոմատացված, ժամանակավոր վերականգնման թեստավորում՝ որպես ձեր ամենօրյա գործառնական խողովակաշարի մաս:

Պասիվ «գործարկիր և մոռացիր» պահուստավորման մտածելակերպից անցնելով ակտիվ «շարունակական վերականգնման վավերացման» մոդելին՝ դուք ապահովում եք, որ երբ աղետը անխուսափելիորեն տեղի ունենա, ձեր տվյալները պատրաստ են, հուսալի և լիովին վերականգնելի: