Mae pob Gweinyddwr Cronfa Ddata (DBA) a Pheiriannydd Systemau, ar ryw adeg yn eu gyrfa, wedi ysgrifennu sgript shell bersonol i wneud copi wrth gefn o gronfa ddata. Mae bron yn ddefod o basio. Yn y camau cynnar o brosiect, mae swydd cron syml sy’n gweithredu mysqldump neu pg_dump wedi’i bibellu i gzip yn ymddangos fel datrysiad cain, ysgafn a chost-effeithiol.
Fodd bynnag, wrth i seilwaith raddio, cyfrolau data dyfu, ac SLA amser gweithredu ddod yn llymach, mae’r sgript Bash 10 llinell honno’n trawsnewid yn dawel yn fom amser. Mae amgylcheddau cynhyrchu yn mynnu argaeledd uchel, Amcanion Pwynt Adfer (RPO) llym, ac Amcanion Amser Adfer (RTO) cyflym. Mae dibynnu ar sgriptiau copi wrth gefn DIY yn yr amgylcheddau hyn yn cyflwyno risgiau difrifol sy’n ymwneud â chysondeb data, methiannau tawel, gwendidau diogelwch, a phrosesau adfer na ellir eu rheoli.
Yn yr erthygl hon, byddwn yn dadansoddi diffygion pensaernïol a pheryglon cudd sgriptiau copi wrth gefn cronfa ddata DIY, yn archwilio’r peryglon technegol o gopïau wrth gefn rhesymegol yn erbyn rhai ffisegol, ac yn trafod sut i drosglwyddo i ddatrysiadau gradd menter fel CloudSave i amddiffyn eich data sy’n hanfodol i’r genhadaeth.
Rhith Symlrwydd: Dadansoddi’r Sgript DIY Glasurol
I ddeall y perygl, rhaid i ni edrych yn gyntaf ar anatomeg sgript copi wrth gefn DIY nodweddiadol. Mae dull safonol ar gyfer cronfa ddata MySQL yn aml yn edrych fel hyn:
#!/bin/bash
# Sgript Copi Wrth Gefn MySQL DIY Syml
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
# Dileu copïau wrth gefn sy'n hŷn na 30 diwrnod
find $BACKUP_DIR -type f -name "*.sql.gz" -mtime +30 -exec rm {} ;
Ar yr olwg gyntaf, mae’r sgript hon yn cyflawni’r nod: mae’n tynnu’r data, yn ei gywasgu, ac yn rheoli cadw. Ond o dan yr wyneb, mae’n llawn diffygion critigol a fydd yn y pen draw yn arwain at golli data mewn amgylchedd cynhyrchu.
Perygl 1: Methiannau Tawel a’r Trap Pibell
Un o beryglon mwyaf twyllodrus sgriptiau DIY yw’r methiant tawel. Yn y sgript uchod, mae’r gorchymyn mysqldump yn cael ei bibellu (|) yn uniongyrchol i gzip.
Yn Bash, statws ymadael piblinell yw statws ymadael y gorchymyn olaf yn y biblinell. Os yw’r gweinydd cronfa ddata yn rhedeg allan o gof, yn gollwng y cysylltiad, neu’n dod ar draws tabl wedi’i gloi hanner ffordd trwy’r dump, bydd mysqldump yn methu ac yn taflu gwall. Fodd bynnag, bydd gzip yn cywasgu’r allbwn rhannol a dderbyniodd yn llwyddiannus ac yn gadael gyda chod statws o 0 (llwyddiant).
Bydd eich system fonitro, sy’n gwirio cod ymadael y swydd cron, yn adrodd am gopi wrth gefn llwyddiannus. Bydd gennych ffeil .gz ddilys ar y ddisg, ond y tu mewn bydd ffeil SQL wedi’i thorri a’i difetha. Ni fyddwch yn darganfod hyn nes i chi geisio adferiad critigol.
Y Lliniaru (a’i gyfyngiadau)
Mae peirianwyr yn aml yn ceisio clwtio hyn trwy alluogi trin gwallau llym yn Bash:
set -e
set -o pipefail
Er bod set -o pipefail yn sicrhau bod y sgript yn methu os yw unrhyw orchymyn yn y biblinell yn methu, mae’n dal i ofyn i chi adeiladu mecanweithiau rhybuddio, logio ac ail-geisio cadarn o amgylch y sgript. Pan fydd gwall rhwydwaith dros dro yn achosi methiant am 2:00 AM, mae sgript DIY yn marw’n syml. Mae llwyfannau menter yn trin y gwallau dros dro hyn gydag ail-geisiau deallus, esbonyddol.
Perygl 2: Cysondeb Data a Hunllefau Cloi
Mae sgriptiau DIY yn dibynnu’n drwm ar gopïau wrth gefn rhesymegol (mysqldump, pg_dump). Mae copïau wrth gefn rhesymegol yn tynnu data trwy redeg datganiadau SELECT ar draws yr holl dablau. Mewn cronfa ddata gynhyrchu hynod drafodol, mae data yn newid yn gyson. Os yw sgript yn cymryd 45 munud i dumpio cronfa ddata 100GB, bydd y data ar ddechrau’r dump 45 munud yn hŷn na’r data ar y diwedd, gan dorri cydymffurfiaeth ACID.
Cysondeb Trafodol MySQL
I gyflawni ciplun cyson yn MySQL gan ddefnyddio InnoDB, rhaid i chi basio baneri penodol:
mysqldump --single-transaction --quick --routines --events -u user -p db > dump.sql
Mae’r faner --single-transaction yn gosod y lefel ynysu i REPEATABLE READ ac yn cychwyn trafodiad cyn dumpio. Fodd bynnag, os yw eich cronfa ddata yn dal i gynnwys tablau MyISAM etifeddiaeth, ni fydd y faner hon yn eu hatal rhag cloi, gan o bosibl atal traffig darllen/ysgrifennu cynhyrchu tra bod y copi wrth gefn yn rhedeg. Ar ben hynny, bydd unrhyw ddatganiadau ALTER TABLE, DROP TABLE, neu RENAME TABLE a weithredir gan ddatblygwyr yn ystod y copi wrth gefn yn torri’r ciplun REPEATABLE READ, gan achosi i’r dump fethu.
PostgreSQL ac Archifo WAL
Ar gyfer PostgreSQL, mae pg_dump yn darparu copïau wrth gefn rhesymegol cyson, ond ni all copïau wrth gefn rhesymegol ar eu pen eu hunain ddarparu Adferiad Pwynt-mewn-Amser (PITR). Os yw eich cronfa ddata yn chwalu am 4:00 PM a bod eich sgript cron ddiwethaf wedi rhedeg am hanner nos, rydych chi’n colli 16 awr o ddata.
Mae cyflawni PITR yn gofyn am archifo parhaus o Logiau Ysgrifennu-Ymlaen (WAL). Mae ysgrifennu sgript DIY i drin archive_command yn ddiogel yn hynod anodd.
# postgresql.conf
wal_level = replica
archive_mode = on
archive_command = 'test ! -f /mnt/wal_archive/%f && cp %p /mnt/wal_archive/%f'
Os yw’r storfa cyrchfan (/mnt/wal_archive/) yn llenwi neu’n dod yn anhygyrch, bydd y archive_command yn methu. Bydd PostgreSQL wedyn yn cronni ffeiliau WAL yn lleol nes bod y brif ddisg yn llenwi, gan achosi methiant llwyr i’r gronfa ddata. Anaml y mae gan sgriptiau DIY y telemetreg sydd ei angen i fonitro cronni WAL a rhybuddio gweinyddwyr cyn i fethiant ddigwydd.
Perygl 3: Roulette Cadw
Edrychwch yn ôl ar y gorchymyn cadw yn ein sgript gychwynnol:
find $BACKUP_DIR -type f -name "*.sql.gz" -mtime +30 -exec rm {} ;
Mae hwn yn ddigwyddiad colli data trychinebus sy’n aros i ddigwydd. Dychmygwch senario lle mae newid cyfluniad yn torri dilysu mysqldump. Mae’r sgript yn methu creu copïau wrth gefn newydd, ond mae’r gorchymyn find yn parhau i redeg bob nos, gan ddileu ffeiliau sy’n hŷn na 30 diwrnod yn ddiwyd.
Ar ôl 30 diwrnod o fethiannau copi wrth gefn tawel, bydd y gorchymyn find yn dileu eich copi wrth gefn da olaf sy’n weddill. Rydych chi nawr ar ôl gyda dim copïau wrth gefn.
Mae meddalwedd copi wrth gefn menter fel CloudSave yn defnyddio polisïau cadw cyflwr. Mae’n deall y gwahaniaeth rhwng “dileu copïau wrth gefn sy’n hŷn na 30 diwrnod” a “sicrhau bod o leiaf 30 o bwyntiau adfer llwyddiannus yn bodoli cyn tocio data hen.”
Perygl 4: Mannau Dall Diogelwch, Amgryptio, a Chydymffurfiaeth
Yn oes meddalwedd pridwerth a fframweithiau cydymffurfio llym (GDPR, HIPAA, SOC 2), mae copïau wrth gefn yn darged pennaf. Mae sgriptiau DIY yn aml yn torri arferion gorau diogelwch:
- Tystlythyrau wedi’u codio’n galed: Mae storio cyfrineiriau cronfa ddata mewn sgriptiau testun plaen neu ddiffiniadau cron yn risg diogelwch enfawr. Er bod offer fel
mysql_config_editorMySQL neu ffeil.pgpassPostgreSQL yn lliniaru hyn, maent yn dal i ofyn am reoli ffeiliau allweddol lleol ar y gweinydd. - Diffyg Amgryptio wrth Orffwys: Mae dumpio SQL amrwd i ddisg yn gadael PII/PHI sensitif yn agored.
- Piblinellau Amgryptio Cymhleth: Mae ceisio amgryptio copïau wrth gefn ar y hedfan gan ddefnyddio GPG yn cyflwyno gorbenion CPU difrifol a chymhlethdodau rheoli allweddi.
# Piblinell copi wrth gefn wedi'i hamgryptio DIY
pg_dump mydb | gzip | gpg --symmetric --cipher-algo AES256 --passphrase-file /etc/keys/backup.key > backup.sql.gz.gpg
Os yw’r gweinydd wedi’i beryglu, mae gan yr ymosodwr fynediad i’r copi wrth gefn wedi’i amgryptio a’r ffeil /etc/keys/backup.key, gan wneud yr amgryptio yn ddiwerth. Ar ben hynny, os yw’r DBA a gynhyrchodd yr allwedd GPG yn gadael y cwmni ac mae’r allwedd ar goll, mae’r copïau wrth gefn yn anadferadwy.
Perygl 5: Gwirio Realiti RTO (Mae Adfer yn Anoddach na Gwneud Copi Wrth Gefn)
Prawf eithaf copi wrth gefn yw’r adferiad. Mae copïau wrth gefn rhesymegol a gynhyrchir gan sgriptiau DIY yn enwog am fod yn araf i’w hadfer. Gall dump SQL 500GB gymryd 15 munud i’w greu, ond mae ei adfer yn gofyn i’r injan cronfa ddata ddadansoddi’r SQL, ailadeiladu mynegeion, ac ailgyfrifo cyfyngiadau. Gall hyn gymryd oriau neu hyd yn oed ddyddiau, gan ddileu eich RTO.
Ar gyfer cronfeydd data cynhyrchu mawr, mae copïau wrth gefn ffisegol (copïo’r ffeiliau data gwirioneddol) yn orfodol. Er bod offer fel Percona XtraBackup neu pg_basebackup yn bodoli, mae eu lapio mewn sgriptiau Bash DIY yn hynod gymhleth. Rhaid i chi reoli cipluniau LVM, trin tawelu system ffeiliau, a sicrhau bod y copi wrth gefn yn cael ei drosglwyddo oddi ar y safle heb ddirlawn y rhyngwyneb rhwydwaith.
Y Trap Ciplun LVM
Mae llawer o beirianwyr yn ceisio copïau wrth gefn ffisegol “dim amser segur” gan ddefnyddio cipluniau LVM:
# Creu ciplun
lvcreate --size 20G --snapshot --name db_snap /dev/vg0/db_vol
# Mowntio a chopïo
mount /dev/vg0/db_snap /mnt/snap
tar -czf /backups/db_physical.tar.gz /mnt/snap/mysql
Os yw’r gronfa ddata yn profi pigyn sydyn mewn ysgrifennu I/O, gall y ciplun LVM 20G lenwi ar unwaith. Pan fydd ciplun LVM yn llenwi, mae’n dod yn annilys, ac mae’r copi wrth gefn yn methu. Yn waeth, gall cipluniau LVM a ddefnyddir yn drwm ddiraddio perfformiad I/O y brif gyfrol cronfa ddata yn ddifrifol, gan achosi pigau hwyrni cymhwysiad.
Trosglwyddo i Amddiffyniad Gradd Menter
Mae’r trosglwyddiad o sgriptiau DIY i lwyfan menter yn garreg filltir aeddfedrwydd hanfodol ar gyfer unrhyw dîm seilwaith. Y nod yw symud o “obeithio bod y sgript wedi rhedeg” i gael prawf cryptograffig o allu i adfer.
Mae llwyfannau fel CloudSave wedi’u peiriannu’n benodol i ddileu mannau dall sgriptio DIY. Trwy ddefnyddio asiantau sy’n ymwybodol o gymwysiadau, mae CloudSave yn rhyngweithio’n uniongyrchol ag APIs y gronfa ddata (MySQL, PostgreSQL, MS SQL, Oracle) i drefnu copïau wrth gefn ffisegol a rhesymegol cyson heb gloi tablau neu ddiraddio perfformiad.
Manteision Allweddol Symud i Ffwrdd o Sgriptiau:
- Dilysu Awtomataidd: Nid yw llwyfannau modern yn cymryd copïau wrth gefn yn unig; maent yn eu profi. Gall CloudSave droi enghraifft cronfa ddata dros dro ymlaen yn awtomatig, adfer y copi wrth gefn, rhedeg gwiriadau cysondeb (e.e.,
DBCC CHECKDB), a’i ddymchwel, gan ddarparu adroddiad wedi’i ddilysu bod y copi wrth gefn yn ddefnyddiadwy mewn gwirionedd. - Storfa Anadnewyddadwy: I frwydro yn erbyn meddalwedd pridwerth, rhaid i gopïau wrth gefn fod yn anadnewyddadwy. Ni all sgriptiau DIY ysgrifennu’n hawdd i storfa WORM (Ysgrifennu Unwaith, Darllen Llawer). Mae datrysiadau menter yn integreiddio’n frodorol â S3 Object Lock a storfa cwmwl anadnewyddadwy, gan sicrhau, hyd yn oed os yw gweinydd wedi’i beryglu’n llwyr, na ellir dileu neu amgryptio’r copïau wrth gefn gan ymosodwr.
- PITR Syml: Yn lle pwytho copi wrth gefn sylfaenol a channoedd o ffeiliau WAL at ei gilydd â llaw gan ddefnyddio paramedrau
recovery.confneupostgresql.auto.confcymhleth, mae llwyfannau yn darparu llinell amser weledol. Rydych chi’n dewis y funud union rydych chi am adfer iddi, ac mae’r meddalwedd yn trin yr ailchwarae log yn awtomatig. - Deduplication a Chywasgu: Mae sgriptiau DIY yn dibynnu ar
gzip, sy’n cywasgu pob ffeil yn unigol. Mae meddalwedd copi wrth gefn menter yn defnyddio deduplication ar lefel bloc byd-eang, gan leihau costau storio a lled band rhwydwaith yn ddramatig wrth drosglwyddo copïau wrth gefn oddi ar y safle.
Casgliad
Mae ysgrifennu sgript Bash bersonol i wneud copi wrth gefn o gronfa ddata yn hawdd. Mae ysgrifennu sgript sy’n trin methiannau piblinell tawel, yn gwarantu cysondeb ACID, yn rheoli allweddi cryptograffig yn ddiogel, yn atal colli data yn seiliedig ar gadw, ac yn gwarantu SLA RTO/RPO llym yn bron yn amhosibl.
Mewn amgylcheddau cynhyrchu, y gronfa ddata yw ased mwyaf critigol y busnes. Mae trin ei amddiffyniad fel prosiect ochr a gynhelir gan ychydig gannoedd o linellau o sgript shell yn risg na all unrhyw fenter ei fforddio. Trwy archwilio eich strategaethau copi wrth gefn cyfredol, deall cyfyngiadau dumps rhesymegol, a mudo i lwyfannau cadarn, awtomataidd fel CloudSave, gall timau DevOps a DBA ddileu “ffactor bws” sgriptiau personol a sicrhau bod eu data yn wirioneddol wydn.
