O pesadelo do snapshot stun: como a consolidação de discos delta paralisa bancos de dados

O telefone toca às três da manhã. O monitoramento aponta que o banco de dados principal da empresa caiu. Você acessa a VPN, verifica os logs do SQL Server ou do Oracle e encontra uma enxurrada de erros de timeout, conexões derrubadas e transações abortadas. O servidor não reiniciou, a rede física está intacta e o storage não reporta falhas de hardware. O culpado? O seu próprio software de proteção de dados executando a rotina noturna. Você acabou de ser vítima do snapshot stun.

Resumo em 30 segundos

O snapshot stun ocorre quando o hypervisor congela a máquina virtual para mesclar os dados do disco delta de volta ao disco original.

Bancos de dados sofrem timeouts severos devido à interrupção abrupta de I/O durante essa janela de consolidação.

A solução definitiva para ambientes críticos exige a transferência dessa carga de processamento para os snapshots do array de storage físico.

Na minha experiência lidando com desastres de dados, aprendi uma regra fundamental: backup não existe, o que existe é o restore. E se o seu processo de backup causa indisponibilidade no ambiente de produção, você não tem uma estratégia de proteção, você tem uma bomba-relógio agendada via cron. O congelamento de máquinas virtuais durante a consolidação de discos é um dos problemas mais antigos e negligenciados da infraestrutura moderna.

O silêncio aterrorizante das conexões derrubadas na janela de backup

Para entender a gravidade do problema, precisamos olhar para o comportamento das aplicações transacionais. Bancos de dados são criaturas sensíveis à latência. Eles operam sob a premissa de que o subsistema de armazenamento (seja um disco NVMe local ou uma LUN em uma SAN Enterprise) responderá em poucos milissegundos.

Quando o software de backup solicita ao hypervisor a criação de um snapshot para iniciar a cópia dos dados, a máquina virtual sofre uma micro pausa. Até aí, a maioria das aplicações sobrevive. O verdadeiro pesadelo ocorre no final do processo, na fase de consolidação. O hypervisor precisa pegar todas as alterações que ocorreram durante a janela de backup e gravá-las de volta no disco base.

Durante os segundos (ou minutos, em casos graves) em que essa mesclagem final ocorre, o hypervisor suspende completamente as operações de I/O da máquina virtual. O ping continua respondendo, enganando os painéis de monitoramento mais simples, mas a porta do banco de dados fica muda. As aplicações clientes, não recebendo o acknowledgement (ACK) de suas gravações, atingem o limite de timeout e encerram as conexões. O resultado é uma cascata de falhas na camada de aplicação que muitas vezes exige a reinicialização manual dos serviços.

Figura: Diagrama do fluxo de I/O durante a criação e consolidação de um disco delta no hypervisor

A física por trás do congelamento de I/O durante o commit do disco delta

Vamos dissecar a mecânica do desastre. Quando um snapshot de hypervisor é criado (seja um arquivo .vmdk no VMware vSphere ou um .avhdx no Microsoft Hyper-V), o disco virtual original é travado em modo de apenas leitura. Imediatamente, um novo arquivo é criado: o disco delta.

A partir desse milissegundo, todas as novas gravações geradas pelo sistema operacional da máquina virtual são direcionadas para este disco delta. Isso permite que o software de backup leia o disco base de forma consistente, bloco a bloco, sem se preocupar com dados mudando no meio da cópia.

O problema matemático começa aqui. Se o seu backup demora quatro horas para ser concluído e o seu banco de dados possui uma alta taxa de alteração (High Churn Rate), o disco delta crescerá massivamente. Quando o backup termina, o hypervisor precisa realizar o "commit". Ele lê os blocos do disco delta e os reescreve no disco base.

