Datu-baseen administrazioaren eta guneen fidagarritasunaren ingeniaritzaren mundu arriskutsuan, axioma ezagun bat dago: Schrödinger-en babeskopia. Babeskopia baten egoera ezezaguna da hura leheneratzen saiatu arte. Une hori iritsi arte, egoera kuantiko batean dago: aldi berean guztiz bideragarria eta guztiz hondatuta egon daiteke.
DevOps ingeniarientzat eta DBAentzat, gorabehera aktibo batean datu-baseen babeskopia kritiko bat hondatuta dagoela deskubritzea amesgaiztorik handiena da. Leheneratze-eragiketa errutina bat datu-galera katastrofiko bihurtzen du. Datuen osotasunaren “hiltzaile isil” honek sarritan oharkabean pasatzen da, babeskopia-lanek maiz Exit Code 0 arrakastatsua ematen dutelako, nahiz eta azpiko edukia konprometituta egon.
Gida integral honetan, babeskopien hondatzearen anatomia aztertuko dugu, datu-baseen araberako baliozkotze-teknikak esploratuko ditugu eta produkzio-inguruneetarako leheneratze-kanal automatizatu eta iragazgaitzak nola eraiki erakutsiko dugu.
Babeskopien hondatzearen anatomia
Hondatzea detektatzeko, lehenik eta behin nola gertatzen den ulertu behar duzu. Babeskopien hondatzea bi kategoriatan banatzen da: fisikoa (azpiegitura-mailakoa) eta logikoa (aplikazio-mailakoa).
Hondatze fisikoa
Hondatze fisikoa biltegiratze-euskarriko bitak aldatzen direnean gertatzen da. Hori iturburu-diskoko irakurketa-prozesuan, sareko garraioan edo helburuko biltegiratzean gerta daiteke.
* Bit Rot: Biltegiratze-euskarrien degradazio gradualak bitak isilean irauli ditzake.
* Garraio-erroreak: TCPk kontrol-batuketak (checksums) dituen arren, oso ahulak dira (16-bit). Errendimendu handiko inguruneek datuen hondatze isila jasan dezakete kable bidez, TCPk detektatzen ez duena.
* Biltegiratze-kontrolagailuen akatsak: RAID kontrolagailuen edo SAN ehunen hardware-akatsek datu zaborrak idatz ditzakete, sistemari arrakasta eman diotela jakinarazten dioten bitartean.
Hondatze logikoa
Hondatze logikoa arriskutsuagoa da, babeskopia-fitxategia bera guztiz osorik dagoelako, baina barruko datuak hondatuta daudelako.
* Garbage In, Garbage Out (GIGO): Zure datu-baseak aurkibide hondatua edo orrialde urratua badu, zure babeskopia-tresnak orrialde hondatu hori kopiatu dezake. Babeskopia-lana arrakastatsua da, baina leheneratzeak huts egingo du edo datu-base hondatua emango du.
* Transakzio osatugabeak: Datu-basearen I/O izoztu gabe (adibidez, MySQL-n FLUSH TABLES WITH READ LOCK erabili gabe) egindako fitxategi-sistemako argazkiek (snapshots) orrialde urratuak eta berreskuraezinak diren egoerak sortzen dituzte.
Proaktiboki detektatzea: Kontrol-batuketak eta Hash kriptografikoak
Hondatze fisikoaren aurkako lehen defentsa-lerroa baliozkotze kriptografikoa da. Fitxategien tamainetan edo aldaketa-datetan oinarritzea ez da nahikoa.
Datu-base mailako kontrol-batuketak gaitzea
Datu-base erlazionalen kudeaketa-sistema modernoek (RDBMS) orrialde-mailako kontrol-batuketak onartzen dituzte. Gaituta daudenean, datu-baseak kontrol-batuketa bat kalkulatzen du orrialde bakoitzerako diskora idatzi aurretik. Orrialdea irakurtzen denean (kontsulta edo babeskopia-prozesu baten bidez), kontrol-batuketa egiaztatzen da.
PostgreSQL-rako, datuen kontrol-batuketak gaitu ditzakezu klusterraren hasieratzean:
# PostgreSQL kluster berri bat hasieratu kontrol-batuketak gaituta
initdb --data-checksums -D /var/lib/postgresql/data
Oharra: Dagoeneko PostgreSQL kluster bat baduzu, pg_checksums erabilgarritasuna erabil dezakezu lineaz kanpo gaitzeko.
Microsoft SQL Server-erako, ziurtatu PAGE_VERIFY CHECKSUM gisa ezarrita dagoela (bertsio modernoetan lehenetsia, baina sistema zaharretan egiaztatzea merezi du):
ALTER DATABASE [ProductionDB] SET PAGE_VERIFY CHECKSUM;
GO
Babeskopiak atsedenaldian baliozkotzea
Babeskopia zure biltegiratze-helburura iristen denean, bere osotasuna kriptografikoki egiaztatu behar da. CloudSave bezalako enpresa-mailako babeskopia-plataformek automatikoki kalkulatzen eta egiaztatzen dituzte babeskopia-blokeen SHA-256 hash-ak garraioan eta atsedenaldian. Script pertsonalizatuak kudeatzen ari bazara, eskuz inplementatu behar duzu:
# Sortu SHA-256 hash babeskopia sortu ondoren
sha256sum prod_db_backup.tar.gz > prod_db_backup.tar.gz.sha256
# Egiaztatu hash-a biltegiratze-zerbitzarian
sha256sum -c prod_db_backup.tar.gz.sha256
Datu-baseen araberako baliozkotze-teknikak
Datu-base motor ezberdinek tresna natiboak eskaintzen dituzte babeskopien osotasuna egiaztatzeko.
PostgreSQL: pg_verifybackup
PostgreSQL 13-n aurkeztua, pg_verifybackup iraultzailea da pg_basebackup-ekin egindako babeskopia fisikoetarako. Babeskopian sortutako backup_manifest fitxategia irakurtzen du eta fitxategi guztiak bertan daudela eta haien kontrol-batuketak bat datozela egiaztatzen du.
# Exekutatu egiaztapena oinarrizko babeskopia fisikoaren direktorio batean
pg_verifybackup /mnt/backups/postgres/base_backup_20231025/
Datu-fitxategiren batean bit bat aldatu bada, pg_verifybackup-ek errore larria emango du, zure monitorizazio-sistemek DBA taldeari berehala abisatzeko aukera emanez.
Microsoft SQL Server: RESTORE VERIFYONLY
SQL Server-ek komando natibo bat eskaintzen du babeskopia-fitxategi baten osotasun fisikoa egiaztatzeko, hura leheneratu gabe. Babeskopiaren goiburuak egiaztatzen ditu eta orrialdeen kontrol-batuketak baliozkotzen ditu (babeskopian gaituta baziren).
RESTORE VERIFYONLY
FROM DISK = 'Z:BackupsProdDB_Full.bak'
WITH CHECKSUM;
Abisua: RESTORE VERIFYONLY-k babeskopia-fitxategia irakurgarria dela eta kontrol-batuketa fisikoak bat datozela soilik baieztatzen du. Ez du osotasun logikoa bermatzen. Osotasun logikoa bermatzeko, leheneratze osoa egin eta DBCC CHECKDB exekutatu behar duzu.
MySQL / InnoDB: Percona XtraBackup
MySQL inguruneetarako, babeskopia fisikoak Percona XtraBackup-ek kudeatzen ditu sarritan. Babeskopia-prozesua fitxategiak kopiatzean datza, baina babeskopia ez da koherentea transakzio-erregistroak (redo logs) aplikatu arte. --prepare faseak osotasun-egiaztapen integratu gisa funtzionatzen du.
# Babeskopia prestatzeak redo logs aplikatzen ditu.
# Babeskopia hondatuta badago, urrats honek huts egingo du.
xtrabackup --prepare --target-dir=/data/backups/mysql/
Urrezko estandarra: Leheneratze-probak automatizatzea
Kontrol-batuketak eta egiaztapen-komandoak beharrezkoak dira, baina ez dira nahikoak. Babeskopia bat bideragarria dela frogatzeko modu bakarra hura leheneratzea da. DevOps ingurune modernoetan, prozesu hau guztiz automatizatuta egon behar da.
Babeskopiak kode gisa tratatuz, zure datu-baseak leheneratzeko CI/CD kanal bat eraiki dezakezu. Kanal honek azpiegitura efimeroa hornitu, leheneratzea exekutatu, baliozkotze-kontsultak egin eta ingurunea desegin behar du.
Leheneratze-kanal automatizatua eraikitzea
Jarraian, egunero cron lan batek edo CI exekutore batek (GitLab CI edo GitHub Actions bezalakoak) PostgreSQL dump logiko bat baliozkotzeko abiarazi dezakeen Bash script baten adibidea dago.
#!/bin/bash
set -e
BACKUP_FILE="/mnt/storage/prod_db_latest.dump"
DB_NAME="prod_db"
CONTAINER_NAME="pg_restore_test"
echo "[INFO] Leheneratze-proba automatizatua hasten..."
# 1. Abiarazi PostgreSQL edukiontzi efimero bat
docker run --name $CONTAINER_NAME
-e POSTGRES_PASSWORD=testpass
-d postgres:15
# Itxaron PostgreSQL prest egon arte
echo "[INFO] Datu-basea hasieratu arte itxaroten..."
until docker exec $CONTAINER_NAME pg_isready -U postgres; do
sleep 2
done
# 2. Sortu helburuko datu-basea
docker exec $CONTAINER_NAME psql -U postgres -c "CREATE DATABASE $DB_NAME;"
# 3. Exekutatu leheneratzea
echo "[INFO] Babeskopia leheneratzen..."
docker cp $BACKUP_FILE $CONTAINER_NAME:/tmp/backup.dump
docker exec $CONTAINER_NAME pg_restore -U postgres -d $DB_NAME -1 /tmp/backup.dump
# 4. Exekutatu baliozkotze-kontsulta logikoak
echo "[INFO] Baliozkotze-kontsultak exekutatzen..."
# Egiaztatu erabiltzaileen taulak 10.000 erregistro baino gehiago dituen
USER_COUNT=$(docker exec $CONTAINER_NAME psql -U postgres -d $DB_NAME -t -c "SELECT COUNT(*) FROM users;")
if [ "$USER_COUNT" -lt 10000 ]; then
echo "[ERROR] Baliozkotze logikoak huts egin du. 10000 erabiltzaile baino gehiago espero ziren, $USER_COUNT aurkitu dira"
# Abiarazi PagerDuty / Slack alerta hemen
exit 1
else
echo "[SUCCESS] Baliozkotze logikoa arrakastatsua. Erabiltzaile kopurua: $USER_COUNT"
fi
# 5. Desegin ingurune efimeroa
echo "[INFO] Garbitzen..."
docker rm -f $CONTAINER_NAME
echo "[INFO] Leheneratze-proba automatizatua arrakastaz amaitu da."
Zer baliozkotu behar duzu?
Leheneratze-probak automatizatzean, ez egiaztatu datu-basea abiarazten den soilik. Exekutatu aplikazioaren araberako baliozkotze-kontsultak:
1. Erregistro kopuruak: Ziurtatu oinarrizko taulek espero diren erregistro kopuruak dituztela (adibidez, users taula ez litzateke hutsik egon behar).
2. Datu berriak: Kontsultatu azken 24 orduetan sortutako erregistroak, babeskopia zaharkituta ez dagoela ziurtatzeko.
3. Erreferentzia-osotasuna: Exekutatu script-ak umezurtz geratu diren kanpoko gakoak (foreign keys) bilatzeko, horiek hondatze logikoa adierazten baitute.
Babeskopien anomalien monitorizazioa eta alertak
Hondamendia gertatu aurretik hondatzea detektatzeko, behagarritasun sendoa behar da. Arrakasta/huts egoera bitarrez haratago, zure babeskopia-lanen metadatuak monitorizatu behar dituzu anomaliak detektatzeko.
Monitorizazio heuristikoa
Integratu zure babeskopia-metadatuak Prometheus-en eta bistaratu Grafana-rekin. Konfiguratu alertak ondorengo heuristiketarako:
* Tamainaren bat-bateko jaitsierak: Zure eguneroko babeskopia 500GB-koa bada eta gaurkoa 50MB-koa, lana arrakastaz amaitu daiteke (Exit Code 0), baina litekeena da eskema huts bat babeskopiatu izana.
* Iraupenaren anomaliak: Normalean 2 ordu irauten duen babeskopia bat 5 minututan amaitzen bada, zerbait saltatu da. Alderantziz, 10 ordu irauten badu, diskoaren I/O degradazioa izan dezakezu, hondatzea ekar dezakeena.
* WAL/Archive Log metaketa: Zure datu-basea Write-Ahead Logs (WAL) sortzen ari bada baina babeskopia-sistema ez bada nahikoa azkar artxibatzen, zure Point-in-Time Recovery (PITR) katean hutsune bat izateko arriskua duzu.
3-2-1 araua inplementatzea osotasun-egiaztapenekin
Industriako 3-2-1 babeskopia-araua (datuen 3 kopia, 2 euskarri ezberdin, 1 kanpoan) kopia guztiak egiaztatuta badaude soilik da eraginkorra.
Hemen CloudSave bezalako enpresa-soluzio bat erabiltzeak eragiketa-karga nabarmen murrizten du. Datu-base nodo bakoitzerako bash script konplexuak idatzi eta mantendu beharrean, CloudSave-k zure azpiegiturarekin zuzenean integratzen da 3-2-1 bizi-zikloa automatizatzeko. Biltegiratze aldaezina eskaintzen du (ransomwarearen aurka babestuz) eta leheneratze-egiaztapen automatizatuen egutegiak ditu. CloudSave-k automatikoki abiarazi ditzake sandbox ingurune isolatuak, babeskopia muntatu, zure SQL baliozkotze-script pertsonalizatuak exekutatu eta osasun-egoera zure panel zentralera itzuli.
Ondorioa
Hondatutako datu-baseen babeskopiak negozioak suntsitu ditzakeen hiltzaile isila dira. Babeskopia-script baten Exit Code 0-an soilik konfiantza izatea apustu arriskutsua da.
Zure produkzio-inguruneak benetan babesteko, defentsa sakoneko estrategia bat hartu behar duzu:
1. Gaitu orrialde-mailako kontrol-batuketak zure datu-base motorrean.
2. Erabili egiaztapen-tresna natiboak (pg_verifybackup, RESTORE VERIFYONLY) babeskopia sortu eta berehala.
3. Monitorizatu babeskopien metadatuak (tamaina, iraupena) anomalia heuristikoetarako.
4. Inplementatu leheneratze-proba efimero automatizatuak zure eguneroko eragiketa-kanalaren zati gisa.
Babeskopia-mentalitate pasibo batetik “leheneratze-baliozkotze jarraituaren” eredu aktibo batera pasatuz, hondamendia gertatzen denean zure datuak prest, fidagarriak eta guztiz berreskuragarriak direla ziurtatzen duzu.
