Para engenheiros de DevOps e administradores de sistemas, os snapshots de m\u00e1quinas virtuais (VM) s\u00e3o uma ferramenta fundamental. Eles oferecem uma maneira r\u00e1pida e conveniente de capturar o estado de um servidor antes de um patch arriscado, uma grande mudan\u00e7a de configura\u00e7\u00e3o ou uma implanta\u00e7\u00e3o de aplicativo. Se algo der errado, a revers\u00e3o leva segundos.<\/p>\n
No entanto, quando essa mesma metodologia \u00e9 aplicada a bancos de dados transacionais \u2014 como PostgreSQL, MySQL, Oracle ou Microsoft SQL Server \u2014 os snapshots de VM se transformam de uma rede de seguran\u00e7a em uma bomba-rel\u00f3gio.<\/p>\n
Confiar em snapshots de hipervisor padr\u00e3o para backups de banco de dados \u00e9 uma das causas mais comuns de corrup\u00e7\u00e3o de dados, p\u00e1ginas corrompidas (torn pages) e interrup\u00e7\u00f5es de produ\u00e7\u00e3o irrecuper\u00e1veis. Neste artigo, exploraremos o conflito arquitetural entre hipervisores e mecanismos de banco de dados, a mec\u00e2nica da corrup\u00e7\u00e3o de dados durante snapshots e as melhores pr\u00e1ticas de engenharia necess\u00e1rias para fazer backup de bancos de dados virtualizados com seguran\u00e7a.<\/p>\n
Para entender por que os snapshots de VM colocam os bancos de dados em risco, devemos primeiro examinar como ambos os sistemas gerenciam o estado e as opera\u00e7\u00f5es de E\/S (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, ele congela o arquivo de disco virtual atual (por exemplo, Quando o snapshot \u00e9 exclu\u00eddo, o hipervisor deve confirmar (consolidar) os dados do disco delta de volta para o disco base. Snapshots padr\u00e3o n\u00e3o t\u00eam conhecimento algum dos aplicativos em execu\u00e7\u00e3o dentro do sistema operacional convidado. Eles capturam o estado do disco exatamente como ele existe naquele microssegundo.<\/p>\n Bancos de dados transacionais s\u00e3o projetados em torno das propriedades ACID (Atomicidade, Consist\u00eancia, Isolamento, Durabilidade). Para obter alto desempenho mantendo a conformidade ACID, os bancos de dados n\u00e3o gravam cada transa\u00e7\u00e3o diretamente nos arquivos de dados prim\u00e1rios no disco imediatamente. Em vez disso, eles usam uma arquitetura complexa de v\u00e1rias camadas:<\/p>\n Devido a essa arquitetura, os arquivos de dados f\u00edsicos no disco est\u00e3o quase sempre fora de sincronia com o estado real do banco de dados. O verdadeiro estado do banco de dados existe apenas como uma combina\u00e7\u00e3o dos arquivos de dados no disco, dos logs WAL\/Redo e dos dados que residem atualmente na mem\u00f3ria.<\/p>\n Ao tirar um snapshot de VM padr\u00e3o de um servidor de banco de dados, voc\u00ea est\u00e1 capturando um estado de consist\u00eancia de falha (crash-consistent)<\/strong>.<\/p>\n Um snapshot com consist\u00eancia de falha \u00e9 o equivalente a puxar o cabo de for\u00e7a do servidor f\u00edsico. O estado do disco \u00e9 capturado, mas o que estava na mem\u00f3ria \u00e9 perdido, e o que estava em tr\u00e2nsito para o controlador de armazenamento \u00e9 abruptamente cortado.<\/p>\n Embora os bancos de dados modernos sejam projetados para se recuperar de perda inesperada de energia reproduzindo o Write-Ahead Log, confiar na recupera\u00e7\u00e3o de falhas como sua estrat\u00e9gia principal de backup \u00e9 altamente perigoso. Se o seu banco de dados abranger v\u00e1rios discos virtuais (por exemplo, arquivos 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\u00f4meno conhecido como “VM Stun” (travamento da VM).<\/p>\n Para alternar a E\/S do disco base para o disco delta com seguran\u00e7a, o hipervisor deve pausar brevemente (travar) a m\u00e1quina virtual. Para um servidor web com pouca carga, esse travamento pode durar de 10 a 50 milissegundos e passar despercebido. No entanto, para um banco de dados de alto rendimento com E\/S massiva, consolidar um grande disco delta pode travar a VM por v\u00e1rios segundos.<\/p>\n Durante um VM stun: Os mecanismos de banco de dados normalmente gravam dados em tamanhos de p\u00e1gina espec\u00edficos (por exemplo, 8 KB para PostgreSQL e SQL Server, 16 KB para InnoDB). No entanto, o sistema operacional subjacente e as matrizes de armazenamento processam E\/S em blocos menores (por exemplo, 4 KB ou 512 bytes).<\/p>\n Se um hipervisor tirar um snapshot exatamente enquanto o banco de dados est\u00e1 gravando uma p\u00e1gina de 8 KB, o snapshot pode capturar os primeiros 4 KB dos novos dados e os \u00faltimos 4 KB dos dados antigos. Isso cria uma p\u00e1gina corrompida (torn page)<\/strong>. Quando voc\u00ea tentar restaurar o snapshot, o banco de dados ler\u00e1 a p\u00e1gina, falhar\u00e1 na valida\u00e7\u00e3o da soma de verifica\u00e7\u00e3o (checksum) e marcar\u00e1 o banco de dados como corrompido.<\/p>\n Diferentes mecanismos de banco de dados reagem a snapshots com consist\u00eancia de falha de v\u00e1rias maneiras, mas nenhum deles lida com isso de forma elegante em um ambiente de produ\u00e7\u00e3o.<\/p>\n Para proteger bancos de dados transacionais, voc\u00ea deve migrar de backups com consist\u00eancia de falha para backups com consist\u00eancia de aplicativo<\/strong>. Isso exige que o mecanismo de backup se comunique com o mecanismo de banco de dados, for\u00e7ando-o a liberar a mem\u00f3ria para o disco e pausar as opera\u00e7\u00f5es de E\/S momentaneamente enquanto o snapshot \u00e9 realizado.<\/p>\n Para Windows (SQL Server):<\/strong> Para Linux (PostgreSQL \/ MySQL):<\/strong> Aqui est\u00e1 um exemplo de um E o Embora snapshots com consist\u00eancia de aplicativo sejam melhores que snapshots padr\u00e3o, eles ainda carregam o risco de VM stun. A abordagem mais segura para backups de banco de dados \u00e9 usar utilit\u00e1rios de backup de streaming nativos 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 backup completo protege voc\u00ea apenas at\u00e9 o minuto em que foi realizado. Se o seu banco de dados travar \u00e0s 16:00 e seu \u00faltimo snapshot foi \u00e0s 02:00, voc\u00ea perde 14 horas de dados transacionais.<\/p>\n Para obter verdadeira resili\u00eancia empresarial, voc\u00ea deve combinar backups completos com consist\u00eancia de aplicativo com arquivamento cont\u00ednuo de logs (fazendo backup do WAL, Redo Logs ou Transaction Logs a cada poucos minutos). Isso permite que os DBAs restaurem o banco 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 Gerenciar scripts de pr\u00e9-congelamento personalizados, tarefas cron para dumps nativos e envio de logs em dezenas de servidores de banco de dados \u00e9 um pesadelo operacional para equipes 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 banco de dados. Em vez de confiar em snapshots cegos do hipervisor, o CloudSave utiliza agentes com reconhecimento de aplicativo que se integram nativamente ao SQL Server, PostgreSQL, MySQL e Oracle.<\/p>\n Quando o CloudSave inicia um backup: Ao transferir a complexidade da consist\u00eancia de aplicativo para o CloudSave, DBAs e administradores de sistemas podem garantir a integridade dos dados sem sacrificar o desempenho ou a disponibilidade de seus clusters de produ\u00e7\u00e3o.<\/p>\n Snapshots de m\u00e1quinas virtuais s\u00e3o uma ferramenta incr\u00edvel para o gerenciamento de infraestrutura, mas s\u00e3o fundamentalmente incompat\u00edveis com os requisitos ACID de bancos de dados transacionais. Confiar em snapshots de hipervisor com consist\u00eancia de falha exp\u00f5e sua organiza\u00e7\u00e3o a p\u00e1ginas corrompidas, cadeias de replica\u00e7\u00e3o quebradas e perda catastr\u00f3fica de dados.<\/p>\n Para proteger seus dados de miss\u00e3o cr\u00edtica, voc\u00ea deve implementar o quiescing com reconhecimento de aplicativo, utilizar metodologias de backup de banco de dados nativas e manter arquivos cont\u00ednuos de logs de transa\u00e7\u00e3o. Ao adotar solu\u00e7\u00f5es de backup empresarial criadas para esse fim, voc\u00ea pode garantir que seus bancos de dados permane\u00e7am altamente dispon\u00edveis, totalmente recuper\u00e1veis e completamente seguros.<\/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":[615],"tags":[3440,3782,3783,3784,3785,3786,3787],"class_list":["post-5505","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>) em um estado somente leitura e cria um novo disco delta (disco de diferencia\u00e7\u00e3o). Todas as grava\u00e7\u00f5es subsequentes s\u00e3o direcionadas para esse disco delta.<\/p>\nComo os Bancos de Dados Transacionais Gerenciam 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 Aplicativo<\/h3>\n
Unidade D:<\/code> e WAL na Unidade E:<\/code>), o hipervisor pode n\u00e3o tirar o snapshot de ambos os discos no mesmo microssegundo exato. Se o snapshot do disco WAL for capturado apenas uma fra\u00e7\u00e3o de segundo ap\u00f3s o snapshot do disco de dados, o banco de dados n\u00e3o conseguir\u00e1 reconciliar os n\u00fameros de sequ\u00eancia na restaura\u00e7\u00e3o, resultando em corrup\u00e7\u00e3o fatal.<\/p>\nO Efeito “VM Stun” em Sistemas de Alta Transa\u00e7\u00e3o<\/h3>\n
\n* As conex\u00f5es de rede caem, causando timeouts de aplicativos.
\n* Clusters de alta disponibilidade (como SQL Server Always On, PostgreSQL Patroni ou MySQL Galera) perdem as verifica\u00e7\u00f5es de heartbeat.
\n* O cluster pode assumir que o n\u00f3 travado est\u00e1 morto, acionando um failover desnecess\u00e1rio e disruptivo (cen\u00e1rio de split-brain).<\/p>\nP\u00e1ginas Corrompidas (Torn Pages) e Desalinhamento de E\/S<\/h3>\n
Consequ\u00eancias no Mundo Real para Mecanismos de Banco de Dados Espec\u00edficos<\/h2>\n
\n
pg_wal<\/code>. Se um snapshot capturar o diret\u00f3rio de dados ($PGDATA<\/code>) e o WAL fora de sincronia, o PostgreSQL falhar\u00e1 ao iniciar, exibindo um erro PANIC: could not locate a valid checkpoint record<\/code>.<\/li>\nibdata1<\/code> e o ib_logfile<\/code> forem capturados fora de sincronia, o mecanismo InnoDB travar\u00e1 na recupera\u00e7\u00e3o.<\/li>\nMelhores Pr\u00e1ticas para Fazer Backup de Bancos de Dados Virtualizados com Seguran\u00e7a<\/h2>\n
1. Aproveite o Quiescing com Reconhecimento de Aplicativo (VSS e fsfreeze)<\/h3>\n
\nSempre garanta que sua solu\u00e7\u00e3o de backup utilize o Microsoft Volume Shadow Copy Service (VSS). Quando um backup com reconhecimento de VSS \u00e9 acionado, o VSS Writer do SQL Server congela a E\/S do banco de dados, libera transa\u00e7\u00f5es pendentes para o disco e garante que o snapshot seja perfeitamente consistente com o aplicativo.<\/p>\n
\nO Linux n\u00e3o possui um equivalente nativo ao VSS. Para obter consist\u00eancia de aplicativo, voc\u00ea deve usar 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 o banco de dados com seguran\u00e7a para um snapshot:<\/p>\n#!\/bin\/bash\n# \/usr\/sbin\/pre-freeze-script\n# Certifique-se de que este script seja execut\u00e1vel (chmod +x)\n\n# 1. Diga ao PostgreSQL para se preparar para um backup\nsu - postgres -c \"psql -c \"SELECT pg_backup_start('vm_snapshot', true);\"\"\n\n# 2. Libere os buffers do sistema de arquivos para o disco\nsync\n\n# 3. Congele o sistema de arquivos (assumindo que os dados est\u00e3o em \/var\/lib\/pgsql)\nfsfreeze -f \/var\/lib\/pgsql\n<\/code><\/pre>\npost-thaw-script<\/code> correspondente para retomar as opera\u00e7\u00f5es:<\/p>\n#!\/bin\/bash\n# \/usr\/sbin\/post-thaw-script\n\n# 1. Descongele o sistema de arquivos\nfsfreeze -u \/var\/lib\/pgsql\n\n# 2. Diga ao PostgreSQL que o backup foi conclu\u00eddo\nsu - postgres -c \"psql -c \"SELECT pg_backup_stop();\"\"\n<\/code><\/pre>\n2. Use Utilit\u00e1rios de Backup Nativos do Banco de Dados<\/h3>\n
pg_basebackup -h localhost -U replication_user -D \/mnt\/backups\/pg_backup -Ft -z -P\n<\/code><\/pre>\n
\nEssas ferramentas realizam backups a quente (hot backups), sem bloqueio, copiando os arquivos 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 Log<\/h3>\n
Estrat\u00e9gias de Backup Empresarial com CloudSave<\/h2>\n
\n1. Ele se comunica diretamente com o mecanismo de banco de dados via APIs nativas (como VSS para Windows ou streaming de WAL nativo para Linux).
\n2. Ele orquestra a libera\u00e7\u00e3o dos buffers de mem\u00f3ria para o disco sem causar travamentos disruptivos na VM.
\n3. Ele captura com seguran\u00e7a os arquivos de dados e gerencia automaticamente o truncamento dos logs de transa\u00e7\u00e3o.
\n4. Ele faz backup cont\u00ednuo dos logs de transa\u00e7\u00e3o, permitindo a Recupera\u00e7\u00e3o para um Ponto no Tempo (PITR) granular com poucos cliques.<\/p>\nConclus\u00e3o<\/h2>\n