Windows Server Backup com erro VSS 0x81000101: diagnóstico e correcção

O Windows Server Backup depende do Volume Shadow Copy Service para criar a fotografia consistente dos volumes antes de copiar. Quando a criação dessa shadow copy passa do tempo limite, o backup morre com o erro 0x81000101 — “The creation of a shadow copy has timed out. Try this operation again”. É um dos erros mais comuns em servidores PME com volumes grandes, discos lentos ou serviços de aplicações a responder mal. O caminho é o diagnóstico: confirmar a causa no Event Viewer, medir os writers, corrigir writers parados — incluindo contas de serviço sem permissões, o caso documentado do System Writer em falta —, alargar o tempo limite do SPP e rever os casos menos frequentes: Hyper-V, drivers de terceiros e falta de espaço livre no volume.

O que significa o 0x81000101

O 0x81000101 não é um erro do backup em si — é o erro do mecanismo de shadow copy que o antecede. A mensagem completa devolvida pelo Windows Server Backup é:


The shared restore point operation failed with error (0x81000101) The creation of a shadow copy has timed out. Try this operation again.

No Event Viewer (registo Application), a falha aparece assim, com a mensagem verbatim da documentação Microsoft:


The backup operation that started at '****' has failed because the Volume Shadow Copy Service operation to create a shadow copy of the volumes being backed up failed with following error code '2155348001'. Please review the event details for a solution, and then rerun the backup operation once the issue is resolved.

O par de códigos é a mesma falha contada duas vezes: no Windows, o 0x80780021 aparece nas mensagens do próprio Backup como “Windows Backup timed-out before the shared protection point was created”, e o 0x81000101 é a tradução do Windows Server Backup para “The creation of a shadow copy has timed out. Try this operation again”. O tempo limite documentado da criação do snapshot é de 10 minutos — e em servidores com muito para fotografar (Hyper-V com vários VMs, SQL, AD, volumes de dados volumosos) os 10 minutos esgotam-se frequentemente.

💡 Aviso: sem a shadow copy não há backup consistente. O 0x81000101 nunca indicia má sorte no disco de destino — indica que o servidor não conseguiu entregar, em 10 minutos, um snapshot estável de todos os volumes que o backup abrange.

Etapa 1: confirmar a causa no Event Viewer

Antes de tocar no registo, confirme que a falha é exactamente esta. Abra o Event Viewer e filtre o registo Application por duas fontes: Microsoft-Windows-Backup (Event ID 517) e VSS. O Event 517 traz o código de erro interno — se aparecer o 2155348001, está no caminho certo deste artigo.

Eventos VSS com outros códigos neste momento apontam para outra família de falhas: 0x80042302 (VSS_E_UNEXPECTED — uma falha inesperada de um componente VSS, frequentemente com o sistema de ficheiros danificado), 0x800423F2 (VSS_E_WRITERERROR_TIMEOUT — o timeout de um writer, o clássico é o SQL VSS Writer, mas qualquer writer pode dar), 0x800423F4 (VSS_E_WRITERERROR_NONRETRYABLE — falha de writer que não se resolve ao tentar de novo, em PME é muitas vezes SQL ou Hyper-V), 0x80070005 (permissões). Nesses casos, os passos seguintes ainda ajudam a medir writers, mas a causa primária é outra.

Etapa 2: medir os writers com vssadmin

O comando vssadmin list writers mostra o estado de todos os writers subscritos no sistema. Num prompt elevado:


vssadmin list writers
vssadmin list providers

Saída exemplo documentada pela Microsoft (dois writers saudáveis):


Listing writer status ...
* WRITER System Writer
        - Status: 5 (VSS_WS_WAITING_FOR_BACKUP_COMPLETE)
        - Writer Failure code: 0x00000000 (S_OK)
        - Writer ID: {e8132975-6f93-4464-a53e-1050253ae220}
        - Instance ID: {7e631031-c695-4229-9da1-a7de057e64cb}
* WRITER Shadow Copy Optimization Writer
        - Status: 1 (VSS_WS_STABLE)
        - Writer Failure code: 0x00000000 (S_OK)
        - Writer ID: {4dc3bdd4-ab48-4d07-adb0-3bee2926fd7f}
        - Instance ID: {9e362607-9794-4dd4-a7cd-b3d5de0aad20}
8 writers listed.

O que interessa: cada writer com Failure code: 0x00000000 (S_OK) e estado numérico estável (Stable, Waiting, Waiting for backup complete). Writers com Failed, Timed Out ou estado 7 (VSS_WS_FAILED_AT_PREPARE_BACKUP — o FAILED_AT_FREEZE é o estado 9) são a causa clássica do snapshot não se fechar a tempo — e a lista que o Windows Server Backup tenta fotografar fica incompleta.

