Categories
Database Backup

** Discover the hidden dangers of DIY database backup scripts. Learn why custom Bash scripts fail in production, the risks of logical dumps, and how to secure your data with enterprise solutions.

Kiekvienas duomenų bazių administratorius (DBA) ir sistemų inžinierius savo karjeroje bent kartą yra parašęs pasirinktinį „shell“ scenarijų duomenų bazei kurti. Tai praktiškai yra savotiškas „krikštas“. Ankstyvosiose projekto stadijose paprastas „cron“ užduoties vykdymas, kai mysqldump arba pg_dump nukreipiami į gzip, atrodo kaip elegantiškas, lengvas ir ekonomiškas sprendimas.

Tačiau infrastruktūrai plečiantis, duomenų kiekiui augant, o veikimo laiko (uptime) SLA (paslaugų kokybės susitarimams) tampant griežtesniems, tas 10 eilučių „Bash“ scenarijus tyliai virsta tiksinčia bomba. Gamybinėse aplinkose reikalaujama aukšto pasiekiamumo, griežtų duomenų atkūrimo taškų (RPO) ir greitų atkūrimo laiko tikslų (RTO). Pasikliovimas savadarbiais atsarginių kopijų scenarijais šiose aplinkose sukelia rimtą riziką, susijusią su duomenų vientisumu, nepastebimais gedimais, saugumo spragomis ir nevaldomais atkūrimo procesais.

Šiame straipsnyje išnagrinėsime architektūrinius trūkumus ir paslėptus savadarbių duomenų bazių atsarginių kopijų scenarijų pavojus, aptarsime technines loginių ir fizinių atsarginių kopijų problemas bei tai, kaip pereiti prie verslo klasės sprendimų, tokių kaip „CloudSave“, siekiant apsaugoti jūsų verslui kritinius duomenis.

Paprastumo iliuzija: savadarbio scenarijaus anatomija

Norėdami suprasti pavojų, pirmiausia turime pažvelgti į tipinio savadarbio atsarginių kopijų scenarijaus struktūrą. Standartinis požiūris į „MySQL“ duomenų bazę dažnai atrodo taip:

#!/bin/bash
# Paprastas savadarbis MySQL atsarginių kopijų scenarijus
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

# Ištrinti senesnes nei 30 dienų atsargines kopijas
find $BACKUP_DIR -type f -name "*.sql.gz" -mtime +30 -exec rm {} ;

Iš pirmo žvilgsnio šis scenarijus atlieka savo darbą: ištraukia duomenis, juos suspaudžia ir tvarko saugojimo laikotarpį. Tačiau po paviršiumi jis kupinas kritinių trūkumų, kurie gamybinėje aplinkoje ilgainiui sukels duomenų praradimą.

1 pavojus: nepastebimi gedimai ir „pipe“ spąstai

Vienas klastingiausių savadarbių scenarijų pavojų yra nepastebimi gedimai. Aukščiau pateiktame scenarijuje mysqldump komanda nukreipiama (|) tiesiai į gzip.

„Bash“ aplinkoje konvejerio (pipeline) išėjimo būsena yra paskutinės konvejerio komandos išėjimo būsena. Jei duomenų bazės serveryje baigiasi atmintis, nutrūksta ryšys arba pusiaukelėje aptinkama užrakinta lentelė, mysqldump nepavyks ir bus išmesta klaida. Tačiau gzip sėkmingai suspaus gautą dalinį išvesties rezultatą ir baigs darbą su būsenos kodu 0 (sėkmė).

Jūsų stebėjimo sistema, tikrinanti „cron“ užduoties išėjimo kodą, praneš apie sėkmingą atsarginę kopiją. Diske turėsite galiojantį .gz failą, tačiau jo viduje bus sugadintas, nenaudingas SQL failas. Tai sužinosite tik tada, kai bandysite atlikti kritinį atkūrimą.

Švelninimo priemonės (ir jų ribos)

Inžinieriai dažnai bando tai ištaisyti įjungdami griežtą klaidų apdorojimą „Bash“:

set -e
set -o pipefail

Nors set -o pipefail užtikrina, kad scenarijus nutrūktų, jei nepavyksta bet kuri konvejerio komanda, vis tiek reikia sukurti patikimus įspėjimo, registravimo ir pakartotinio bandymo mechanizmus. Kai dėl laikino tinklo gedimo 2:00 val. nakties įvyksta klaida, savadarbis scenarijus tiesiog nutrūksta. Verslo platformos tokias laikinas klaidas sprendžia naudodamos išmanius, eksponentinius pakartotinius bandymus.

2 pavojus: duomenų vientisumas ir užrakinimo košmarai

Savadarbiai scenarijai labai priklauso nuo loginių atsarginių kopijų (mysqldump, pg_dump). Loginės atsarginės kopijos ištraukia duomenis vykdydamos SELECT užklausas visose lentelėse. Labai transakcinėje gamybinėje duomenų bazėje duomenys nuolat keičiasi. Jei scenarijus 100 GB duomenų bazės kopijavimui užtrunka 45 minutes, duomenys kopijos pradžioje bus 45 minutėmis senesni nei duomenys pabaigoje, taip pažeidžiant ACID reikalavimus.

MySQL transakcijų vientisumas

Norint pasiekti vientisą „MySQL“ momentinę kopiją naudojant „InnoDB“, būtina nurodyti specifinius parametrus:

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

Parametras --single-transaction nustato izoliacijos lygį į REPEATABLE READ ir pradeda transakciją prieš kopijavimą. Tačiau, jei jūsų duomenų bazėje vis dar yra senų „MyISAM“ lentelių, šis parametras neapsaugos nuo jų užrakinimo, o tai gali sustabdyti gamybinį skaitymo/rašymo srautą kopijavimo metu. Be to, bet kokios ALTER TABLE, DROP TABLE ar RENAME TABLE komandos, kurias kūrėjai įvykdys kopijavimo metu, sugadins REPEATABLE READ momentinę kopiją, todėl kopijavimas nepavyks.

PostgreSQL ir WAL archyvavimas

„PostgreSQL“ atveju pg_dump suteikia vientisas logines atsargines kopijas, tačiau vien loginės kopijos negali užtikrinti atkūrimo iki tam tikro laiko momento (PITR). Jei jūsų duomenų bazė sugenda 16:00 val., o paskutinis „cron“ scenarijus veikė vidurnaktį, prarasite 16 valandų duomenų.

PITR pasiekimui reikalingas nuolatinis „Write-Ahead Logs“ (WAL) archyvavimas. Parašyti savadarbį scenarijų, kuris saugiai tvarkytų archive_command, yra itin sudėtinga.

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

Jei paskirties saugykla (/mnt/wal_archive/) užsipildo arba tampa nepasiekiama, archive_command nepavyks. Tada „PostgreSQL“ kaups WAL failus lokaliai, kol užsipildys pagrindinis diskas, o tai sukels visišką duomenų bazės veiklos sutrikimą. Savadarbiai scenarijai retai turi telemetriją, reikalingą WAL kaupimosi stebėjimui ir administratorių įspėjimui prieš įvykstant gedimui.

3 pavojus: saugojimo laikotarpio ruletė

Pažvelkite atgal į saugojimo komandą mūsų pradiniame scenarijuje:

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

Tai katastrofiško duomenų praradimo scenarijus. Įsivaizduokite situaciją, kai konfigūracijos pakeitimas sugadina mysqldump autentifikavimą. Scenarijus nebegali sukurti naujų atsarginių kopijų, tačiau find komanda ir toliau veikia kiekvieną naktį, sąžiningai trindama senesnius nei 30 dienų failus.

Po 30 dienų tylių atsarginių kopijų kūrimo nesėkmių find komanda ištrins jūsų paskutinę likusią gerą atsarginę kopiją. Jūs liksite be jokių atsarginių kopijų.

