En l’alt risc del món de l’administració de bases de dades i l’enginyeria de fiabilitat del lloc (SRE), hi ha un axioma ben conegut: la còpia de seguretat de Schrödinger. L’estat de qualsevol còpia de seguretat és desconegut fins que intentes restaurar-la. Fins a aquest moment, existeix en un estat quàntic de ser alhora perfectament viable i completament corrompuda.
Per als enginyers de DevOps i els administradors de bases de dades (DBA), descobrir que una còpia de seguretat crítica està corrompuda durant un incident actiu és el malson definitiu. Transforma una operació de recuperació rutinària en un esdeveniment catastròfic de pèrdua de dades. Aquest «assassí silenciós» de la integritat de les dades sovint passa desapercebut perquè les tasques de còpia de seguretat sovint informen d’un Exit Code 0 (codi de sortida 0) correcte, fins i tot quan la càrrega útil subjacent està compromesa.
En aquesta guia exhaustiva, disseccionarem l’anatomia de la corrupció de les còpies de seguretat, explorarem tècniques de validació específiques per a bases de dades i demostrarem com construir pipelines de restauració automatitzats i a prova de bombes per a entorns de producció.
L’anatomia de la corrupció de les còpies de seguretat
Per detectar la corrupció, primer heu d’entendre com es produeix. La corrupció de les còpies de seguretat generalment es divideix en dues categories: física (a nivell d’infraestructura) i lògica (a nivell d’aplicació).
Corrupció física
La corrupció física es produeix quan s’alteren els bits reals del suport d’emmagatzematge. Això pot passar durant el procés de lectura des del disc d’origen, durant el trànsit per la xarxa o en repòs a l’emmagatzematge de destinació.
* Bit Rot (degradació de bits): La degradació gradual dels suports d’emmagatzematge pot invertir bits silenciosament.
* Errors de trànsit: Tot i que el TCP té sumes de verificació (checksums), són notòriament febles (16 bits). Els entorns d’alt rendiment poden experimentar corrupció de dades silenciosa a través del cable que el TCP no detecta.
* Errors del controlador d’emmagatzematge: Els errors de maquinari en els controladors RAID o les estructures SAN poden escriure dades brossa mentre informen d’èxit al sistema operatiu.
Corrupció lògica
La corrupció lògica és, sens dubte, més perillosa perquè el fitxer de còpia de seguretat en si està perfectament intacte, però les dades que conté estan trencades.
* Garbage In, Garbage Out (GIGO): Si la vostra base de dades en viu té un índex corromput o una pàgina trencada, la vostra eina de còpia de seguretat podria copiar fidelment aquesta pàgina corrompuda. La tasca de còpia de seguretat té èxit, però la restauració fallarà o produirà una base de dades trencada.
* Transaccions incompletes: Les instantànies (snapshots) a nivell de sistema de fitxers preses sense congelar correctament l’E/S de la base de dades (p. ex., no utilitzar FLUSH TABLES WITH READ LOCK a MySQL) donen lloc a pàgines trencades i estats irrecuperables.
Detecció proactiva: sumes de verificació i hashing criptogràfic
La primera línia de defensa contra la corrupció física és la validació criptogràfica. Confiar en la mida dels fitxers o en les dates de modificació és insuficient.
Habilitació de sumes de verificació a nivell de base de dades
Els sistemes de gestió de bases de dades relacionals (RDBMS) moderns admeten sumes de verificació a nivell de pàgina. Quan s’habilita, la base de dades calcula una suma de verificació per a cada pàgina abans d’escriure-la al disc. Quan es llegeix la pàgina (ja sigui per una consulta o per un procés de còpia de seguretat), es verifica la suma de verificació.
Per a PostgreSQL, podeu habilitar les sumes de verificació de dades durant la inicialització del clúster:
# Inicialitzar un nou clúster de PostgreSQL amb sumes de verificació habilitades
initdb --data-checksums -D /var/lib/postgresql/data
Nota: Si teniu un clúster de PostgreSQL existent, podeu utilitzar la utilitat pg_checksums per habilitar-les fora de línia.
Per a Microsoft SQL Server, assegureu-vos que PAGE_VERIFY estigui configurat com a CHECKSUM (el valor predeterminat en versions modernes, però val la pena verificar-ho en sistemes antics):
ALTER DATABASE [ProductionDB] SET PAGE_VERIFY CHECKSUM;
GO
Validació de còpies de seguretat en repòs
Un cop la còpia de seguretat arriba al vostre destí d’emmagatzematge, la seva integritat s’ha de verificar criptogràficament. Les plataformes de còpia de seguretat empresarials com CloudSave calculen i verifiquen automàticament els hashes SHA-256 dels blocs de còpia de seguretat durant el trànsit i en repòs. Si gestioneu scripts personalitzats, heu d’implementar-ho manualment:
# Generar hash SHA-256 després de la creació de la còpia de seguretat
sha256sum prod_db_backup.tar.gz > prod_db_backup.tar.gz.sha256
# Verificar el hash al servidor d'emmagatzematge
sha256sum -c prod_db_backup.tar.gz.sha256
Tècniques de validació específiques per a bases de dades
Diferents motors de bases de dades ofereixen eines natives per verificar la integritat dels seus artefactes de còpia de seguretat.
PostgreSQL: pg_verifybackup
Introduït a PostgreSQL 13, pg_verifybackup és un canvi de joc per a les còpies de seguretat físiques preses amb pg_basebackup. Llegeix el fitxer backup_manifest generat durant la còpia de seguretat i verifica que tots els fitxers estiguin presents i que les seves sumes de verificació coincideixin.
# Executar la verificació contra un directori de còpia de seguretat física base
pg_verifybackup /mnt/backups/postgres/base_backup_20231025/
Si s’ha invertit un sol bit en qualsevol dels fitxers de dades, pg_verifybackup llançarà un error fatal, permetent que els vostres sistemes de monitorització alertin l’equip de DBA immediatament.
Microsoft SQL Server: RESTORE VERIFYONLY
SQL Server proporciona una ordre nativa per verificar la integritat física d’un fitxer de còpia de seguretat sense restaurar-lo realment. Comprova les capçaleres de la còpia de seguretat i valida les sumes de verificació de pàgina (si estaven habilitades durant la còpia de seguretat).
RESTORE VERIFYONLY
FROM DISK = 'Z:BackupsProdDB_Full.bak'
WITH CHECKSUM;
Avís: RESTORE VERIFYONLY només confirma que el fitxer de còpia de seguretat és llegible i que les sumes de verificació físiques coincideixen. No garanteix la integritat lògica. Per garantir la integritat lògica, heu de realitzar una restauració completa i executar DBCC CHECKDB.
MySQL / InnoDB: Percona XtraBackup
Per als entorns MySQL, les còpies de seguretat físiques sovint són gestionades per Percona XtraBackup. El procés de còpia de seguretat consisteix a copiar fitxers, però la còpia de seguretat no és consistent fins que s’apliquen els registres de transaccions (redo logs). La fase --prepare actua com una comprovació d’integritat integrada.
# La preparació de la còpia de seguretat aplica els redo logs.
# Si la còpia de seguretat està corrompuda, aquest pas fallarà.
xtrabackup --prepare --target-dir=/data/backups/mysql/
L’estàndard d’or: proves de restauració automatitzades
Les sumes de verificació i les ordres de verificació són necessàries, però no són suficients. L’única manera de demostrar definitivament que una còpia de seguretat és viable és restaurar-la. En els entorns DevOps moderns, aquest procés ha d’estar totalment automatitzat.
Tractant les còpies de seguretat com a codi, podeu construir un pipeline de CI/CD per a les restauracions de la vostra base de dades. Aquest pipeline hauria d’aprovisionar infraestructura efímera, executar la restauració, executar consultes de validació i eliminar l’entorn.
Construcció d’un pipeline de restauració automatitzat
A continuació es mostra un exemple d’un script de Bash que podria ser activat diàriament per una tasca cron o un runner de CI (com GitLab CI o GitHub Actions) per validar un dump lògic de PostgreSQL.
#!/bin/bash
set -e
BACKUP_FILE="/mnt/storage/prod_db_latest.dump"
DB_NAME="prod_db"
CONTAINER_NAME="pg_restore_test"
echo "[INFO] Iniciant prova de restauració automatitzada..."
# 1. Iniciar un contenidor efímer de PostgreSQL
docker run --name $CONTAINER_NAME
-e POSTGRES_PASSWORD=testpass
-d postgres:15
# Esperar que PostgreSQL estigui llest
echo "[INFO] Esperant que la base de dades s'inicialitzi..."
until docker exec $CONTAINER_NAME pg_isready -U postgres; do
sleep 2
done
# 2. Crear la base de dades de destinació
docker exec $CONTAINER_NAME psql -U postgres -c "CREATE DATABASE $DB_NAME;"
# 3. Executar la restauració
echo "[INFO] Restaurant còpia de seguretat..."
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. Executar consultes de validació lògica
echo "[INFO] Executant consultes de validació..."
# Comprovar si la taula d'usuaris té més de 10.000 registres
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] La validació lògica ha fallat. S'esperaven >10000 usuaris, s'han trobat $USER_COUNT"
# Activar alerta de PagerDuty / Slack aquí
exit 1
else
echo "[SUCCESS] Validació lògica superada. Recompte d'usuaris: $USER_COUNT"
fi
# 5. Eliminar l'entorn efímer
echo "[INFO] Netejant..."
docker rm -f $CONTAINER_NAME
echo "[INFO] Prova de restauració automatitzada completada amb èxit."
Què hauríeu de validar?
Quan realitzeu proves de restauració automatitzades, no us limiteu a comprovar si la base de dades s’inicia. Executeu consultes de validació específiques de l’aplicació:
1. Recompte de files: Assegureu-vos que les taules principals tinguin el recompte de files esperat (p. ex., la taula users no hauria d’estar buida).
2. Dades recents: Consulteu els registres creats en les últimes 24 hores per assegurar-vos que la còpia de seguretat no estigui obsoleta.
3. Integritat referencial: Executeu scripts per comprovar si hi ha claus externes orfes, que indiquen corrupció lògica.
Monitorització i alertes per a anomalies en les còpies de seguretat
Detectar la corrupció abans que es produeixi el desastre requereix una observabilitat robusta. Més enllà dels estats binaris d’èxit/error, hauríeu de monitoritzar les metadades de les vostres tasques de còpia de seguretat per detectar anomalies.
Monitorització heurística
Integreu les metadades de les vostres còpies de seguretat a Prometheus i visualitzeu-les amb Grafana. Configureu alertes per a les següents heurístiques:
* Caigudes sobtades de mida: Si la vostra còpia de seguretat diària és constantment de 500 GB i la d’avui és de 50 MB, és possible que la tasca s’hagi completat amb èxit (Exit Code 0), però probablement ha fet una còpia de seguretat d’un esquema buit.
* Anomalies de durada: Si una còpia de seguretat que normalment triga 2 hores acaba en 5 minuts, s’ha saltat alguna cosa. Per contra, si triga 10 hores, és possible que tingueu una degradació de l’E/S del disc que podria provocar corrupció.
* Acumulació de registres WAL/Archive: Si la vostra base de dades està generant registres d’escriptura prèvia (WAL) però el sistema de còpia de seguretat no els està arxivant prou ràpid, correu el risc de tenir un buit en la vostra cadena de recuperació puntual (PITR).
Implementació de la regla 3-2-1 amb comprovacions d’integritat
La regla de còpia de seguretat 3-2-1 estàndard del sector (3 còpies de dades, 2 suports diferents, 1 fora de lloc) només és efectiva si totes les còpies estan verificades.
Aquí és on aprofitar una solució empresarial com CloudSave redueix dràsticament la càrrega operativa. En lloc d’escriure i mantenir scripts bash complexos per a cada node de base de dades, CloudSave s’integra directament amb la vostra infraestructura per automatitzar el cicle de vida 3-2-1. Proporciona emmagatzematge immutable —protegint contra el ransomware— i inclou programacions de verificació de restauració automatitzades integrades. CloudSave pot iniciar automàticament entorns sandbox aïllats, muntar la còpia de seguretat, executar els vostres scripts de validació SQL personalitzats i informar de l’estat de salut al vostre tauler central.
Conclusió
Les còpies de seguretat de bases de dades corrompudes són un assassí silenciós que pot destruir empreses. Confiar únicament en el Exit Code 0 d’un script de còpia de seguretat és una aposta perillosa.
Per protegir realment els vostres entorns de producció, heu d’adoptar una estratègia de defensa en profunditat:
1. Habiliteu sumes de verificació a nivell de pàgina dins del vostre motor de base de dades.
2. Utilitzeu eines de verificació natives (pg_verifybackup, RESTORE VERIFYONLY) immediatament després de la creació de la còpia de seguretat.
3. Monitoritzeu les metadades de la còpia de seguretat (mida, durada) per detectar anomalies heurístiques.
4. Implementeu proves de restauració efímeres i automatitzades com a part del vostre pipeline operatiu diari.
En passar d’una mentalitat passiva de «disparar i oblidar» a un model actiu de «validació contínua de la restauració», us assegureu que quan el desastre arribi inevitablement, les vostres dades estiguin preparades, siguin fiables i totalment recuperables.
