Para engenheiros de DevOps e administradores de sistemas, os snapshots de máquinas virtuais (VM) são uma ferramenta fundamental. Eles proporcionam uma forma rápida e conveniente de capturar o estado de um servidor antes de uma correção arriscada, uma alteração importante de configuração ou uma implementação de aplicação. Se algo correr mal, a reversão demora segundos.
No entanto, quando esta mesma metodologia é aplicada a bases de dados transacionais — como PostgreSQL, MySQL, Oracle ou Microsoft SQL Server — os snapshots de VM transformam-se de uma rede de segurança numa bomba-relógio.
Confiar em snapshots padrão do hipervisor para cópias de segurança de bases de dados é uma das causas mais comuns de corrupção de dados, páginas fragmentadas (torn pages) e falhas de produção irrecuperáveis. Neste artigo, exploraremos o conflito arquitetónico entre hipervisores e motores de base de dados, a mecânica da corrupção de dados durante os snapshots e as melhores práticas de engenharia necessárias para fazer cópias de segurança de bases de dados virtualizadas de forma segura.
O Conflito de Arquitetura: Hipervisores vs. Motores de Base de Dados
Para entender por que os snapshots de VM colocam as bases de dados em risco, devemos primeiro examinar como ambos os sistemas gerem o estado e as operações de I/O.
Como os Hipervisores Executam Snapshots
Quando um hipervisor (como VMware ESXi, Microsoft Hyper-V ou KVM) tira um snapshot, ele não copia o disco. Em vez disso, congela o ficheiro de disco virtual atual (por exemplo, .vmdk ou .vhdx) num estado de leitura e cria um novo disco delta (disco de diferenciação). Todas as escritas subsequentes são direcionadas para este disco delta.
Quando o snapshot é eliminado, o hipervisor deve consolidar os dados do disco delta de volta para o disco base. Os snapshots padrão não têm qualquer conhecimento das aplicações que correm dentro do sistema operativo convidado. Eles capturam o estado do disco exatamente como ele existe naquele microssegundo.
Como as Bases de Dados Transacionais Gerem o Estado
As bases de dados transacionais são concebidas em torno das propriedades ACID (Atomicidade, Consistência, Isolamento, Durabilidade). Para obter um alto desempenho mantendo a conformidade ACID, as bases de dados não escrevem todas as transações diretamente nos ficheiros de dados primários no disco imediatamente. Em vez disso, utilizam uma arquitetura complexa e de vários níveis:
- Buffer Pool / Shared Buffers: Os dados são lidos e modificados na memória do sistema.
- Write-Ahead Log (WAL) / Redo Logs: As alterações são escritas sequencialmente num ficheiro de registo altamente otimizado no disco para garantir a durabilidade.
- Checkpoints / Lazy Writers: Periodicamente, a base de dados descarrega as páginas modificadas (sujas) da memória para os ficheiros de dados reais no disco.
Devido a esta arquitetura, os ficheiros de dados físicos no disco estão quase sempre dessincronizados com o estado real da base de dados. O verdadeiro estado da base de dados existe apenas como uma combinação dos ficheiros de dados no disco, dos registos WAL/Redo e dos dados que residem atualmente na memória.
A Zona de Perigo: O que Acontece Durante um Snapshot de VM
Quando tira um snapshot de VM padrão de um servidor de base de dados, está a capturar um estado de consistência de falha (crash-consistent).
Consistência de Falha vs. Consistência de Aplicação
Um snapshot com consistência de falha é o equivalente a desligar o cabo de alimentação do servidor físico. O estado do disco é capturado, mas tudo o que estava na memória perde-se, e tudo o que estava a caminho do controlador de armazenamento é abruptamente cortado.
Embora as bases de dados modernas sejam concebidas para recuperar de perdas de energia inesperadas através da reprodução do Write-Ahead Log, confiar na recuperação de falhas como a sua estratégia principal de cópia de segurança é altamente perigoso. Se a sua base de dados abrange vários discos virtuais (por exemplo, ficheiros de dados na Unidade D: e WAL na Unidade E:), o hipervisor pode não tirar o snapshot de ambos os discos exatamente no mesmo microssegundo. Se o snapshot do disco WAL for capturado apenas uma fração de segundo após o snapshot do disco de dados, a base de dados não conseguirá reconciliar os números de sequência durante o restauro, resultando numa corrupção fatal.
O Efeito “VM Stun” em Sistemas de Alta Transação
O processo de criação de snapshot — e, mais importante, o processo de consolidação de snapshot — causa um fenómeno conhecido como “VM Stun” (atordoamento da VM).
Para alternar o I/O do disco base para o disco delta de forma segura, o hipervisor deve pausar brevemente (atordoar) a máquina virtual. Para um servidor web com pouca carga, este atordoamento pode durar 10-50 milissegundos e passar despercebido. No entanto, para uma base de dados de alto rendimento com I/O massivo, consolidar um grande disco delta pode atordoar a VM durante vários segundos.
Durante um VM stun:
* As ligações de rede caem, causando tempos limite (timeouts) na aplicação.
* Clusters de alta disponibilidade (como SQL Server Always On, PostgreSQL Patroni ou MySQL Galera) falham as verificações de heartbeat.
* O cluster pode assumir que o nó atordoado está morto, desencadeando uma ativação pós-falha (failover) desnecessária e disruptiva (cenário de split-brain).
Páginas Fragmentadas (Torn Pages) e Desalinhamento de I/O
Os motores de base de dados normalmente escrevem dados em tamanhos de página específicos (por exemplo, 8KB para PostgreSQL e SQL Server, 16KB para InnoDB). No entanto, o sistema operativo subjacente e as matrizes de armazenamento processam I/O em blocos menores (por exemplo, 4KB ou 512 bytes).
Se um hipervisor tirar um snapshot exatamente enquanto a base de dados está a escrever uma página de 8KB, o snapshot pode capturar os primeiros 4KB dos novos dados e os últimos 4KB dos dados antigos. Isto cria uma página fragmentada (torn page). Quando tentar restaurar o snapshot, a base de dados lerá a página, falhará a validação de soma de verificação (checksum) e marcará a base de dados como corrompida.
Consequências no Mundo Real para Motores de Base de Dados Específicos
Diferentes motores de base de dados reagem a snapshots de consistência de falha de várias formas, mas nenhum deles lida com isso de forma elegante num ambiente de produção.
- PostgreSQL: O PostgreSQL depende fortemente do diretório
pg_wal. Se um snapshot capturar o diretório de dados ($PGDATA) e o WAL dessincronizados, o PostgreSQL não iniciará, lançando um erroPANIC: could not locate a valid checkpoint record. - MySQL/InnoDB: O InnoDB utiliza um doublewrite buffer para evitar páginas fragmentadas, o que oferece alguma proteção contra estados de consistência de falha. No entanto, se o ficheiro
ibdata1e oib_logfileforem capturados dessincronizados, o motor InnoDB falhará durante a recuperação. - Microsoft SQL Server: O SQL Server é altamente sensível ao congelamento de I/O. Sem a integração adequada com o VSS (Volume Shadow Copy Service), restaurar um SQL Server a partir de um snapshot de VM padrão resultará frequentemente em bases de dados suspeitas e cadeias de registos quebradas, destruindo as suas capacidades de Recuperação para um Ponto no Tempo (PITR).
Melhores Práticas para Fazer Cópias de Segurança de Bases de Dados Virtualizadas de Forma Segura
Para proteger bases de dados transacionais, deve passar de cópias de segurança de consistência de falha para cópias de segurança de consistência de aplicação. Isto exige que o mecanismo de cópia de segurança comunique com o motor da base de dados, forçando-o a descarregar a memória para o disco e a pausar as operações de I/O momentaneamente enquanto o snapshot é tirado.
1. Aproveite o Quiescing com Reconhecimento de Aplicação (VSS e fsfreeze)
Para Windows (SQL Server):
Certifique-se sempre de que a sua solução de cópia de segurança utiliza o Microsoft Volume Shadow Copy Service (VSS). Quando uma cópia de segurança com reconhecimento de VSS é acionada, o VSS Writer do SQL Server congela o I/O da base de dados, descarrega as transações pendentes para o disco e garante que o snapshot seja perfeitamente consistente com a aplicação.
Para Linux (PostgreSQL / MySQL):
O Linux não possui um equivalente nativo ao VSS. Para obter consistência de aplicação, deve utilizar scripts de pré-congelamento (pre-freeze) e pós-descongelamento (post-thaw) em conjunto com as ferramentas de convidado do hipervisor (por exemplo, VMware Tools).
Aqui está um exemplo de um pre-freeze-script do VMware para PostgreSQL 15+ que prepara a base de dados de forma segura para um snapshot:
#!/bin/bash
# /usr/sbin/pre-freeze-script
# Certifique-se de que este script é executável (chmod +x)
# 1. Diga ao PostgreSQL para se preparar para uma cópia de segurança
su - postgres -c "psql -c "SELECT pg_backup_start('vm_snapshot', true);""
# 2. Descarregue os buffers do sistema de ficheiros para o disco
sync
# 3. Congele o sistema de ficheiros (assumindo que os dados estão em /var/lib/pgsql)
fsfreeze -f /var/lib/pgsql
E o correspondente post-thaw-script para retomar as operações:
#!/bin/bash
# /usr/sbin/post-thaw-script
# 1. Descongele o sistema de ficheiros
fsfreeze -u /var/lib/pgsql
# 2. Diga ao PostgreSQL que a cópia de segurança está completa
su - postgres -c "psql -c "SELECT pg_backup_stop();""
2. Utilize Utilitários Nativos de Cópia de Segurança de Base de Dados
Embora os snapshots com consistência de aplicação sejam melhores do que os snapshots padrão, eles ainda carregam o risco de VM stun. A abordagem mais segura para cópias de segurança de bases de dados é utilizar utilitários de cópia de segurança nativos e de streaming que operam 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 realizam cópias de segurança a quente e sem bloqueio, copiando os ficheiros de dados e rastreando simultaneamente as alterações no 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. Implemente a Recuperação para um Ponto no Tempo (PITR) via Arquivamento de Registos
Um snapshot diário ou uma cópia de segurança completa apenas o protege até ao minuto em que foi tirado. Se a sua base de dados falhar às 16:00 e o seu último snapshot foi às 02:00, perde 14 horas de dados transacionais.
Para obter uma verdadeira resiliência empresarial, deve combinar cópias de segurança completas com consistência de aplicação com o arquivamento contínuo de registos (fazendo cópias de segurança do WAL, Redo Logs ou Transaction Logs a cada poucos minutos). Isto permite que os DBAs restaurem a base de dados para um minuto específico ou até mesmo para um ID de transação específico antes de um desastre.
Estratégias de Cópia de Segurança Empresarial com CloudSave
Gerir scripts de pré-congelamento personalizados, tarefas cron para dumps nativos e envio de registos (log shipping) em dezenas de servidores de base de dados é um pesadelo operacional para as equipas de DevOps. É aqui que uma plataforma de nível empresarial como o CloudSave se torna crítica.
O CloudSave preenche a lacuna entre a virtualização e a arquitetura de base de dados. Em vez de confiar em snapshots cegos do hipervisor, o CloudSave utiliza agentes com reconhecimento de aplicação que se integram nativamente com SQL Server, PostgreSQL, MySQL e Oracle.
Quando o CloudSave inicia uma cópia de segurança:
1. Comunica diretamente com o motor da base de dados através de APIs nativas (como VSS para Windows ou streaming de WAL nativo para Linux).
2. Orquestra a descarga dos buffers de memória para o disco sem causar VM stuns disruptivos.
3. Captura de forma segura os ficheiros de dados e gere automaticamente o truncamento dos registos de transação.
4. Faz cópias de segurança contínuas dos registos de transação, permitindo uma Recuperação para um Ponto no Tempo (PITR) granular com apenas alguns cliques.
Ao descarregar a complexidade da consistência de aplicação para o CloudSave, os DBAs e administradores de sistemas podem garantir a integridade dos dados sem sacrificar o desempenho ou a disponibilidade dos seus clusters de produção.
Conclusão
Os snapshots de máquinas virtuais são uma ferramenta incrível para a gestão de infraestruturas, mas são fundamentalmente incompatíveis com os requisitos ACID das bases de dados transacionais. Confiar em snapshots de hipervisor com consistência de falha expõe a sua organização a páginas fragmentadas, cadeias de replicação quebradas e perda catastrófica de dados.
Para proteger os seus dados críticos, deve implementar o quiescing com reconhecimento de aplicação, utilizar metodologias nativas de cópia de segurança de base de dados e manter arquivos contínuos de registos de transação. Ao adotar soluções de cópia de segurança empresariais concebidas para este fim, pode garantir que as suas bases de dados permanecem altamente disponíveis, totalmente recuperáveis e completamente seguras.