Porquê: list writers antes de qualquer correcção — um writer parado trava o ciclo de snapshot inteiro; um writer saudável não. O comando leva segundos e dá a lista exacta do responsável, em vez do palpite “o VSS está doente” que leva a reintroduções cegas.

Etapa 3: corrigir writers parados

O remédio depende do writer que falhou. A documentação Microsoft agrupa as falhas por quem aloja o writer:

  1. Writers alojados no próprio serviço VSS (Registry Writer, COM+ CLASS Registration Database Writer, Shadow Copy Optimization Writer, ASR Writer) — reiniciar o serviço Volume Shadow Copy reinicia o ciclo do writer.
  2. Writers alojados na aplicação (SQL Server VSS Writer, Hyper-V vmms, Exchange, AD DS) — reiniciar o serviço da aplicação correspondente; o writer volta ao estado estável no arranque.
  3. Se o System Writer falta completamente ou o vssadmin list writers não devolve nenhum writer, corrigir permissões e reiniciar o COM+ Event System: a Microsoft documenta o caso com o registo a apontar mal no valor TypeLib de EventCls.dll e os serviços COM+ Event System e Volume Shadow Copy a reiniciar.

Em PME, a classe mais comum de writer problemático é a do próprio serviço de apps (SQL, Hyper-V): um serviço parado ou lento faz o backup inteiro falhar no snapshot, mesmo que o volume em si esteja saudável. Confirmar serviço a serviço antes de ajustar tempos.

Etapa 4: alargar o CreateTimeout (o fix documentado)

Quando writers estão saudáveis e o snapshot ainda não se fecha em 10 minutos, a correção do post da Microsoft é criar o valor de registo CreateTimeout no ramo SPP (HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SPP) e alargá-lo:


# CreateTimeout: alargar o periodo limite de criacao de shadow copy
reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SPP" /v CreateTimeout /t REG_DWORD /d 1200000 /f

O regedit equivalente: navegue até HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SPP, crie um valor DWORD chamado CreateTimeout e defina em decimal o tempo em milissegundos. O valor base é 10 minutos (600000 ms). O post da Microsoft usa 12000000 (200 minutos) — o deslize é do próprio post, e foram leitores nos comentários a apontar que há um zero a mais: o valor correcto é 1200000, que são exactamente 20 minutos (20×60×1000 ms).

Porquê

1200000 — em milissegundos, 20 minutos são exactamente 20×60×1000 = 1.200.000 ms. Depois do regedit (ou reg add), repita o backup. Alguns administradores reiniciam o servidor entre o regedit e o backup — o post da Microsoft não o prescreve, e os comentários mostram casos em que o novo tempo limite não chegou por si só. Em servidores que continuam a atingir o limite com 20 minutos, o problema é de performance na criação do snapshot — disco lento, antivírus a bloquear writers, VMs em arranque — e alargamento adicional do tempo esconde essa causa em vez de a resolver.

Aplicado o registo, repetir a operação de backup. O Windows Server Backup volta a tentar a criação da shadow copy com o tempo novo — e com writers saudáveis o snapshot fecha no primeiro intervalo.

Casos específicos que também produzem o 0x81000101

Três casos documentados pela Microsoft, menos frequentes no terreno mas reais:

  • Hyper-V com CSV ou guests: a documentação do VSS no Hyper-V descreve dois mecanismos de backup de VM — o padrão “Saved State”, em que o VM fica em saved state entre o PrepareForSnapshot e o PostSnapshot, e o “Child VM Snapshot”, em que o VSS corre dentro do guest — e em ambos o tempo de congelar tudo e tirar os snapshots entra no mesmo relógio de 10 minutos do host. A documentação nota ainda que o Hyper-V VSS writer não considera os VMs de um failover cluster. Um VM a arrancar ou a gravar intensivamente durante o snapshot é carga que soma.
  • Dispositivos/filter drivers de terceiros: observação de terreno e de leitores do post da Microsoft, não um caso da documentação oficial: drivers de antivírus ou de ferramentas de disco que interceptam o I/O durante o snapshot acrescentam segundos a mais de milhares de ficheiros que o snapshot tem de coordenar. Se o 0x81000101 aparece há dias num servidor que não mudou de carga, desactive temporariamente o driver de terceiros (e não apenas o antivírus como serviço) e repita.
  • Falta de espaço livre no volume: a área de diferenças (diff area) das shadow copies vive no próprio volume e sem espaço livre o snapshot não se completa — a Microsoft documenta o caso no Data Protection Manager (erro 30116, “VSS has deleted a shadow copy since it has probably run out of disk space”), e no Azure Backup a regra prática são pelo menos 1 GB livres em cada volume incluído no backup (erro 100099). Verificar com vssadmin list shadowstorage e alargar com o comando resize shadowstorage se estiver no limite.

Em qualquer destes casos, o registo CreateTimeout é um atenuador, não a cura — a causa continua activa, apenas com menos probabilidade de atingir o limite.

Artigos relacionados

Fontes oficiais