Per què les instantànies de VM no són segures per a bases de dades transaccionals: una guia d’un DBA sobre la integritat de les dades

Per als enginyers de DevOps i els administradors de sistemes, les instantànies (snapshots) de màquines virtuals (VM) són una eina fonamental. Proporcionen una manera ràpida i còmoda de capturar l’estat d’un servidor abans d’un pedaç arriscat, un canvi de configuració important o un desplegament d’aplicacions. Si alguna cosa va malament, la restauració triga segons.

Tanmateix, quan aquesta mateixa metodologia s’aplica a bases de dades transaccionals —com PostgreSQL, MySQL, Oracle o Microsoft SQL Server—, les instantànies de VM es transformen d’una xarxa de seguretat en una bomba de rellotgeria.

Confiar en les instantànies estàndard de l’hipervisor per a les còpies de seguretat de bases de dades és una de les causes més comunes de corrupció de dades, pàgines trencades i interrupcions de producció irrecuperables. En aquest article, explorarem el conflicte arquitectònic entre els hipervisors i els motors de bases de dades, la mecànica de la corrupció de dades durant les instantànies i les millors pràctiques d’enginyeria necessàries per fer còpies de seguretat de bases de dades virtualitzades de manera segura.

El conflicte arquitectònic: Hipervisors vs. Motors de bases de dades

Per entendre per què les instantànies de VM posen en perill les bases de dades, primer hem d’examinar com ambdós sistemes gestionen l’estat i les operacions d’E/S.

Com executen les instantànies els hipervisors

Quan un hipervisor (com VMware ESXi, Microsoft Hyper-V o KVM) fa una instantània, no copia el disc. En canvi, congela el fitxer de disc virtual actual (p. ex., .vmdk o .vhdx) en un estat de només lectura i crea un nou disc delta (disc de diferències). Totes les escriptures posteriors es dirigeixen a aquest disc delta.

Quan s’elimina la instantània, l’hipervisor ha de confirmar (consolidar) les dades del disc delta de tornada al disc base. Les instantànies estàndard no són gens conscients de les aplicacions que s’executen dins del sistema operatiu convidat. Capturen l’estat del disc exactament tal com existeix en aquest microsegon.

Com gestionen l’estat les bases de dades transaccionals

Les bases de dades transaccionals estan dissenyades al voltant de les propietats ACID (Atomicitat, Consistència, Aïllament, Durabilitat). Per aconseguir un alt rendiment mantenint el compliment d’ACID, les bases de dades no escriuen cada transacció directament als fitxers de dades primaris del disc immediatament. En canvi, utilitzen una arquitectura complexa de diversos nivells:

1. Buffer Pool / Shared Buffers: Les dades es llegeixen i es modifiquen dins de la memòria del sistema.
2. Write-Ahead Log (WAL) / Redo Logs: Els canvis s’escriuen seqüencialment en un fitxer de registre altament optimitzat al disc per garantir la durabilitat.
3. Checkpoints / Lazy Writers: Periòdicament, la base de dades buida les pàgines modificades (brutes) de la memòria als fitxers de dades reals del disc.

A causa d’aquesta arquitectura, els fitxers de dades físics del disc gairebé sempre estan desincronitzats amb l’estat real de la base de dades. L’estat real de la base de dades només existeix com una combinació dels fitxers de dades del disc, els registres WAL/Redo i les dades que resideixen actualment a la memòria.

La zona de perill: Què passa durant una instantània de VM

Quan feu una instantània de VM estàndard d’un servidor de base de dades, esteu capturant un estat consistent amb bloqueig (crash-consistent).

Consistència de bloqueig vs. Consistència d’aplicació

Una instantània consistent amb bloqueig és l’equivalent a desconnectar el cable d’alimentació del servidor físic. L’estat del disc es captura, però el que hi havia a la memòria es perd, i el que estava a mig camí cap al controlador d’emmagatzematge es talla bruscament.

Tot i que les bases de dades modernes estan dissenyades per recuperar-se d’una pèrdua d’energia inesperada reproduint el Write-Ahead Log, confiar en la recuperació de bloquejos com a estratègia principal de còpia de seguretat és molt perillós. Si la vostra base de dades abasta diversos discos virtuals (p. ex., fitxers de dades a la Unitat D: i WAL a la Unitat E:), és possible que l’hipervisor no faci la instantània d’ambdós discos exactament al mateix microsegon. Si la instantània del disc WAL es captura fins i tot una fracció de segon després de la instantània del disc de dades, la base de dades no pot reconciliar els números de seqüència en restaurar-se, la qual cosa provoca una corrupció fatal.