Para garantir que nenhum dado seja corrompido durante os últimos instantes dessa cópia, o hypervisor aplica o "stun". Ele congela a execução da CPU da máquina virtual, limpa a memória em trânsito e finaliza a gravação dos últimos blocos. Quanto maior o disco delta e mais lento for o seu storage físico subjacente, maior será o tempo de stun. Se o seu storage não conseguir processar os IOPS (Input/Output Operations Per Second) necessários para esvaziar o delta rapidamente, sua máquina virtual ficará paralisada tempo suficiente para derrubar o banco de dados.

Por que desativar o quiescence do VSS apenas garante um restore corrompido

Diante do pânico das aplicações caindo de madrugada, muitos administradores de infraestrutura tomam a pior decisão possível. Eles abrem as configurações da rotina de backup e desativam a integração com o VSS (Volume Shadow Copy Service) do Windows ou os scripts de pre-freeze do Linux. Eles desativam o quiescence da aplicação.

⚠️ Perigo: Desativar o VSS (quiescence) para evitar o stun transforma seu backup de banco de dados em um mero peso de papel digital. Você terá um arquivo no disco, mas o restore falhará miseravelmente por corrupção de transações em voo.

O quiescence é o processo de avisar o banco de dados de que um backup vai ocorrer. O VSS instrui o SQL Server a descarregar as transações da memória RAM para o disco e pausar novas gravações por uma fração de segundo. Isso garante um backup "Application-Consistent" (consistente com a aplicação).

Ao desativar isso para tentar diminuir o tempo de stun, você passa a fazer backups "Crash-Consistent". É o equivalente a arrancar o cabo de energia do servidor e copiar o disco. Se você precisar restaurar esse banco de dados amanhã, os logs de transação estarão dessincronizados com os arquivos de dados. O banco entrará em estado de recuperação (Recovery Mode) e, na maioria das vezes, exigirá reparos destrutivos que causam perda de dados. A paranoia é uma virtude na TI: nunca sacrifique a integridade do restore para mascarar um problema de performance no storage.

A engenharia correta utilizando snapshots baseados em array de storage

Se não podemos desativar a consistência e o hypervisor não aguenta a carga da consolidação, qual é a saída? A resposta está em mover o problema para a camada de hardware que foi desenhada especificamente para lidar com blocos de dados: o array de storage físico (SAN ou NAS Enterprise).

A arquitetura moderna de proteção de dados exige a integração direta entre o software de backup, o hypervisor e a controladora do storage. Tecnologias como o VAAI (vStorage APIs for Array Integration) permitem que o hypervisor delegue a criação do snapshot para o hardware físico.

Neste cenário, o fluxo muda drasticamente. O software de backup aciona o VSS na máquina virtual para garantir a consistência. Em vez de criar um disco delta no hypervisor, uma chamada de API é enviada para o storage All-Flash (como um NetApp, Pure Storage ou HPE Alletra). O storage tira um snapshot do volume inteiro em nível de hardware. Como os storages modernos usam metadados e ponteiros (pointers) para gerenciar blocos, a criação e a exclusão do snapshot ocorrem em tempo zero, sem movimentação real de dados.

Figura: Comparativo arquitetural entre processamento de snapshot no hypervisor versus offload para o array de storage

Abaixo, detalho as diferenças críticas entre as duas abordagens:

Característica	Snapshot de Hypervisor (Disco Delta)	Snapshot de Array de Storage (Hardware)
Local de Processamento	CPU e Memória do Host (ESXi/Hyper-V)	Controladora do Storage Físico (SAN/NAS)
Impacto de I/O (Stun)	Alto (Pode durar de segundos a minutos)	Praticamente Nulo (Milissegundos)
Crescimento de Dados	Cria arquivos delta que consomem espaço real	Baseado em ponteiros de metadados (Zero-copy)
Tempo de Consolidação	Depende do tamanho do delta e velocidade do disco	Instantâneo (Apenas descarte de ponteiros)
Risco para Banco de Dados	Crítico (Timeouts e queda de conexões)	Baixo (Transparente para a aplicação)

Ao utilizar snapshots de storage, a máquina virtual é liberada do estado de quiescence em milissegundos. O software de backup então monta o snapshot do hardware em um servidor proxy e extrai os dados com calma, sem afetar a produção. O disco delta do hypervisor nunca chega a crescer, eliminando o pesadelo da consolidação.

Como provar a eliminação da latência de cauda monitorando o hypervisor

Não confie cegamente nas promessas dos fornecedores. Você precisa provar que a mudança de arquitetura resolveu o problema. O snapshot stun é um assassino silencioso porque ele raramente altera a média diária de latência do seu ambiente. Se você olhar para um gráfico de médias de 24 horas, o storage parecerá saudável.

O segredo está em monitorar a latência de cauda (tail latency), especificamente os picos no percentil 99 (p99). Você deve utilizar ferramentas de linha de comando do hypervisor durante a janela de backup. No VMware, a ferramenta esxtop é sua melhor amiga. Pressione a tecla 'v' para visualizar as máquinas virtuais e observe a coluna CSTP (Co-Stop). Valores altos aqui durante o backup indicam que a VM está congelada esperando o agendamento da CPU, frequentemente causado pelo travamento de I/O.

💡 Dica Pro: Monitore a métrica de latência de dispositivo (DAVG no esxtop) e a latência do sistema operacional convidado (KAVG). Durante o commit de um disco delta tradicional, você verá o DAVG saltar de 2ms para absurdos 1000ms ou mais por um breve período. Esse é o exato momento em que seu banco de dados morre.

Figura: Gráfico de monitoramento evidenciando o pico de latência de cauda durante o commit do snapshot

Ao implementar a integração com o array de storage, repita o teste. O gráfico de latência deve permanecer plano durante toda a janela de backup. A eliminação desse pico de latência de cauda é a prova técnica de que seu banco de dados está seguro contra o stun.

O veredito da sobrevivência dos dados

Ignorar o impacto do snapshot stun é aceitar que sua infraestrutura é frágil por design. A proteção de dados não pode ser o gatilho para a indisponibilidade do negócio. Se o seu ambiente roda bancos de dados transacionais pesados, a transição para backups baseados em integração de storage não é um luxo, é um requisito de sobrevivência.

Lembre-se sempre da regra 3-2-1: mantenha três cópias dos seus dados, em duas mídias diferentes, com uma cópia fora do site. Mas adicione um corolário a essa regra: garanta que a extração da primeira cópia não destrua a sua produção. Revise sua arquitetura de storage, valide suas integrações de API e, acima de tudo, teste seus restores. Porque no fim do dia, a única métrica que importa quando o desastre atinge seu datacenter é a sua capacidade de trazer os dados de volta à vida de forma íntegra e rápida.

Referências & leitura complementar

VMware Knowledge Base (KB 1002836): A virtual machine can pause for several seconds when a snapshot is removed. Documentação oficial detalhando a mecânica do stun no vSphere.
SNIA (Storage Networking Industry Association): Dictionary of Storage Networking Terminology. Definições técnicas sobre Copy-on-Write, Redirect-on-Write e Storage Snapshots.
Microsoft Learn: Volume Shadow Copy Service (VSS) Architecture. Guia técnico sobre como os writers do VSS interagem com bancos de dados transacionais.

O que causa o snapshot stun em uma máquina virtual?

Ocorre quando o hypervisor pausa temporariamente a VM para mesclar os dados do disco delta (criado durante o backup) de volta ao disco virtual original, causando um pico severo de latência de I/O.

Por que bancos de dados são mais afetados pelo snapshot stun?

Bancos de dados exigem baixa latência e alta taxa de transações. O congelamento de I/O, mesmo por poucos segundos durante o commit do snapshot, causa timeouts nas conexões e falhas nas transações em andamento.

Snapshots de storage resolvem o problema de stun da VM?

Sim. Ao transferir a carga de criação e consolidação do snapshot do hypervisor para a controladora do storage físico, o impacto na CPU e no I/O da máquina virtual é praticamente eliminado.