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.

Datu-baseen administratzaile (DBA) eta sistema-ingeniari guztiek, beren karreraren uneren batean, datu-base bat babeskopiatzeko shell script pertsonalizatu bat idatzi dute. Ia igarotze-erritu bat da. Proiektu baten hasierako faseetan, mysqldump edo pg_dump exekutatzen duen eta gzip-era bideratzen duen cron lan sinple bat irtenbide dotore, arin eta errentagarria dirudi.

Hala ere, azpiegitura eskalatzen denean, datuen bolumenak hazten direnean eta zerbitzu-mailako akordioak (SLA) zorrotzagoak bihurtzen direnean, 10 lerroko Bash script hori isil-isilik denbora-bonba bihurtzen da. Ekoizpen-inguruneek erabilgarritasun handia, Berreskuratze Puntuaren Helburu (RPO) zorrotzak eta Berreskuratze Denboraren Helburu (RTO) azkarrak eskatzen dituzte. Ingurune horietan DIY (zeure kabuz egindako) babeskopia-scriptetan konfiantza izateak arrisku larriak dakartza datuen koherentziari, hutsegite isilei, segurtasun-ahultasunei eta kudeaezinak diren berreskuratze-prozesuei dagokienez.

Artikulu honetan, DIY datu-baseen babeskopia-scripten akats arkitektonikoak eta ezkutuko arriskuak aztertuko ditugu, babeskopia logikoen eta fisikoen arteko zulo teknikoak esploratuko ditugu, eta CloudSave bezalako enpresa-mailako irtenbideetara nola igaro eztabaidatuko dugu, zure datu kritikoak babesteko.

Sinpletasunaren ilusioa: DIY script klasikoaren disekzioa

Arriskua ulertzeko, lehenik eta behin DIY babeskopia-script tipiko baten anatomia aztertu behar dugu. MySQL datu-base baterako ikuspegi estandar batek honelako itxura izaten du askotan:

#!/bin/bash
# MySQL babeskopia-script sinplea
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

# 30 egun baino zaharragoak diren babeskopiak ezabatu
find $BACKUP_DIR -type f -name "*.sql.gz" -mtime +30 -exec rm {} ;

Lehen begiratuan, script honek helburua betetzen du: datuak atera, konprimitu eta atxikipena kudeatzen du. Baina azalaren azpian, ekoizpen-ingurune batean datuak galtzea ekarriko duten akats larriz beteta dago.

1. arriskua: Hutsegite isilak eta kanalizazioaren tranpa

DIY scripten arrisku maltzurrenetako bat hutsegite isila da. Goiko scriptean, mysqldump komandoa zuzenean gzip-era bideratzen da (|).

Bash-en, kanalizazio baten irteera-egoera kanalizazioko azken komandoaren irteera-egoera da. Datu-basearen zerbitzariak memoria agortzen badu, konexioa galtzen badu edo dump-aren erdian blokeatutako taula batekin topo egiten badu, mysqldump-ek huts egingo du eta errore bat emango du. Hala ere, gzip-ek jasotako irteera partziala behar bezala konprimituko du eta 0 (arrakasta) egoera-kodearekin amaituko du.

Zure monitorizazio-sistemak, cron lanaren irteera-kodea egiaztatzean, babeskopia arrakastatsua izan dela jakinaraziko du. Diskoan .gz fitxategi baliodun bat izango duzu, baina barruan SQL fitxategi moztu eta erabilgaitz bat egongo da. Hori ez duzu jakingo berreskuratze kritiko bat egiten saiatu arte.

Arintzea (eta bere mugak)

Ingeniariek sarritan Bash-en errore-kudeaketa zorrotza gaituz saiatzen dira hau konpontzen:

set -e
set -o pipefail

set -o pipefail-ek kanalizazioko komando batek huts egiten badu script-ak huts egiten duela ziurtatzen duen arren, oraindik ere alerta, erregistro eta berriro saiatzeko mekanismo sendoak eraiki behar dituzu scriptaren inguruan. Sareko errore iragankor batek goizaldeko 2:00etan huts egitea eragiten duenean, DIY script bat besterik gabe hil egiten da. Enpresa-plataformek errore iragankor horiek kudeatzen dituzte berriro saiatzeko logika adimendun eta esponentzialekin.

2. arriskua: Datuen koherentzia eta blokeo-amesgaiztoak

DIY scriptak babeskopia logikoetan oinarritzen dira (mysqldump, pg_dump). Babeskopia logikoek datuak ateratzen dituzte taula guztietan SELECT aginduak exekutatuz. Transakzio handiko ekoizpen-datu-base batean, datuak etengabe aldatzen ari dira. Script batek 100 GB-ko datu-base bat dump egiteko 45 minutu behar baditu, dump-aren hasierako datuak amaierakoak baino 45 minutu zaharragoak izango dira, ACID betetzea urratuz.

MySQL transakzio-koherentzia

InnoDB erabiliz MySQL-n snapshot koherentea lortzeko, bandera zehatzak erabili behar dituzu:

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

