Para engenheiros de DevOps e administradores de sistemas, os snapshots de m\u00e1quinas virtuais (VM) s\u00e3o uma ferramenta fundamental. Eles proporcionam uma forma r\u00e1pida e conveniente de capturar o estado de um servidor antes de uma corre\u00e7\u00e3o arriscada, uma altera\u00e7\u00e3o importante de configura\u00e7\u00e3o ou uma implementa\u00e7\u00e3o de aplica\u00e7\u00e3o. Se algo correr mal, a revers\u00e3o demora segundos.<\/p>\n
No entanto, quando esta mesma metodologia \u00e9 aplicada a bases de dados transacionais \u2014 como PostgreSQL, MySQL, Oracle ou Microsoft SQL Server \u2014 os snapshots de VM transformam-se de uma rede de seguran\u00e7a numa bomba-rel\u00f3gio.<\/p>\n
Confiar em snapshots padr\u00e3o do hipervisor para c\u00f3pias de seguran\u00e7a de bases de dados \u00e9 uma das causas mais comuns de corrup\u00e7\u00e3o de dados, p\u00e1ginas fragmentadas (torn pages) e falhas de produ\u00e7\u00e3o irrecuper\u00e1veis. Neste artigo, exploraremos o conflito arquitet\u00f3nico entre hipervisores e motores de base de dados, a mec\u00e2nica da corrup\u00e7\u00e3o de dados durante os snapshots e as melhores pr\u00e1ticas de engenharia necess\u00e1rias para fazer c\u00f3pias de seguran\u00e7a de bases de dados virtualizadas de forma segura.<\/p>\n
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\u00e7\u00f5es de I\/O.<\/p>\n
Quando um hipervisor (como VMware ESXi, Microsoft Hyper-V ou KVM) tira um snapshot, ele n\u00e3o copia o disco. Em vez disso, congela o ficheiro de disco virtual atual (por exemplo, Quando o snapshot \u00e9 eliminado, o hipervisor deve consolidar os dados do disco delta de volta para o disco base. Os snapshots padr\u00e3o n\u00e3o t\u00eam qualquer conhecimento das aplica\u00e7\u00f5es que correm dentro do sistema operativo convidado. Eles capturam o estado do disco exatamente como ele existe naquele microssegundo.<\/p>\n As bases de dados transacionais s\u00e3o concebidas em torno das propriedades ACID (Atomicidade, Consist\u00eancia, Isolamento, Durabilidade). Para obter um alto desempenho mantendo a conformidade ACID, as bases de dados n\u00e3o escrevem todas as transa\u00e7\u00f5es diretamente nos ficheiros de dados prim\u00e1rios no disco imediatamente. Em vez disso, utilizam uma arquitetura complexa e de v\u00e1rios n\u00edveis:<\/p>\n Devido a esta arquitetura, os ficheiros de dados f\u00edsicos no disco est\u00e3o quase sempre dessincronizados com o estado real da base de dados. O verdadeiro estado da base de dados existe apenas como uma combina\u00e7\u00e3o dos ficheiros de dados no disco, dos registos WAL\/Redo e dos dados que residem atualmente na mem\u00f3ria.<\/p>\n Quando tira um snapshot de VM padr\u00e3o de um servidor de base de dados, est\u00e1 a capturar um estado de consist\u00eancia de falha (crash-consistent)<\/strong>.<\/p>\n Um snapshot com consist\u00eancia de falha \u00e9 o equivalente a desligar o cabo de alimenta\u00e7\u00e3o do servidor f\u00edsico. O estado do disco \u00e9 capturado, mas tudo o que estava na mem\u00f3ria perde-se, e tudo o que estava a caminho do controlador de armazenamento \u00e9 abruptamente cortado.<\/p>\n Embora as bases de dados modernas sejam concebidas para recuperar de perdas de energia inesperadas atrav\u00e9s da reprodu\u00e7\u00e3o do Write-Ahead Log, confiar na recupera\u00e7\u00e3o de falhas como a sua estrat\u00e9gia principal de c\u00f3pia de seguran\u00e7a \u00e9 altamente perigoso. Se a sua base de dados abrange v\u00e1rios discos virtuais (por exemplo, ficheiros de dados na O processo de cria\u00e7\u00e3o de snapshot \u2014 e, mais importante, o processo de consolida\u00e7\u00e3o de snapshot \u2014 causa um fen\u00f3meno conhecido como “VM Stun” (atordoamento da VM).<\/p>\n Para alternar o I\/O do disco base para o disco delta de forma segura, o hipervisor deve pausar brevemente (atordoar) a m\u00e1quina 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\u00e1rios segundos.<\/p>\n Durante um VM stun: Os motores de base de dados normalmente escrevem dados em tamanhos de p\u00e1gina espec\u00edficos (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).<\/p>\n Se um hipervisor tirar um snapshot exatamente enquanto a base de dados est\u00e1 a escrever uma p\u00e1gina de 8KB, o snapshot pode capturar os primeiros 4KB dos novos dados e os \u00faltimos 4KB dos dados antigos. Isto cria uma p\u00e1gina fragmentada (torn page)<\/strong>. Quando tentar restaurar o snapshot, a base de dados ler\u00e1 a p\u00e1gina, falhar\u00e1 a valida\u00e7\u00e3o de soma de verifica\u00e7\u00e3o (checksum) e marcar\u00e1 a base de dados como corrompida.<\/p>\n Diferentes motores de base de dados reagem a snapshots de consist\u00eancia de falha de v\u00e1rias formas, mas nenhum deles lida com isso de forma elegante num ambiente de produ\u00e7\u00e3o.<\/p>\n Para proteger bases de dados transacionais, deve passar de c\u00f3pias de seguran\u00e7a de consist\u00eancia de falha para c\u00f3pias de seguran\u00e7a de consist\u00eancia de aplica\u00e7\u00e3o<\/strong>. Isto exige que o mecanismo de c\u00f3pia de seguran\u00e7a comunique com o motor da base de dados, for\u00e7ando-o a descarregar a mem\u00f3ria para o disco e a pausar as opera\u00e7\u00f5es de I\/O momentaneamente enquanto o snapshot \u00e9 tirado.<\/p>\n Para Windows (SQL Server):<\/strong> Para Linux (PostgreSQL \/ MySQL):<\/strong> Aqui est\u00e1 um exemplo de um E o correspondente Embora os snapshots com consist\u00eancia de aplica\u00e7\u00e3o sejam melhores do que os snapshots padr\u00e3o, eles ainda carregam o risco de VM stun. A abordagem mais segura para c\u00f3pias de seguran\u00e7a de bases de dados \u00e9 utilizar utilit\u00e1rios de c\u00f3pia de seguran\u00e7a nativos e de streaming que operam independentemente do hipervisor.<\/p>\n PostgreSQL (pg_basebackup):<\/strong><\/p>\n MySQL\/MariaDB (Percona XtraBackup \/ Mariabackup):<\/strong> SQL Server (T-SQL):<\/strong><\/p>\n Um snapshot di\u00e1rio ou uma c\u00f3pia de seguran\u00e7a completa apenas o protege at\u00e9 ao minuto em que foi tirado. Se a sua base de dados falhar \u00e0s 16:00 e o seu \u00faltimo snapshot foi \u00e0s 02:00, perde 14 horas de dados transacionais.<\/p>\n Para obter uma verdadeira resili\u00eancia empresarial, deve combinar c\u00f3pias de seguran\u00e7a completas com consist\u00eancia de aplica\u00e7\u00e3o com o arquivamento cont\u00ednuo de registos (fazendo c\u00f3pias de seguran\u00e7a 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\u00edfico ou at\u00e9 mesmo para um ID de transa\u00e7\u00e3o espec\u00edfico antes de um desastre.<\/p>\n Gerir scripts de pr\u00e9-congelamento personalizados, tarefas cron para dumps nativos e envio de registos (log shipping) em dezenas de servidores de base de dados \u00e9 um pesadelo operacional para as equipas de DevOps. \u00c9 aqui que uma plataforma de n\u00edvel empresarial como o CloudSave se torna cr\u00edtica.<\/p>\n O CloudSave preenche a lacuna entre a virtualiza\u00e7\u00e3o e a arquitetura de base de dados. Em vez de confiar em snapshots cegos do hipervisor, o CloudSave utiliza agentes com reconhecimento de aplica\u00e7\u00e3o que se integram nativamente com SQL Server, PostgreSQL, MySQL e Oracle.<\/p>\n Quando o CloudSave inicia uma c\u00f3pia de seguran\u00e7a: Ao descarregar a complexidade da consist\u00eancia de aplica\u00e7\u00e3o 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\u00e7\u00e3o.<\/p>\n Os snapshots de m\u00e1quinas virtuais s\u00e3o uma ferramenta incr\u00edvel para a gest\u00e3o de infraestruturas, mas s\u00e3o fundamentalmente incompat\u00edveis com os requisitos ACID das bases de dados transacionais. Confiar em snapshots de hipervisor com consist\u00eancia de falha exp\u00f5e a sua organiza\u00e7\u00e3o a p\u00e1ginas fragmentadas, cadeias de replica\u00e7\u00e3o quebradas e perda catastr\u00f3fica de dados.<\/p>\n Para proteger os seus dados cr\u00edticos, deve implementar o quiescing com reconhecimento de aplica\u00e7\u00e3o, utilizar metodologias nativas de c\u00f3pia de seguran\u00e7a de base de dados e manter arquivos cont\u00ednuos de registos de transa\u00e7\u00e3o. Ao adotar solu\u00e7\u00f5es de c\u00f3pia de seguran\u00e7a empresariais concebidas para este fim, pode garantir que as suas bases de dados permanecem altamente dispon\u00edveis, totalmente recuper\u00e1veis e completamente seguras.<\/p>\n","protected":false},"excerpt":{"rendered":" > Discover why standard VM snapshots cause data corruption in transactional databases like PostgreSQL and SQL Server. Learn DBA best practices for application-consistent backups, avoiding VM stun, and ensuring data integrity with CloudSave.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"rank_math_title":"Why VM Snapshots Are Unsafe for Transactional Databases","rank_math_description":"> Discover why standard VM snapshots cause data corruption in transactional databases like PostgreSQL and SQL Server. Learn DBA best practices for application-consistent backups, avoiding VM stun, and ensuring data integrity with CloudSave.","rank_math_focus_keyword":"VM snapshots transactional databases","footnotes":""},"categories":[623],"tags":[3444,3788,3789,3790,3791,3792,3793],"class_list":["post-5511","post","type-post","status-publish","format-standard","hentry","category-database-backup","tag-data-integrity","tag-database-corruption","tag-database-recovery","tag-dba-guide","tag-hypervisor-snapshots","tag-transactional-databases","tag-vm-snapshots"],"yoast_head":"\n.vmdk<\/code> ou .vhdx<\/code>) num estado de leitura e cria um novo disco delta (disco de diferencia\u00e7\u00e3o). Todas as escritas subsequentes s\u00e3o direcionadas para este disco delta.<\/p>\nComo as Bases de Dados Transacionais Gerem o Estado<\/h3>\n
\n
A Zona de Perigo: O que Acontece Durante um Snapshot de VM<\/h2>\n
Consist\u00eancia de Falha vs. Consist\u00eancia de Aplica\u00e7\u00e3o<\/h3>\n
Unidade D:<\/code> e WAL na Unidade E:<\/code>), o hipervisor pode n\u00e3o tirar o snapshot de ambos os discos exatamente no mesmo microssegundo. Se o snapshot do disco WAL for capturado apenas uma fra\u00e7\u00e3o de segundo ap\u00f3s o snapshot do disco de dados, a base de dados n\u00e3o conseguir\u00e1 reconciliar os n\u00fameros de sequ\u00eancia durante o restauro, resultando numa corrup\u00e7\u00e3o fatal.<\/p>\nO Efeito “VM Stun” em Sistemas de Alta Transa\u00e7\u00e3o<\/h3>\n
\n* As liga\u00e7\u00f5es de rede caem, causando tempos limite (timeouts) na aplica\u00e7\u00e3o.
\n* Clusters de alta disponibilidade (como SQL Server Always On, PostgreSQL Patroni ou MySQL Galera) falham as verifica\u00e7\u00f5es de heartbeat.
\n* O cluster pode assumir que o n\u00f3 atordoado est\u00e1 morto, desencadeando uma ativa\u00e7\u00e3o p\u00f3s-falha (failover) desnecess\u00e1ria e disruptiva (cen\u00e1rio de split-brain).<\/p>\nP\u00e1ginas Fragmentadas (Torn Pages) e Desalinhamento de I\/O<\/h3>\n
Consequ\u00eancias no Mundo Real para Motores de Base de Dados Espec\u00edficos<\/h2>\n
\n
pg_wal<\/code>. Se um snapshot capturar o diret\u00f3rio de dados ($PGDATA<\/code>) e o WAL dessincronizados, o PostgreSQL n\u00e3o iniciar\u00e1, lan\u00e7ando um erro PANIC: could not locate a valid checkpoint record<\/code>.<\/li>\nibdata1<\/code> e o ib_logfile<\/code> forem capturados dessincronizados, o motor InnoDB falhar\u00e1 durante a recupera\u00e7\u00e3o.<\/li>\nMelhores Pr\u00e1ticas para Fazer C\u00f3pias de Seguran\u00e7a de Bases de Dados Virtualizadas de Forma Segura<\/h2>\n
1. Aproveite o Quiescing com Reconhecimento de Aplica\u00e7\u00e3o (VSS e fsfreeze)<\/h3>\n
\nCertifique-se sempre de que a sua solu\u00e7\u00e3o de c\u00f3pia de seguran\u00e7a utiliza o Microsoft Volume Shadow Copy Service (VSS). Quando uma c\u00f3pia de seguran\u00e7a com reconhecimento de VSS \u00e9 acionada, o VSS Writer do SQL Server congela o I\/O da base de dados, descarrega as transa\u00e7\u00f5es pendentes para o disco e garante que o snapshot seja perfeitamente consistente com a aplica\u00e7\u00e3o.<\/p>\n
\nO Linux n\u00e3o possui um equivalente nativo ao VSS. Para obter consist\u00eancia de aplica\u00e7\u00e3o, deve utilizar scripts de pr\u00e9-congelamento (pre-freeze) e p\u00f3s-descongelamento (post-thaw) em conjunto com as ferramentas de convidado do hipervisor (por exemplo, VMware Tools).<\/p>\npre-freeze-script<\/code> do VMware para PostgreSQL 15+ que prepara a base de dados de forma segura para um snapshot:<\/p>\n#!\/bin\/bash\n# \/usr\/sbin\/pre-freeze-script\n# Certifique-se de que este script \u00e9 execut\u00e1vel (chmod +x)\n\n# 1. Diga ao PostgreSQL para se preparar para uma c\u00f3pia de seguran\u00e7a\nsu - postgres -c \"psql -c \"SELECT pg_backup_start('vm_snapshot', true);\"\"\n\n# 2. Descarregue os buffers do sistema de ficheiros para o disco\nsync\n\n# 3. Congele o sistema de ficheiros (assumindo que os dados est\u00e3o em \/var\/lib\/pgsql)\nfsfreeze -f \/var\/lib\/pgsql\n<\/code><\/pre>\npost-thaw-script<\/code> para retomar as opera\u00e7\u00f5es:<\/p>\n#!\/bin\/bash\n# \/usr\/sbin\/post-thaw-script\n\n# 1. Descongele o sistema de ficheiros\nfsfreeze -u \/var\/lib\/pgsql\n\n# 2. Diga ao PostgreSQL que a c\u00f3pia de seguran\u00e7a est\u00e1 completa\nsu - postgres -c \"psql -c \"SELECT pg_backup_stop();\"\"\n<\/code><\/pre>\n2. Utilize Utilit\u00e1rios Nativos de C\u00f3pia de Seguran\u00e7a de Base de Dados<\/h3>\n
pg_basebackup -h localhost -U replication_user -D \/mnt\/backups\/pg_backup -Ft -z -P\n<\/code><\/pre>\n
\nEstas ferramentas realizam c\u00f3pias de seguran\u00e7a a quente e sem bloqueio, copiando os ficheiros de dados e rastreando simultaneamente as altera\u00e7\u00f5es no redo log.<\/p>\nmariabackup --backup --target-dir=\/mnt\/backups\/mysql_backup --user=root --password=SecurePass\n<\/code><\/pre>\nBACKUP DATABASE [ProductionDB] \nTO DISK = N'Z:BackupsProductionDB.bak' \nWITH NOFORMAT, NOINIT, NAME = N'ProductionDB-Full Backup', \nSKIP, NOREWIND, NOUNLOAD, COMPRESSION, STATS = 10;\nGO\n<\/code><\/pre>\n3. Implemente a Recupera\u00e7\u00e3o para um Ponto no Tempo (PITR) via Arquivamento de Registos<\/h3>\n
Estrat\u00e9gias de C\u00f3pia de Seguran\u00e7a Empresarial com CloudSave<\/h2>\n
\n1. Comunica diretamente com o motor da base de dados atrav\u00e9s de APIs nativas (como VSS para Windows ou streaming de WAL nativo para Linux).
\n2. Orquestra a descarga dos buffers de mem\u00f3ria para o disco sem causar VM stuns disruptivos.
\n3. Captura de forma segura os ficheiros de dados e gere automaticamente o truncamento dos registos de transa\u00e7\u00e3o.
\n4. Faz c\u00f3pias de seguran\u00e7a cont\u00ednuas dos registos de transa\u00e7\u00e3o, permitindo uma Recupera\u00e7\u00e3o para um Ponto no Tempo (PITR) granular com apenas alguns cliques.<\/p>\nConclus\u00e3o<\/h2>\n