Her rêvebirêkê databasê (DBA) û endezyarekî sîstemê di qonaxekê de ji kariyera xwe, ji bo paşvekişandina (backup) databasê, skrîptekî shell ê taybet nivîsiye. Ev bi pratîkî wekî merasîmeke derbasbûnê ye. Di qonaxên destpêkê yên projeyekê de, karekî hêsan ê cron ku mysqldump an pg_dump bi rêya gzip ve pêk tîne, wekî çareseriyeke elegant, sivik û biha-bandor xuya dike.
Lê belê, her ku binesazî mezin dibe, qebareya daneyan zêde dibe û SLA-yên dema xebatê (uptime) hişktir dibin, ew skrîpta Bash a 10-rêzî bi bêdengî vediguhere bombeyeke demkî. Jîngehên hilberînê (production) hewceyê hebûna bilind, Armancên Xala Vegerandinê (RPO) yên hişk û Armancên Dema Vegerandinê (RTO) yên bilez in. Piştgirîdayîna bi skrîptên paşvekişandinê yên DIY (bixwe-çêkirî) di van jîngehan de xetereyên giran ên têkildarî hevgirtina daneyan, têkçûnên bêdeng, qelsiyên ewlehiyê û pêvajoyên vegerandinê yên ku nayên birêvebirin, derdixe holê.
Di vê gotarê de, em ê kêmasiyên mîmarî û xetereyên veşartî yên skrîptên paşvekişandina databasê yên DIY analîz bikin, li ser astengên teknîkî yên paşvekişandinên mantiqî li hember fîzîkî bisekinin û nîqaş bikin ka çawa meriv dikare derbasî çareseriyên asta pargîdaniyê yên wekî CloudSave bibe da ku daneyên xwe yên krîtîk biparêze.
Xeyala Hêsaniyê: Analîzkirina Skrîpta Klasîk a DIY
Ji bo têgihîştina xetereyê, divê em pêşî li anatomîya skrîpteke paşvekişandinê ya tîpîk a DIY binêrin. Nêzîkatiyeke standard ji bo databasa MySQL bi gelemperî wiha xuya dike:
#!/bin/bash
# Skrîpta Paşvekişandina MySQL a DIY ya Hêsan
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
# Paşvekişandinên ji 30 rojan kevntir jê bibe
find $BACKUP_DIR -type f -name "*.sql.gz" -mtime +30 -exec rm {} ;
Di nihêrîna pêşîn de, ev skrîpt armancê pêk tîne: daneyan derdixe, wan kompres dike û hilanînê birêve dibe. Lê di bin rûyê wê de, ew bi kêmasiyên krîtîk tijî ye ku dê di dawiyê de di jîngeheke hilberînê de bibe sedema windabûna daneyan.
Xetereya 1: Têkçûnên Bêdeng û Kapanê Boriyê (Pipe Trap)
Yek ji xetereyên herî xedar ên skrîptên DIY, têkçûna bêdeng e. Di skrîpta jorîn de, fermana mysqldump rasterast bi rêya boriyê (|) tê şandin bo gzip.
Di Bash de, rewşa derketinê ya boriyekê, rewşa derketinê ya fermana dawî ya di boriyê de ye. Heke servera databasê bîra wê biqede, girêdanê qut bike, an di nîvê dumpê de rastî tabloyeke girtî were, mysqldump dê têk biçe û xeletiyekê bide. Lê belê, gzip dê bi serkeftî wê beşê ku wergirtiye kompres bike û bi koda rewşê ya 0 (serkeftin) derkeve.
Sîstema we ya çavdêriyê, ku koda derketinê ya karê cron kontrol dike, dê paşvekişandineke serkeftî ragihîne. Hûn ê li ser dîskê dosyeyeke .gz ya derbasdar hebin, lê di hundurê wê de dê dosyeyeke SQL ya qutbûyî û bêkêr hebe. Hûn ê heta ku hewl nedin vegerandineke krîtîk bikin, vê yekê fêm nekin.
Kêmkirina Xetereyê (û sînorên wê)
Endezyar bi gelemperî hewl didin vê yekê bi çalakirina birêvebirina xeletiyan a hişk di Bash de çareser bikin:
set -e
set -o pipefail
Her çend set -o pipefail piştrast dike ku skrîpt têk biçe heke her fermanek di boriyê de têk biçe, dîsa jî hewce dike ku hûn li dora skrîptê mekanîzmayên hişyarkirin, tomarkirin û ji nû ve hewldanê yên xurt ava bikin. Dema ku xeletiyeke tora demkî di saet 2:00ê sibehê de bibe sedema têkçûnê, skrîpteke DIY tenê dimire. Platformên pargîdaniyê van xeletiyên demkî bi hewldanên ji nû ve yên zîrek û pêşkeftî birêve dibin.
Xetereya 2: Hevgirtina Daneyan û Kabûsên Girtinê
Skrîptên DIY bi giranî xwe dispêrin paşvekişandinên mantiqî (mysqldump, pg_dump). Paşvekişandinên mantiqî daneyan bi xebitandina daxuyaniyên SELECT li ser hemû tabloyan derdixin. Di databaseke hilberînê ya pir danûstandinî de, dane her gav diguherin. Heke skrîpteke 45 deqîqeyan bikişîne da ku databaseke 100GB dump bike, daneyên li destpêka dumpê dê 45 deqîqeyan ji daneyên dawiyê kevntir bin, ku ev yek li dijî lihevhatina ACID e.
Hevgirtina Danûstandinî ya MySQL
Ji bo bidestxistina snapshoteke hevgirtî di MySQL de bi karanîna InnoDB, divê hûn alayên taybetî bişînin:
mysqldump --single-transaction --quick --routines --events -u user -p db > dump.sql
Alaya --single-transaction asta îzolasyonê dike REPEATABLE READ û berî dumpkirinê danûstandinekê dest pê dike. Lê belê, heke databasa we hîn jî tabloyan MyISAM ên kevnar dihewîne, ev ala dê rê li ber girtina wan negire, ku dibe ku trafîka xwendin/nivîsandinê ya hilberînê rawestîne dema ku paşvekişandin tê kirin. Wekî din, her daxuyaniyeke ALTER TABLE, DROP TABLE, an RENAME TABLE ku ji hêla pêşdebiran ve di dema paşvekişandinê de were xebitandin, dê snapshotê REPEATABLE READ bişkîne û bibe sedema têkçûna dumpê.
PostgreSQL û Arşîvkirina WAL
Ji bo PostgreSQL, pg_dump paşvekişandinên mantiqî yên hevgirtî peyda dike, lê paşvekişandinên mantiqî bi tenê nikarin Vegerandina Xala Demê (PITR) peyda bikin. Heke databasa we di saet 4:00ê êvarê de têk biçe û skrîpta we ya cron a dawî di nîvê şevê de xebitîbe, hûn 16 saetên daneyan winda dikin.
Bidestxistina PITR hewceyê arşîvkirina domdar a Tomarên Pêş-Nivîsandinê (WAL) ye. Nivîsandina skrîpteke DIY ji bo birêvebirina archive_command bi awayekî ewle pir dijwar e.
# postgresql.conf
wal_level = replica
archive_mode = on
archive_command = 'test ! -f /mnt/wal_archive/%f && cp %p /mnt/wal_archive/%f'
Heke depoya armanc (/mnt/wal_archive/) tijî bibe an neberdest bibe, archive_command dê têk biçe. PostgreSQL dê dûv re dosyeyên WAL bi xwe re kom bike heta ku dîska sereke tijî bibe, ku bibe sedema qutbûna temamî ya databasê. Skrîptên DIY kêm caran xwedî telemetriya pêwîst in ji bo çavdêriya komkirina WAL û hişyarkirina rêvebiran berî ku qutbûnek çêbibe.
Xetereya 3: Rûleta Hilanînê
Li fermana hilanînê ya di skrîpta me ya destpêkê de binêrin:
find $BACKUP_DIR -type f -name "*.sql.gz" -mtime +30 -exec rm {} ;
Ev bûyereke karesatbar a windabûna daneyan e ku li benda qewimînê ye. Senaryoyekê bifikirin ku guhertineke mîhengê rastkirina mysqldump dişkîne. Skrîpt nikare paşvekişandinên nû çêbike, lê fermana find her şev xebitandina xwe didomîne û bi dilsozî dosyeyên ji 30 rojan kevntir jê dibe.
Piştî 30 rojên têkçûnên bêdeng ên paşvekişandinê, fermana find dê paşvekişandina we ya baş a dawî ya mayî jî jê bibe. Hûn niha bêyî ti paşvekişandinê dimînin.
Nermalava paşvekişandinê ya pargîdaniyê wekî CloudSave polîtîkayên hilanînê yên dewletî (stateful) bikar tîne. Ew ferqa di navbera “paşvekişandinên ji 30 rojan kevntir jê bibe” û “piştrast bike ku herî kêm 30 xalên vegerandinê yên serkeftî hene berî ku daneyên kevn werin jêbirin” fêm dike.
Xetereya 4: Ewlehî, Şîfrekirin û Qelsiyên Lihevhatinê
Di serdema ransomware û çarçoveyên lihevhatinê yên hişk (GDPR, HIPAA, SOC 2) de, paşvekişandin hedefeke sereke ne. Skrîptên DIY pir caran rêgezên çêtirîn ên ewlehiyê binpê dikin:
- Nasnavên Hardcoded: Hilanîna şîfreyên databasê di skrîptên nivîsa sade an pênaseyên cron de xetereyeke mezin a ewlehiyê ye. Her çend amûrên wekî
mysql_config_editora MySQL an dosyeya.pgpassa PostgreSQL vê yekê kêm bikin jî, ew dîsa jî hewceyê birêvebirina dosyeyên kilîtên herêmî li ser serverê ne. - Nebûna Şîfrekirinê li ser Dîskê: Dumpkirina SQL-a xav bo ser dîskê, PII/PHI-yên hesas eşkere dihêle.
- Boriyên Şîfrekirinê yên Tevlihev: Hewldana şîfrekirina paşvekişandinan di dema xebatê de bi karanîna GPG, barê CPU-yê yê giran û tevliheviyên birêvebirina kilîtan derdixe holê.
# Boriyeke paşvekişandinê ya şîfrekirî ya DIY
pg_dump mydb | gzip | gpg --symmetric --cipher-algo AES256 --passphrase-file /etc/keys/backup.key > backup.sql.gz.gpg
Heke server were binpêkirin, êrîşkar gihîştina hem paşvekişandina şîfrekirî û hem jî dosyeya /etc/keys/backup.key heye, ku şîfrekirinê bêkêr dike. Wekî din, heke DBA-yê ku kilîta GPG çêkiriye ji pargîdaniyê derkeve û kilît were windakirin, paşvekişandin nayên vegerandin.
Xetereya 5: Rastiya RTO (Vegerandin ji Paşvekişandinê Zehmettir e)
Testa dawî ya paşvekişandinê, vegerandin e. Paşvekişandinên mantiqî yên ku ji hêla skrîptên DIY ve têne çêkirin, bi gelemperî hêdî têne vegerandin. Dumpkirineke SQL ya 500GB dibe ku 15 deqîqeyan bikişîne da ku were çêkirin, lê vegerandina wê hewce dike ku motora databasê SQL-ê şîrove bike, îndeksan ji nû ve ava bike û sînoran ji nû ve hesab bike. Ev dikare saetan an heta rojan bikişîne, RTO-ya we tune bike.
Ji bo databasên hilberînê yên mezin, paşvekişandinên fîzîkî (kopîkirina dosyeyên daneyan ên rastîn) mecbûrî ne. Her çend amûrên wekî Percona XtraBackup an pg_basebackup hebin jî, pêçandina wan di skrîptên Bash ên DIY de pir tevlihev e. Divê hûn snapshotên LVM birêve bibin, pergala dosyeyan kontrol bikin û piştrast bikin ku paşvekişandin bêyî qerebalixkirina navrûya torê bo derveyî malperê tê şandin.
Kapanê Snapshotê ya LVM
Gelek endezyar hewl didin paşvekişandinên fîzîkî yên “bê qutbûn” bi karanîna snapshotên LVM bikin:
# Snapshotekê çêbike
lvcreate --size 20G --snapshot --name db_snap /dev/vg0/db_vol
# Mount bike û kopî bike
mount /dev/vg0/db_snap /mnt/snap
tar -czf /backups/db_physical.tar.gz /mnt/snap/mysql
Heke databas rastî zêdebûneke nişkave ya I/O-ya nivîsandinê were, snapshotê LVM ya 20G dikare tavilê tijî bibe. Dema ku snapshotê LVM tijî dibe, ew dibe nederbasdar û paşvekişandin têk diçe. Ya xerabtir, snapshotên LVM yên ku zêde têne bikar anîn dikarin performansa I/O ya voluma databasê ya sereke bi giranî kêm bikin, ku bibe sedema derengiyên di sepanê de.
Derbasbûna bo Parastina Asta Pargîdaniyê
Derbasbûna ji skrîptên DIY bo platformeke pargîdaniyê, qonaxeke girîng a gihîştinê ye ji bo her tîmeke binesaziyê. Armanc ew e ku ji “hêviya ku skrîpt xebitiye” derbasî xwedîbûna delîlên krîptografîk ên vegerandinê bibin.
Platformên wekî CloudSave bi taybetî hatine sêwirandin da ku qelsiyên skrîptên DIY ji holê rakin. Bi bicihkirina ajanên hişmend ên sepanê, CloudSave rasterast bi API-yên databasê (MySQL, PostgreSQL, MS SQL, Oracle) re têkilî datîne da ku paşvekişandinên fîzîkî û mantiqî yên hevgirtî bêyî girtina tabloyan an kêmkirina performansê birêve bibe.
Feydeyên Sereke yên Derketina ji Skrîptan:
- Verastkirina Otomatîk: Platformên nûjen tenê paşvekişandinê nakin; ew wan test dikin. CloudSave dikare bixweber mînakeke databasê ya demkî veke, paşvekişandinê vegerîne, kontrolên hevgirtinê bimeşîne (mînak,
DBCC CHECKDB) û wê bigire, raporeke verastkirî pêşkêş bike ku paşvekişandin bi rastî bikêr e. - Depoya Neguhêrbar (Immutable): Ji bo şerê li dijî ransomware, paşvekişandin divê neguhêrbar bin. Skrîptên DIY nikarin bi hêsanî li depoya WORM (Carekê Binivîse, Gelek Caran Bixwîne) binivîsin. Çareseriyên pargîdaniyê bi xweber bi S3 Object Lock û depoya ewr a neguhêrbar re entegre dibin, piştrast dikin ku heke serverek bi tevahî were binpêkirin jî, paşvekişandin ji hêla êrîşkarekî ve nayên jêbirin an şîfrekirin.
- PITR-a Hêsankirî: Li şûna ku bi destan paşvekişandineke bingehîn û bi sedan dosyeyên WAL bi karanîna pîvanên tevlihev ên
recovery.confanpostgresql.auto.confbi hev ve girêdin, platform demjimêreke dîtbarî pêşkêş dikin. Hûn tenê deqîqeya rast a ku hûn dixwazin vegerînin hildibijêrin û nermalav bixweber lîstina tomaran (log replay) birêve dibe. - Deduplication û Kompresyon: Skrîptên DIY xwe dispêrin
gzip, ku her dosyeyê bi serê xwe kompres dike. Nermalava paşvekişandinê ya pargîdaniyê deduplication-a asta blokê ya gerdûnî bikar tîne, ku lêçûnên hilanînê û firehiya bandê ya torê dema şandina paşvekişandinan bo derveyî malperê bi giranî kêm dike.
Encam
Nivîsandina skrîpteke Bash a taybet ji bo paşvekişandina databasekê hêsan e. Nivîsandina skrîpteke ku têkçûnên boriyê yên bêdeng birêve dibe, hevgirtina ACID garantî dike, kilîtên krîptografîk bi ewlehî birêve dibe, pêşî li windabûna daneyan a li ser bingeha hilanînê digire û SLA-yên RTO/RPO yên hişk garantî dike, hema hema ne gengaz e.
Di jîngehên hilberînê de, databas sermayeya herî krîtîk a karsaziyê ye. Dîtina parastina wê wekî projeyeke alîkar ku ji hêla çend sed rêzên skrîpta shell ve tê domandin, xetereyek e ku tu pargîdanî nikare hilgire. Bi kontrolkirina stratejiyên xwe yên paşvekişandinê yên niha, têgihîştina sînorên dumpên mantiqî û koçkirina bo platformên xurt û otomatîk ên wekî CloudSave, tîmên DevOps û DBA dikarin “faktora otobusê” ya skrîptên taybet ji holê rakin û piştrast bikin ku daneyên wan bi rastî berxwedêr in.