--single-transaction banderak isolamendu-maila REPEATABLE READ-era ezartzen du eta transakzio bat hasten du dump-a egin aurretik. Hala ere, zure datu-baseak oraindik MyISAM taula zaharrak baditu, bandera honek ez ditu blokeatzea eragotziko, ekoizpeneko irakurketa/idazketa trafikoa geldituz babeskopiak irauten duen bitartean. Gainera, garatzaileek babeskopian zehar exekutatutako edozein ALTER TABLE, DROP TABLE edo RENAME TABLE aginduk REPEATABLE READ snapshot-a hautsiko du, dump-ak huts egitea eraginez.

PostgreSQL eta WAL artxibatzea

PostgreSQL-rako, pg_dump-ek babeskopia logiko koherenteak eskaintzen ditu, baina babeskopia logikoek bakarrik ezin dute Puntu-denborako Berreskurapena (PITR) eskaini. Zure datu-baseak arratsaldeko 4:00etan huts egiten badu eta zure azken cron script-a gauerdian exekutatu bazen, 16 orduko datuak galtzen dituzu.

PITR lortzeko, Write-Ahead Logs (WAL) etengabe artxibatzea beharrezkoa da. archive_command segurtasunez kudeatzeko DIY script bat idaztea oso zaila da.

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

Helburuko biltegia (/mnt/wal_archive/) betetzen bada edo erabilgarri ez badago, archive_command-ak huts egingo du. PostgreSQL-k WAL fitxategiak lokalean pilatuko ditu disko nagusia bete arte, datu-basearen erabateko etenaldia eraginez. DIY scriptek oso gutxitan izaten dute WAL pilaketa monitorizatzeko eta administratzaileei etenaldia gertatu aurretik abisatzeko beharrezkoa den telemetria.

3. arriskua: Atxikipenaren erruleta

Begiratu berriro gure hasierako script-eko atxikipen-komandoari:

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

Hau gertatzear dagoen datu-galera katastrofikoa da. Imajinatu konfigurazio-aldaketa batek mysqldump autentifikazioa hausten duen eszenatoki bat. Script-ak huts egiten du babeskopia berriak sortzeko, baina find komandoak gauero exekutatzen jarraitzen du, 30 egun baino zaharragoak diren fitxategiak ezabatuz.

Babeskopia-hutsegite isilen 30 egun igaro ondoren, find komandoak geratzen zitzaizun azken babeskopia ona ezabatuko du. Orain babeskopiarik gabe geratu zara.

CloudSave bezalako enpresa-mailako babeskopia-softwareak atxikipen-politika estatudunak erabiltzen ditu. “30 egun baino zaharragoak diren babeskopiak ezabatu” eta “datu zaharrak kendu aurretik gutxienez 30 berreskuratze-puntu arrakastatsu daudela ziurtatu” arteko aldea ulertzen du.

4. arriskua: Segurtasuna, enkriptatzea eta betetze-arauetako puntu itsuak

Ransomwarearen eta betetze-arau zorrotzen (GDPR, HIPAA, SOC 2) garaian, babeskopiak helburu nagusi dira. DIY scriptek maiz urratzen dituzte segurtasun-praktika onenak:

  1. Kredentzial gogortuak: Datu-basearen pasahitzak testu arrunteko scriptetan edo cron definizioetan gordetzea segurtasun-arrisku handia da. MySQL-ren mysql_config_editor edo PostgreSQL-ren .pgpass fitxategia bezalako tresnek hau arintzen duten arren, zerbitzarian tokiko gako-fitxategiak kudeatzea eskatzen dute oraindik.
  2. Enkriptatze falta: SQL gordina diskora botatzeak PII/PHI sentikorra agerian uzten du.
  3. Enkriptatze-kanalizazio konplexuak: GPG erabiliz babeskopiak hegan enkriptatzen saiatzeak CPU-ren gainkarga larria eta gakoen kudeaketa konplexua dakar.
# DIY enkriptatutako babeskopia-kanalizazioa
pg_dump mydb | gzip | gpg --symmetric --cipher-algo AES256 --passphrase-file /etc/keys/backup.key > backup.sql.gz.gpg

Zerbitzaria arriskuan jartzen bada, erasotzaileak enkriptatutako babeskopiarako eta /etc/keys/backup.key fitxategirako sarbidea du, enkriptatzea alferrikakoa bihurtuz. Gainera, GPG gakoa sortu zuen DBAk enpresa uzten badu eta gakoa galtzen bada, babeskopiak ezin dira berreskuratu.

5. arriskua: RTO-ren errealitatearen egiaztapena (Berreskuratzea babeskopia egitea baino zailagoa da)

Babeskopia baten azken proba berreskuratzea da. DIY scriptek sortutako babeskopia logikoak oso motelak dira berreskuratzeko. 500 GB-ko SQL dump batek 15 minutu behar izan ditzake sortzeko, baina hura berreskuratzeko datu-basearen motorrak SQL-a analizatu, indizeak berreraiki eta murrizketak berriro kalkulatu behar ditu. Honek orduak edo egunak ere har ditzake, zure RTO suntsituz.