Verslo klasės atsarginių kopijų programinė įranga, tokia kaip „CloudSave“, naudoja būsenos saugojimo politikas. Ji supranta skirtumą tarp „ištrinti senesnes nei 30 dienų kopijas“ ir „užtikrinti, kad prieš šalinant senus duomenis egzistuoja bent 30 sėkmingų atkūrimo taškų“.

4 pavojus: saugumas, šifravimas ir atitikties spragos

Išpirkos reikalaujančių virusų ir griežtų atitikties sistemų (BDAR, HIPAA, SOC 2) eroje atsarginės kopijos yra pagrindinis taikinys. Savadarbiai scenarijai dažnai pažeidžia geriausią saugumo praktiką:

  1. Įrašyti kredencialai: Duomenų bazės slaptažodžių laikymas paprastu tekstu scenarijuose ar „cron“ apibrėžimuose yra didžiulė saugumo rizika. Nors tokie įrankiai kaip „MySQL“ mysql_config_editor ar „PostgreSQL“ .pgpass failas tai sušvelnina, jie vis tiek reikalauja valdyti vietinius raktų failus serveryje.
  2. Šifravimo ramybės būsenoje trūkumas: Neapdoroto SQL išmetimas į diską palieka jautrius PII/PHI duomenis atvirus.
  3. Sudėtingi šifravimo konvejeriai: Bandymai šifruoti atsargines kopijas skrydžio metu naudojant GPG sukelia didelę procesoriaus apkrovą ir raktų valdymo sudėtingumą.
# Savadarbis šifruotų atsarginių kopijų konvejeris
pg_dump mydb | gzip | gpg --symmetric --cipher-algo AES256 --passphrase-file /etc/keys/backup.key > backup.sql.gz.gpg

Jei serveris yra kompromituotas, užpuolikas gauna prieigą ir prie šifruotos atsarginės kopijos, ir prie /etc/keys/backup.key failo, todėl šifravimas tampa bevertis. Be to, jei GPG raktą sugeneravęs DBA palieka įmonę ir raktas prarandamas, atsarginės kopijos tampa neatkuriamos.

5 pavojus: RTO realybės patikrinimas (atkurti sunkiau nei kopijuoti)

Galutinis atsarginės kopijos patikrinimas yra atkūrimas. Savadarbių scenarijų sukurtas logines atsargines kopijas atkurti yra itin lėta. 500 GB SQL kopijos sukūrimas gali užtrukti 15 minučių, tačiau jos atkūrimas reikalauja, kad duomenų bazės variklis išanalizuotų SQL, perstatytų indeksus ir perskaičiuotų apribojimus. Tai gali užtrukti valandas ar net dienas, sunaikinant jūsų RTO.

Didelėms gamybinėms duomenų bazėms fizinės atsarginės kopijos (faktinių duomenų failų kopijavimas) yra privalomos. Nors egzistuoja tokie įrankiai kaip „Percona XtraBackup“ ar pg_basebackup, jų įtraukimas į savadarbius „Bash“ scenarijus yra labai sudėtingas. Turite valdyti LVM momentines kopijas, tvarkyti failų sistemos užšaldymą ir užtikrinti, kad atsarginė kopija būtų perkelta už serverio ribų neapkraunant tinklo sąsajos.

LVM momentinės kopijos spąstai

Daugelis inžinierių bando atlikti „nulinės prastovos“ fizines atsargines kopijas naudodami LVM momentines kopijas:

# Sukurti momentinę kopiją
lvcreate --size 20G --snapshot --name db_snap /dev/vg0/db_vol

# Prijungti ir nukopijuoti
mount /dev/vg0/db_snap /mnt/snap
tar -czf /backups/db_physical.tar.gz /mnt/snap/mysql

Jei duomenų bazėje staiga padidėja rašymo I/O, 20 GB LVM momentinė kopija gali akimirksniu užsipildyti. Kai LVM momentinė kopija užsipildo, ji tampa negaliojančia ir atsarginės kopijos kūrimas nepavyksta. Dar blogiau, intensyviai naudojamos LVM momentinės kopijos gali smarkiai pabloginti pagrindinio duomenų bazės tomo I/O našumą, sukeldamos programos vėlavimo šuolius.