L’efecte «VM Stun» en sistemes d’alta transacció

El procés de creació d’instantànies —i, el que és més important, el procés de consolidació d’instantànies— provoca un fenomen conegut com «VM Stun» (aturada de la VM).

Per canviar l’E/S de manera segura del disc base al disc delta, l’hipervisor ha de pausar (aturar) breument la màquina virtual. Per a un servidor web amb poca càrrega, aquesta aturada pot durar entre 10 i 50 mil·lisegons i passar desapercebuda. Tanmateix, per a una base de dades d’alt rendiment amb una E/S massiva, consolidar un disc delta gran pot aturar la VM durant diversos segons.

Durant una aturada de VM:
* Les connexions de xarxa cauen, provocant temps d’espera de l’aplicació.
* Els clústers d’alta disponibilitat (com SQL Server Always On, PostgreSQL Patroni o MySQL Galera) perden les comprovacions de batec (heartbeat).
* El clúster pot assumir que el node aturat està mort, provocant una conmutació per error (failover) innecessària i disruptiva (escenari de cervell dividit).

Pàgines trencades i desalineació d’E/S

Els motors de bases de dades solen escriure dades en mides de pàgina específiques (p. ex., 8 KB per a PostgreSQL i SQL Server, 16 KB per a InnoDB). Tanmateix, el sistema operatiu subjacent i les matrius d’emmagatzematge processen l’E/S en blocs més petits (p. ex., 4 KB o 512 bytes).

Si un hipervisor fa una instantània exactament mentre la base de dades està escrivint una pàgina de 8 KB, la instantània podria capturar els primers 4 KB de les dades noves i els últims 4 KB de les dades antigues. Això crea una pàgina trencada (torn page). Quan intenteu restaurar la instantània, la base de dades llegirà la pàgina, fallarà la validació de la suma de comprovació i marcarà la base de dades com a corrupta.

Conseqüències en el món real per a motors de bases de dades específics

Diferents motors de bases de dades reaccionen a les instantànies consistents amb bloqueig de diverses maneres, però cap d’ells ho gestiona correctament en un entorn de producció.

• PostgreSQL: PostgreSQL depèn molt del directori pg_wal. Si una instantània captura el directori de dades ($PGDATA) i el WAL desincronitzats, PostgreSQL no s’iniciarà, llançant un error PANIC: could not locate a valid checkpoint record.
• MySQL/InnoDB: InnoDB utilitza un buffer de doble escriptura (doublewrite buffer) per evitar pàgines trencades, la qual cosa ofereix certa protecció contra estats consistents amb bloqueig. Tanmateix, si el fitxer ibdata1 i el ib_logfile es capturen desincronitzats, el motor InnoDB fallarà en la recuperació.
• Microsoft SQL Server: SQL Server és molt sensible a la congelació d’E/S. Sense una integració adequada de VSS (Volume Shadow Copy Service), restaurar un SQL Server a partir d’una instantània de VM estàndard sovint donarà lloc a bases de dades sospitoses i cadenes de registre trencades, destruint les vostres capacitats de recuperació puntual (PITR).

Millors pràctiques per fer còpies de seguretat de bases de dades virtualitzades de manera segura

Per protegir les bases de dades transaccionals, heu de passar de les còpies de seguretat consistents amb bloqueig a les còpies de seguretat consistents amb l’aplicació. Això requereix que el mecanisme de còpia de seguretat es comuniqui amb el motor de la base de dades, forçant-lo a buidar la memòria al disc i pausar les operacions d’E/S momentàniament mentre es fa la instantània.

1. Aprofiteu la quiescència conscient de l’aplicació (VSS i fsfreeze)

Per a Windows (SQL Server):
Assegureu-vos sempre que la vostra solució de còpia de seguretat utilitzi el Microsoft Volume Shadow Copy Service (VSS). Quan s’activa una còpia de seguretat compatible amb VSS, el VSS Writer de SQL Server congela l’E/S de la base de dades, buida les transaccions pendents al disc i garanteix que la instantània sigui perfectament consistent amb l’aplicació.

Per a Linux (PostgreSQL / MySQL):
Linux no té un equivalent natiu a VSS. Per aconseguir la consistència de l’aplicació, heu d’utilitzar scripts de pre-congelació i post-descongelació juntament amb les eines de convidat de l’hipervisor (p. ex., VMware Tools).

Aquí teniu un exemple d’un pre-freeze-script de VMware per a PostgreSQL 15+ que prepara la base de dades de manera segura per a una instantània:

#!/bin/bash
# /usr/sbin/pre-freeze-script
# Assegureu-vos que aquest script sigui executable (chmod +x)

# 1. Digueu a PostgreSQL que es prepari per a una còpia de seguretat
su - postgres -c "psql -c "SELECT pg_backup_start('vm_snapshot', true);""

# 2. Buideu els buffers del sistema de fitxers al disc
sync

# 3. Congeleu el sistema de fitxers (suposant que les dades estan a /var/lib/pgsql)
fsfreeze -f /var/lib/pgsql

I el post-thaw-script corresponent per reprendre les operacions:

#!/bin/bash
# /usr/sbin/post-thaw-script

# 1. Descongeleu el sistema de fitxers
fsfreeze -u /var/lib/pgsql

# 2. Digueu a PostgreSQL que la còpia de seguretat s'ha completat
su - postgres -c "psql -c "SELECT pg_backup_stop();""

2. Utilitzeu utilitats natives de còpia de seguretat de bases de dades

Tot i que les instantànies consistents amb l’aplicació són millors que les instantànies estàndard, encara comporten el risc d’aturada de la VM. L’enfocament més segur per a les còpies de seguretat de bases de dades és utilitzar utilitats de còpia de seguretat natives i en streaming que funcionin independentment de l’hipervisor.

PostgreSQL (pg_basebackup):

pg_basebackup -h localhost -U replication_user -D /mnt/backups/pg_backup -Ft -z -P

MySQL/MariaDB (Percona XtraBackup / Mariabackup):
Aquestes eines fan còpies de seguretat en calent i sense bloqueig copiant els fitxers de dades i seguint simultàniament els canvis al registre de re-execució (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. Implementeu la recuperació puntual (PITR) mitjançant l’arxiu de registres

Una instantània diària o una còpia de seguretat completa només us protegeix fins al minut en què es va fer. Si la vostra base de dades falla a les 16:00 i la vostra última instantània va ser a les 02:00, perdeu 14 hores de dades transaccionals.

Per aconseguir una autèntica resiliència empresarial, heu de combinar còpies de seguretat completes consistents amb l’aplicació amb l’arxiu continu de registres (fent còpies de seguretat del WAL, Redo Logs o Transaction Logs cada pocs minuts). Això permet als administradors de bases de dades restaurar la base de dades a un minut específic o fins i tot a un ID de transacció específic abans d’un desastre.

Estratègies de còpia de seguretat empresarial amb CloudSave

Gestionar scripts de pre-congelació personalitzats, treballs cron per a bolcats natius i enviament de registres a través de desenes de servidors de bases de dades és un malson operatiu per als equips de DevOps. Aquí és on una plataforma de nivell empresarial com CloudSave esdevé crítica.

CloudSave salva la distància entre la virtualització i l’arquitectura de bases de dades. En lloc de confiar en instantànies cegues de l’hipervisor, CloudSave utilitza agents conscients de l’aplicació que s’integren de manera nativa amb SQL Server, PostgreSQL, MySQL i Oracle.

Quan CloudSave inicia una còpia de seguretat:
1. Es comunica directament amb el motor de la base de dades mitjançant API natives (com VSS per a Windows o streaming WAL natiu per a Linux).
2. Orquestra el buidatge dels buffers de memòria al disc sense causar aturades disruptives de la VM.
3. Captura de manera segura els fitxers de dades i gestiona automàticament el truncament dels registres de transaccions.
4. Fa còpies de seguretat contínues dels registres de transaccions, permetent una recuperació puntual (PITR) granular amb uns pocs clics.

En descarregar la complexitat de la consistència de l’aplicació a CloudSave, els administradors de bases de dades i els administradors de sistemes poden garantir la integritat de les dades sense sacrificar el rendiment o la disponibilitat dels seus clústers de producció.

Conclusió

Les instantànies de màquines virtuals són una eina increïble per a la gestió de la infraestructura, però són fonamentalment incompatibles amb els requisits ACID de les bases de dades transaccionals. Confiar en instantànies d’hipervisor consistents amb bloqueig exposa la vostra organització a pàgines trencades, cadenes de replicació trencades i pèrdua catastròfica de dades.

Per protegir les vostres dades crítiques, heu d’implementar la quiescència conscient de l’aplicació, utilitzar metodologies natives de còpia de seguretat de bases de dades i mantenir arxius continus de registres de transaccions. En adoptar solucions de còpia de seguretat empresarials dissenyades per a aquest propòsit, podeu assegurar-vos que les vostres bases de dades romanguin altament disponibles, totalment recuperables i completament segures.