Ekoizpen-datu-base handietarako, babeskopia fisikoak (benetako datu-fitxategiak kopiatzea) derrigorrezkoak dira. Percona XtraBackup edo pg_basebackup bezalako tresnak existitzen diren arren, DIY Bash scriptetan biltzea oso konplexua da. LVM snapshot-ak kudeatu, fitxategi-sistemaren egonkortasuna maneiatu eta babeskopia kanpora transferitzen dela ziurtatu behar duzu sareko interfazea saturatu gabe.

LVM snapshot-aren tranpa

Ingeniari askok “zero etenaldi” babeskopia fisikoak egiten saiatzen dira LVM snapshot-ak erabiliz:

# Snapshot bat sortu
lvcreate --size 20G --snapshot --name db_snap /dev/vg0/db_vol

# Muntatu eta kopiatu
mount /dev/vg0/db_snap /mnt/snap
tar -czf /backups/db_physical.tar.gz /mnt/snap/mysql

Datu-baseak idazketa I/O-an bat-bateko gorakada bat jasaten badu, 20 GB-ko LVM snapshot-a berehala bete daiteke. LVM snapshot bat betetzen denean, baliogabe bihurtzen da eta babeskopiak huts egiten du. Okerrago, erabilera handiko LVM snapshot-ek datu-base nagusiaren bolumenaren I/O errendimendua larriki degradatu dezakete, aplikazioaren latentzia-pikoak eraginez.

Enpresa-mailako babesera igarotzea

DIY scriptetatik enpresa-plataforma batera igarotzea azpiegitura-talde ororentzat heldutasun-mugarri kritikoa da. Helburua “script-ak funtzionatu izana espero izatetik” berreskuragarritasunaren froga kriptografikoa izatera pasatzea da.

CloudSave bezalako plataformak bereziki diseinatuta daude DIY scripten puntu itsuak ezabatzeko. Aplikazioak ezagutzen dituzten agenteak zabalduz, CloudSave-k zuzenean datu-basearen APIekin (MySQL, PostgreSQL, MS SQL, Oracle) elkarreragiten du babeskopia fisiko eta logiko koherenteak antolatzeko, taulak blokeatu edo errendimendua degradatu gabe.

Scriptetatik aldentzearen abantaila nagusiak:

  1. Egiaztapen automatizatua: Plataforma modernoek ez dituzte babeskopiak bakarrik egiten; probatu egiten dituzte. CloudSave-k automatikoki abiarazi dezake datu-basearen instantzia tenporal bat, babeskopia berreskuratu, koherentzia-egiaztapenak egin (adibidez, DBCC CHECKDB) eta itxi, babeskopia benetan erabilgarria dela dioen txosten egiaztatua emanez.
  2. Biltegiratze aldaezina: Ransomwareari aurre egiteko, babeskopiak aldaezinak izan behar dira. DIY scriptek ezin dute erraz idatzi WORM (Write Once, Read Many) biltegiratzean. Enpresa-irtenbideek modu naturalean integratzen dute S3 Object Lock eta hodeiko biltegiratze aldaezinarekin, zerbitzari bat erabat arriskuan egon arren, babeskopiak erasotzaile batek ezabatu edo enkriptatu ezin dituela ziurtatuz.
  3. PITR sinplifikatua: Oinarrizko babeskopia bat eta ehunka WAL fitxategi eskuz elkartu beharrean recovery.conf edo postgresql.auto.conf parametro konplexuak erabiliz, plataformek denbora-lerro bisuala eskaintzen dute. Berreskuratu nahi duzun minutu zehatza hautatu besterik ez duzu, eta softwareak erregistroaren erreprodukzioa automatikoki kudeatzen du.
  4. Deduplikazioa eta konpresioa: DIY scriptek gzip-ean oinarritzen dira, fitxategi bakoitza banaka konprimitzen duena. Enpresa-mailako babeskopia-softwareak bloke-mailako deduplikazio globala erabiltzen du, biltegiratze-kostuak eta sareko banda-zabalera nabarmen murriztuz babeskopiak kanpora transferitzean.

Ondorioa

Datu-base bat babeskopiatzeko Bash script pertsonalizatu bat idaztea erraza da. Kanalizazio-hutsegite isilak kudeatzen dituen, ACID koherentzia bermatzen duen, gako kriptografikoak segurtasunez kudeatzen dituen, atxikipenean oinarritutako datu-galera eragozten duen eta RTO/RPO SLA zorrotzak bermatzen dituen script bat idaztea ia ezinezkoa da.

Ekoizpen-inguruneetan, datu-basea da negozioaren aktiborik kritikoena. Haren babesa ehunka shell script lerro batzuek mantentzen duten alboko proiektu gisa tratatzea enpresa batek onartu ezin duen arriskua da. Zure egungo babeskopia-estrategiak auditatuz, dump logikoen mugak ulertuz eta CloudSave bezalako plataforma automatizatu eta sendoetara migratuz, DevOps eta DBA taldeek script pertsonalizatuen “bus factor”-a ezabatu eta beren datuak benetan erresilienteak direla ziurtatu dezakete.

Kategoriak