Perėjimas prie verslo klasės apsaugos

Perėjimas nuo savadarbių scenarijų prie verslo platformos yra kritinis brandos etapas bet kuriai infrastruktūros komandai. Tikslas yra pereiti nuo „tikėjimosi, kad scenarijus suveikė“ prie kriptografinio atkūrimo galimybės įrodymo.

Tokios platformos kaip „CloudSave“ yra sukurtos specialiai tam, kad pašalintų savadarbių scenarijų akląsias zonas. Diegdama programoms pritaikytus agentus, „CloudSave“ tiesiogiai sąveikauja su duomenų bazių API („MySQL“, „PostgreSQL“, „MS SQL“, „Oracle“), kad suderintų vientisas fizines ir logines atsargines kopijas be lentelių užrakinimo ar našumo mažinimo.

Pagrindiniai atsisakymo nuo scenarijų privalumai:

  1. Automatizuotas patikrinimas: Šiuolaikinės platformos ne tik kuria atsargines kopijas; jos jas tikrina. „CloudSave“ gali automatiškai paleisti laikiną duomenų bazės egzempliorių, atkurti atsarginę kopiją, atlikti vientisumo patikrinimus (pvz., DBCC CHECKDB) ir ją išjungti, pateikdama patvirtintą ataskaitą, kad atsarginė kopija yra tikrai tinkama naudoti.
  2. Nekintanti saugykla: Kovai su išpirkos reikalaujančiais virusais atsarginės kopijos turi būti nekintančios. Savadarbiai scenarijai negali lengvai rašyti į WORM (Write Once, Read Many) saugyklas. Verslo sprendimai natūraliai integruojasi su „S3 Object Lock“ ir nekintančia debesų saugykla, užtikrindami, kad net jei serveris būtų visiškai kompromituotas, atsarginių kopijų užpuolikas negalėtų ištrinti ar užšifruoti.
  3. Supaprastintas PITR: Užuot rankiniu būdu sujungus bazinę atsarginę kopiją ir šimtus WAL failų naudojant sudėtingus recovery.conf ar postgresql.auto.conf parametrus, platformos pateikia vizualią laiko juostą. Jūs tiesiog pasirenkate tikslią minutę, iki kurios norite atkurti, o programinė įranga automatiškai atlieka žurnalų atkūrimą.
  4. Deduplikacija ir suspaudimas: Savadarbiai scenarijai remiasi gzip, kuris suspaudžia kiekvieną failą atskirai. Verslo atsarginių kopijų programinė įranga naudoja pasaulinę blokų lygio deduplikaciją, drastiškai sumažindama saugojimo išlaidas ir tinklo pralaidumą perkeliant atsargines kopijas už serverio ribų.

Išvada

Parašyti pasirinktinį „Bash“ scenarijų duomenų bazės atsarginei kopijai sukurti yra lengva. Parašyti scenarijų, kuris tvarkytų tylius konvejerio gedimus, garantuotų ACID vientisumą, saugiai valdytų kriptografinius raktus, užkirstų kelią duomenų praradimui dėl saugojimo politikos ir garantuotų griežtus RTO/RPO SLA, yra beveik neįmanoma.

Gamybinėse aplinkose duomenų bazė yra kritiškiausias verslo turtas. Jos apsaugą laikyti šalutiniu projektu, palaikomu kelių šimtų eilučių „shell“ scenarijumi, yra rizika, kurios negali sau leisti joks verslas. Audituodamos dabartines atsarginių kopijų strategijas, suprasdamos loginių kopijų apribojimus ir migruodamos į patikimas, automatizuotas platformas, tokias kaip „CloudSave“, „DevOps“ ir DBA komandos gali pašalinti „autobusų faktorių“ (riziką, kai viskas priklauso nuo vieno žmogaus) ir užtikrinti, kad jų duomenys būtų tikrai atsparūs.

Kategorijos