DIY տվյալների բազայի պահուստային պատճենման սկրիպտների թաքնված վտանգները. ինչո՞ւ հատուկ Bash-ը չի կարող մասշտաբավորվել արտադրական միջավայրում

Յուրաքանչյուր տվյալների բազայի ադմինիստրատոր (DBA) և համակարգային ինժեներ իր կարիերայի ինչ-որ պահի գրել է հատուկ shell սկրիպտ՝ տվյալների բազան պահուստավորելու համար: Սա գործնականում «կնունքի» պես մի բան է: Նախագծի վաղ փուլերում mysqldump կամ pg_dump հրամանները gzip-ի միջոցով կատարող պարզ cron job-ը թվում է էլեգանտ, թեթև և ծախսարդյունավետ լուծում:

Այնուամենայնիվ, ենթակառուցվածքների ընդլայնմանը զուգընթաց, երբ տվյալների ծավալները մեծանում են, իսկ աշխատունակության (uptime) SLA-ները դառնում են ավելի խիստ, այդ 10 տողանոց Bash սկրիպտը լուռ վերածվում է «ժամանակացույցով աշխատող ռումբի»: Արտադրական միջավայրերը պահանջում են բարձր հասանելիություն, վերականգնման կետի խիստ նպատակներ (RPO) և վերականգնման ժամանակի արագ նպատակներ (RTO): Նման միջավայրերում ինքնաշեն (DIY) պահուստավորման սկրիպտների վրա հույս դնելը լուրջ ռիսկեր է առաջացնում՝ կապված տվյալների հետևողականության, աննկատ ձախողումների, անվտանգության խոցելիության և անկառավարելի վերականգնման գործընթացների հետ:

Այս հոդվածում մենք կվերլուծենք DIY պահուստավորման սկրիպտների ճարտարապետական թերությունները և թաքնված վտանգները, կուսումնասիրենք տրամաբանական և ֆիզիկական պահուստավորման տեխնիկական թակարդները և կքննարկենք, թե ինչպես անցնել CloudSave-ի նման ձեռնարկատիրական մակարդակի լուծումներին՝ ձեր առաքելության համար կարևոր տվյալները պաշտպանելու համար:

Պարզության պատրանք. դասական DIY սկրիպտի վերլուծություն

Վտանգը հասկանալու համար նախ պետք է դիտարկել տիպիկ DIY պահուստավորման սկրիպտի կառուցվածքը: MySQL տվյալների բազայի համար ստանդարտ մոտեցումը հաճախ այսպիսի տեսք ունի.

#!/bin/bash
# Simple DIY MySQL Backup Script
BACKUP_DIR="/mnt/backups"
DATE=$(date +%F)
DB_USER="admin"
DB_PASS="SuperSecret123!"

mysqldump -u $DB_USER -p$DB_PASS my_database | gzip > $BACKUP_DIR/mydb_$DATE.sql.gz

# Delete backups older than 30 days
find $BACKUP_DIR -type f -name "*.sql.gz" -mtime +30 -exec rm {} ;

Առաջին հայացքից այս սկրիպտը կատարում է իր խնդիրը. այն արտահանում է տվյալները, սեղմում դրանք և կառավարում պահպանման ժամկետը: Սակայն մակերեսի տակ այն լի է կրիտիկական թերություններով, որոնք վաղ թե ուշ կհանգեցնեն արտադրական միջավայրում տվյալների կորստի:

Վտանգ 1. Աննկատ ձախողումներ և «խողովակաշարի» թակարդը

DIY սկրիպտների ամենավտանգավոր կողմերից մեկը աննկատ ձախողումն է: Վերոնշյալ սկրիպտում mysqldump հրամանը խողովակով (|) ուղղակիորեն փոխանցվում է gzip-ին:

Bash-ում խողովակաշարի ելքային կարգավիճակը հանդիսանում է խողովակաշարի վերջին հրամանի ելքային կարգավիճակը: Եթե տվյալների բազայի սերվերի հիշողությունը սպառվի, կապը ընդհատվի կամ dump-ի ընթացքում հանդիպի արգելափակված աղյուսակի, mysqldump-ը կձախողվի և սխալ կտա: Այնուամենայնիվ, gzip-ը հաջողությամբ կսեղմի ստացված մասնակի տվյալները և կավարտի աշխատանքը 0 (հաջող) կարգավիճակով:

Ձեր մոնիտորինգի համակարգը, ստուգելով cron job-ի ելքային կոդը, կհաղորդի հաջող պահուստավորման մասին: Դուք սկավառակի վրա կունենաք վավեր .gz ֆայլ, բայց դրա ներսում կլինի կտրված, անպետք SQL ֆայլ: Դուք դա չեք բացահայտի այնքան ժամանակ, քանի դեռ չեք փորձի կատարել կրիտիկական վերականգնում:

Մեղմացում (և դրա սահմանափակումները)

Ինժեներները հաճախ փորձում են սա շտկել՝ Bash-ում միացնելով սխալների խիստ մշակումը.

set -e
set -o pipefail

Թեև set -o pipefail-ը երաշխավորում է, որ սկրիպտը կձախողվի, եթե խողովակաշարի որևէ հրաման ձախողվի, այնուամենայնիվ, այն պահանջում է սկրիպտի շուրջ կառուցել հուսալի ծանուցման, գրանցման (logging) և վերափորձման մեխանիզմներ: Երբ ցանցային ժամանակավոր սխալը առաջացնում է ձախողում գիշերվա ժամը 2-ին, DIY սկրիպտը պարզապես դադարում է աշխատել: Ձեռնարկատիրական հարթակները նման ժամանակավոր սխալները լուծում են խելացի, էքսպոնենցիալ վերափորձման մեխանիզմներով:

Վտանգ 2. Տվյալների հետևողականություն և արգելափակման մղձավանջներ

DIY սկրիպտները մեծապես հիմնված են տրամաբանական պահուստավորման (mysqldump, pg_dump) վրա: Տրամաբանական պահուստավորումը տվյալները հանում է՝ բոլոր աղյուսակներում SELECT հրամաններ կատարելով: Բարձր գործարքային արտադրական տվյալների բազայում տվյալները անընդհատ փոխվում են: Եթե սկրիպտին 100 ԳԲ տվյալների բազան dump անելու համար պահանջվում է 45 րոպե, ապա dump-ի սկզբում առկա տվյալները 45 րոպեով ավելի հին կլինեն, քան վերջում առկա տվյալները՝ խախտելով ACID համապատասխանությունը:

MySQL գործարքային հետևողականություն

InnoDB-ի միջոցով MySQL-ում հետևողական snapshot ստանալու համար դուք պետք է օգտագործեք հատուկ դրոշակներ.

mysqldump --single-transaction --quick --routines --events -u user -p db > dump.sql

--single-transaction դրոշակը մեկուսացման մակարդակը սահմանում է REPEATABLE READ և dump-ից առաջ սկսում է գործարք: Այնուամենայնիվ, եթե ձեր տվյալների բազան դեռ պարունակում է հին MyISAM աղյուսակներ, այս դրոշակը չի կանխի դրանց արգելափակումը, ինչը կարող է կանգնեցնել արտադրական ընթերցման/գրման երթևեկությունը պահուստավորման ընթացքում: Ավելին, պահուստավորման ժամանակ ծրագրավորողների կողմից կատարված ցանկացած ALTER TABLE, DROP TABLE կամ RENAME TABLE հրաման կխախտի REPEATABLE READ snapshot-ը՝ հանգեցնելով dump-ի ձախողման:

PostgreSQL և WAL արխիվացում

