Para os enxeñeiros de DevOps e administradores de sistemas, as instantáneas (snapshots) de máquinas virtuais (VM) son unha ferramenta fundamental. Ofrecen unha forma rápida e cómoda de capturar o estado dun servidor antes dun parche arriscado, un cambio importante na configuración ou a implementación dunha aplicación. Se algo sae mal, a reversión leva segundos.
Porén, cando esta mesma metodoloxía se aplica a bases de datos transaccionais —como PostgreSQL, MySQL, Oracle ou Microsoft SQL Server—, as instantáneas de VM pasan de ser unha rede de seguridade a unha bomba de reloxería.
Confiar nas instantáneas estándar do hipervisor para as copias de seguridade das bases de datos é unha das causas máis comúns de corrupción de datos, páxinas rotas e interrupcións de produción irrecuperables. Neste artigo, exploraremos o choque arquitectónico entre os hipervisores e os motores de bases de datos, a mecánica da corrupción de datos durante as instantáneas e as mellores prácticas de enxeñaría necesarias para facer copias de seguridade de bases de datos virtualizadas de forma segura.
O choque arquitectónico: Hipervisores vs. Motores de bases de datos
Para entender por que as instantáneas de VM poñen en perigo as bases de datos, debemos examinar primeiro como ambos os sistemas xestionan o estado e as operacións de E/S (entrada/saída).
Como executan as instantáneas os hipervisores
Cando un hipervisor (como VMware ESXi, Microsoft Hyper-V ou KVM) toma unha instantánea, non copia o disco. En cambio, conxela o ficheiro de disco virtual actual (por exemplo, .vmdk ou .vhdx) nun estado de só lectura e crea un novo disco delta (disco de diferenciación). Todas as escrituras posteriores diríxense a este disco delta.
Cando se elimina a instantánea, o hipervisor debe confirmar (consolidar) os datos do disco delta de volta ao disco base. As instantáneas estándar non son conscientes das aplicacións que se executan dentro do sistema operativo convidado. Capturan o estado do disco exactamente como existe nese microsegundo.
Como xestionan o estado as bases de datos transaccionais
As bases de datos transaccionais están deseñadas arredor das propiedades ACID (Atomicidade, Consistencia, Illamento, Durabilidade). Para acadar un alto rendemento mantendo o cumprimento de ACID, as bases de datos non escriben cada transacción directamente nos ficheiros de datos primarios do disco de inmediato. En cambio, utilizan unha arquitectura complexa de varios niveis:
- Buffer Pool / Shared Buffers: Os datos léense e modifícanse na memoria do sistema.
- Write-Ahead Log (WAL) / Redo Logs: Os cambios escríbense secuencialmente nun ficheiro de rexistro altamente optimizado no disco para garantir a durabilidade.
- Checkpoints / Lazy Writers: Periodicamente, a base de datos baleira as páxinas modificadas (sucias) da memoria aos ficheiros de datos reais no disco.
Debido a esta arquitectura, os ficheiros de datos físicos no disco están case sempre desincronizados co estado real da base de datos. O verdadeiro estado da base de datos só existe como unha combinación dos ficheiros de datos no disco, os rexistros WAL/Redo e os datos que residen actualmente na memoria.
A zona de perigo: Que ocorre durante unha instantánea de VM
Cando tomas unha instantánea de VM estándar dun servidor de base de datos, estás capturando un estado de consistencia de fallo (crash-consistent).
Consistencia de fallo vs. Consistencia de aplicación
Unha instantánea de consistencia de fallo é o equivalente a desconectar o cable de alimentación do servidor físico. O estado do disco captúrase, pero o que estaba na memoria pérdese, e o que estaba a medio camiño cara ao controlador de almacenamento córtase abruptamente.
Aínda que as bases de datos modernas están deseñadas para recuperarse dunha perda de enerxía inesperada reproducindo o Write-Ahead Log, confiar na recuperación de fallos como a túa estratexia principal de copia de seguridade é moi perigoso. Se a túa base de datos abarca varios discos virtuais (por exemplo, ficheiros de datos na Unidade D: e WAL na Unidade E:), o hipervisor pode non facer a instantánea de ambos os discos no mesmo microsegundo exacto. Se a instantánea do disco WAL se captura incluso unha fracción de segundo despois da instantánea do disco de datos, a base de datos non pode reconciliar os números de secuencia na restauración, o que resulta nunha corrupción fatal.
O efecto “VM Stun” en sistemas de alta transacción
O proceso de creación da instantánea —e, máis importante, o proceso de consolidación da instantánea— causa un fenómeno coñecido como “VM Stun” (parálise da VM).
Para cambiar a E/S do disco base ao disco delta de forma segura, o hipervisor debe pausar brevemente (paralizar) a máquina virtual. Para un servidor web con pouca carga, esta parálise pode durar entre 10 e 50 milisegundos e pasar desapercibida. Porén, para unha base de datos de alto rendemento con E/S masiva, consolidar un disco delta grande pode paralizar a VM durante varios segundos.
Durante unha parálise da VM:
* As conexións de rede caen, causando tempos de espera na aplicación.
* Os clústeres de alta dispoñibilidade (como SQL Server Always On, PostgreSQL Patroni ou MySQL Galera) perden as comprobacións de estado (heartbeat).
* O clúster pode asumir que o nodo paralizado está morto, provocando unha conmutación por erro (failover) innecesaria e perturbadora (escenario de cerebro dividido).
Páxinas rotas e desalineación de E/S
Os motores de bases de datos normalmente escriben datos en tamaños de páxina específicos (por exemplo, 8 KB para PostgreSQL e SQL Server, 16 KB para InnoDB). Porén, o sistema operativo subxacente e as matrices de almacenamento procesan a E/S en bloques máis pequenos (por exemplo, 4 KB ou 512 bytes).
Se un hipervisor toma unha instantánea exactamente mentres a base de datos está escribindo unha páxina de 8 KB, a instantánea podería capturar os primeiros 4 KB dos novos datos e os últimos 4 KB dos datos antigos. Isto crea unha páxina rota (torn page). Cando intentes restaurar a instantánea, a base de datos lerá a páxina, fallará a validación da suma de comprobación e marcará a base de datos como corrupta.
Consecuencias no mundo real para motores de bases de datos específicos
Diferentes motores de bases de datos reaccionan ás instantáneas de consistencia de fallo de diversas maneiras, pero ningún deles o xestiona correctamente nun ambiente de produción.
- PostgreSQL: PostgreSQL depende moito do directorio
pg_wal. Se unha instantánea captura o directorio de datos ($PGDATA) e o WAL desincronizados, PostgreSQL non poderá iniciarse, lanzando un erroPANIC: could not locate a valid checkpoint record. - MySQL/InnoDB: InnoDB usa un búfer de dobre escritura (doublewrite buffer) para evitar páxinas rotas, o que ofrece certa protección contra estados de consistencia de fallo. Porén, se o ficheiro
ibdata1e oib_logfilese capturan desincronizados, o motor InnoDB fallará na recuperación. - Microsoft SQL Server: SQL Server é moi sensible á conxelación de E/S. Sen unha integración adecuada de VSS (Volume Shadow Copy Service), restaurar un SQL Server a partir dunha instantánea de VM estándar a miúdo resultará en bases de datos sospeitosas e cadeas de rexistros rotas, destruíndo as túas capacidades de recuperación a un punto no tempo (PITR).
Mellores prácticas para facer copias de seguridade de bases de datos virtualizadas de forma segura
Para protexer as bases de datos transaccionais, debes pasar de copias de seguridade de consistencia de fallo a copias de seguridade de consistencia de aplicación. Isto require que o mecanismo de copia de seguridade se comunique co motor da base de datos, obrigándoo a baleirar a memoria ao disco e pausar as operacións de E/S momentaneamente mentres se toma a instantánea.
1. Aproveitar a quiescencia consciente da aplicación (VSS e fsfreeze)
Para Windows (SQL Server):
Asegúrate sempre de que a túa solución de copia de seguridade utilice o Microsoft Volume Shadow Copy Service (VSS). Cando se activa unha copia de seguridade consciente de VSS, o VSS Writer de SQL Server conxela a E/S da base de datos, baleira as transaccións pendentes ao disco e garante que a instantánea sexa perfectamente consistente coa aplicación.
Para Linux (PostgreSQL / MySQL):
Linux non ten un equivalente nativo a VSS. Para acadar a consistencia da aplicación, debes usar scripts de pre-conxelación e post-desconxelación en conxunto coas ferramentas de convidado do hipervisor (por exemplo, VMware Tools).
Aquí tes un exemplo dun pre-freeze-script de VMware para PostgreSQL 15+ que prepara a base de datos de forma segura para unha instantánea:
#!/bin/bash
# /usr/sbin/pre-freeze-script
# Asegúrate de que este script sexa executable (chmod +x)
# 1. Dille a PostgreSQL que se prepare para unha copia de seguridade
su - postgres -c "psql -c "SELECT pg_backup_start('vm_snapshot', true);""
# 2. Baleira os búferes do sistema de ficheiros ao disco
sync
# 3. Conxela o sistema de ficheiros (asumindo que os datos están en /var/lib/pgsql)
fsfreeze -f /var/lib/pgsql
E o correspondente post-thaw-script para retomar as operacións:
#!/bin/bash
# /usr/sbin/post-thaw-script
# 1. Desconxela o sistema de ficheiros
fsfreeze -u /var/lib/pgsql
# 2. Dille a PostgreSQL que a copia de seguridade está completa
su - postgres -c "psql -c "SELECT pg_backup_stop();""
2. Usar utilidades nativas de copia de seguridade de bases de datos
Aínda que as instantáneas de consistencia de aplicación son mellores que as estándar, seguen correndo o risco de parálise da VM. O enfoque máis seguro para as copias de seguridade de bases de datos é usar utilidades de copia de seguridade nativas e en fluxo que operan independentemente do hipervisor.
PostgreSQL (pg_basebackup):
pg_basebackup -h localhost -U replication_user -D /mnt/backups/pg_backup -Ft -z -P
MySQL/MariaDB (Percona XtraBackup / Mariabackup):
Estas ferramentas realizan copias de seguridade en quente e sen bloqueo copiando os ficheiros de datos e rastrexando simultaneamente os cambios no rexistro de re-execución (redo log).
mariabackup --backup --target-dir=/mnt/backups/mysql_backup --user=root --password=SecurePass
SQL Server (T-SQL):
BACKUP DATABASE [ProductionDB]
TO DISK = N'Z:BackupsProductionDB.bak'
WITH NOFORMAT, NOINIT, NAME = N'ProductionDB-Full Backup',
SKIP, NOREWIND, NOUNLOAD, COMPRESSION, STATS = 10;
GO
3. Implementar a recuperación a un punto no tempo (PITR) mediante o arquivado de rexistros
Unha instantánea diaria ou unha copia de seguridade completa só che protexe ata o minuto en que se tomou. Se a túa base de datos falla ás 16:00 e a túa última instantánea foi ás 02:00, perdes 14 horas de datos transaccionais.
Para acadar unha verdadeira resiliencia empresarial, debes combinar copias de seguridade completas de consistencia de aplicación con arquivado continuo de rexistros (facendo copias de seguridade do WAL, Redo Logs ou Transaction Logs cada poucos minutos). Isto permite aos administradores de bases de datos restaurar a base de datos a un minuto específico ou incluso a un ID de transacción específico antes dun desastre.
Estratexias de copia de seguridade empresarial con CloudSave
Xestionar scripts de pre-conxelación personalizados, traballos cron para volcados nativos e envío de rexistros a través de ducias de servidores de bases de datos é un pesadelo operativo para os equipos de DevOps. Aquí é onde unha plataforma de nivel empresarial como CloudSave se volve crítica.
CloudSave pecha a brecha entre a virtualización e a arquitectura de bases de datos. En lugar de confiar en instantáneas cegas do hipervisor, CloudSave utiliza axentes conscientes da aplicación que se integran nativamente con SQL Server, PostgreSQL, MySQL e Oracle.
Cando CloudSave inicia unha copia de seguridade:
1. Comunícase directamente co motor da base de datos a través de APIs nativas (como VSS para Windows ou streaming de WAL nativo para Linux).
2. Orquestra o baleirado dos búferes de memoria ao disco sen causar parálises disruptivas na VM.
3. Captura de forma segura os ficheiros de datos e xestiona automaticamente o truncamento dos rexistros de transaccións.
4. Realiza copias de seguridade continuas dos rexistros de transaccións, permitindo unha recuperación granular a un punto no tempo (PITR) con uns poucos clics.
Ao descargar a complexidade da consistencia da aplicación en CloudSave, os administradores de bases de datos e sistemas poden garantir a integridade dos datos sen sacrificar o rendemento ou a dispoñibilidade dos seus clústeres de produción.
Conclusión
As instantáneas de máquinas virtuais son unha ferramenta incrible para a xestión da infraestrutura, pero son fundamentalmente incompatibles cos requisitos ACID das bases de datos transaccionais. Confiar en instantáneas de hipervisor de consistencia de fallo expón á túa organización a páxinas rotas, cadeas de replicación rotas e perda catastrófica de datos.
Para protexer os teus datos de misión crítica, debes implementar a quiescencia consciente da aplicación, utilizar metodoloxías nativas de copia de seguridade de bases de datos e manter arquivos continuos de rexistros de transaccións. Ao adoptar solucións de copia de seguridade empresariais deseñadas para este fin, podes garantir que as túas bases de datos permanezan altamente dispoñibles, totalmente recuperables e completamente seguras.