PostgreSQL-ի համար pg_dump-ը ապահովում է հետևողական տրամաբանական պահուստավորում, սակայն միայն տրամաբանական պահուստավորումը չի կարող ապահովել Point-in-Time Recovery (PITR): Եթե ձեր տվյալների բազան խափանվի ժամը 16:00-ին, իսկ ձեր վերջին cron սկրիպտը աշխատել է կեսգիշերին, դուք կկորցնեք 16 ժամվա տվյալներ:

PITR-ին հասնելու համար անհրաժեշտ է Write-Ahead Logs (WAL)-ի շարունակական արխիվացում: archive_command-ը անվտանգ կառավարելու համար DIY սկրիպտ գրելը չափազանց դժվար է:

# postgresql.conf
wal_level = replica
archive_mode = on
archive_command = 'test ! -f /mnt/wal_archive/%f && cp %p /mnt/wal_archive/%f'

Եթե նպատակային պահեստը (/mnt/wal_archive/) լցվի կամ դառնա անհասանելի, archive_command-ը կձախողվի: Այնուհետև PostgreSQL-ը տեղում կկուտակի WAL ֆայլերը, մինչև հիմնական սկավառակը լցվի՝ առաջացնելով տվյալների բազայի ամբողջական խափանում: DIY սկրիպտները հազվադեպ են ունենում WAL-ի կուտակումը վերահսկելու և մինչև խափանումը ադմինիստրատորներին զգուշացնելու համար անհրաժեշտ հեռաչափություն (telemetry):

Վտանգ 3. Պահպանման ժամկետի ռուլետկա

Հետ նայեք մեր սկզբնական սկրիպտի պահպանման հրամանին.

find $BACKUP_DIR -type f -name "*.sql.gz" -mtime +30 -exec rm {} ;

Սա տվյալների կորստի աղետալի իրադարձություն է, որը սպասում է իր ժամին: Պատկերացրեք մի սցենար, որտեղ կոնֆիգուրացիայի փոփոխությունը խախտում է mysqldump-ի նույնականացումը: Սկրիպտը չի կարողանում ստեղծել նոր պահուստային պատճեններ, բայց find հրամանը շարունակում է աշխատել ամեն գիշեր՝ բարեխղճորեն ջնջելով 30 օրից ավելի հին ֆայլերը:

Պահուստավորման 30-օրյա լուռ ձախողումներից հետո find հրամանը կջնջի ձեր վերջին մնացած լավ պահուստային պատճենը: Դուք այժմ մնացել եք առանց պահուստային պատճենների:

CloudSave-ի նման ձեռնարկատիրական պահուստավորման ծրագրերը օգտագործում են պահպանման պետական (stateful) քաղաքականություններ: Այն հասկանում է «ջնջել 30 օրից ավելի հին պահուստային պատճենները» և «համոզվել, որ հին տվյալները հեռացնելուց առաջ առկա են առնվազն 30 հաջող վերականգնման կետեր» հրամանների տարբերությունը:

Վտանգ 4. Անվտանգության, գաղտնագրման և համապատասխանության «կույր կետեր»

Փրկագին-վիրուսների (ransomware) և խիստ համապատասխանության շրջանակների (GDPR, HIPAA, SOC 2) դարաշրջանում պահուստային պատճենները հիմնական թիրախ են: DIY սկրիպտները հաճախ խախտում են անվտանգության լավագույն փորձը.

1. Կոշտ կոդավորված հավատարմագրեր (Hardcoded Credentials): Տվյալների բազայի գաղտնաբառերը պարզ տեքստով սկրիպտներում կամ cron սահմանումներում պահելը անվտանգության հսկայական ռիսկ է: Թեև MySQL-ի mysql_config_editor կամ PostgreSQL-ի .pgpass ֆայլի նման գործիքները մեղմացնում են սա, դրանք դեռ պահանջում են սերվերի վրա տեղական բանալի ֆայլերի կառավարում:
2. Հանգստի վիճակում գաղտնագրման բացակայություն: Հում SQL-ը սկավառակի վրա dump անելը բաց է թողնում զգայուն PII/PHI տվյալները:
3. Գաղտնագրման բարդ խողովակաշարեր: GPG-ի միջոցով պահուստային պատճենները թռիչքի ժամանակ գաղտնագրելու փորձը ներկայացնում է պրոցեսորի ծանրաբեռնվածության և բանալիների կառավարման լուրջ բարդություններ:

# A DIY encrypted backup pipeline
pg_dump mydb | gzip | gpg --symmetric --cipher-algo AES256 --passphrase-file /etc/keys/backup.key > backup.sql.gz.gpg

Եթե սերվերը վտանգված է, հարձակվողը հասանելիություն ունի և՛ գաղտնագրված պահուստային պատճենին, և՛ /etc/keys/backup.key ֆայլին, ինչը գաղտնագրումը դարձնում է անօգուտ: Ավելին, եթե GPG բանալին ստեղծած DBA-ն հեռանում է ընկերությունից և բանալին կորչում է, պահուստային պատճենները անվերականգնելի են:

Վտանգ 5. RTO-ի իրականության ստուգում (Վերականգնումը ավելի դժվար է, քան պահուստավորումը)

Պահուստային պատճենի վերջնական ստուգումը վերականգնումն է: DIY սկրիպտների կողմից ստեղծված տրամաբանական պահուստային պատճենները վերականգնելու համար հայտնի են իրենց դանդաղությամբ: 500 ԳԲ SQL dump-ը կարող է ստեղծվել 15 րոպեում, բայց այն վերականգնելու համար տվյալների բազայի շարժիչից պահանջվում է վերլուծել SQL-ը, վերակառուցել ինդեքսները և վերահաշվարկել սահմանափակումները: Սա կարող է տևել ժամեր կամ նույնիսկ օրեր՝ ոչնչացնելով ձեր RTO-ն:

Խոշոր արտադրական տվյալների բազաների համար ֆիզիկական պահուստավորումը (իրական տվյալների ֆայլերի պատճենումը) պարտադիր է: Թեև գոյություն ունեն Percona XtraBackup կամ pg_basebackup գործիքներ, դրանք DIY Bash սկրիպտներում փաթեթավորելը չափազանց բարդ է: Դուք պետք է կառավարեք LVM snapshot-ները, կարգավորեք ֆայլային համակարգի quiescing-ը և ապահովեք, որ պահուստային պատճենը փոխանցվի արտաքին վայր՝ առանց ցանցային ինտերֆեյսը ծանրաբեռնելու:

LVM snapshot-ի թակարդը

Շատ ինժեներներ փորձում են «զրոյական պարապուրդով» ֆիզիկական պահուստավորում կատարել՝ օգտագործելով LVM snapshot-ներ.

# Create a snapshot
lvcreate --size 20G --snapshot --name db_snap /dev/vg0/db_vol

# Mount and copy
mount /dev/vg0/db_snap /mnt/snap
tar -czf /backups/db_physical.tar.gz /mnt/snap/mysql

Եթե տվյալների բազան զգում է գրման I/O-ի հանկարծակի աճ, 20 ԳԲ LVM snapshot-ը կարող է ակնթարթորեն լցվել: Երբ LVM snapshot-ը լցվում է, այն դառնում է անվավեր, և պահուստավորումը ձախողվում է: Ավելի վատ, ծանրաբեռնված LVM snapshot-ները կարող են լրջորեն նվազեցնել հիմնական տվյալների բազայի ծավալի I/O արդյունավետությունը՝ առաջացնելով հավելվածի ուշացումներ:

Անցում ձեռնարկատիրական մակարդակի պաշտպանության

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

CloudSave-ի նման հարթակները նախագծված են հատուկ DIY սկրիպտավորման «կույր կետերը» վերացնելու համար: Տեղակայելով հավելվածի մասին տեղեկացված գործակալներ՝ CloudSave-ը անմիջականորեն փոխազդում է տվյալների բազայի API-ների (MySQL, PostgreSQL, MS SQL, Oracle) հետ՝ կազմակերպելու հետևողական ֆիզիկական և տրամաբանական պահուստավորումներ՝ առանց աղյուսակները արգելափակելու կամ արդյունավետությունը նվազեցնելու:

Սկրիպտներից հրաժարվելու հիմնական առավելությունները.

1. Ավտոմատացված ստուգում. Ժամանակակից հարթակները ոչ միայն պահուստավորում են կատարում, այլև ստուգում են դրանք: CloudSave-ը կարող է ավտոմատ կերպով գործարկել ժամանակավոր տվյալների բազայի օրինակ, վերականգնել պահուստային պատճենը, կատարել հետևողականության ստուգումներ (օրինակ՝ DBCC CHECKDB) և ջնջել այն՝ տրամադրելով հաստատված հաշվետվություն, որ պահուստային պատճենը իրականում օգտագործելի է:
2. Անփոփոխ պահեստ (Immutable Storage). Փրկագին-վիրուսների դեմ պայքարելու համար պահուստային պատճենները պետք է լինեն անփոփոխ: DIY սկրիպտները չեն կարող հեշտությամբ գրել WORM (Write Once, Read Many) պահեստում: Ձեռնարկատիրական լուծումները բնիկ կերպով ինտեգրվում են S3 Object Lock-ի և անփոփոխ ամպային պահեստի հետ՝ ապահովելով, որ նույնիսկ եթե սերվերը լիովին վտանգված է, պահուստային պատճենները չեն կարող ջնջվել կամ գաղտնագրվել հարձակվողի կողմից:
3. Պարզեցված PITR. Բարդ recovery.conf կամ postgresql.auto.conf պարամետրերի միջոցով բազային պահուստային պատճենը և հարյուրավոր WAL ֆայլերը ձեռքով միացնելու փոխարեն, հարթակները տրամադրում են տեսողական ժամանակացույց: Դուք պարզապես ընտրում եք այն ճշգրիտ րոպեն, որին ցանկանում եք վերականգնել, և ծրագրաշարը ավտոմատ կերպով կատարում է լոգերի վերարտադրումը:
4. Դեդուպլիկացիա և սեղմում. DIY սկրիպտները հիմնված են gzip-ի վրա, որը սեղմում է յուրաքանչյուր ֆայլ առանձին: Ձեռնարկատիրական պահուստավորման ծրագրերը օգտագործում են գլոբալ բլոկային մակարդակի դեդուպլիկացիա՝ կտրուկ նվազեցնելով պահեստավորման ծախսերը և ցանցի թողունակությունը պահուստային պատճենները արտաքին վայր փոխանցելիս:

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

Տվյալների բազան պահուստավորելու համար հատուկ Bash սկրիպտ գրելը հեշտ է: Սկրիպտ գրելը, որը կարգավորում է խողովակաշարի լուռ ձախողումները, երաշխավորում է ACID հետևողականությունը, անվտանգ կառավարում է գաղտնագրային բանալիները, կանխում է պահպանման ժամկետի վրա հիմնված տվյալների կորուստը և երաշխավորում է RTO/RPO խիստ SLA-ները, գրեթե անհնար է:

Արտադրական միջավայրերում տվյալների բազան բիզնեսի ամենակարևոր ակտիվն է: Դրա պաշտպանությունը որպես մի քանի հարյուր տող shell սկրիպտով պահպանվող կողմնակի նախագիծ դիտարկելը ռիսկ է, որին ոչ մի ձեռնարկություն չի կարող իրեն թույլ տալ: Աուդիտի ենթարկելով ձեր ընթացիկ պահուստավորման ռազմավարությունները, հասկանալով տրամաբանական dump-երի սահմանափակումները և տեղափոխվելով CloudSave-ի նման հուսալի, ավտոմատացված հարթակներ՝ DevOps և DBA թիմերը կարող են վերացնել հատուկ սկրիպտների «ավտոբուսի գործոնը» (bus factor) և ապահովել, որ իրենց տվյալները իսկապես կայուն են: